- Arch-general - lists.archlinux.org

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

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

10 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

[arch-general] [signoff] kernel 2.6.36-3
by Tobias Powalowski 09 Nov '10

09 Nov '10

Hi guys, please signoff 2.6.36 series for both arches and give feedback if real issues arise. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - Tomoyo support: https://bugs.archlinux.org/task/21533 - Apparmor support: https://bugs.archlinux.org/task/21533 - Build RTC support into kernel: https://bugs.archlinux.org/task/21137 - changed cpu support to 64 on x86_64 - added hugetables support: https://bugs.archlinux.org/task/20862 - disabled RDS modules due to security concerns: https://bugs.archlinux.org/task/21510 - pcieaspm enabled greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

9 19

Re: [arch-general] [arch-dev-public] [signoff] glibc-2.12.1-4
by Jan Steffens 09 Nov '10

09 Nov '10

On Tue, Nov 9, 2010 at 8:48 AM, Allan McRae <allan(a)archlinux.org> wrote: > On 03/11/10 12:50, Allan McRae wrote: >> >> On 26/10/10 11:38, Allan McRae wrote: >>> >>> Another day, another glibc... >>> >>> This adjusts the static linking fix. The one previously used is a more >>> correct fix but appears incomplete. I have replaced this by a hack fix >>> that Fedora uses. >>> >>> I will leave this in [testing] a while. My concern is the previous patch >>> apparently fixed a bunch of segfault bugs in glibc and I am hoping that >>> these do not get reintroduced. >>> >>> If only upstream made a proper fix for this. Saying upstream is doing >>> not much about this bug would imply that they are doing something... >>> >> >> OK, things seem fine for this so I think it is time for this to move. >> Signoff away! >> > > I said... Signoff away! :P > Signoff i686, x86_64

1 0

[arch-general] Radeon HD 5xxx
by Andrew Allen Barkley 09 Nov '10

09 Nov '10

I am now an owner of a Radeon HD 5870. But... lspci reports it as: VGA compatible controller: ATI Technologies Inc Device 6898 I am running testing. Also, the feature matrix linked to by the ATI page on the wiki indicates that HD 5xxx cards are supported by xf86-video-ati, as does the wiki. What's the situation on this? -- Cordialement, Andrew Allen Barkley () /\ against html e-mail against proprietary attachments www.asciiribbon.org

3 3