Roland Mainz wrote:
Hi!
----
Is it possible that bugs.opensolaris.org is loosing bugs (again) ?
I am missing two bug reports:
1. "usr/src/cmd/perl/ build installs Subversion directories (.svn) in
the proto area" (note that this is not the exact title). That one was
filed seveal days ago and since noone from Sun could find the bug I
filed it again (now known as CR #6546677 ("usr/src/cmd/perl/ build
installs Subversion directories (.svn) in the proto area").
Was the first submission on 4/15/2007 9:08 PM PT
Containing the following:
Description
An attempt to run "makebfu" on an OS/Net tree which is under
Subversion control still fails in B61 with attempts to install
the Sub-version-provate ".svn/" files in the proto area.
Example:
-- snip --
$ time nice makebfu 2>&1 | tee -a buildlog_makebfu.log
Making archives from
/home/test001/ksh93/on_build1/test1_x86/proto/root_i386 in
/home/test001/ksh93/on_build1/test1_x86/archives/i386/nightly.
Creating generic kernel archive: 152240 blocks
Creating generic lib archive: 59950 blocks
Creating generic root archive: 4720 blocks
Creating generic sbin archive: 2520 blocks
Failed to create generic usr archive: 379370 blocks
cpiotranslate: usr/perl5/5.6.1/lib/File/Spec/.svn/entries: no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/File/Spec/.svn/format: no packaging info
cpiotranslate:
usr/perl5/5.6.1/lib/File/Spec/.svn/text-base/VMS.pm.svn-base: no
packaging info
cpiotranslate:
usr/perl5/5.6.1/lib/File/Spec/.svn/text-base/Epoc.pm.svn-base: no
packaging info
[snip]
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base/FileCache.pm.svn-base:
no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base: no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn: no packaging info
Creating i86pc boot archive: 5070 blocks
Creating i86pc root archive: 11090 blocks
Creating i86pc usr archive: 2300 blocks
Creating conflict resolution archive: 630 blocks
real 1m6.791s
user 0m1.978s
sys 0m4.601s
-- snip --
It seems the perl5.8.4 su
2. Today I filed a bug that the number of realtime signals is
insufficient, again noone can find the bug report in the triage queue or
elsewhere while my browser says:
-- snip --
Report a Bug
The bug has been reported.
-- snip --
Is this it:
Category
kernel
Sub-Category
limits
Description
Currently the maximum number of realtime signals is set to
|_POSIX_RTSIG_MAX|==8 which is too low for some applications
>From [EMAIL PROTECTED]:
-- snip --
POSIX_RTSIG_MAX is a minimum maximum for the number of realtime signals;
there can be no less than 8 realtime signals. This is from IEEE 1003.1
or ISO/IEC 9945-1.
-- snip --
It would be very nice to bump this value to |16| or higher to be closer
to more modern OSes like Linux (e.g. Linux supports up to |32| realtime
signals per getconf output).
Frequency
Always
Erm... I guess something is going horribly wrong here and needs some
immediate action. We may be loosing bug reports... ;-(
If you get a confirmation then I get a copy (assuming there was no mail
failure), so they are not quite lost, however sometimes bugs-by mail
rejects the incoming XML and we need to manually insert the info into
Bugster, which happened in both of these cases. That manual process
should happen within 48 hours of a failure, which did not seem to happen
in these cases, so I will investigate as to why.
Derek
----
Bye,
Roland
--
Derek Cicero
Program Manager
Solaris Kernel Group, Software Division
_______________________________________________
opensolaris-discuss mailing list
[email protected]
