Fron developer publish this: 09/09/2005 Stable fcron 3.0.0 is out ! Quite a lot has changed since the 2.0.x branch: * Added the program fcrondyn to interact with a running fcron process * PAM support * SE Linux support * Options and command line parameters to execute fcron in a script * Ability to run fcron without root priveleges * Ported to AIX, HP-UX * Better time zone support * fcron is more secure and robust. I strongly recommend that people who would still use fcron branch 2.0.x upgrade to fcron 3.0.0. By ChangeLog fcron v3.0.0 add as 12 Sep 2005. When its set stable ?
Please, don't restrict bugs without any reason. Just leave the checkboxes alone.
okey.
3.0.1-r2 working fine for me on several boxes since 07/2006. Arch teams, please test and mark stable if testing is successful. Also, it could be a good idea to check upgrading from 2.0 to 3.0 (I never ran 2.0 myself, just started using fcron from 3.0). Thanks!
Whoops, forgot to click the "Add Archs" button ;) @Arch teams: please see previous comment, thanks!
First Post!!!!!!onethousandonehundredandeleven!!!
Oh and we're stable too :-P
stable on ppc!!!111cos(0)!!!! (can't let sparc have *all* the fun...)
In x86: Compiles and works fine. Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.12.5 Last Sync: Thu, 28 Sep 2006 21:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ " LINGUAS="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise" SYNC="rsync://rsync.belnet.be/packages/gentoo-portage" USE="x86 X bitmap-fonts bzip2 cairo cdr cli crypt dbus dlloader dri dvd dvdr eds elibc_glibc emboss encode fam firefox fortran gif gpm gstreamer gtk hal input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kernel_linux ldap libg++ mad mikmod mp3 mpeg ncurses nptl nptlonly ogg opengl pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_vesa vorbis win32codecs xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
i'm using fcron-3.0.1-r2 USE="pam -debug -doc (-selinux)" on my stable x86 system for quite some time and it works like a charm.
> Arch teams, please test and mark stable if testing is successful. > Also, it could be a good idea to check upgrading from 2.0 to 3.0 It's fine but need regenerate all crontab. Binary crontab file fron 2.0 not compatible with fcron 3.0.
(In reply to comment #10) > > Arch teams, please test and mark stable if testing is successful. > > Also, it could be a good idea to check upgrading from 2.0 to 3.0 > > It's fine but need regenerate all crontab. Binary crontab file fron 2.0 not > compatible with fcron 3.0. Does it spit out a warning, or do the old crontabs just not work?! In any case, I think I need to add at least some ewarn foo to the ebuilds. Or should I try to automagically regenerate with "fcrontab -z"?! Comments, please.
> > Does it spit out a warning, or do the old crontabs just not work?! > In any case, I think I need to add at least some ewarn foo to the ebuilds. > Or should I try to automagically regenerate with "fcrontab -z"?! > Comments, please. > You can regenerate with fcrontab -z only for one user. If you run this at root it regerate crontab for user root or for selected user. I'm think need ewarn about this issue.
>>> Install fcron-3.0.1-r2 into /var/tmp/portage/fcron-3.0.1-r2/image/ category sys-process install: Ung
>>> Install fcron-3.0.1-r2 into /var/tmp/portage/fcron-3.0.1-r2/image/ category sys-process install: Ungültiger Anwender ,,cron" touch: kann ,,/var/tmp/portage/fcron-3.0.1-r2/image///var/spool/cron/fcrontabs/.keep_sys-process_fcron-0" nicht berühren: Datei oder Verzeichnis nicht gefunden You might want to add a check if the "cron" user exists.
And another one, without app-editor/vim installed to provide /usr/bin/vim but with EDITOR=/usr/bin/vim: checking editor... configure: error: File /usr/bin/vim is not an executable file !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/fcron-3.0.1-r2/work/fcron-3.0.1/config.log !!! ERROR: sys-process/fcron-3.0.1-r2 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile fcron-3.0.1-r2.ebuild, line 66: Called econf '--with-pam' '--without-selinux' '--without-debug' '--with-username=cron' '--with-groupname=cron' '--with-piddir=/var/run' '--with-etcdir=/etc/fcron' '--with-spooldir=/var/spool/cron' '--with-fifodir=/var/run' '--with-sendmail=/usr/sbin/sendmail' '--with-fcrondyn=yes' '--with-editor=/usr/bin/vim' '--with-shell=/bin/sh' '--with-dsssl-dir=/usr/share/sgml/stylesheets/dsssl/docbook' '--with-rootname=root' '--with-rootgroup=root' ebuild.sh, line 540: Called die !!! econf failed !!! If you need support, post the topmost build error, and the call stack if relevant. Build systems should NEVER depend on private env vars like these. Since fcron must use one, it should use the value from /etc/rc.conf (which will most often make it the system target's default, nano), not from the env.
Seems like this patch fixes the entire EDITOR problem: Index: fcron-3.0.1-r2.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/sys-process/fcron/fcron-3.0.1-r2.ebuild,v retrieving revision 1.3 diff -u -B -r1.3 fcron-3.0.1-r2.ebuild --- fcron-3.0.1-r2.ebuild 29 Sep 2006 19:19:03 -0000 1.3 +++ fcron-3.0.1-r2.ebuild 1 Oct 2006 17:40:06 -0000 @@ -74,7 +74,6 @@ --with-fifodir=/var/run \ --with-sendmail=/usr/sbin/sendmail \ --with-fcrondyn=yes \ - --with-editor=${EDITOR} \ --with-shell=/bin/sh \ ${myconf} \ || die "Configure problem"
(In reply to comment #15) > Seems like this patch fixes the entire EDITOR problem: > > Index: fcron-3.0.1-r2.ebuild > =================================================================== > RCS file: /var/cvsroot/gentoo-x86/sys-process/fcron/fcron-3.0.1-r2.ebuild,v > retrieving revision 1.3 > diff -u -B -r1.3 fcron-3.0.1-r2.ebuild > --- fcron-3.0.1-r2.ebuild 29 Sep 2006 19:19:03 -0000 1.3 > +++ fcron-3.0.1-r2.ebuild 1 Oct 2006 17:40:06 -0000 > @@ -74,7 +74,6 @@ > --with-fifodir=/var/run \ > --with-sendmail=/usr/sbin/sendmail \ > --with-fcrondyn=yes \ > - --with-editor=${EDITOR} \ > --with-shell=/bin/sh \ > ${myconf} \ > || die "Configure problem" > It's not work see bug #65263. This patch work. Get EDITOR from rc.conf --- fcron-3.0.1-r2.ebuild 2006-09-30 01:36:20.000000000 +0600 +++ fcron-3.0.1-r3.ebuild 2006-10-06 14:15:13.054234157 +0600 @@ -18,23 +18,7 @@ pam? ( >=sys-libs/pam-0.77 )" pkg_setup() { - # sudo unsets EDITOR - if [[ -z "${EDITOR}" ]] ; then - eerror "EDITOR seems to be unset. If you use sudo, it may be the cause." - eerror "Try using 'sudo env EDITOR=\${EDITOR} emerge' instead." - die "Please set the EDITOR env variable to the path of a valid executable." - fi - - # bug #65263 - # fcron's ./configure complains if EDITOR is not set to an absolute path, - # so try to set it to the abs path if it isn't - if [[ "${EDITOR}" != */* ]] ; then - einfo "Attempting to deduce absolute path of ${EDITOR}" - EDITOR=$(which ${EDITOR} 2>/dev/null) - [[ -x "${EDITOR}" ]] || \ - die "Please set the EDITOR env variable to the path of a valid executable." - fi - + EDITOR=`awk -F\" '/^EDITOR=/{print $2}' /etc/rc.conf` ROOTUSER=$(egetent passwd 0 | cut -d':' -f1) ROOTGROUP=$(egetent group 0 | cut -d':' -f1) } Test it. If it work this can move to stable ? ;)
(In reply to comment #16) > It's not work see bug #65263. This patch work. Get EDITOR from rc.conf I don't see what that bug has to do with the problem of the ebuild picking up vars from the environment. Removing the configure option fixes the problem for me on several systems. In that case, with EDITOR unset in the environment, the packages configures, builds and merges fine. We could remove all the cruft that makes the ebuild depend on the environment, including the warnings, and then *not* specify --with-editor=${EDITOR} to be rid of the entire problem, which only arrises because the ebuild is doing something it should never do, namely to rely on the environment. With the --with-editor option left out, the build system formally defaults to /usr/bin/vi, which is completely inconsequential at build time or run time, using any $EDITOR you can think of afterward to run crontab. Again, the ebuild should never rely on env vars, including those in rc.conf. And indeed, I won't mark it stable until this has been properly fixed. Also note dertobi123's comment #13, which points out another problem with the ebuild.
(In reply to comment #17) > We could remove all the cruft that makes the ebuild depend on the environment, > including the warnings, and then *not* specify --with-editor=${EDITOR} to be > rid of the entire problem, which only arrises because the ebuild is doing > something it should never do, namely to rely on the environment. With the > --with-editor option left out, the build system formally defaults to > /usr/bin/vi, which is completely inconsequential at build time or run time, > using any $EDITOR you can think of afterward to run crontab. Yes. But if i'm not install vi in system ? And if $EDITOR not set ? And i'm run crontab ? I'm get error. I'm think if you remove option --with-editor need add ewarn about editor issue. > Again, the ebuild should never rely on env vars, including those in rc.conf. > And indeed, I won't mark it stable until this has been properly fixed. Also > note dertobi123's comment #13, which points out another problem with the > ebuild. Ок. I'm check it.
(In reply to comment #18) > Yes. But if i'm not install vi in system ? And if $EDITOR not set ? And i'm run > crontab ? I'm get error. I'm think if you remove option --with-editor need add > ewarn about editor issue. As I said, fcron's build system does not care if you have an EDITOR variable set in your environment, and in fact it shouldn't care. The ebuild does not fail if you remove that configure option, only if you set it to a path to a file that does not exist. The ebuild cares and does so falsely, and the ebuild fails. # unset EDITOR # echo $EDITOR # crontab -e <-- launches vim on my system, perhaps because of rc.conf, but that is decided at runtime not at build time. If you use anything other than fcron's default of /usr/bin/vi, you should probably set the EDITOR variable. There is something to say about using the value in rc.conf, but in general it would be better to default to /bin/nano as that is Gentoo Linux's default editor, so set that with --with-editor=/bin/nano as configure option and be done with it... vim or emacs users will know to edit rc.conf or .bashrc appropriately anyway. (Removing arches to stop the bug spam for them)
> As I said, fcron's build system does not care if you have an EDITOR variable > set in your environment, and in fact it shouldn't care. The ebuild does not > fail if you remove that configure option, only if you set it to a path to a > file that does not exist. The ebuild cares and does so falsely, and the ebuild > fails. > > # unset EDITOR > # echo $EDITOR > > # crontab -e <-- launches vim on my system, perhaps because of > rc.conf, but that is decided at runtime not at > build time. > > If you use anything other than fcron's default of /usr/bin/vi, you should > probably set the EDITOR variable. There is something to say about using the > value in rc.conf, but in general it would be better to default to /bin/nano as > that is Gentoo Linux's default editor, so set that with --with-editor=/bin/nano > as configure option and be done with it... vim or emacs users will know to edit > rc.conf or .bashrc appropriately anyway. > > (Removing arches to stop the bug spam for them) > Hmm. Okey. Set --with-editor=/bin/nano or remove --with-editor? If set --with-editor=/bin/nano shuld change DEPEND from virtual/editor ? Or simple get from rc.conf env EDITOR and print warning ?
(In reply to comment #13) > >>> Install fcron-3.0.1-r2 into /var/tmp/portage/fcron-3.0.1-r2/image/ category sys-process > install: Ung
(In reply to comment #13) > >>> Install fcron-3.0.1-r2 into /var/tmp/portage/fcron-3.0.1-r2/image/ category sys-process > install: Ungültiger Anwender ,,cron" > touch: kann > ,,/var/tmp/portage/fcron-3.0.1-r2/image///var/spool/cron/fcrontabs/.keep_sys-process_fcron-0" > nicht berühren: Datei oder Verzeichnis nicht gefunden > > > You might want to add a check if the "cron" user exists. Hmm, I thought cronbase would handle that, but it seems that it only does this since 0.3.2 :-( Since 0.3.2 is stable on any arch except x86-fbsd, I will update cron.eclass to depend on >=sys-process/cronbase-0.3.2 rather than >=sys-process/cronbase-0.2.1-r3. Any objections?
(In reply to comment #20) > Hmm. Okey. Set --with-editor=/bin/nano or remove --with-editor? If set > --with-editor=/bin/nano shuld change DEPEND from virtual/editor ? Or simple get > from rc.conf env EDITOR and print warning ? app-editors/nano is the default editor (system target) for Gentoo Linux so the dependency on virtual/editor is redundant I should think. Also, BSD's vi is probably the default editor for x86-fbsd, which could be a problem there, so maybe it should default to /bin/nano unless otherwise specified (for x86-fbsd for example). (CC'ing bsd@)
> app-editors/nano is the default editor (system target) for Gentoo Linux so the > dependency on virtual/editor is redundant I should think. Also, BSD's vi is > probably the default editor for x86-fbsd, which could be a problem there, so > maybe it should default to /bin/nano unless otherwise specified (for x86-fbsd > for example). Hmm... We can get list all editors provide virtual/editor from ebuild? If can may get nano if exist or vi.
(In reply to comment #21) > (In reply to comment #13) > > [...] > > You might want to add a check if the "cron" user exists. > > Hmm, I thought cronbase would handle that, but it seems that > it only does this since 0.3.2 :-( > Since 0.3.2 is stable on any arch except x86-fbsd, I will update > cron.eclass to depend on >=sys-process/cronbase-0.3.2 rather > than >=sys-process/cronbase-0.2.1-r3. > Any objections? No objections so far -- will change cron.eclass now.
cron.eclass updated to depend on >=sys-process/cronbase-0.3.2. Tobias, please retry merging =sys-process/fcron-3.0.1-r2 with the new cron.eclass. Still no 100% sane solution for the EDITOR problem.
Guys. What do you think about following simple solution: - Install in the cronbase ebuild fake-editor executable into /bin: #!/bin/sh echo '>>> Please, set EDITOR variable.' - Force all sys-process/cron* to use this executable as editor. Thus if user does not have EDITOR variable set he'll see 'Please, set EDITOR' message. This will fix build time problems and clearly states that all crontabs should take EDITOR variable at runtime. I've checked sys-process/{bcron,fcron,dcron,vixie-cron} and seems that all of them can use this solution (ether suppling --with-editor to configure or modifing PATH_VI variable in sources or in similar way). The anacron do not use EDITOR neither at build time nor at runtime and is not affected by this change. The same solution could be applied to sudo. Just modify configure.in not to check for executable but rather export EDITOR=/bin/fake-editor and then install fake-editor with sudo. What do you think about such solution? If it looks OK I can incarnate it :) Another possible enhancement for this solution will be to create eselect-module that will configure wrapper to use this or that editor instead of echoing error message but personally I do not think that this is required.
(In reply to comment #26) > Guys. What do you think about following simple solution: > > - Install in the cronbase ebuild fake-editor executable into /bin: > > #!/bin/sh > echo '>>> Please, set EDITOR variable.' > > - Force all sys-process/cron* to use this executable as editor. > > Thus if user does not have EDITOR variable set he'll see 'Please, set EDITOR' > message. This will fix build time problems and clearly states that all crontabs > should take EDITOR variable at runtime. I've checked > sys-process/{bcron,fcron,dcron,vixie-cron} and seems that all of them can use > this solution (ether suppling --with-editor to configure or modifing PATH_VI > variable in sources or in similar way). The anacron do not use EDITOR neither > at build time nor at runtime and is not affected by this change. I'm thinking about this. But may create editor-config? If we provide virtual-editor may provide link virtual-editor and tools for manage this? This create for java packages, MTA packages and etc. > Another possible enhancement for this solution will be to create eselect-module > that will configure wrapper to use this or that editor instead of echoing error > message but personally I do not think that this is required. I'm think this required. This should required for all virtual package. It's can resolve many many problem with analog problems.
ugh, what a horrible idea editor-config is nothing but over engineering for a non-existent problem EDITOR should really be a runtime variable only
(In reply to comment #28) > ugh, what a horrible idea > > editor-config is nothing but over engineering for a non-existent problem > > EDITOR should really be a runtime variable only > hmmm. We can use this simple script as virtual-editor virtual-editor #!/bin/sh if [ -n "$EDITOR" ]; then exec $EDITOR $*; else echo ">>> Please, set EDITOR variable."; fi It simple and should work. And may install as part virtual-editor.ebuild
no, that should never be in portage ... there is also no "virtual-editor" ebuild
(In reply to comment #30) > no, that should never be in portage ... there is also no "virtual-editor" > ebuild > Okay. How you resolve this problem? If install this script as part cronbase we can got broken sudo. If install as part sudo we can got broken fcron.
I've thought about this whole yesterday and I'd like to modify my previous proposal. But before that I'll restate the problem: There are programs (fcrontab, visudo, vipw and etc.) which require some default editor to work. To select editor they use the two methods: 1.) take editor name from environment (EDITOR or VISUAL vars) 2.) from defined at build time compiled in defaults The problem is that both of methods suck in some special situations which, of course, happen in extreme configurability Gentoo provides. Currently build time dependency impossible to specify reliably for virtual/editor (most of packages either use nano or vi). While we should use compiled in defaults because environment variables are dropped and thus does not work in sudo (are there any other cases when environment is dropped?). Other distributions does not have such problem as they use vi as sane default and always provide vi and upstream use compiled in defaults exactly for situations when EDITOR is not specified but currently this part is not reliable or just broken in Gentoo. So modified proposal is: 1. We should create virtual/editor ebuild which will install /bin/editor. As a side effect this will port virtual/editor to glep 37. 2. /usr/bin/editor should use user defined EDITOR if exist (from environment). If there is no EDITOR in environment it should source /etc/profile and take system wide EDITOR (solves bug #94771). If all failed print error message. 3. All programs that use compiled in default editor should use /usr/bin/editor vapier: But could you point on drawbacks of this solution instead of dropping it? Thank you.
> So modified proposal is: > > 1. We should create virtual/editor ebuild which will install /bin/editor. As a > side effect this will port virtual/editor to glep 37. > > 2. /usr/bin/editor should use user defined EDITOR if exist (from environment). > If there is no EDITOR in environment it should source /etc/profile and take > system wide EDITOR (solves bug #94771). If all failed print error message. > > 3. All programs that use compiled in default editor should use /usr/bin/editor > Yep. It's fine. > vapier: But could you point on drawbacks of this solution instead of dropping > it? Thank you. I'm it's not simple for simple things as editor. ;)
again, over engineering here's a better idea: tell the user to set EDITOR properly -> no more problem
(In reply to comment #34) > here's a better idea: tell the user to set EDITOR properly -> no more problem no. 1. this does not fix bug #94771 2. upstream suppose us to have working, defined at build time editor (or why should we report upstream this build time dependency as a bug and force them to simplify their code?) I've tried to do my best and summarize everything in mail I've just sent to -dev.
(In reply to comment #34) > again, over engineering > > here's a better idea: tell the user to set EDITOR properly -> no more problem > Bad idea. It's not automatic. We need more automatic. Or we need delete mail-wrapper, eselect, java-config and other automatic tools and tell user set manualy MTA, opengl, java and many others things.
you're not comparing equivalent things ... your examples do more than simply set an environment variable the discussion have moved to the gentoo-dev mailing list, stop following up here
Created attachment 104073 [details, diff] patch remove editor checking from configure
Created attachment 104074 [details] new fcron ebuild With fix editor problem similar as sudo ebuild
Damn. I'm busy and forgot about this. Check attach patch & ebuild.
It's going in stable or not?
I'm sick of this. =sys-process/fcron-3.0.1-r2 now depends on app-editors/nano. Comment on bug #124904 if you're unhappy with it. @x86,amd64,mips,hppa: please re-test. Thanks!
amd64 stable
1) emerges ok 2) passes collision test 3) works Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.19-suspend2-r1 i686) ================================================================= System uname: 2.6.19-suspend2-r1 i686 Intel(R) Pentium(R) M processor 1600MHz Gentoo Base System version 1.12.6 Last Sync: Thu, 18 Jan 2007 00:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -Os -pipe -ggdb3" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=pentium-m -Os -pipe -ggdb3" DISTDIR="/opt/distfiles" FEATURES="autoconfig buildpkg ccache collision-protect distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms splitdebug strict test userfetch" GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo" LANG="en_GB.utf8" LINGUAS="da en en_GB" MAKEOPTS="-j2" PKGDIR="/opt/packages" PORTAGE_RSYNC_EXTRA_OPTS="--timeout=60" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/paludis/repositories/gentoo" PORTDIR_OVERLAY="/var/paludis/repositories/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi aiglx alsa alsa_cards_ali5451 alsa_cards_als4000 alsa_cards_atiixp alsa_cards_atiixp-modem alsa_cards_bt87x alsa_cards_ca0106 alsa_cards_cmipci alsa_cards_emu10k1x alsa_cards_ens1370 alsa_cards_ens1371 alsa_cards_es1938 alsa_cards_es1968 alsa_cards_fm801 alsa_cards_hda-intel alsa_cards_intel8x0 alsa_cards_intel8x0m alsa_cards_maestro3 alsa_cards_trident alsa_cards_usb-audio alsa_cards_via82xx alsa_cards_via82xx-modem alsa_cards_ymfpci alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol asf avahi bash-completion berkdb bitmap-fonts bluetooth branding bzip2 cairo cdr cli cracklib crypt css cups dlloader dri dvd dvdr elibc_glibc emboss encode fam fat fbcon ffmpeg firefox flac fortran gdbm gif gnokii gphoto2 gpm hal i8x0 iconv ieee1394 imagemagick input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_synaptics input_devices_void irda irmc isdnlog jfs jpeg kcal kde kdehiddenvisibility kernel_linux lcd lcd_devices_bayrad lcd_devices_cfontz lcd_devices_cfontz633 lcd_devices_glk lcd_devices_hd44780 lcd_devices_lb216 lcd_devices_lcdm001 lcd_devices_mtxorb lcd_devices_ncurses lcd_devices_text libg++ linguas_da linguas_en linguas_en_GB lm_sensors logitech-mouse mad mikmod mmx mmxext mp3 mpeg mplayer msn musicbrainz ncurses network nls nptl nptlonly nsplugin ntfs ogg opengl pam pcre pdf perl png ppds pppd python qt3 quicktime rdesktop readline real reflection reiser4 reiserfs ruby scanner sdl session slp sms spell spl sse sse2 ssl subversion svg svga syslog tcpd test tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU vcd video_cards_fbdev video_cards_fglrx video_cards_i810 video_cards_radeon video_cards_vesa vim vim-syntax vorbis wifi win32codecs xcomposite xfs xine xml xorg xscreensaver xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS
x86 stable
Stable for HPPA.
go MIPS go! ;)))
ping
[M]ark [I]t [P]lease [S]table ;)
mips mips mips mips mips mips mips mips mips mips mips... ;) Anyway, I'm removing ~mips from all new ebuilds I'm creating until I get some proof of life.
24 Apr 2007; Alexander Færøy <eroyf@gentoo.org> fcron-3.0.2-r1.ebuild: Stable on MIPS.
