Re: [arch-general] mplayer needs a rebuild
On Wed, Oct 21, 2009 at 12:51 AM, member zhurai zhu...@archlinux.us wrote: I tried rebuilding mplayer, but I'm getting errors O_o and when I looked in #mplayer ... it said in the topic: * Topic for #mplayer is: Do NOT paste inside the channel, use www.pastebin.com | *gcc 4.4.0 and 4.4.1 cause problems, use newer/older gcc*| http://wiki.multimedia.cx/index.php?title=MPlayer_FAQ | svn co svn:// svn.mplayerhq.hu/mplayer/trunk | 64bit real codecs available, win32 dlls still need 32bit mplayer, in /usr/local/lib/codecs | 1080 h264 requires 2.4ghz c2d / amd x2 2.8ghz+ | no plugin help | windows builds: http://oss.netfarm.it/mplayer-win32.php | how DID you compile it right abs, when I tried in all that I can and it still fails =_= (yes I tried in abs, svn, -mt-git, -mt-oss-git) fails on: libx264.c: In function 'encode_nals': libx264.c:75: warning: implicit declaration of function 'x264_nal_encode' libx264.c: In function 'X264_init': libx264.c:190: error: 'x264_param_t' has no member named 'b_bframe_pyramid' make[1]: *** [libx264.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/root/mplayer/src/mplayer/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 should probably mention I'm on x86_64 and not doing a new build heck I didn't even bump the release version. using gcc 4.4.1 possibly noteable in makepkg.conf but I doubt it. CFLAGS=-march=core2 -O2 -pipe CXXFLAGS=-march=core2 -O2 -pipe other than that I just ran makepkg from the abs/extra/mplayer/PKGBUILD Finished making: mplayer 29776-1 x86_64 (Tue Oct 20 23:25:34 EDT 2009) -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [arch-general] defunct packages spooking around
Allan McRae a écrit : Firmicus wrote: Hi folks, Sorry for the halloweenish subject heading ;) I recently got this bug report: http://bugs.archlinux.org/task/16690 It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package termcap-compat is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed! That prompts me to ask the following: Are there other such obsolete packages that typically should no longer be installed on a clean Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion. Please submit your suggestions for the forthcoming Arch Ghostbusting Day (aka The Great Halloween Cleanup)! :) libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs I removed these long ago, but... Although, all these should be detectable by pacman -Qqtd (maybe not libdownload as it was part of base). the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago! F
Re: [arch-general] mplayer needs a rebuild
works fine here but i agree that a mplayer optimized for nvidia cards (VDPAU) and ffmpeg-mt is missing on the repos... 2009/10/21 Caleb Cushing xenoterrac...@gmail.com On Wed, Oct 21, 2009 at 12:51 AM, member zhurai zhu...@archlinux.us wrote: I tried rebuilding mplayer, but I'm getting errors O_o and when I looked in #mplayer ... it said in the topic: * Topic for #mplayer is: Do NOT paste inside the channel, use www.pastebin.com | *gcc 4.4.0 and 4.4.1 cause problems, use newer/older gcc*| http://wiki.multimedia.cx/index.php?title=MPlayer_FAQ | svn co svn:// svn.mplayerhq.hu/mplayer/trunk | 64bit real codecs available, win32 dlls still need 32bit mplayer, in /usr/local/lib/codecs | 1080 h264 requires 2.4ghz c2d / amd x2 2.8ghz+ | no plugin help | windows builds: http://oss.netfarm.it/mplayer-win32.php | how DID you compile it right abs, when I tried in all that I can and it still fails =_= (yes I tried in abs, svn, -mt-git, -mt-oss-git) fails on: libx264.c: In function 'encode_nals': libx264.c:75: warning: implicit declaration of function 'x264_nal_encode' libx264.c: In function 'X264_init': libx264.c:190: error: 'x264_param_t' has no member named 'b_bframe_pyramid' make[1]: *** [libx264.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/root/mplayer/src/mplayer/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 should probably mention I'm on x86_64 and not doing a new build heck I didn't even bump the release version. using gcc 4.4.1 possibly noteable in makepkg.conf but I doubt it. CFLAGS=-march=core2 -O2 -pipe CXXFLAGS=-march=core2 -O2 -pipe other than that I just ran makepkg from the abs/extra/mplayer/PKGBUILD Finished making: mplayer 29776-1 x86_64 (Tue Oct 20 23:25:34 EDT 2009) -- Caleb Cushing http://xenoterracide.blogspot.com -- http://id.liquuid.net
Re: [arch-general] defunct packages spooking around
On Wed, Oct 21, 2009 at 5:39 AM, Firmicus firmi...@gmx.net wrote: Allan McRae a écrit : Firmicus wrote: Hi folks, Sorry for the halloweenish subject heading ;) I recently got this bug report: http://bugs.archlinux.org/task/16690 It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package termcap-compat is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed! That prompts me to ask the following: Are there other such obsolete packages that typically should no longer be installed on a clean Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion. Please submit your suggestions for the forthcoming Arch Ghostbusting Day (aka The Great Halloween Cleanup)! :) libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs I removed these long ago, but... Although, all these should be detectable by pacman -Qqtd (maybe not libdownload as it was part of base). the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago! F Try with pacman -Qm. That might work better if you don't have a lot of custom/AUR packages installed.
Re: [arch-general] defunct packages spooking around
Eric Bélanger a écrit : On Wed, Oct 21, 2009 at 5:39 AM, Firmicus firmi...@gmx.net wrote: Allan McRae a écrit : Firmicus wrote: Hi folks, Sorry for the halloweenish subject heading ;) I recently got this bug report: http://bugs.archlinux.org/task/16690 It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package termcap-compat is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed! That prompts me to ask the following: Are there other such obsolete packages that typically should no longer be installed on a clean Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion. Please submit your suggestions for the forthcoming Arch Ghostbusting Day (aka The Great Halloween Cleanup)! :) libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs I removed these long ago, but... Although, all these should be detectable by pacman -Qqtd (maybe not libdownload as it was part of base). the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago! F Try with pacman -Qm. That might work better if you don't have a lot of custom/AUR packages installed. Hem, I have hundreds of them! But they're almost exclusively auto-generated packages for CPAN/perl stuff. In my case running pacman -Qqm | grep -v perl does the job, which does not, however, reveal any new item to be cleaned away. I am actually hunting for packages that used to be in core or extra and no longer exist, not even in community/AUR, but might still be polluting some Arch installations... Perhaps termcap-compat was an exceptional case after all.
Re: [arch-general] defunct packages spooking around
On Wed, Oct 21, 2009 at 11:42 PM, Firmicus firmi...@gmx.net wrote: That's what I guessed: termcap-compat has ~18%! csup: 15% and libdownload: 59%!! For the rest one would need to check each pkg under unknown for non-existence in AUR... Any volunteer? :) I think you can automate that. One example from http://wiki.archlinux.org/index.php/Optdepends_bugs#Checking_script : if [ $(slurpy -i $pkg 2/dev/null | wc -l) -gt 1 ]; then continue fi But you can use any other ways you like to access AUR :)
Re: [arch-general] Why does kde4 over vnc look bad if host is Arch, looks fine if suse?
On Wednesday 21 October 2009 11:14:02 pm David C. Rankin wrote: On Wednesday 21 October 2009 09:56:29 pm Byron Clark wrote: On Wed, Oct 21, 2009 at 09:50:53PM -0500, David C. Rankin wrote: You are 100% correct, suse had RENDER enable, arch doesn't. How do I enable RENDER on Arch? You'll need a vnc server that supports the RENDER extension. xf4vnc-xvnc should work. Hmm, it conflicts with tightvnc on Arch. Can't I just rebuilt tightvnc with RENDER enabled? Evidently it is build with RENDER on suse, so I guess it should be possible. The reason being, I kind of like to keep the utilities the same across all the boxes I have (save mental storage space). I'll give it a shot, if it doesn't work for some reason, I'll see about building tightvnc with RENDER enabled. Thanks for you help tonight! I used the workaround at: http://wiki.archlinux.org/index.php/Tightvnc and it doesn't really work. RENDER is there and rendering is better, but you still have artifacts on the screen and the plasma panel is cut in half: http://www.3111skyline.com/download/screenshots/archlinux/arch-kde4overvnc- xf4vnc.jpg I'll look at trying to rebuild tightvnc. Arch should fix the missing 'vnc...' scripts with the Xvnc package so it is usable and should also fix the tightvnc package so it is built with RENDER. If I'm successful, I'll have somebody walk me through putting the package in AUR or adding it to the community repository. In the interim if the maintainer takes the initiative, we can all rest easy knowing we will get a correctly built package :D -- 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
