November 2010 - Arch-general - lists.archlinux.org

[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 13 Nov '10

13 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 12 Nov '10

12 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

Re: [arch-general] [aur-general] [extra] repository cleanup
by Heiko Baums 10 Nov '10

10 Nov '10

Am Wed, 10 Nov 2010 11:33:32 +0100 schrieb Andrea Scarpino <andrea(a)archlinux.org>: > Hi DEVs/TUs, > currently we have 700 (counting both arches and any) orphans packages > in [extra]. > As member of the orphans team, I made a list[1] of these packages and > I'd like to move them to Unsupported. > If some DEV wants to keep a package simply cross it out (adoption is > not required, but it would be nice) or reply to this mail. > If some TU wants to maintain a package in [community], please write > the name into the "Candidate to [community]" section, *DO NOT* cross > it out. Or reply to this mail. > > I think that a week is enough time for this job. 17th November I will > move the remaining packages to Unsupported and the candidates to > [community]. > > Cheers > > [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Repo_Cleanup You should really think about that. There are many of the most important, oldest and best known packages in this list like dia, ding, xboard, eboard, epdfview, slmodem etc. In other words, your list is likely the half of the distro. If you would put all of them to AUR then you could give up Arch Linux, because then it has almost no advantage over Gentoo, that is, then will Arch Linux become a second Gentoo, because the users will have to compile a lot of (most of the) important packages manually. And the reason why I switched from Gentoo to Arch Linux about 3 or 4 years ago after using Gentoo for about 6 years was that I was sick of compiling everything and that Arch Linux was a binary distribution. So if you would really do this clean up and move all these packages to AUR then I could and most likely would switch back to Gentoo. So really, please, reconsider your idea of doing this massive and pointless cleanup. Btw., ding was updated recently. Heiko

3 2

[arch-general] dmraid boot fail (grub errors 5 & 24) - follow up
by David C. Rankin 09 Nov '10

09 Nov '10

Guys, As a follow up, the post to kernel.org did not elicit any response. The folks at dm-devel suggested it may be a grub bug. So that leave me with two more avenues to try (1) the grub list, and (2) lilo test. I have also kept a running summary of the problem and input from the various lists and I've made it available here: http://www.3111skyline.com/dl/Archlinux/bugs/dmraid/dmraid-boot-fail-summar… I'll continue to add to it to capture relevant info concerning the history of this problem. The theory that the boot failure is a result of where initramfs gets placed on the disk doesn't seem like it is the issue. It's not ruled out, but I've created multiple initramfs images, installed the kernels in multiple different orders and the boot failures don't change. 2.6.35.8 & 2.6.36-3 fail, but booting 2.6.35.7, LTS, SuSE, etc. work just fine. I'll update the post with additional info as it becomes available (hopefully a solution). If anyone else has a stroke of genius, please let me know. Thanks. -- 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

4 4