No real bug, but there are no solaris sparc nightly builds

Re-assigned to cyeh@netscape.com and changed component to Build Config. Chris, know about this one?

Not a M3 blocker...setting to M4.

when we do get solaris nightly builds, coordinate with leaf so they go to the magic /h/chrome place for mozilla daily builds

moving to m5

I've made the necessary changes so that the nightly build system will successfully handle Solaris/SPARC builds. Don has graciously agreed to do the nightly builds and deliver them, so I'm reassigning this bug to him.

*** Bug 4003 has been marked as a duplicate of this bug. ***

Brian O has agreed to take this on and it should be fixed. Assigning to him to close.

Is it possible to get a Solaris Sparc counterpart of the Win32 build 1999-04-27 {IMHO the best build until now :-))) } ? Or should I ask briano@netscape.com directly ?

did we build/deliver solaris this morning? if answer is yes, then let's close this. if the answer is no, what needs to be done to make this happen?

ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-04-28-09/ contains only a build for irix/sgi; a 1999-04-29*/ directory is public available yet (29.4.99 / 20.14h MET)

I have been doing nightly Solaris/sparc builds for the past week now. That is not a problem. The problem is that I don't know what I'm supposed to do after that. I've been simply packaging the dist/bin directory, after stripping the binaries, but even gzip'd, this results in a 14MB .tar.gz file. Something I'm doing (or not doing) is wrong. 14MB is too much to expect anyone to be willing to wait to download. In my opinion. I am working on this. Immer noch....

14 MB won't hurt me, even 30 MB won't. My system can do the download without my help :-) Possible options (in my optinion): a) Delay solaris nightly builds until the 14+ MB has been fixed (preferred by the FTP admin: no large downloads...:-) ) OR b) Do the solaris nightly builds now, even with this big archive size, and write a bug report about the problem... (preferred by me) I don't have any idea about the 14MB problem, but maybe I have an idea when I see a living archive... Aber so eilig hab' ichs damit auch wieder nicht. Derzeit nutze ich die Win32-Version zur Vorführung. Muß nur immer noch den Laptop mitschleppen... nicht so toll :-(

Besser als einen SparcStation und Monitor mitschleppen, oder? ;-) Aber ich tu' was ich kann. Hoffentlich heute abend gibt es etwas fuer Solaris/sparc am ftp://ftp.mozilla.org/.

Wir haben bei uns im Klinikum viele Sun Sparcs im Einsatz, da brauch ich gar nichts (au0er Kopien und Stifte für die Whilteboards) schleppen, nur eine Sparc, die frei ist und Solaris >= 2.5.1 drauf hat... Nur für größrere Vorlesungen muß wegen des Projektors eine Sparc vorbereiten...

I've solved the size problem and written a simple script to deliver the nightly builds. Starting Monday there will be Solaris 2.5.1 builds available daily on the FTP server.

Reopened the bug, now for sparcv9 (64bit) sparc nightly builds...

Clearing FIXED resolution due to reopen.

Moving to M12 since M5 id way over...

Removed donm from the CC: list since he no longer works here.

I don't know if we can do this yet with the systems we currently have. What version(s) of Solaris support the sparcv9 flag?

All Solaris 2.7 or Solaris 2.8 machines with UltraSPARC hardware running the 64bit kernel. Pre-UltraSPARC machines can run Solaris 2.7/2.8 only with the 32bit kernel, not with the 64bit one... Test this with "isainfo -v" (the "isainfo" command shows which "ISA" codesets are supported): -- snip -- 64-bit sparcv9 applications 32-bit sparc applications -- snip -- sparc means that sparcv7,v8 code is supported, sparcv9 means 64bit sparc. If you don't have a Solaris 2.7 test machine ready, think about setting up a machine (UltraSPARC) with Solaris 2.8 beta. For production usage, I recomment Solaris 2.7 SPARC with MU4 (Maintaince update 4, which kills all serious issues in Solaris 2.7).

give the nightly's/m13 a try. briano checkin something that might get a few more people running.

uh, we still have no sparc 64 bit builds like the bug says. reopening

1st problem is to manage it that the Zilla can be compiled with Sun Workshop compilers (4/5/6EA) in 32bit mode - because the Workshop compilers are currently the only sparcv9-compilers which are producing useable code - gcc sparcv9 is very far away ;-( Seems we've to kill a LOT of compillation errors...