[webstack-discuss] [sfwnv-discuss] diffs in CRs [Re: WebRTI: ....]
>From sfwnv-discuss-bounces at opensolaris.org Tue Nov 13 21:16:20 2007 >Mike.Sullivan at sun.com wrote: >> >> BTW please go make sure to fill out the suggested fix for each bug, >> I looked at two and saw none. While it would be best to put the >> fix for each bug only in that bug, if you can't it's ok to attach >> the diffs to one and then point the other bugs at that one. Please >> don't attach the tarballs of course, just the other changes. > >Who in the current process makes use of diff's in/attached to the CRs? People From The Future. And me. >For what purpose? to try to figure out what changed and why, without having to track down putback logs and all the files involved. >Why? perhaps when backporting a bug fix, or when trying to figure out if the fix made broke something else. >I dislike diffs in CR text (for what should hopefully be obvious >reasons) so I want to explore why is this being done and how to fix it >in the process of whoever is dependent on them. umm ok. However I've been on the recieving end of "why did you make this change 10 years ago without filling in the suggested fix with exact diffs" many times. And I look at diffs in bugs all the time when trying to figure out what changed in why, particularly when looking at bugs that affect things outside a source base I'm familiar with. And sometimes I look at them when approving rti's because they're easier than a webrev for me. But perhaps I'm just strange. Mike
[webstack-discuss] [sfwnv-discuss] webrev review requested for the various miscellaneous PHP5 features
>From sfwnv-discuss-bounces at opensolaris.org Mon Nov 26 15:50:11 2007 >> If not, we >> should discuss and decide on one. > >Ok... >... who is the gatekeeper for SFWNV ? me... but while I would like things to be as consistent as they can be (because todays's maintainer of the foo package may not be tomorrow's) I'm not really interested in going to meetings about shell style. And while yes, if such standards are agreed on I do think going and fixing all the scripts would be a good thing, I'd also hope it would be a one-time thing and not something that happens each time a nifty new shell feature comes along :) Mike
[webstack-discuss] [sfwnv-discuss] webrev review requested for the various miscellaneous PHP5 features
>From roland.mainz at nrubsig.org Mon Nov 26 16:34:41 2007 >> me... but while I would like things to be as consistent as they >> can be (because todays's maintainer of the foo package may not be >> tomorrow's) I'm not really interested in going to meetings about shell >> style. > >Would you be interested to sponsor an all-in-one cleanup patch >(including things like adding "-xtrconst" to CFLAGS (e.g. less memory >wasted with duplicate string literals etc.) etc. ...) ? I don't want to sponsor anything myself, it feels a bit wrong given I'm the gatekeeper and seem to be involved in reviewing/approving things already. But someone else could. That's assuming everything is properly tested, one cannot just turn on -xstrconst and assume it works of course. Mike
[webstack-discuss] [sfwnv-discuss] CR 6665970 (memcached 1.2.5) - Code Review Request
>From sfwnv-discuss-bounces at opensolaris.org Wed Mar 12 05:57:19 2008 >Running checkproto on my workspace gives the following output: > >error: SUNWmemcached: hardlink to non-existent file: >usr/lib/memcached=/usr/lib/isaexec >warning: SUNWmemcachedr: duplicate entry for etc/security/auth_attr - >ignored >error: Errors found in >/export/home/victor/memcached/usr/src/pkgdefs/SUNWmemcachedr/prototype_com >warning: SUNWmemcachedr: duplicate entry for etc/security/prof_attr - >ignored >error: Errors found in >/export/home/victor/memcached/usr/src/pkgdefs/SUNWmemcachedr/prototype_com > >The hardlink error there's nothing to do about I believe? Well if that's true you're also not putting this back :) It's upset because, as it says, you're linking to a file that's not in the proto area. And since /usr/lib/isaexec is in ON not sfw, that's not surprising. First I'd guess that should be a relative link anyway or install isn't going to be happy. But then I'd wonder if it's really legal to make a hard link to that binary in the first place? I don't even see a man page for it on my desktop, so I'd wonder if it's really consolidation-private to ON (but haven't looked in the ARC database). If it's not, you'd have to copy it from somewhere into the proto area (ick). But you might also see if a symlink works, or perhaps just write your own given isaexec(3C) is documented and stable. >The two "duplicate entry" warnings are confusing. I cannot see why this >is happening. because you can't deliver the same file in multiple packages, and protocmp doesn't know that you aren't really because you're using a class-action script to do the install. I think this is already done for exec_attr, as long as you're doing what other packages do with that it might be that you just need to add an exception. Which isn't the ideal thing but it's probably simplest. >Another thing I noticed is that when installing the SUNWmemcachedr >package multiple times on the same system the header lines between CDDL >HEADER START and CDDL HEADER END are added the same number of times to >/etc/security/auth_attr and /etc/security/prof_attr. Is something wrong >with the i.rbac script? I don't know, did you check bugster? It could be that we're just using an older i.rbac script since I see a bug that might be this fixed a while ago in ON: D 1.12 06/02/16 17:08:43 X 13 12 00024/00011/00348 MRs: COMMENTS: 6365088 New CDDL header gets added to /etc/security/exec_attr every upgrade You may want to upgrade the sfw copy of i.rbac, I think there may be a bug for that already. Mike
[webstack-discuss] [sfwnv-discuss] Reminder: CR 6665970 (memcached 1.2.5) - Code Review Request
>From sfwnv-discuss-bounces at opensolaris.org Thu Mar 13 17:44:17 2008 >In memcached/install-sfw, you're copying the rbac (not smf, btw) files into >place, even though you don't completely own them. Mike, is this okay with >you? It seems like this should be done in a more common location. I haven't looked at what this is doing, but there are a bunch of other things that I believe just add their bits to the rbac files. This should do what they do. There may be build dependencies that they use to make sure only one creates the initial proto area files though. I think the right thing is really to do the package fragment thing that you added support to protocmp for in 6460124, but some of these things seem to target updates and can't use that yet. No it's not common yet though, nobody has wanted to do that :) >SUNWmemcached-java/depend: same comment, though shouldn't you have a >dependency on one of the java packages (SUNWj6rt or something)? Maybe j5rt as we build with java 1.5 still. Mike
[webstack-discuss] [sfwnv-discuss] resend: need Code Review for Lighttpd 1.4 integration
>From sfwnv-discuss-bounces at opensolaris.org Tue Apr 22 01:02:26 2008 >> - Why does it need "LD_LIBRARY_PATH=/opt/SUNWspro/lib", that seems odd? >> > >This was done as a temporary measure to get round the mysql_config >--libs problem. Basically it needs to find libcrun in the linker library >path, at run time is uses the /usr/lib/libcrun.so but I was concerned >about trying to coerce the linker to look into /usr/lib at build time. The C++ compiler should already handle finding its libCrun link there. Are you using CC to link or ld directly? Don't forget -norunpath too if you're linking C++ stuff. BTW you shouldn't hardcode /opt/SUNWspro - if you _really_ need to find the compiler you need to do it via the variables in Makefile.master (probably $(SPRO_VROOT)/lib). Though I'd be surprised if you really need to, it really sounds like something is linking with ld but should be using CC. Mike
[webstack-discuss] [sfwnv-discuss] Webrevs for Review: Ruby Integration.
>From sfwnv-discuss-bounces at opensolaris.org Mon Nov 5 12:52:26 2007 >Shanti > Well, there seems to be a bit of disconnect here. Sun Studio Compiler >folks consistently recommend us to use '-fast' compiler option but at >the same time folks reviewing our integration within SXDE give a >consistent 'NO' to this option. I am not sure, what is the right >direction here. It will be very unfortunate and confusing for folks >using SXDE or Indiana if components from Cool Stack can significantly >out perform. The important thing is that the output of the build should be the same whether I'm building on the wimpiest machine we support or the super-fastest we want to make look good. And the binaries run on all supported machines (and I'd hope, at great performance on all even if that means a bit more work). Reproducible build output is a good thing. If you can use -fast and then use other options that then make the above true then perhaps that's ok. But I'd still probably prefer making explicit all the options you want instead so that maintainers that follow you know exactly what you wanted. Plus I'd be a little bit worried about this: The expansion of -fast can change from one release of the compiler to the next which could mean it gets worse or better, but maybe just different, but still you don't know what it may mean in SS11+ (though of course one hopes any explicit options still mean the same too :) Then there's this: NOTES If you specify -fast, you should not rely on the value of errno because the value can change as a result of code optimization. The easiest way to avoid this problem is to not specify -fast. which would seem to be bad for code in sfw since we don't control it. Mike
