Re: [arch-general] Replace dcron once again?
At Freitag, 12. November 2010 02:26 Alex Matviychuk wrote: > This is from a Linux From Scratch readme here: > http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt I would prefer this info: http://www.gentoo.org/doc/en/cron-guide.xml Here you can see that dcron is the first option in gentoo too and so the decision of installing it from the arch devs seems okay. If there is a bug than this could happens in every application and should be only a problem if there is no solution for it. And again i'm a satisfied fcron user but i enjoy that we have the choice in arch linux ... which is not normal because some distributions ships only one cron and only this one could discuss about replacing. :) See you, Attila
Re: [arch-general] python3 thoughts
On 11/12/10 01:51, Auguste Pop wrote: ... I hope python3 won't die this way, so that all the previous efforts in transition to python3 will not go in vain. Maybe we just took the transitional leap too early when nobody is ready except us. As you note, "nobody is ready except us" -- we are ready -- the pain is not very much. On the flip side, the little pain that we do feel is a really valuable offering to the other more conservative distros: they get to see how it was for us and what the biggest pain points are in practice. You're also (I think?) making a good point that, at least where upstream projects written in python can run on python3, we as packagers should proactively package them to do so. We should be conscious if we're letting them languish in the doldrums of 2-ness untended. -Isaac
[arch-general] python3 thoughts
Hi, Firstly, I want to state clearly that I am 100% supportive to the python3 transition which took part in Archlinux a month ago. I installed libreoffice from extra today to replace go-openoffice. And all of a sudden, python is no longer required by any package at all. I checked the dependencies of openoffice, go-openoffice, and libreoffice, it seems that openoffice depends on python2, go-openoffice depends on python, and libreoffice goes back to depend on python2 again. In fact, the "required-by" list of python on the package website is quite short. Ideally, python2 packages will migration to python3 and the package python will be required again one of these days. I am just wondering if this change would actually happen in the future. When I tried to learn python several year ago, I felt a very strong reluctance from the python community to moving on to python3 and the split of language drove me away. After all these years, python developers are still so unwilling to move on to the new system. I hope python3 won't die this way, so that all the previous efforts in transition to python3 will not go in vain. Maybe we just took the transitional leap too early when nobody is ready except us. Best Regards,
Re: [arch-general] Could python2 be breaking genpkgmetadata.py?
On Fri, 2010-11-12 at 13:46 +0800, Gergely Imreh wrote: > On 12 November 2010 13:32, David C. Rankin > wrote: > > Guys, > > > >I'm using yum-createrepo 0.9.8-3 on from AUR and suddenly my > > createrepo updates > > on my Arch server are failing with the following error: > > > > 23:22 nirvana:/home/backup/rpms> sudo createrepo --update -d openSUSE_11.3/ > > File "/usr/share/createrepo/genpkgmetadata.py", line 189 > >print thing > > ^ > > SyntaxError: invalid syntax > > Not bug, change. > Print is now a function in Python 3, i.e. one has to use print(thing) > instead of the previous form. > http://docs.python.org/release/3.0.1/whatsnew/3.0.html > > Most likely either change the call in beginning of the script to > python2 instead of python, or roll up the sleeves and start converting > to the new version (python 2to3 should help > http://docs.python.org/library/2to3.html ) > > Cheers, > Greg Out of curiosity, David, I know you're on the ML quite often, how could you NOT realize all the python update emails and complaints going around?
Re: [arch-general] Could python2 be breaking genpkgmetadata.py?
On 12 November 2010 13:32, David C. Rankin wrote: > Guys, > > I'm using yum-createrepo 0.9.8-3 on from AUR and suddenly my > createrepo updates > on my Arch server are failing with the following error: > > 23:22 nirvana:/home/backup/rpms> sudo createrepo --update -d openSUSE_11.3/ > File "/usr/share/createrepo/genpkgmetadata.py", line 189 > print thing > ^ > SyntaxError: invalid syntax Not bug, change. Print is now a function in Python 3, i.e. one has to use print(thing) instead of the previous form. http://docs.python.org/release/3.0.1/whatsnew/3.0.html Most likely either change the call in beginning of the script to python2 instead of python, or roll up the sleeves and start converting to the new version (python 2to3 should help http://docs.python.org/library/2to3.html ) Cheers, Greg
[arch-general] Could python2 be breaking genpkgmetadata.py?
Guys,
I'm using yum-createrepo 0.9.8-3 on from AUR and suddenly my createrepo
updates
on my Arch server are failing with the following error:
23:22 nirvana:/home/backup/rpms> sudo createrepo --update -d openSUSE_11.3/
File "/usr/share/createrepo/genpkgmetadata.py", line 189
print thing
^
SyntaxError: invalid syntax
Nothing with createrepo has changed, could this be a python/python2
bug? I have
both the following installed:
python 3.1.2-2
python2 2.7-3
Should I have both installed? I've also posted to the rpm-metadata list
to see
if they have identified an issue with the genpkgmetadata.py script. The relevant
lines in the python script are:
class MDCallBack(object):
"""cli callback object for createrepo"""
def errorlog(self, thing):
"""error log output"""
print >> sys.stderr, thing
def log(self, thing):
"""log output"""
print thing
def progress(self, item, current, total):
"""progress bar"""
beg = "%*d/%d - " % (len(str(total)), current, total)
left = 80 - len(beg)
sys.stdout.write("\r%s%-*.*s" % (beg, left, left, item))
sys.stdout.flush()
Which since I don't know python -- it might as well be Greek. But from the
error, I can tell it chokes on the line "print thing"... whatever that thing is.
Anybody have any info on any problems caused by recent python changes?
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Re: [arch-general] Replace dcron once again?
Am Fri, 12 Nov 2010 13:10:12 +0900 schrieb Alex Matviychuk : > I agree, however, it sounds a bit odd to say that we should replace a > simple package with a more complicated one in the hope the more > complicated one will screw us over less going forward. We're just as > bound to the idiosyncrasies and bugs of fcron as dcron, but with the > added complexity of fcron. I'm not really a cron expert, but fcron is not more complicated than dcron, it's just more feature-rich, more flexible, has more ways to configure, can be configured more precisely in my estimation. But fcron is as easy or hard to configure as dcron. It's fact that the fcron package is bigger than dcron but it has some more configuration files with which e.g. access privileges can be granted and a comprehensive documentation in plain text, HTML and several manpages. But this documentation can be very helpful for people who are not that familiar with cron daemons in general and fcron in particular. There's probably one thing that could be changed in the fcron package to reduce the size. The complete documentation is in English as well as in French. Nothing against France, but the French documentation could probably be removed from the package. All in all fcron looks a bit more mature in my view. Heiko
Re: [arch-general] Replace dcron once again?
On Fri, Nov 12, 2010 at 13:10, Alex Matviychuk wrote: > For such a crucial system package it would seem wise to deal with the > devil that's easier to understand (in theory, I don't claim to > understand the internals of e. That should read: For such a crucial system package it would seem wise to deal with the devil that's easier to understand (in theory, I don't claim to understand the internals of either package, but if I was forced to debug both, I imagine dcron would be easier to deal with based on lines of code alone.)
Re: [arch-general] Replace dcron once again?
On Fri, Nov 12, 2010 at 11:57, Loui Chang wrote: > The only problem is finding someone who can do the work to maintain > dcron. It's pretty damning to have a scheduler that can't schedule > properly installed by default - that's what people seem to be concerned > about mostly. I'd like to keep the simpler package too, but if it ain't > working chuck it. I agree, however, it sounds a bit odd to say that we should replace a simple package with a more complicated one in the hope the more complicated one will screw us over less going forward. We're just as bound to the idiosyncrasies and bugs of fcron as dcron, but with the added complexity of fcron. For such a crucial system package it would seem wise to deal with the devil that's easier to understand (in theory, I don't claim to understand the internals of e. Also, looking over the comments in the bugtracker (https://bugs.archlinux.org/task/18681), it seems this may not even be a dcron issue. I would urge further consideration before making a switch. Cheers, Alex
Re: [arch-general] Replace dcron once again?
On 11/11/10 20:26, Alex Matviychuk wrote: Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this: (As Loui noted, many of those points are changed by the passage of seven years. Distros probably use different crons now; and fcron has improved in the meantime; and dcron might have changed, I'm not sure.) In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code. I dispute that something that doesn't always schedule jobs at the frequency the user requests (this user often being root) -- and that we as a community don't even understand when/why -- is secure. (It leaves me somewhat wondering about mature too, if no one's noticed (or fixed anyhow) this bug before. I wouldn't assume it's the only bug (although it might be).) -Isaac
Re: [arch-general] Replace dcron once again?
On Fri 12 Nov 2010 10:26 +0900, Alex Matviychuk wrote: > Thanks to this thread I decided to look at both dcron and fcron. First > google result for dcron led me to this: > > This is from a Linux From Scratch readme here: > http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt Nice. The guy who wrote that article is an Archer and former TU. It's also from 7 years ago. I'm sure a good deal has changed since. > From my naive point of view, it seems like dcron is more in line with > the Arch Way. > > In response to the initial concern about a bug in dcron, don't we have > anyone in our userbase that could take a look at the dcron code? As > far as updates, I wouldn't expect a basic mature package to be updated > more than once or twice a year. Update frequency alone says nothing > about the quality of the code. > My vote would be to focus efforts on fixing the bug and to keep Arch > as small and lightweight as possible at its base. One of the best > parts of Arch for me is that it starts out minimalistic and you can > extend it to make it fit your needs. Trying to make our favorite > packages defaults instead of minimal, stable, small packages, is a > mistake imho. The only problem is finding someone who can do the work to maintain dcron. It's pretty damning to have a scheduler that can't schedule properly installed by default - that's what people seem to be concerned about mostly. I'd like to keep the simpler package too, but if it ain't working chuck it.
Re: [arch-general] Replace dcron once again?
Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this: 1 Why use dcron when there's fcron? --- - dcron is SIMPLE: dcron just gives you two binaries, crond and crontab, and consists only of a few source files. - dcron is SMALL: binaries (i386-elf) are only about 25k - dcron is MATURE: it is many distributions' default cron and in use since ~1994. - dcron is SECURE: that's the consequence of being simple and mature. - dcron WORKS: fcron only worked for root on my box, no matter how hard I tried. This is from a Linux From Scratch readme here: http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt >From my naive point of view, it seems like dcron is more in line with the Arch Way. In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code. My vote would be to focus efforts on fixing the bug and to keep Arch as small and lightweight as possible at its base. One of the best parts of Arch for me is that it starts out minimalistic and you can extend it to make it fit your needs. Trying to make our favorite packages defaults instead of minimal, stable, small packages, is a mistake imho. Cheers, Alex
Re: [arch-general] Replace dcron once again?
On 11.11.2010 23:50, Ng Oon-Ee wrote: > On Thu, 2010-11-11 at 16:31 -0500, Leonid Isaev wrote: >> Not only this, but also the fact that now there are 2 crons being maintained: >> fcron in community and dcron in core. Removing dcron to, say, AUR, will be a >> wiser use of devs' time... > Bottom-posting please. And I don't see a problem with the current > situation, one is in [core] the other in [community] (devs vs TUs). It > could be reverse, if that's what's meant by 'replacing'. > > As a result of this thread I've switched to fcron as well. No big deal. > > As far as I am aware, dcron is installed by default and is being advised as the main crond for Arch on the wiki. By replacing I'd mean making fcron default in wiki and install.
Re: [arch-general] Replace dcron once again?
On Thu, 2010-11-11 at 16:31 -0500, Leonid Isaev wrote: > Not only this, but also the fact that now there are 2 crons being maintained: > fcron in community and dcron in core. Removing dcron to, say, AUR, will be a > wiser use of devs' time... Bottom-posting please. And I don't see a problem with the current situation, one is in [core] the other in [community] (devs vs TUs). It could be reverse, if that's what's meant by 'replacing'. As a result of this thread I've switched to fcron as well. No big deal.
Re: [arch-general] Replace dcron once again?
Not only this, but also the fact that now there are 2 crons being maintained: fcron in community and dcron in core. Removing dcron to, say, AUR, will be a wiser use of devs' time... On (11/11/10 21:35), Sven-Hendrik Haase wrote: -~> On 11.11.2010 21:15, Attila wrote: -~> The way I see it we at least shouldn't give/advise users to dcron as a -~> default. -- lis...@svibor
Re: [arch-general] Replace dcron once again?
On 11.11.2010 21:15, Attila wrote: > At Donnerstag, 11. November 2010 20:16 Sven-Hendrik Haase wrote: > >> So, not a mail since a while. Can we replace dcron now? :) > What i don't understand is this "replace" here because fcron (or incron) is > only > one "pacman -S" away. And i say this as an fcron user. :) > > See you, Attila > > > The way I see it we at least shouldn't give/advise users to dcron as a default.
Re: [arch-general] Replace dcron once again?
At Donnerstag, 11. November 2010 20:16 Sven-Hendrik Haase wrote: > So, not a mail since a while. Can we replace dcron now? :) What i don't understand is this "replace" here because fcron (or incron) is only one "pacman -S" away. And i say this as an fcron user. :) See you, Attila
Re: [arch-general] Replace dcron once again?
On 09.11.2010 11:47, Dieter Plaetinck wrote: > FWIW: > I've gone through the archives and found multiple threads about our > cron discussions. > http://mailman.archlinux.org/pipermail/arch-dev-public/2009-September/ > http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January > (esp. > http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January/014781.html) > > Seems like the last time we were on the verge of switching to fcron, > but didn't because Jim took over dcron upstream (and added his "yacron" > features.) > > The only negative thing i could find in the archives about fcron is > that it doesn't support /etc/cron.d natively (but we can write scripts > to work around that). Although Heiko seemed to suggest this is no > longer true anymore. (?) > > Other then that, it seems a solid featureful-but-simple-enough cron > daemon. > > Dieter > So, not a mail since a while. Can we replace dcron now? :)
