Where to upload builds?
Dave Yeo
like it might be a good idea if I could upload the odd build of
Mercurial trunk builds somewhere.
Do I have to worry about branding? The only patch right now is Peter's
GCC 3.4.6 patch.
My first thought is Hobbes
Dave
Steve Wendt
> Do I have to worry about branding?
Peter appends "(PmW)" to his unofficial builds, so if you appended your
own (short) branding of your choosing to differentiate it, that is what
would make the most sense to me.
> My first thought is Hobbes
I would say that's a poor choice for nightly builds. Perhaps Peter can
give you upload access to his SourceForge project; otherwise, I'd
suggest the NetLabs FTP server.
Andy Willis
on hobbes but doesn't strike me as a good place for nightlies.
Peter Weilbacher
> Steve Wendt wrote:
>> On 09/26/08 08:23 pm, Dave Yeo wrote:
>>
>>> Do I have to worry about branding?
>>
>> Peter appends "(PmW)" to his unofficial builds, so if you appended your
>> own (short) branding of your choosing to differentiate it, that is what
>> would make the most sense to me.
Yes, that could be done. You could add something like
pref("general.useragent.extra.zdry", "(DRY)");
to the end of browser-prefs.js. (Probably easier to do after the build
and not in the source tree.)
>>> My first thought is Hobbes
>>
>> I would say that's a poor choice for nightly builds. Perhaps Peter can
>> give you upload access to his SourceForge project; otherwise, I'd
>> suggest the NetLabs FTP server.
> I tend to hold this opinion as well. I wouldn't mind seeing releases on
> hobbes but doesn't strike me as a good place for nightlies.
sf.net is a pain to set up for and then do the uploading, so I think
Netlabs incoming would be nice. If we want to archive them further some
time, I could upload them to mozilla.org at some point with an extra
ReadMe.
(At the moment I am running builds with hg bisect to find out with which
patch my builds got bad. That I can't create a good build is also the
reason why I haven't done a SM 2.0a1 release candidate or nightly that
comes close.)
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
Dave Yeo
> On 27.09.08 07:25, Andy Willis wrote:
>> Steve Wendt wrote:
>>> On 09/26/08 08:23 pm, Dave Yeo wrote:
>>>
>>>> Do I have to worry about branding?
>>>
>>> Peter appends "(PmW)" to his unofficial builds, so if you appended your
>>> own (short) branding of your choosing to differentiate it, that is what
>>> would make the most sense to me.
>
> Yes, that could be done. You could add something like
> pref("general.useragent.extra.zdry", "(DRY)");
> to the end of browser-prefs.js. (Probably easier to do after the build
> and not in the source tree.)
Well I looked for browser-prefs.js in my object directory and didn't
find it. Then I remembered I had added
set MOZILLA_OFFICIAL=1
set BUILD_OFFICIAL=1
to my setmozenv so I unset them, rebuilt and edited browser-prefs.js
adding the line you suggested.
When I started Seamonkey it came up with the extension manager and
disabled all my extensions as being incompatible with this version and
things seem really slow. Took minutes just to get it to respond to help
--> about.
I'm not sure if something changed in the tree like the version getting
updated or if it is related to browser-prefs.js being added.
I'll have to do some experiments.
Dave
Build identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b1pre)
Gecko/20080927112200 SeaMonkey/2.0a2pre (DRY)
>
>>>> My first thought is Hobbes
>>>
>>> I would say that's a poor choice for nightly builds. Perhaps Peter can
>>> give you upload access to his SourceForge project; otherwise, I'd
>>> suggest the NetLabs FTP server.
>> I tend to hold this opinion as well. I wouldn't mind seeing releases on
>> hobbes but doesn't strike me as a good place for nightlies.
>
> sf.net is a pain to set up for and then do the uploading, so I think
> Netlabs incoming would be nice. If we want to archive them further some
> time, I could upload them to mozilla.org at some point with an extra
> ReadMe.
If I can get an up to date working build I'll upload to Netlabs.
>
> (At the moment I am running builds with hg bisect to find out with which
> patch my builds got bad. That I can't create a good build is also the
> reason why I haven't done a SM 2.0a1 release candidate or nightly that
> comes close.)
Wonder if setting Mozilla_Official and build_official to 1 would make
any difference to you?
Dave
Peter Weilbacher
> Well I looked for browser-prefs.js in my object directory and didn't
> find it. Then I remembered I had added
> set MOZILLA_OFFICIAL=1
> set BUILD_OFFICIAL=1
> to my setmozenv so I unset them, rebuilt and edited browser-prefs.js
> adding the line you suggested.
Interesting, didn't know that the OFFICIAL variables were needed to get
that.
> When I started Seamonkey it came up with the extension manager and
> disabled all my extensions as being incompatible with this version and
> things seem really slow. Took minutes just to get it to respond to help
> --> about.
Actually, I think this is because of a bug in mzfntcfgft. I hope I fixed
this a few hours ago in the Hg repo. (I was already wondering why I was
the only one seeing the problem...) Once you recompiled that, remove
thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
gone.
I'll upload the SM build that I have now and also make FF and TB
nightlies from the same Hg revision.
(My 3.4.6 build of SM from the same sources + GCC 3.4.6 build fixes
still shows the 100% CPU problem, it's probably still polling the
network endlessly.)
Dave Yeo
>> When I started Seamonkey it came up with the extension manager and
>> disabled all my extensions as being incompatible with this version and
>> things seem really slow. Took minutes just to get it to respond to help
>> --> about.
>
> Actually, I think this is because of a bug in mzfntcfgft. I hope I fixed
> this a few hours ago in the Hg repo. (I was already wondering why I was
> the only one seeing the problem...) Once you recompiled that, remove
> thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
> gone.
Ok I went to obj/gfx/thebes/src and did a make clean && make. Discovered
that it needed a make LDFLAGS=-lgcc to resolve all symbols. Anyways now
Seamonkey is snappy. My extensions are still disabled but that seems to
be due to the version bump. Also the test page I tried had updated their
page (more javascript :( ) so that is where other problems come from.
> I'll upload the SM build that I have now and also make FF and TB
> nightlies from the same Hg revision.
> (My 3.4.6 build of SM from the same sources + GCC 3.4.6 build fixes
> still shows the 100% CPU problem, it's probably still polling the
> network endlessly.)
I'll try to upload my Seamonkey build to ftp.netlabs.org/incoming. It's
going to take a couple of hours though. Hopefully the connection doesn't
get dropped :)
It should be close enough to your build that you could try swapping DLLs
to narrow down where your problem is (or show that it is a problem with
your system)
Dave
Peter Weilbacher
> I'll try to upload my Seamonkey build to ftp.netlabs.org/incoming. It's
> going to take a couple of hours though. Hopefully the connection doesn't
> get dropped :)
> It should be close enough to your build that you could try swapping DLLs
> to narrow down where your problem is (or show that it is a problem with
> your system)
I think I found it already, I swapped nspr4.dll from a 3.3.5 build and
it runs. More details (but no solution) in bug 454956.
Btw, your upload has finished and your version runs nicely here, too.
But yes, with JIT enabled, the GCC 3.4.6 builds don't survive more than
one or two page loads...
Dave Yeo
> this a few hours ago in the Hg repo. (I was already wondering why I was
> the only one seeing the problem...) Once you recompiled that, remove
> thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
> gone.
Under a busy system I'm still seeing lots of delays. Towards the end of
loading a page I've had Seamonkey (and often the WPS) stall for minutes.
Even window repainting doesn't happen. Going to watchcat shows Seamonkey
not using any CPU and bumping up its priority doesn't help. Lowering
GCC's priority to idle does help.
On an idle system these delays do not happen and in the past under the
same circumstances things were just slow.
Dave
Dave Yeo
> Btw, your upload has finished and your version runs nicely here, too.
Yes, unluckily I got 17067090 bytes sent in 10840.85 seconds, 1.54 kB/s.
I don't think I'll be uploading to many files though I don't mind
uploading something when I go to bed
Dave
Peter Weilbacher
> On 09/27/08 01:27 pm, Peter Weilbacher wrote:
>> Actually, I think this is because of a bug in mzfntcfgft. I hope I fixed
>> this a few hours ago in the Hg repo. (I was already wondering why I was
>> the only one seeing the problem...) Once you recompiled that, remove
>> thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
>> gone.
>
> Under a busy system I'm still seeing lots of delays. Towards the end of
> loading a page I've had Seamonkey (and often the WPS) stall for minutes.
That is exactly what my last change to mzfntcfgft should have fixed.
Did you rebuild it fully after the last pull & update?
Dave Yeo
> On 29.09.08 01:57, Dave Yeo wrote:
>> On 09/27/08 01:27 pm, Peter Weilbacher wrote:
>>> Actually, I think this is because of a bug in mzfntcfgft. I hope I fixed
>>> this a few hours ago in the Hg repo. (I was already wondering why I was
>>> the only one seeing the problem...) Once you recompiled that, remove
>>> thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
>>> gone.
>>
>> Under a busy system I'm still seeing lots of delays. Towards the end of
>> loading a page I've had Seamonkey (and often the WPS) stall for minutes.
>
> That is exactly what my last change to mzfntcfgft should have fixed.
> Did you rebuild it fully after the last pull & update?
I just did a make clean && make LDFLAGS=-lgcc in gfx/thebes/src.
After I update GCC I'll do a complete build
Dave
ps I did rebuild mzfntcfgft
William L. Hartzell
Peter Weilbacher wrote:
> On 29.09.08 01:57, Dave Yeo wrote:
>> On 09/27/08 01:27 pm, Peter Weilbacher wrote:
>>> Actually, I think this is because of a bug in mzfntcfgft. I hope I fixed
>>> this a few hours ago in the Hg repo. (I was already wondering why I was
>>> the only one seeing the problem...) Once you recompiled that, remove
>>> thebes.dll and re-link it (in gfx/thebes/src) and the problem should be
>>> gone.
>>
>> Under a busy system I'm still seeing lots of delays. Towards the end of
>> loading a page I've had Seamonkey (and often the WPS) stall for minutes.
>
> That is exactly what my last change to mzfntcfgft should have fixed.
> Did you rebuild it fully after the last pull & update?
While speaking of this library, is there a patch needed to it to make it
work with GCC346, or do I need to rebu1ild it, or both? I only have the
last version posted to Hobbes.
--
Bill
Thanks a Million!
Dave Yeo
> Sir:
>
> Peter Weilbacher wrote:
[...]
>> That is exactly what my last change to mzfntcfgft should have fixed.
>> Did you rebuild it fully after the last pull & update?
> While speaking of this library, is there a patch needed to it to make it
> work with GCC346, or do I need to rebu1ild it, or both? I only have the
> last version posted to Hobbes.
Go to http://hg.mozilla.org/users/mozilla_weilbacher.org/mzfntcfgft/ and
click the zip at the top to download the newest. I started with a 3.3.5
compiled version and didn't notice any problems. Still maybe safer to
build for the GCC you're using.
BTW Paul has a new release of 3.4.6
Dave
Peter Weilbacher
> Peter Weilbacher wrote:
>> That is exactly what my last change to mzfntcfgft should have fixed.
>> Did you rebuild it fully after the last pull & update?
> While speaking of this library, is there a patch needed to it to make it
> work with GCC346, or do I need to rebu1ild it, or both? I only have the
> last version posted to Hobbes.
No need to recompile with 3.4.6, I think.
William L. Hartzell
My last attempt to build the CVS branch stopped with Cairo, while using
3.4.6. I will look for Paul's newest. It, mzfntcfgft library, is the
same as was posted to Hobbes last August. Built SeaMonkey fine using
GCC3.3.5. On the other thread about slow execution, I noticed that
started happening with the CVS build when a week ago someone changed the
build instructions.
Dave Yeo
> My last attempt to build the CVS branch stopped with Cairo, while using
> 3.4.6. I will look for Paul's newest. It, mzfntcfgft library, is the
> same as was posted to Hobbes last August. Built SeaMonkey fine using
> GCC3.3.5. On the other thread about slow execution, I noticed that
> started happening with the CVS build when a week ago someone changed the
> build instructions.
Can you report the errors (at least the begining) that you got from Cairo?
mzfntcfgft has been updated a couple of times since the Hobbes version
was posted, see the hg page. Probably none of these were needed for the
CVS tree.
Dave
Walter Meinl
> On 09/30/08 10:43 am, Peter Weilbacher wrote:
>
> I just did a make clean && make LDFLAGS=-lgccin gfx/thebes/src.
> After I update GCC I'll do a complete build
> Dave
Since I was a bit offside during the time Paul got gcc-3.4.6 running
on OS/2, I did not get the point, why -lgcc has now to be set, while
it is not necessary with older compilers. Can you please enlighten
me ;-) ? Thanks
Paul Smedley
If you look in one of the cairo source files, the function popcounts
is defined for compiles < gcc 3.4 or the gcc one is used if gcc >= 3.4
--
Cheers,
Paul.