After a bit of discussion, we[1] agreed that it makes sense to try to put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases it seems to be a minimally risky proposition. Additionally, GNOME appears to be right on schedule. We may have to push out the Cambridge release date a little, but it's looking very good in general. Alex and I will be rebuilding and upgrading the packages in rawhide over the next week or so.
Thanks, -Jonathan
[1] Those of us on the desktop team, anyway.
On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote:
After a bit of discussion, we[1] agreed that it makes sense to try to put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases it seems to be a minimally risky proposition. Additionally, GNOME appears to be right on schedule. We may have to push out the Cambridge release date a little, but it's looking very good in general. Alex and I will be rebuilding and upgrading the packages in rawhide over the next week or so.
For those of us using NyQuist's apt repository - would it be a good idea to downgrade to RedHat's gnome packages now, or will the transition likely be smooth enough to just stop upgrading from nyquist's repository?
Thanks, -Jonathan
[1] Those of us on the desktop team, anyway.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote:
After a bit of discussion, we[1] agreed that it makes sense to try to put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases it seems to be a minimally risky proposition. Additionally, GNOME appears to be right on schedule. We may have to push out the Cambridge release date a little, but it's looking very good in general. Alex and I will be rebuilding and upgrading the packages in rawhide over the next week or so.
Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively clean?
How many config files will break?
-sv
On Fri, Aug 08, 2003 at 02:28:25PM -0400, seth vidal wrote:
Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively clean?
How many config files will break?
The stated objective with GNOME is that if you have an NFS home directory used by 2.0, 2.2, 2.4, 2.6, and 2.8 systems then everything still works. "Works" meaning nothing gets confused; it's possible you have have to configure something twice, for different GNOME versions, but the two configurations should coexist.
If this doesn't hold true, it's a bug; file a bug report with details on where it breaks.
Havoc
On Fri, 8 Aug 2003, Havoc Pennington wrote:
On Fri, Aug 08, 2003 at 02:28:25PM -0400, seth vidal wrote:
Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively clean?
How many config files will break?
The stated objective with GNOME is that if you have an NFS home directory used by 2.0, 2.2, 2.4, 2.6, and 2.8 systems then everything still works. "Works" meaning nothing gets confused; it's possible you have have to configure something twice, for different GNOME versions, but the two configurations should coexist.
For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective....
later, chris
For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective....
I have been told by others that I am 'beating a dead horse' when I bring up gconf sucking on network mounted homedirs with multiple simultaneous logins.
so I think it is safe to assume that the answer to the above question is 'no'.
-sv
skvidal@phy.duke.edu (seth vidal) writes:
I have been told by others that I am 'beating a dead horse' when I bring up gconf sucking on network mounted homedirs with multiple simultaneous logins.
What is with non-simultaneous logins? How can I prevent the .fonts.cache-regeneration-memorial-minute after logging in on another machine?
Enrico
On Fri, 2003-08-08 at 15:52, Enrico Scholz wrote:
skvidal@phy.duke.edu (seth vidal) writes:
I have been told by others that I am 'beating a dead horse' when I bring up gconf sucking on network mounted homedirs with multiple simultaneous logins.
What is with non-simultaneous logins? How can I prevent the .fonts.cache-regeneration-memorial-minute after logging in on another machine?
hmm I've not experienced that. Can you describe it some more or link to a bug?
-sv
skvidal@phy.duke.edu (seth vidal) writes:
What is with non-simultaneous logins? How can I prevent the .fonts.cache-regeneration-memorial-minute after logging in on another machine?
hmm I've not experienced that. Can you describe it some more
~/.fonts.cache-1 is shared between machines whose font-directories might have different timestamps. When started on machine A, the ~/.fonts.cache-1 file can contain the timestamps of machine B and applications will regenerate the cache therefore. The same repeats on machine B because fonts.cache-1 has now the machine A timestamps. Now, the recursion starts at A again...
Enrico
On Mon, 2003-08-11 at 17:51, Enrico Scholz wrote:
skvidal@phy.duke.edu (seth vidal) writes:
What is with non-simultaneous logins? How can I prevent the .fonts.cache-regeneration-memorial-minute after logging in on another machine?
hmm I've not experienced that. Can you describe it some more
~/.fonts.cache-1 is shared between machines whose font-directories might have different timestamps. When started on machine A, the ~/.fonts.cache-1 file can contain the timestamps of machine B and applications will regenerate the cache therefore. The same repeats on machine B because fonts.cache-1 has now the machine A timestamps. Now, the recursion starts at A again...
If you always run fc-cache on the parent directory (*) of any place you install fonts, then this shouldn't be an issue.
~/.fonts.cache-1 is only for font directories that don't have proper fonts.cache-1 files in them.
Regards, Owen
(*) Parent directory or directory itself depends on the details, but if you install stuff in /usr/share/fonts/foo it's better to run fc-cache /usr/share/fonts.
otaylor@redhat.com (Owen Taylor) writes:
~/.fonts.cache-1 is shared between machines whose font-directories might have different timestamps. When started on machine A, the ~/.fonts.cache-1 file can contain the timestamps of machine B and applications will regenerate the cache therefore. The same repeats on machine B because fonts.cache-1 has now the machine A timestamps. Now, the recursion starts at A again...
If you always run fc-cache on the parent directory (*) of any place you install fonts, then this shouldn't be an issue.
This seems to be a bug in the %post scriptlets of the font-packages. E.g. /usr/share/fonts/zh_TW/TrueType/ contains
| -rw-r--r-- 1 root root 8586 25. Jul 14:11 fonts.cache-1 | -rw-r--r-- 1 root root 945 28. Jul 21:26 fonts.dir
When calling the questionable /usr/bin/redhat-update-gnome-font-install* programs manually, the timestamp of fonts.cache-1 does not change. But since the directory is changed by rpm's cpio, the local ~/.fonts.cache-1 will be updated.
The same happens with /usr/X11R6/lib/X11/fonts/{75dpi,Type1,misc} which are having very old fonts.cache-1 files (Jan 08, 2003).
Enrico
enrico.scholz@informatik.tu-chemnitz.de (Enrico Scholz) writes:
~/.fonts.cache-1 is shared between machines whose font-directories might have different timestamps...
If you always run fc-cache on the parent directory (*) of any place you install fonts, then this shouldn't be an issue.
This seems to be a bug in the %post scriptlets of the font-packages.
Hmm, I am wrong; the scriptlets are ok. Problem happens since something (XFree86 update, xfs startup?) triggered the regeneration of fonts.dir/scale without doing 'fc-cache' also.
Enrico
On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote:
For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective....
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
Given that preliminary setup, the last bugs in multiple logins should have been fixed in RHL 9.
But as Seth says the "real fix" is well-known and it's just a matter of someone having time to implement it. It is certainly known that opening TCP between machines isn't a great solution.
Havoc
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
What makes this one so much more dangerous?
Given that preliminary setup, the last bugs in multiple logins should have been fixed in RHL 9.
But as Seth says the "real fix" is well-known and it's just a matter of someone having time to implement it. It is certainly known that opening TCP between machines isn't a great solution.
And as you and I have talked about before. In some cases it is impossible. b/c the two machines might not be able to see each other.
-sv
On Fri, Aug 08, 2003 at 03:20:48PM -0400, seth vidal wrote:
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
What makes this one so much more dangerous?
Because you can sometimes get inconsistent configuration state that confuses the panel or gnome-terminal. Usually would show up as losing terminal profiles or losing panels probably. I would expect this to be rare but Owen argues it will happen a lot, and there have been a couple reports.
And as you and I have talked about before. In some cases it is impossible. b/c the two machines might not be able to see each other.
Yep.
Havoc
On Fri, 2003-08-08 at 15:25, Havoc Pennington wrote:
On Fri, Aug 08, 2003 at 03:20:48PM -0400, seth vidal wrote:
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
What makes this one so much more dangerous?
Because you can sometimes get inconsistent configuration state that confuses the panel or gnome-terminal. Usually would show up as losing terminal profiles or losing panels probably. I would expect this to be rare but Owen argues it will happen a lot, and there have been a couple reports.
oh - you mean dangerous in that sense. Yah. ok. I was one of the reporters of this - and yah - we got the configuration corruption to occur with relative ease.
ok. Thanks -sv
On Fri, 8 Aug 2003, Havoc Pennington wrote:
On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote:
For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective....
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
How does one do these? I assume the second is an env variable, but what's the first? And what's more dangerous about the second?
later, chris
On Fri, Aug 08, 2003 at 01:24:35PM -0600, Chris Ricker wrote:
On Fri, 8 Aug 2003, Havoc Pennington wrote:
On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote:
For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective....
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
How does one do these? I assume the second is an env variable, but what's the first? And what's more dangerous about the second?
See www.gnome.org/projects/gconf/, conceivably the GNOME admin guide at www.gnome.org/learn/ has something on it too.
For dangerousness see my reply to Seth just now.
Havoc
On Fri, 8 Aug 2003, Chris Ricker wrote:
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
How does one do these? I assume the second is an env variable, but what's the first?
echo ORBIIOPIPv4=1 > ~/.orbitrc
Can also be done per-machine using /etc/orbitrc. IPv6 should also work, if that's your piece of cake.
-- Elliot Humpty Dumpty was pushed.
On Fri, 8 Aug 2003, Elliot Lee wrote:
On Fri, 8 Aug 2003, Chris Ricker wrote:
It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1
How does one do these? I assume the second is an env variable, but what's the first?
echo ORBIIOPIPv4=1 > ~/.orbitrc
Can also be done per-machine using /etc/orbitrc. IPv6 should also work, if that's your piece of cake.
Hmm, when I try that, either .orbitrc or /etc, when I start GNOME I get:
"There was an error starting the GNOME Settings Daemon.
Some things, such as themes, sounds, or background settings may not work correctly.
The Settings Daemon restarted too many times.
GNOME will still try to restart the Settings Daemon next time you log in."
This is on rawhide
later, chris
seth vidal skvidal@phy.duke.edu writes:
On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote:
After a bit of discussion, we[1] agreed that it makes sense to try to put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases it seems to be a minimally risky proposition. Additionally, GNOME appears to be right on schedule. We may have to push out the Cambridge release date a little, but it's looking very good in general. Alex and I will be rebuilding and upgrading the packages in rawhide over the next week or so.
Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively clean?
The big thing I can think of is that we now use ~/Desktop instead of ~/.gnome-desktop for the users desktop by default.
-Jonathan
On Fri, 2003-08-08 at 14:48, Jonathan Blandford wrote:
The big thing I can think of is that we now use ~/Desktop instead of ~/.gnome-desktop for the users desktop by default.
On one hand, that's a very small change.
On the other... Great! In many ways - it's not a hidden directory anymore, it's the same dir used by KDE, etc.
I love when things get compatible. :-)
-
Chris Ricker -
Elliot Lee -
Enrico Scholz -
Florin Andrei -
Havoc Pennington -
Jonathan Blandford -
Owen Taylor -
Sean Middleditch -
seth vidal