James C. McPherson wrote:
> On 31/05/10 12:04 PM, Garrett D'Amore wrote:
>> I need a quickie code review... just Makefile and packaging really.
>> This cleans up graph and spline, which will enable a bunch of other
>> lpsched and postscript conversion cleanups. (Ultimately this
>> facilitates remo
Albert Lee writes:
>
> Likewise, if cdm's pbchk is already catching #pragma ident, it's clearly a
> bug for it to ignore #ident.
>
It catches anything that looks to be an SCCS keyword, it shouldn't care
about #ident, #pragma ident, or any other non /%.%/ section of the line
containing them.
--
James Carlson writes:
> % find /usr/perl5 -print | fgrep Scalar/Util
> /usr/perl5/5.8.4/lib/Scalar/Util.pm
> /usr/perl5/5.8.4/lib/i86pc-solaris-64int/Scalar/Util
> /usr/perl5/5.8.4/lib/i86pc-solaris-64int/Scalar/Util/PP.pm
> /usr/perl5/5.8.4/lib/i86pc-solaris-64int/Scalar/Util.pm
% find /usr/per
John Beck writes:
> Dina> These changes to libcryptoutil/random went to snv_112, not snv_111.
> Dina> The RTI was held until after snv_111 closed. John Beck?
>
> You are correct.
>
>
> Dina> If all you have is some conglomeration of snv_108 to snv_111, I don't
> Dina> (yet) understand how code f
Richard Lowe writes:
> James Carlson writes:
>
>> Paul Durrant writes:
>>> James Carlson wrote:
>>> > Paul Durrant writes:
>>> >> James Carlson wrote:
>>> >>> I had this problem a while ago, and it turned out that I was using a
James Carlson writes:
> Paul Durrant writes:
>> James Carlson wrote:
>> > Paul Durrant writes:
>> >> James Carlson wrote:
>> >>> I had this problem a while ago, and it turned out that I was using a
>> >>> stale copy of the 'on-closed' tarball. Could that be your problem as
>> >>> well?
>> >>>
>>
Roland Mainz writes:
> Hi!
>
>
>
> It seems VLAs still do not work - the Sun Studio build now works if we
> use DWARF but gcc now fails like this:
> -- snip --
> ../common/bltins/shiocmd_solaris.c -mcpu=v8 -mno-v8plus
> ERROR: ctfconvert: die 8002: failed to get unsigned (form 0x13)
> Removi
"Garrett D'Amore" <[EMAIL PROTECTED]> writes:
> Artem Kachitchkine wrote:
>>
>>> [EMAIL PROTECTED]> pfexec truss -f -t mount mount -F pcfs -o ro
>>> /dev/dsk/c2t0d0p0:1 /mnt
>>> 3708: mount("/dev/dsk/c2t0d0p0:1", "/mnt", MS_OPTIONSTR, "pcfs",
>>> 0x, 0, 0x08063240, 1024) Err#30 EROFS
>
Roland Mainz <[EMAIL PROTECTED]> writes:
> Hi!
>
>
>
> What is the "Floating point scrubber" referenced in CR #6656791
> ("Floating point scrubber needs weaker CPU and processor set bindings")
> ? I know the memory and cache scrubbers but a scrubber system for
> floating-point sounds... weire
Roland Mainz <[EMAIL PROTECTED]> writes:
> Richard Lowe wrote:
>> Roland Mainz <[EMAIL PROTECTED]> writes:
> [snip]
>> >> but in any
>> >> case, yes, given the c99 changes, we should make the ctf tools handle
>> >> that. U
is such a
>> designation) are both busy on other things at the moment. So if you
>> can't get around with by using the DWARF mode, then feel free to pitch
>> in by proposing a set of diffs and we'll sponsor you: this should
>> be relatively trivial to fix.
>
>
Nils Goroll <[EMAIL PROTECTED]> writes:
> Hi all,
>
> apologies if this question has already been answered - yes, I did
> search the forum:
>
> - It seems to me that the closed bins in
> http://dlc.sun.com/osol/on/downloads/nightly-bins are not strictly
> nightly. It there a reason why they are no
James Carlson <[EMAIL PROTECTED]> writes:
> James Carlson writes:
>> Assuming it's just one of the drivers or kernel modules, you can
>> always go down into one of the $SRC/uts/intel/* subdirectories and do
>> a "dmake" there. That can then be manually copied to the system being
>> tested -- then
"Shawn Walker" <[EMAIL PROTECTED]> writes:
> This seems rather tedious to do for every change. What do you folks do
> when making changes to ONNV? Do you work / build nightlies out of your
> mercurial directory? Do you commit them to a local mercurial
> repository? If so, can you tell me what setu
James Carlson <[EMAIL PROTECTED]> writes:
> Mark J. Nelson writes:
>> I think an upstream sync necessarily implies pulling the current upstream
>> source, integrating your changes, and building it OUTSIDE of the context
>> of ON. Anything else is negligent. Including the unused-in-ON code
>>
Darren J Moffat <[EMAIL PROTECTED]> writes:
> Joerg Schilling wrote:
>> Peter Memishian <[EMAIL PROTECTED]> wrote:
>>
>>> Folks,
>>>
>>> During the ksh93 code review, the topic of policies for unreferenced files
>>> in ON came up. As per http://opensolaris.org/os/community/on/findunref
>>> we've
Stephen Lau <[EMAIL PROTECTED]> writes:
> Just wanted to send a pointer to mark's heads up message that was
> mirrored. I forgot to ask for opensolaris-code to be included in the
> recipients.
>
> http://opensolaris.org/os/community/on/flag-days/pages/2007070901/
>
Which is just one reason why
陶捷 Tao Jie wrote:
> Dear all:
>
> I'm building ON source b66 these days. But I fail all the time, no
> matter what I've tried, the "nightly opensolaris.sh" or "cd usr/src/uts;
> dmake all".
>
> My build environment is:
> Intel P4 with 512M memory, Solaris Express B66 + Sun Studio 11
>
Mike Kupfer wrote:
"meem" == Peter Memishian <[EMAIL PROTECTED]> writes:
meem> What ensures the packaging will end up correct when it's set?
As Roland mentioned, nothing. But packaging for the open build is
already broken, and the expectation is that we'd never set this flag for
an internal b
James C. McPherson wrote:
Ben Rockwood wrote:
I've had a couple applications have assorted strange problems on
recent Nevada builds. One of the applications was the LiteSpeed Web
Server, and the response from LiteSpeed regarding the problem was
that an ABI change broke compatibility with existi
Al Hopper wrote:
On Fri, 1 Jun 2007, Peter Memishian wrote:
> > * A number of places do something like this:
> >
> > #
> > # ksh is not lint-clean yet. Fake up a target.
> > #
> > lint:
> > @ print "usr/src/cmd/ksh is
Mike Kupfer wrote:
"stevel" == Stephen Lau <[EMAIL PROTECTED]> writes:
stevel> It looks like there was an old errant hg process holding onto
stevel> onnv/onnv-gate, so it never got unmounted (and thus remounted).
stevel> I've killed it now, which forced the remount, and it looks like
stevel> i
Stephen Lau wrote:
I had to do a small rollback of the gate last night by 3 changesets to
fix the incorrect "onnv_64***" tag that was applied by mistake.
cheers,
steve
Note that due to what appears to be yet another autofs quirk, this is still
not visible as done when pulling from onnv-gate.
Roland Mainz wrote:
Darren J Moffat wrote:
Roland Mainz wrote:
AFAIK OpenSolaris tries to support two SCMs, Mercurial and Subversion,
right ? IMO both should be supported for all OpenSolaris repositories...
Yes for OpenSolaris.org the site. No for all projects/consolidations.
Each project/con
Roland Mainz wrote:
Stephen Hahn wrote:
* Roland Mainz <[EMAIL PROTECTED]> [2007-04-17 15:19]:
Mike Kupfer wrote:
"Roland" == Roland Mainz <[EMAIL PROTECTED]> writes:
Roland> - Should I add support for Mercuial and GIT, too ?
As far as patching ON code, we're not planning on using GIT, so I
Mike Kupfer wrote:
"Roland" == Roland Mainz <[EMAIL PROTECTED]> writes:
Roland> ... BTW: I guess some of the follow-ups of the ksh93-integration
Roland> project will still be Subversion based since they may use
Roland> branches from that tree (e.g. shcomp/shbinexec&co.) ...
I think you'll find
Garrett D'Amore wrote:
I sent you review off-list, since I saw the request on IRC before I saw the
request here, further notes on your notes inline.
I've posted a codereview, which I would love to have folks review. This
adds the platform support for SPARCLE (aka Sun Ultra 3) per PSARC 2007/
Peter Memishian wrote:
> AFAIK only April can do that... I don't have a SCCS repository around
> (and "findunref" only looks at files which are under SCCS control
> (welcome to http://bugs.grommit.com/show_bug.cgi?id=159 ("findunref
> needs to learn about mercurial") ... ;-( )) ... ;-(
Actua
Alexander Kolbasov wrote:
> Suppose that someone wants to integrate some code and in the process of
> developing it some documentation is also produced. Currently there is
> no good place to stick this documentation in the source tree. What do
> you think about having usr/doc subtree for such
John Plocher wrote:
Keith M Wesolowski wrote:
On Thu, Mar 08, 2007 at 04:03:19AM +0100, Roland Mainz wrote:
Grumpf...
Am I correct in thinking that your concerns around removing these
files are entirely a result of a belief that the structure of the code
should be optimised for bulk upgrades fr
Roland Mainz wrote:
Mike Kupfer wrote:
"Roland" == Roland Mainz <[EMAIL PROTECTED]> writes:
Roland> but I fear which possible "precedent" could be constructed from
Roland> that (like "... lets rename all files which are unused from ${i}
Roland> to ${i}.unused ..." or something like that) ... ;
Stephen Lau wrote:
Shawn Walker wrote:
The instructions on this page:
http://dlc.sun.com/osol/on/downloads/hg-build-snapshots/
Seem to indicate I should be able to do this:
hg clone -r onnv_59 ssh://[EMAIL PROTECTED]/hg/onnv/onnv-gate
However, that results in this:
destination directory: onnv-
Garrett D'Amore wrote:
Garrett D'Amore wrote:
Danek Duvall wrote:
On Wed, Feb 07, 2007 at 11:35:52AM -0800, Stephen Hahn wrote:
That seems more than fair. Couldn't we make the keywords removal an
incremental process, via one of the code cleanliness filters? (As we
did for t
Stephen Lau wrote:
Darren J Moffat wrote:
Stephen Lau wrote:
Can you please give step by step instructions on exactly where we
need to rollback to, ie the revision/changeset number last known to
be good (or one close it it) would be really helpful.
It looks like the last common changeset w
Michael Shapiro wrote:
On Mon, Jan 29, 2007 at 07:23:07PM -0800, David Powell wrote:
However, what I'd really, really like to see is a way to embed a keyword
that is taken from a build (say "snv54" or somesuch) via Makefile, for
production builds, and has some other text for unofficial builds (
Richard Lowe wrote:
Roland Mainz wrote:
[EMAIL PROTECTED] wrote:
- All AST sources are in
usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/
and usr/src/cmd/ast/. All files are 100% identical with the upstream
(AT&T) versions except those listed in
"usr/src/lib/libs
Roland Mainz wrote:
[EMAIL PROTECTED] wrote:
- All AST sources are in usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/
and usr/src/cmd/ast/. All files are 100% identical with the upstream
(AT&T) versions except those listed in
"usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.diff".
I don't u
Roland Mainz wrote:
Hi!
I created a couple of webrevs in various flavours based on today's
ksh93-integration sources. This isn't the "reliminary review request"
(yet; the official rquest should come on ~~ monday or tuesday), just an
attempt to provide an updated webrev.
I'm yet to look
Darren J Moffat wrote:
Stephen Hahn wrote:
* Mike Kupfer <[EMAIL PROTECTED]> [2007-01-11 10:25]:
"sch" == Stephen Hahn <[EMAIL PROTECTED]> writes:
sch> I'm quite happy with the discussion, although my inclination is
sch> to get the immediate term issue resolved and then spend some time
sch
Mike Kupfer wrote:
"sch" == Stephen Hahn <[EMAIL PROTECTED]> writes:
sch> So... out of every 8 builds, the last two are restricted for
sch> stabilization?
Works for me.
I like it, if that schedule can be held to from all sides (barring the
forthcoming releases discussion, obviously).
Stephen Lau wrote:
Darren J Moffat wrote:
Stephen Lau wrote:
We've been having serious stability issues with the OpenGrok webapp
serving the OpenSolaris Source Browser (http://src.opensolaris.org).
We started observing the failures about 2 months ago when we rolled
out support for indexing a
John Plocher wrote:
Darren J Moffat wrote:
John Plocher wrote:
James Carlson wrote:
The issue with release management still seems murky to me. I assume
that distributions do not get to manage uname -r, unless they're
willing to fork. If this is the ON community's task, then how
(reasonably)
Richard Lowe wrote:
Darren Reed wrote:
...
I've already said this in an off-list reply, but I guess I'll say it
again here.
Having everyone release their distribution from branches leaves us
with the gate entirely divorced from a binary deliverable. In that
situation it would
Darren Reed wrote:
...
I've already said this in an off-list reply, but I guess I'll say it again here.
Having everyone release their distribution from branches leaves us with the
gate entirely divorced from a binary deliverable. In that situation it
would get little to no testing. This is
John Plocher wrote:
Richard Lowe wrote:
And if ConsolidationA chooses to release, and it depends on
ConsolidationB
which doesn't, ConsolidationA doesn't have any kind of stabilization
period for something parts of it depend on.
What am I missing here?
...
All this says i
John Plocher wrote:
Richard Lowe wrote:
It cannot be up to consolidations individually, how would you then
handle cross-consolidation dependencies?
Very carefully :-)
If the dependency is on public interfaces that have a Committed
stability, then this isn't much of a problem.
John Plocher wrote:
James Carlson wrote:
John Plocher writes:
I don't understand where this view that OpenSolaris
Communities don't have releases came from.
It's a source base. What's the "release model" for a source base that
has no delivery mechanism?
There is a vast difference between
James Carlson wrote:
Stephen Hahn writes:
The authority to identify a release species and manage integrations
moves from internal Sun committees to the Community Group that is
publishing a Consolidation. (The role of the Governing Board in
coordinating among Community Groups is still to
[EMAIL PROTECTED] wrote:
Right. Another possible approach is to have a single OpenSolaris gate
(well, one per consolidation). Each distro would create its own stable
branch when it gets close to a release. (That branch could still be
visible, but it would be run by the distro, not by the commu
James Carlson wrote:
For example, if the PAC decides it wants to have a radical new Major
release, but the community wants to stick with Minors or smaller
because they are more conservative, we have a conflict we can't
resolve. Are they aware of the implications?
Is the "they" there referring
[EMAIL PROTECTED] wrote:
On Tue, Jan 09, 2007 at 11:46:13AM +0100, [EMAIL PROTECTED] wrote:
No issue at all. With gcc builds, string constness should be reasonably
well tested by now.
If only that were true. The failure mode is at runtime, not build
time, and other than maybe Mike Sullivan,
Mike Kupfer wrote:
"RL" == Richard Lowe <[EMAIL PROTECTED]> writes:
RL> does on+2 appear far enough before on+1 is done that none of these
RL> will be problematic?
It can, and that's what we've usually done in the past (i.e., when
Solaris development was clo
James Carlson wrote:
Roland Mainz writes:
... the other items include less controversial things - like sticking a
"-xtrconst" to all SUNWonbld build tools (and some other places, IMO we
should make a list of commands which are run very often and check how
the performance can be improved (options
Stephen Hahn wrote:
I recently wrote a bit about the restricted integration builds we had
during December at
http://blogs.sun.com/sch/entry/opensolaris_restricted_builds_through_the
One of the aspects I believe we need to settle on is an initial
frequency for such restrictions.
Ian Collins wrote:
I'm experiencing an unpleasant crash in libproc from dbx on build 52.
The stack trace is:
main(0x2, 0x8046ecc, 0x8046ed8)
0x80f6dd3(0x837e5c0, 0x8469e88, 0x8046e54)
targ_ppi_init(0x837e5c0, 0x8046e54)
0x81ffc88(0x837e5c0, 0x8046e54)
0x81ff9c4(0x837e5c0, 0x8046e54)
ProcMgr::st
John Plocher wrote:
Glenn Fowler wrote:
again
show us some real numbers that point to a hotspot in the code
that exposes appreciable time/space waste and we'll address it
...
we own all of the ast interfaces
some have threads in mind but not implemented
To clarify - are you saying that, as u
Roland Mainz wrote:
Roland Mainz wrote:
Does anyone know what the following error means:
[snip]
ERROR: ctfconvert: pics/bltins/read.o: Couldn't parse stab
"#vla0:(0,14)" (source file pics/bltins/read.o)
-- snip --
It seems this issue crept in either between B37 and B48 or between B48
and
Stephen Lau wrote:
I'm done regenerating onnv-gate. I've had to rollback to:
1416:48e679b0807a
I've done a comparison against /ws/onnv-gate to make sure there are no
other discrepencies, and everything looks good.
I intend on pushing to the external Hg onnv-gate this evening - so if
you want t
Stephen Lau wrote:
The bridge failed last night on cindi's wad. Internally what happened
was that she did a putback on 11/3 that the bridge failed on. Danek
backed it out due to merge turds, and it was re-putback on 11/4.
The original putback was what got pushed to the Hg onnv-gate, as
revi
James Carlson wrote:
Richard Lowe writes:
I would disagree, I tend to think (though I'm guilty of not doing so),
that doing as much work as is possible on the outside, and making the
sponsors role easier is generally worthwhile. If sponsorship is more
chore-like than it has to be, les
James Carlson wrote:
Richard Lowe writes:
Those of us on the outside don't have SCCS/*.
#pragma ident"%Z%%M% %I%%E% SMI"
Where the longer strings of spaces are literal tabs.
Really, though, until the source code management system is set up to
handle direc
Danek Duvall wrote:
On Thu, Oct 05, 2006 at 05:35:02AM -0700, Richard L. Hamilton wrote:
Ok, next: what do the unexpanded sccs keywords on the
#pragma ident
lines look like, i.e. since I'm using usr/src/lib/libc/port/gen/strlen.c
as a starting point, what should I make that line look like?
T
Alan Coopersmith wrote:
Garrett D'Amore wrote:
Uh, just to be pedantic, _why_ are we still carrying this baggage? Is
there an actual, genuine need to retain K&R compatibility going forward
forever? I'd have thought at some point Solaris could just say "K&R no
longer supported", and rip out the
[doh, apparently I didn't send this to the list]
James Carlson wrote:
Meem and I have been talking on and off about reducing the number of
-erroff directives in $SRC/uts/Makefile.uts. We both feel that
quieting down lint is the wrong direction to go, as it all too often
papers over real problem
Vandana Brar wrote:
Hi,
I am trying to access the ipsec/ike code via the instructions in the
source browser. Have a couple of questions:
- is this source for this functionality also available
- if so, how do I access to code? Where I have the os installed the /on
dir is not there - neither
Bonnie Corwin wrote:
Hi Frank,
If you are publishing internal code anywhere outside Sun for the first
time, you need approval for that. See the internal site:
http://tonic.eng/space/Process for instructions about posting code for
OpenSolaris. And let me know if you have questions.
Surely th
Gavin Maltby wrote:
Joerg Schilling wrote:
This would make OpenSolaris more stable even in the non-cross compilation
case. Note that OpenSolaris does use /usr/include from the host system
instead of using the include files that are specific to the current build
Where that happens for ON it
Darren J Moffat wrote:
Rainer Orth wrote:
Mike Kupfer writes:
"Darren" == Darren J Moffat writes:
Okay, but I'm unable to figure out from that list what Rainer should
do with SUNWcryptoint. What do you recommend?
Darren> What problem is being caused by the way it is handled today ?
It's i
Rainer Orth wrote:
Richard,
I'd suggest not removing anything from the closed tarball (for reasons
other than it's movement to usr/src, obviously)
While bits of it maybe unused, they're also covered under the
OpenSolaris binary license, that allows for their redistribution.
which shouldn't
Stephen Lau wrote:
We've hit the storage limit on the OpenSolaris download center at
dlc.sun.com. We're getting more storage added soon, but in the meantime
we need to free up some space temporarily until the extra storage comes
online.
Given that I can really only speak for ON, and that ON
Rainer,
I'd suggest not removing anything from the closed tarball (for reasons
other than it's movement to usr/src, obviously)
While bits of it maybe unused, they're also covered under the
OpenSolaris binary license, that allows for their redistribution.
-- Rich.
___
Bill Sommerfeld wrote:
On Mon, 2006-06-12 at 15:13, Glen Kriekenbeck wrote:
Hi all,
I'm working with an ISV who asks:
We notice that the system calls are coded differently in the 32 and 64
bit versions of the OS. The 32 version uses sysenter which the 64 uses
syscall. There also seem to be 2
Rainer Orth <[EMAIL PROTECTED]> writes:
Additions to bits pointed out by Mike inline...
(though with the ordering botched, apologies)
> My suggestion is to either move those closed components to new packages of
> their own or to to really omit the affected packages when all or most files
> are mi
73 matches
Mail list logo
