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.
]]>I'm sorry about all the mix ups... but I haven't found a single Xorg problem yet...
]]>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.
]]>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.
]]>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 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.
]]>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
]]>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.
]]>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.
]]>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).
]]>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
]]>