- Arch-general - lists.archlinux.org

[arch-general] [PATCH] devtools: Make sure build files are owned by nobody
by Nezmer 27 Dec '09

27 Dec '09

makechrootpkg copies files to "$uniondir/build" after chowning the directory. This means those files are not owned by nobody. This yields to failure when the files are supposed to be dynamically edited. A common use-case is when we build from git or svn and we want $pkver to be upgraded dynamically. Signed-off-by: Nezmer <Nezmer(a)allurelinux.org> --- makechrootpkg | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/makechrootpkg b/makechrootpkg index 1d2282c..9e36f10 100755 --- a/makechrootpkg +++ b/makechrootpkg @@ -200,6 +200,9 @@ if [ -f "ChangeLog" ]; then cp ChangeLog "$uniondir/build/" fi +# Make sure "$uniondir/build/*" owned by nobody before we start building +chown -R nobody "$uniondir/build" + if ! grep "^nobody" "$uniondir/etc/sudoers" >/dev/null 2>&1; then echo "allowing 'nobody' sudo rights in the chroot" touch "$uniondir/etc/sudoers" -- 1.6.6

1 1

[arch-general] libglew
by richard terry 27 Dec '09

27 Dec '09

Posted this to the gambas list as my current svn won't compile - they said I needed libglew but can't find it in the repos ?under another name? > Le samedi 26 décembre 2009 22:58:38, richard terry a écrit : > > Making all in opengl > > make[5]: Entering directory `/home/richard/gambas3- > > svn/src/trunk/gb.qt4/src/opengl' > > /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > > - I../.. -DQT3_SUPPORT -DQT_SHARED -DQT3_SUPPORT -I/usr/include/QtCore - > > I/usr/include/QtGui -I/usr/include/Qt3Support -I/usr/include/QtNetwork - > > I/usr/include/QtSql -I/usr/include/GL/ -DQT_SHARED > > -I/usr/include/QtCore - I/usr/include/QtGui -I/usr/include/QtOpenGL > > -pipe -Wall > > -fno-exceptions - Wno-unused-value -fsigned-char -fvisibility=hidden -g > > -Os -fno-omit-frame- pointer -MT main.lo -MD -MP -MF .deps/main.Tpo -c > > -o main.lo main.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. > > -DQT3_SUPPORT -DQT_SHARED - DQT3_SUPPORT -I/usr/include/QtCore > > -I/usr/include/QtGui - > > I/usr/include/Qt3Support -I/usr/include/QtNetwork -I/usr/include/QtSql - > > I/usr/include/GL/ -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui > > - I/usr/include/QtOpenGL -pipe -Wall -fno-exceptions -Wno-unused-value > > -fsigned- char -fvisibility=hidden -g -Os -fno-omit-frame-pointer -MT > > main.lo -MD -MP - MF .deps/main.Tpo -c main.cpp -fPIC -DPIC -o > > .libs/main.o > > In file included from main.cpp:29: > > CGLarea.h:30:21: error: GL/glew.h: No such file or directory > > make[5]: *** [main.lo] Error 1 > *************************************************** > Yes, now you need libglew package (and devel files of course) *************************************************** regards richard

3 2

[arch-general] stellarium and x with intel 965
by Sergey Manucharian 24 Dec '09

24 Dec '09

Hi folks, Stellarium won't run properly in my ThinkPad R61 with Intel 965 graphic card. The main window with stars, labels, grids etc. looks fine, but all the dialogs and toolbars' icons are distorted and not "readable" at all. The screenshot is at [1]. stellarium 0.10.2-3 xorg-server 1.7.3.901-1 xorg driver "intel" I've checked it with the same configuration with different HW (EEE PC) - it works perfectly. Any ideas? Thanks, Sergey [1] http://ingeniware.com/downloads/images402b3d63aad79fe059b514174bffe4ae/stel…

2 3

[arch-general] kernel26-2.6.32.2-1 -- Radeon module (EE) config/hal ... org.freedesktop.DBus.Error.AccessDenied
by David C. Rankin 24 Dec '09

24 Dec '09

Guys, Working between the radeon and radeonhd modules, I noticed a strange error as the last line in my Xorg.0.log today that caught me by surprise. It was a hal/DBus error that I haven't seen before. Strange, what is a hal/dbus error doing in my Xorg log? The Radeon driver seems to be working OK, but I would like to find out what is going wrong and how I can fix the system so I don't get this error anymore. The error is: (II) RADEON(0): Setting screen physical size to 381 x 238 (EE) config/hal: couldn't find input device: org.freedesktop.DBus.Error.AccessDenied (Rejected send message, 1 matched rules; type="method_call", sender=":1.11" (uid=0 pid=16410 comm="/usr/bin/X) interface="org.freedesktop.Hal.Manager" member="FindDeviceByCapability" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=4062 comm="/usr/sbin/hald))) The box is my Toshiba 205d x86_64 laptop w/Radeon RS690M. The full log is here: http://www.3111skyline.com/download/linux/radeonhd/log/Xorg.0.22095221.log Anybody know what to do to figure out what is going on here? -- 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 2

[arch-general] MAYDAY - drm/mesa/libgl/radeon updates - laptop stuck in 1152x864 - kdm locks on logout!
by David C. Rankin 24 Dec '09

24 Dec '09

Guys, I got bit bad tonight by the updates tonight. X starts but is stuck at 1152x864, if I log out, X freezes. Looks like bad libdrm and lib32-libdrm packages. Specifically, I upgraded: [2009-12-23 00:30] starting full system upgrade [2009-12-23 00:31] upgraded libdrm (2.4.17-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded ati-dri (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-libdrm (2.4.16-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded lib32-libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded system-config-printer-common (1.1.13-1 -> 1.1.15-1) [2009-12-23 00:31] upgraded system-config-printer-gnome (1.1.13-1 -> 1.1.15-1) Next logout, the machine changed from 1440x900 to 1152x864 (the initial frame buffer resolution). Currently I am not using KMS with the radeon driver due to the current driver/initrd issues. I tried using a minimal xorg.conf setting the preferred resolution to 1440x900 (like I have done before to switch between the radeon/radeonhd drivers). X crashed immediately. Yes I had screens defined. X always started just fine with this xorg before. This is a short log: (this is the complete Xorg.0.log) X.Org X Server 1.7.3.901 (1.7.4 RC 1) Release Date: 2009-12-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-ARCH x86_64 Current Operating System: Linux alchemy 2.6.32-ARCH #1 SMP PREEMPT Sun Dec 20 10:01:30 CET 2009 x86_64 Kernel command line: root=/dev/disk/by-uuid/b004715c-1666-458a-b827-2bbb1d4a735e ro Build Date: 12 December 2009 08:39:02PM <snipped the definitions> Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor OK, so I had 2 choices, either try KMS with the nonworking drm or downgrade. I decided to downgrade. So I tried to downgrade with: pacman -U /var/cache/pacman/pkg/libdrm-2.4.17-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/ati-dri-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libdrm-2.4.16-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-mesa-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/mesa-7.6.1-1-x86_64.pkg.tar.gz Which failed dependencies with mesa/libmesa requiring libdrm/lib32-libdrm > or = 2.4.17-2. HUH?? Deps whacked somewhere, I just upgraded from 2.4.17-1 and it was working fine... So I just eliminated the libdrm/lib32-libdrm packages and downgraded leaving drm the way mesa/libmesa wanted it. (Note the different downgrade times for libdrm below) X was still stuck in 1152x864, this caused me to suspect libdrm was the problem. So I went ahead and downgraded libdrm/lib32-drm with pacman -U --nodeps and then rebooted --> BING0 right back to 1440x900. Some notes on the log for the downgrade. The downgrade log looks weird to me. Maybe that's the way it should look, but I would expect correct version numbers: [2009-12-23 02:00] upgraded libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded ati-dri (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:04] upgraded libdrm (2.4.17-2 -> 2.4.17-1) [2009-12-23 02:04] upgraded lib32-libdrm (2.4.17-2 -> 2.4.16-1) I may have missed some changelog that says change your config to XYZ for these packages, but honestly it just looks like this set of updates isn't quite done cooking yet. Let me know if you need for info, etc. I'm glad to provide logs, etc. I'll also go ahead and open a ticket if you think it is necessary. 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

2 5

[arch-general] Xorg changes / DRM modules
by Andreas Radke 23 Dec '09

23 Dec '09

I've updated the git packages for nouveau and ati ddx driver packages in testing. I also updated the nouveau-drm package. This required to add the new nouveau-firmware package. It will be also needed to use kernel nouveau-drm module that will be introduced with kernel 2.6.33. I will keep updating the separate nouveua-drm module for a while to get features and fixes faster than in Linus tree. The firmware will probably also result in loading issues in early kms mode. We might think about recommending late mode for now. libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy

5 5

[arch-general] Where'd the media:/ kioslave go in KDE4?
by David Rosenstrauch 23 Dec '09

23 Dec '09

Anyone know where the "media:/" kioslave has gone? When I enter that into konqueror it tells me "Protocol not supported media". For that matter, "system:/" and a few others seem to be missing as well. Am I missing some packages? Or did these go the way of the dodo in KDE4? Thanks, DR

1 0

[arch-general] [pkgstats] Patch to allow pkgstats to submit info through a proxy (if this is setted on http_proxy)
by Angel Velásquez 23 Dec '09

23 Dec '09

Hi, I've been trying to submit my stats to the statistics page [1], then I realized that I wasn't submitting anything (I had pkgstats running on a cron). Then I decided to find the reason and it's simply I am behing a noisy and non-transparent proxy (ISA Server which is even worst). So, I decided to do a little patch to pkgstats, I've tested and now it's working .. (I am checking if the http_proxy env var is empty and else I am setting a variable called prox which have the value of the proxy). Just that ;), patch attached [1] https://www.archlinux.de/?page=PackageStatistics -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

3 6

Re: [arch-general] [arch-dev-public] Xorg changes / DRM modules
by Heiko Baums 23 Dec '09

23 Dec '09

Writing again to arch-general because of write permissions. Am Wed, 23 Dec 2009 11:21:03 +0100 schrieb Andreas Radke <a.radke(a)arcor.de>: > The sad part is that we leave all people with modern Ati cards in the > dark until upstream declares their code as stable. This will make them > going back to software rasterizer and either force them to use the > closed source driver or use weird self made git packages from AUR. Doesn't matter. A stable running system is better than new features which don't work yet, lead to regular crashes and make a system unusable. Some people need a stable system for working and need to trust in the stable repos. > Because I'm also affected with my weird X200m card I'm still looking > for a good solution how to offer a good set of binary packages people > can use to try modern code. I could do this on my own like all other > people from AUR but we could also setup an additional unstable repo at > Gerolde. I could do this also in my public dir. I'd prefer to have > people using one set of codebase for reporting bugs upstream. What do > you think? Aren't there already git versions for these packages in AUR? If you want to provide binary packages for them you could just move them to community or extra. But keep the names e.g. mesa-git, libdrm-git etc. and add a provides and conflicts variable to the PKGBUILDs (e.g. provides=libdrm and conflicts=libdrm). And by default (e.g. with pacman -S xorg) the stable packages are installed and if someone wants to test the unstable packages he can simply install the git packages. You could also add a new group xorg-git. In this case there should also a conflicts variable be added to the PKGBUILDs of the stable packages (conflicts=libdrm-git). I think with this solution everyone could be happy, people who need a stable system and people who want to test the latest unstable versions. And it has the advantage that people can easily switch between the stable and the unstable packages depending on how those packages work. When the new features go into the stable upstream packages the git versions could simply be removed from the repos. Greetings, Heiko

1 0

[arch-general] A universal Operating System API - why don't we have it?
by RedShift 22 Dec '09

22 Dec '09

Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... Why doesn't the computer business have something similar? Sure processors are interchangeable in a limited way, we use standardized RAM, standard interfaces for accessing our peripherals, etc... But not when it comes to software. Why don't we have one universal API that works on every operating system? Yes there is libc, the language C is defined "in some way", but I'm talking about stuff that would make applications 100% portable. Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all "extra" features. So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a "child" in some way, compared to other industries? Just a thought. Glenn

15 19