XFCE 4.10
Hello, just curious if you know the time-frame for 4.10 hitting the SL in packaged form :) ? Thank you AZ
Re: [SCIENTIFIC-LINUX-USERS] XFCE 4.10
On 05/31/2012 10:38 AM, Andrew Z wrote: Hello, just curious if you know the time-frame for 4.10 hitting the SL in packaged form :) ? Thank you AZ With xfce making its way into EPEL, we are letting the packaging happen up there. Pat -- Pat Riehecky Scientific Linux Developer
One more SL5.7-5.8 gotcha: autofs and special filesystems
While this is not an SL-specific problem, I thought I'd document it here to save others from tearing out their hair. We have a handful of system that run tomcat in a chroot. They require /proc and so we mount it inside the chroot using autofs. The entry in the map looked like this before the upgrade to SL5.8: /path/to/chroot/proc proc-tomcat60 Since there's no real source file system we use 'proc-tomcat60' here to provide some meaningful information in the output of commands such as df. Well, this broke after the update. I'm not sure why, but we now have to prepend 'proc-tomcat60' with a colon like this: /path/to/chroot/proc :proc-tomcat60 Seems we were bitten by a number of minor text changes this round of patching! What a different one character can make. Oy! :-) -- Chris O'Regan ch...@encs.concordia.ca Senior Unix Systems Administrator, Academic IT Services Faculty of Engineering and Computer Science Concordia University, Montreal, Canada
Re: XFCE 4.10
On 06/01/2012 03:16 AM, Glenn Morris wrote: Andrew Z wrote: just curious if you know the time-frame for 4.10 hitting the SL in packaged form :) ? Probably no time soon, since it apparently requires newer versions of Gtk+, Glib etc than exist in SL 6. http://docs.xfce.org/xfce/building Xfce 4.10 requires Gtk+ 2.20 and Glib 2.24 SL6 has 2.18 and 2.22. This sort of thing is why you exchange cutting edge for stability. Its the same issue with moving KDE ahead to 4.3: a lot of the core distro would have to go along with it. The dependency breakages (or, at a minimum, package rebuilds) required are a hard enough maintenance problem that its better to just spin off a new distro than to deal with rifted library problems. Distros get hard to maintain pretty fast, which is why most distros don't make it very far. Since both XFCE and KDE aren't part of SL or TUV's distro but come from EPEL (and probably other repos) its impossible to expect the SL team to decide to fork the entire distro for the sake of one window manager, as this is completely against their goals.
