You are not logged in.
Pages: 1
Dear Arch Package Maintainers,
We are having a lof of varied, yet serious problems with xorg 6.8.0...
We know from the package maintainer himself that there is a problem with the xorg.sh script...There are additional export'd variables that need to happen, and KDE 3.3 and it are not co-habiting in peace at this time.
PLEASE... Before more systems loose their menus, may I request that the current xorg 6.8 package be pulled from the repository until it's fixed, and the xorg 6.7 release be put back online to allow folks to download it who had their system hose over (like me).
We're working on it... I just don't want to see more issues until we can pin it down to exactly what's happening.
Respectfully,
Dave Babb
Offline
If you hosed your system on upgrade why don't you just downgrade? You should have the 6.7.0 package on your system still in /var/cache/pacman/pkg/
I'm not sure that I think it should be pulled. Sure there are problems, but they aren't arch specific. Granted though I added xorg to NoUpgrade in my pacman.conf after experiencing font oddities.
Offline
I also regularly do a pacman -Scc..............so /var/cache gets flushed...
I DID have it on a CD I cooked, and downgraded back to 6.7, and modified the permissions that got screwed up in my .kde tree, and restored normal operation....
But many folks, just aren't comfortable with this level of system administration.
I've also been in dialog with ICEman, who takes responsibility as the package maintainer for xorg.... and he is aware of errors(self-admitted) and ommisions in the xorg.sh script....
If their wern't admitted errors in it.... then I wouldn't have made such a drastic request as to pull the file... But there are errors, unless ICEMan is not actually the package maintainer as he claims.
I'm relatively new to Arch (< 3 months) to have all the names and positions sorted out yet...
SO if I'm personally hosed over, please accept my sincerest apologies...
Sincerely,
Dave
Offline
Xorg works fine here, with Fluxbox, so it seems it's a problem with KDE instead of Xorg, so that should be fixed, not Xorg.
Offline
Offline
In the current xorg 6.8 package, there is an xorg.sh script that needs fixing.
It affects evironment variables...
It's not a hard fix.... but KDE users are going to have grief with it, and it IS in the xorg package itself, and as thus, the xorg package needs repairing... Not xorg the server, but xorg the package...
If not pulling the package to repair what is now a known issue with package content...
Then I truly don't understand..........
Like I said in the subject... last post for me on this subject..............
Dave...........
Offline
I just completed a fresh ftp install and I am having problems with xorg and xfce4. Though it appears to be a mainly xorg issue. Screen doesn't draw correctly and freezes whole computer.
Offline
Xorg works fine here, with Fluxbox, so it seems it's a problem with KDE instead of Xorg, so that should be fixed, not Xorg.
I have the same Problem not only with KDE but with Gnome too. some standard menue entries still there (just like KDE) but no applications entries anymore.
Really annoying. I reinstalled xorg 6.7.0 and resently even tried Xfree 4.4.0. But nothing helps. Menues still gone . Does anybody know which environment variables i have to set to get it fixed?
CU ActionNews
[URL=http://www.nethands.de/athlon/show.php3?user=actionnews]My System[/URL] - one click ahead!
Offline
(inspired by /etc/profile.d/kde.sh)
/etc/profile.d/gnome.sh should look like the one below:
export GNOMEDIR=/opt/gnome
export PATH=$PATH:$GNOMEDIR/bin
export MANPATH=$MANPATH:$GNOMEDIR/man
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$GNOMEDIR/lib/pkgconfig
export LIBGLADE_MODULE_PATH=$LIBGLADE_MODULE_PATH:$GNOMEDIR/lib/libglade/2.0
if [ ! -z $XDG_DATA_DIRS ]; then
export XDG_DATA_DIRS=$XDG_DATA_DIRS:$GNOMEDIR/share
else
export XDG_DATA_DIRS=$GNOMEDIR/share
fi
# if [ ! -z $XDG_CONFIG_DIRS ]; then
# export XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$GNOMEDIR/etc/gconf
#else
# export XDG_CONFIG_DIRS=$GNOMEDIR/etc/gconf
#fi
I don't know if the last part is correct since I don't know the internals of Gnome.
Unfortunately, why trying to tune the config files around my system, I managed to break it (KDE to be more precise), WITHOUT upgrading Xorg!
This does not guarantee though that it will work afterwards (it doesn't work for me, although it looks good... & the environment variables look good too).
:: / my web presence
Offline
xorg needs to be fixed desperately... why can't we keep stuff in testing until it's fully tested?
If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. 1 Corinthians 13:2
Offline
Xorg works perfect for me. In Firefox, XFCE, Pekwm, and everything else.
Why don't you all stop bitching and blaming people? If there are problems, file bug reports. The developers don't have 100 machines to test on, so problems that only occur for some people may get missed.
This is also not a problem with Arch itself, and the Arch philosophy is very much "let it be fixed upstream". All the env variable things will probably be fixed soon, they seem simple enough.
"Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."
Offline
anyway, you're not forced to install everything that gets to current. You can use IgnorePkg for important stuff, like the kernel, and in your case, x.
And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.
Offline
This is also not a problem with Arch itself, and the Arch philosophy is very much "let it be fixed upstream". All the env variable things will probably be fixed soon, they seem simple enough.
They are simple allright.... but it'd difficult to predict how one tiny variable can mess up an entire Desktop Environment (might be a bug in the Desktop Environment(s)).
I think the best think to do is to update Xorg (with the new variables), KDE (kdelibs) with specific variables and probably Gnome (the specific module, with the correct variables). Different configurations require different solutions, which will come up once everyone has the correct variables.
The env variables can't theoretically hurt the Desktop Enviroments because they are supposed to work properly. If something's not working well, it's definitely a bug in the DEs.
:: / my web presence
Offline
Gentlemen,
I've read the posts in this Forum and the "Package Config Problems" forum and I don't see bitching - I see urgent requests from a LARGE group of users (using both KDE and Gnome) trying to get their systems back in working order.
This wasn't a problem with machine specific differences - it was a problem with package scripts. Some bad code slipped through - it happens. I don't see anyone trying to flame anyone - I see requests to work as a community to CORRECT the problem, and a common sense part of that correction would be to pull the package till the buggy scripts are corrected so no more people are affected. To do anything else is to embrace the microsoft philosophy of user support.
Let's not let wounded egos and misunderstandings drag us down to the microsux level.
Flame me if you want - This is just my two cents....:)
Cheers
Lee
Offline
i don't see any bitching either. all i see is common sense requests. any big important package like xorg, glibc, gcc, kernels, and so forth should always go into testing first. there appears to be plenty of people willing to use the testing repo and all the "possible" bugs it may encompass.
i thought that was what the testing repo was for.
many users use simple wm like fluxbox or pekwm. but many use kde or gnome and they should have the comfort of being able to upgrade with out much worry.
if arch is going to support kde and gnome then they better be able to accommodate for the other issues it provides. users should not have to constantly edit their NoUpgrade sections.
i have learned enough to wait a few hours or days before taking on upgrades of major packages but this really should not be the case. One should be confident in the current repo. it is, afterall, suppose to be a stable repo.
AKA uknowme
I am not your friend
Offline
Hmmm... testing repo... my records show that xorg sat in testing for 3 days, from september 9th to september 12th. A few bugs were found when it was in there too.
How many people tested it and gave feedback? I know of one, tpowa. Can anyone else step up?
If you want a reference (to show that it actually was in testing and no kde people complained about such a problem), there's a thread in this very category: http://bbs.archlinux.org/viewtopic.php?t=6677
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
obviously testing has to be better promoted and the testing length of three days is not appropriate.
AKA uknowme
I am not your friend
Offline
the kde problem appeared only if you changed your menu before
and it seems all that tested didn't changed their menus else it would have been reported but it was greatly fixed in the forum and now included in the packages
Offline
the problem ithough is that people will still look upon this as sloppy packaging which arch already has a reputation for, whether it is a desreved accusation or not.
failure to address this will just mean a continuing bad rep.
oh and it is great that there is info on the forum to fix this but a front page announcement/warning would be good and something to the mail list as MANY people do not use the forum.
AKA uknowme
I am not your friend
Offline
any big important package like xorg, glibc, gcc, kernels, and so forth should always go into testing first.
With Xentac I agree few will do the tests. I suggest to have an "old-pkg" repo for users to downgrade important packages whenever there is a problem.
Markku
Offline
My Gnome just works purrrrrrrrrrfectly :twisted:
I'm sorry about all the mix ups... but I haven't found a single Xorg problem yet...
Offline
sarah31 wrote:any big important package like xorg, glibc, gcc, kernels, and so forth should always go into testing first.
With Xentac I agree few will do the tests. I suggest to have an "old-pkg" repo for users to downgrade important packages whenever there is a problem.
But if packages were left in testing longer then there would be more incentive for people to test them. And more people would access the testing repository if they were desperate to install the latest and greatest.
However, for most users, theres no point in being bleeding edge just for the sake of being bleeding edge, particularly if packages are buggy.
Quality rather than quantity.
Offline
Pages: 1