Patrick/Laca: > Looking at spec-files/prototypes/x86/SUNWgnome-display-mgr-root.proto, > we also have 0755,root,sys for everything under /var/svc/manifest, > so I don't see any conflict there. > > gdm.xml being 644 instead of 444 is a P4 issue, but fixing it is > ~1 min.
I just bumped the gdm.spec file to use the new gdm 2.20.3. While doing this, I fixed the gdm.xml file so it has 444 permissions, so this issue should now be fixed. Patrick, I suspect your file-conflict issue is related to your BFU. The problem with BFU is that it only updates the base kernel and not all of Solaris, so it can leave you system in an odd state. For example, I don't think anything in the desktop layer or in /usr/sfw gets updated when you do a BFU so you can end up with old cruft there causing unique build issues, for example. I remember having an odd issue a while back when I BFU'ed my system in order to work with the Virtual Terminal code. Doing this broke my frkit battery applet. I suspect that was because the battery applet was officially added to Solaris in between my original build and the BFU'ed build, but all the bits needed for it to work didn't get updated in the BFU. When I later reinstalled to a newer version of Nevada, it started working again. Not exactly the sort of issue you are seeing, but another example of odd BFU issues you can run into with the desktop code. Sometimes you can address these sorts of issues by uninstalling and reinstalling newer versions of various packages, but it is not always obvious what packages you need to update. Brian > On Mon, 2008-01-07 at 14:43 +0800, Lin Ma wrote: >> Due to the definition of SUNWcsr, we get: >> >> d none var/svc 755 root sys >> d none var/svc/log 755 root sys >> d none var/svc/manifest 755 root sys >> d none var/svc/manifest/application 755 root sys >> d none var/svc/manifest/application/management 755 root sys >> d none var/svc/manifest/application/security 755 root sys >> d none var/svc/manifest/device 755 root sys >> d none var/svc/manifest/milestone 755 root sys >> f manifest var/svc/manifest/milestone/multi-user.xml 0444 root sys >> f manifest var/svc/manifest/milestone/multi-user-server.xml 0444 root sys >> f manifest var/svc/manifest/milestone/name-services.xml 0444 root sys >> f manifest var/svc/manifest/milestone/network.xml 0444 root sys >> f manifest var/svc/manifest/milestone/single-user.xml 0444 root sys >> f manifest var/svc/manifest/milestone/sysconfig.xml 0444 root sys >> d none var/svc/manifest/network 755 root sys >> f manifest var/svc/manifest/network/forwarding.xml 0444 root sys >> f manifest var/svc/manifest/network/inetd.xml 0444 root sys >> ... >> >> You may see all of them are root:sys, so probably the bug is in >> SUNWgnome-display-mgr. >> >> BTW, gdm.xml is delivered as 0644 which is also wrong. So you may file a >> P3 bug for it. >> ll /var/svc/manifest/application/graphical-login/gdm.xml >> -rw-r--r-- 1 root sys 1779 Jan 1 06:30 >> /var/svc/manifest/application/graphical-login/gdm.xml >> >> Thanks, >> lin >> >> Alan Coopersmith wrote: >>> Patrick Ale wrote: >>>>> It's just a bug in either SUNWdtlog or SUNWgnome-display-mgr-root >>>>> (I haven't checked to see which one has it right or which changed >>>>> most recently to not match the other.) >>>> I've done a BFU to onnv_80 last week so I honestly can't tell you. >>>> Is there a way for a non-sun or non-internal-server access having >>>> person (nice sentence) to pinpoint this out? >>> You should be able to browse the SUNWgnome-display-mgr spec history >>> in svn outside the firewall. If you had copies of the SXCE install >>> images around for past builds, you could check the pkgmap file in >>> the SUNWdtlog packages there, but since it's part of the closed-source >>> CDE, only someone behind the firewall can check its code history. >>> >
