- Arch-general - lists.archlinux.org

Re: [arch-general] Replace dcron once again?
by Jim Pryor 15 Nov '10

15 Nov '10

Hi all, I'm the dcron maintainer. I've replied to a few users who emailed me privately, but I wasn't aware of this thread until now. I agree it's ridiculous to have a cron daemon that can't keep time! I'm sorry I haven't been able to keep up maintenance properly. I'm a chronically over-committed university prof who only gets sporadic windows of time to give to each commitment. I think I know where the scheduling problems are coming from, and I will fix them as soon as I can. Part of the reason this hasn't happened earlier is that I started a large code review early this summer, and was interrupted by the press of other duties. Not a rewrite, just a thorough cleanup, but my private git repo is well ahead of the public one. I now have a queue of fixes and tweaks that users sent me (I think one of them is even the very scheduling fix that's needed), but the hood is open and some changes are only half-installed, so I really do need to take a few days to sort everything out. The problem has been finding the time to do that amidst all my other responsibilities. I would certainly understand and could not reasonably object to any distro's demoting dcron to an unofficial package. But as I said, I I will fix dcron anyway, I hope within the very near future. I'll announce here when I believe the git version has the necessary fixes, and if feedback sounds good, will make a new official release. Extra hands might not help right at this particular moment, but they would help the package be more reliably maintained going forward. I'd be glad to give other interested developers git-push privileges. -- Jim Pryor profjim(a)jimpryor.net

4 5

[arch-general] [signoff] openvpn 2.1.4-1
by Thomas Bächler 15 Nov '10

15 Nov '10

Upstream bugfix update - the release announcement explicitly mentions this one: "Fixed problem with special case route targets ('remote_host'), which could cause filling of the routing table with random garbage. Thanks to Teodo MICU and Gert Doering for finding and fixing this issue." Please sign off.

2 1

[arch-general] abs [WAS: arch-dev-public] Package maintainers wanted - heimdal, db, abs
by Ng Oon-Ee 14 Nov '10

14 Nov '10

Wasn't there a successor or replacement to abs in the works? A git-based one, I believe? (maybe I'm creating false memories?) On Sat, 2010-11-06 at 16:40 +1000, Allan McRae wrote: > Hi, > > I was wondering if anyone wanted to maintain the following packages: > > heimdal, db: I maintain these only because they are deps of things I > use but really do not use them at all. They could be much better served > by someone who does. These also have fairly regular soname bumps (even > on minor releases of heimdal) so you will need to start rebuilds every > so often. > > abs: I really have no motivation to fix any issues found in this and at > the moment an updated version of the package is wasting away in [testing]... > > Allan

6 8

[arch-general] Testing - fusion-icon, ATI drv, xorg -> compiz splash corrupt
by David C. Rankin 14 Nov '10

14 Nov '10

Guys, After updating to the latest packages in testing (fusion-icon, ati driver, xorg), the compiz splash is corrupt. I don't know if this is the result of xorg, the ati driver or the updated fusion-icon to handle python 3. Basically, you just see a blurry square where the compiz splash should be. I grabbed a screenshot so you could see what is happening. The blur from the eyes of the girl in the desktop is the compiz splash.... [54k] http://www.3111skyline.com/dl/Archlinux/bugs/compiz-splash.jpg -- 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

1 0

[arch-general] Replace dcron once again?
by Florian Pritz 13 Nov '10

13 Nov '10

It doesn't seem like dcron is maintained very well [1], so I think we should consider switching. FS#18681 [2] is quite a critical bug in a crond when everyone expects jobs to run only once. I'd like to go with fcron because it seems to work very well for most people, has a lot of features while having a small dependency tree. Comments welcome. [1] http://repo.or.cz/w/dcron.git [2] https://bugs.archlinux.org/task/18681 -- Florian Pritz -- {flo,bluewind}(a)server-speed.net

23 34

Re: [arch-general] Opencl/Cuda headers
by Attila 13 Nov '10

13 Nov '10

At Freitag, 12. November 2010 18:34 Stéphane Gaudreault wrote in gmane.linux.arch.devel: >> It seems the Cuda/OpenCL/vdpau headers are back in nvidia-utils version >> 260.19.21-1. >> >> Stéphane is happy again :-) > > Sorry for the noise, I was misled by a post on the Nvidia forum. The changelog > still say (see bellow) that the headers are no longer packaged with the > driver. The only headers which be included in 260.19.21 are the opengl headers and the default is to not install them: --opengl-headers Normally, installation will not install NVIDIA's OpenGL header files; the OpenGL header files packaged by the Linux distribution or available from http://www.opengl.org/registry/ should be preferred. However, http://www.opengl.org/registry/ does not yet provide a glx.h or gl.h. Until that is resolved, NVIDIA's OpenGL header files can still be chosen, through this installer option. And i can't find (vdpau.h and vdpau_x11.h) or (cuda.h, cudaGL.h, cudaVDPAU.h, cl.h, cl_gl.h, cl_platform.h) if i extract the NVIDIA installer. I think your plan is so good as before and the README be right. See you, Attila

1 0

Re: [arch-general] Could python2 be breaking genpkgmetadata.py?
by Auguste Pop 12 Nov '10

12 Nov '10

the package you mentioned is orphaned and marked out-of-date. i think you can simply adopt and update it. change the PYTHON variable in Makefile to python2 and several shebang lines in .py files may solve the breakage. of course, you need to change the dependency from python to python2. > Date: Fri, 12 Nov 2010 12:00:26 -0600 > From: "David C. Rankin" <drankinatty(a)suddenlinkmail.com> > Subject: Re: [arch-general] Could python2 be breaking > genpkgmetadata.py? > To: General Discussion about Arch Linux <arch-general(a)archlinux.org> > Message-ID: <4CDD80BA.7080004(a)suddenlinkmail.com> > Content-Type: text/plain; charset=ISO-8859-9 > > On 11/12/2010 11:44 AM, David C. Rankin wrote: >> >> But on how many packages? Just the ones that are breaking or is there some set >> of base packages I should backup and the do a 'perl -p -i -e >> s/bin\/python/bin\/python2/' on? >> > > Err.. It doesn't seem to be that simple. After changed the executable line, now > the scripts don't find the modules: > > Traceback (most recent call last): > File "/usr/share/createrepo/genpkgmetadata.py", line 29, in <module> > import createrepo > ImportError: No module named createrepo > > Is there a way to teach the python2 scripts about the modules it used to know? > > > -- > 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 > > > ------------------------------ >

2 1

[arch-general] Could python2 be breaking genpkgmetadata.py?
by David C. Rankin 12 Nov '10

12 Nov '10

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

3 4

[arch-general] Shutdown and reboot
by joker-jar＠yandex.ru 12 Nov '10

12 Nov '10

Please tell me the best way to allow non root user to use halt, reboot, shutdown e t.c. May be set group "power" to this binaries? $ ls -l /sbin/halt -rwxr-xr-x 1 root root 15152 2010-10-02 13:26 /sbin/halt (Not only for me but in distro). No?

3 2

[arch-general] python3 thoughts
by Auguste Pop 12 Nov '10

12 Nov '10

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,

2 1