Jump to content

My Browser Builds (Part 2)


Recommended Posts

New regular/weekly KM-Goanna release:
https://o.rths.ml/kmeleon/KM76.3-Goanna-20200919.7z

Changelog:

Out-of-tree changes:
* update Goanna3 to git 500383702..aebd9e464:
- import changes from `dev' branch of rmottola/Arctic-Fox:
 - Bug 1194905 - Build libvpx neon code without -mthumb and -mfloat-abi=softfp. r=mshal (24098bdb7)
 - Remove spurious commandline.css from AF tree. (49cf2bb5c)
 - Bug 969914 - Make developer toolbar match the light devtools theme when applied;r=jwalker,r=pbrosset (4047862bd)
 - Bug 1152304 - Add displaying of block notes to dis() in the JS shell. (r=jimb) (9c1d7fa30)
 - Bug 1126987 - Fix _lastEventSize initialization in stack.js. r=vporof (2083cb437)
 - Bug 1140569 - Show async stacks attached to timeline markers. r=vporof (f05e1b60c)
 - Bug 1141553 - Give function name the devtools-monospace class in the profiler r=vporof (0ca698ea2)
 - Bug 1150112 - Markers overview should react to theme change, and other marker views now use CSS to automatically use theme change. r=vporof (6f72cde25)
 - Bug 1050500 - Add entry reason to timeline marker. r=jsantell, r=smaug (db9cf8191)
 - Bug 922221 - implement console.timeStamp(label) to create profile timeline markers. r=khuey (73e513562)
 - Bug 1059908 - Merge FunctionType and FunctionSyntaxKind. r=efaust (2d765bde5)
 - Bug 1059908 - Introduce a CONSTRUCTOR flag and make getter/setter/method non-constructable. r=efaust (fddb15f13)
 - Bug 1162310 - Do not use nonexistent macro when XGILL_PLUGIN is defined, r=bhackett (57a5c2861)
 - pointer style (55ec84b3b)
 - Bug 1164602 - Replace js::NullPtr and JS::NullPtr with nullptr_t; r=sfink (9ae473e29)
 - pointer style (7d735a2b9)
 - pointer style (987c0128b)
 - Bug 1135629 - Rename Register::code to Register::encoding for Assembler functions. r=jandem (cf915c814)
 - pointer style (ac97f0d0b)
 - Bug 1150337 - OdinMonkey: Optimize the full range of immediate offsets on x64. r=luke (fffb82aa6)
 - fix typos (511e17002)
 - pointer style (c1b54384c)
 - Bug 1135707 - Fix interaction between Arm NOP fill and calculation of IonCache rejoin label r=jandem (306365ec4)
 - pointer style (a8fe90ade)
 - Bug 1166809 - Remove DispatchIonCache and RepatchIonCache. r=bhackett (9b8b02bf1)
 - Bug 1147403 part 3 - Make IonSpewer work during off-thread compilation. r=h4writer
 - Bug 1147403 part 3.1 - Replace newly added IonSpewPass after KeepAlive transform. r=KWierso (01bd66aa3)
 - Bug 1147403 part 4 - Extract the printer from the serializer. r=h4writer (290a8887e)
 - pointer style (fc70e6a1a)
 - Bug 1147403 part 0 - Replace contextual information of dispatchHook by lambdas. r=shu (e177990e5)
 - Bug 1065657 - Allow multiple Debuggers to track allocations at the same time. r=shu (66b5a3ba9)
 - pointer style (bb317bb87)
 - Bug 1147403 part 5 - Add Debugger::onIonCompilation hook. r=shu (c14a28de1)
 - Bug 1147403 part 6 - Remove GetJitContext from serializing functions. r=h4writer (6d3d605a5)
 - pointer style (b2ec50945)
 - Bug 1147403 part 7 - Fix inIon, only reset the counter when the function is executed. r=jandem (cb6c180ef)
 - Bug 1165392, Bug 1165463 - Various unboxed array fixes and optimizations, r=jandem. (28ec85004) (d43d81d5a)
- import changes from `dev' branch of rmottola/Arctic-Fox:
 - pointer style (db52d9c32)
 - Bug 1158407 - Stop using this one weird allocation fallback for MCreateThisWithTemplate. (r=terrence) (5b489cd5d)
 - Bug 1170124 - Remove unnecessary type monitoring in jit::InvokeFunction. r=bhackett (1603ee063)
 - Bug 1141865 - Part 2: Plumb new.target on the stack and make it accessible to JSNatives. (r=jorendorff, r=jandem, r=shu) (25cfa92ec)
 - Bug 1129795 - Convert rest of docshell/ to Gecko style. r=mccr8 (20acc2d82)
 - Bug 1162309 - Part 1: Remove instances of #ifdef PR_LOGGING in uriloader. r=froydnj (8768f60c0)
 - Bug 1162309 - Part 2: Remove instances of #ifdef PR_LOGGING in docshell. r=froydnj (e9de046f3)
 - Bug 1096908 - forward network security messages to the content process; r=hurley (69b38e624)
 - Bug 1156493 - e10s: move .cacheKey to nsICacheInfoChannel so child channels can get/set it, r=jduell (507efbe2b)
 - Bug 1017758 - Use infallible getters for appId/isInBrowserElement/unknownAppId; r=bz (8021f0ae8) (39a4e30ae)
- import certdata changes from NSS upstream:
 - Bug 1651211 - Remove EE Certification Centre Root CA root cert. r=KathleenWilson,jcj
 - Bug 1653092 - Disable server trust bit for OISTE WISeKey Global Root GA CA root cert. r=KathleenWilson,jcj
 - Bug 1656077 - Remove Taiwan Government Root Certification Authority root cert. r=KathleenWilson,jcj
 - Bug 1663049 - Add SecureTrust's Trustwave Global root certificates to NSS. r=KathleenWilson,jcj
 - Bug 1663049 - September 2020 batch of root changes, NSS_BUILTINS_LIBRARY_VERSION 2.44. r=jcj (52d97533c)
- import change from tenfourfox:
 - fix overzealous assertion (M1531906) (af9a8236e) (ec64c2198)
- import change from tenfourfox:
 - #618: EV now from ESR78, update TLDs, pins, HSTS (cb0f39c2f) (d836a27cc)
- partly import change from tenfourfox:
 - #622: M1660537 M1641487(modified) M1645492 (291688840) (558e8c786)
- import changes from tenfourfox:
 - #622: update brotli to 1.0.9, woff2 to tip (7c24b77e7)
 - #622: actually add new brotli files (fc50954e6) (aebd9e464)

* Notice: the changelog above may not always applicable to XULRunner code which K-Meleon uses.

A goanna3 source tree that has kmeleon adaption patch applied is available here: https://github.com/roytam1/palemoon27/tree/kmeleon76

Link to comment
Share on other sites


New build of post-deprecated Serpent/moebius for XP!
* Notice: This repo will not be built on regular schedule, and changes are experimental as usual.
** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions.

Test binary:
Win32 http://o.rthost.win/basilisk/basilisk55-win32-git-20200919-a4291d5cc-xpmod.7z
Win64 http://o.rthost.win/basilisk/basilisk55-win64-git-20200919-a4291d5cc-xpmod.7z

repo: https://github.com/roytam1/basilisk55

Repo changes:
- update NSS as-of pm27 rev 7606140ee (a50340ee1)
- import changes from tenfourfox:
 - #622: update brotli to 1.0.9, woff2 to tip (7c24b77e7)
 - #622: actually add new brotli files (fc50954e6) (ede090c8c)
- partly import changes from tenfourfox:
 - #622: M1660537 M1641487(modified) M1645492 (291688840) (2e4a9a0ee)
- import certdata changes from NSS upstream:
 - Bug 1651211 - Remove EE Certification Centre Root CA root cert. r=KathleenWilson,jcj
 - Bug 1653092 - Disable server trust bit for OISTE WISeKey Global Root GA CA root cert. r=KathleenWilson,jcj
 - Bug 1656077 - Remove Taiwan Government Root Certification Authority root cert. r=KathleenWilson,jcj
 - Bug 1663049 - Add SecureTrust's Trustwave Global root certificates to NSS. r=KathleenWilson,jcj
 - Bug 1663049 - September 2020 batch of root changes, NSS_BUILTINS_LIBRARY_VERSION 2.44. r=jcj (9db1f081c)
- import change from tenfourfox:
 - fix overzealous assertion (M1531906) (af9a8236e) (093f38513)
- partly import change from tenfourfox:
 - #618: EV now from ESR78, update TLDs, pins, HSTS (cb0f39c2f) (a4291d5cc)

Edited by roytam1
Link to comment
Share on other sites

New build of Firefox 45ESR:

Test binary:
SSE https://o.rths.ml/gpc/files1.rt/firefox-45.9.28-20200919-b23ecef1d-win32-sse.7z
IA32 https://o.rths.ml/gpc/files1.rt/firefox-45.9.28-20200919-b23ecef1d-win32-ia32.7z

repo: https://github.com/roytam1/mozilla45esr

Changes since my last build:
- update NSS as-of pm27 rev 7606140ee (cc6d80fa1)
- bump version to 45.9.28 (b85a291f0)
- import change from tenfourfox:
 - #618: EV now from ESR78, update TLDs, pins, HSTS (cb0f39c2f) (cc99d9023)
- import change from tenfourfox:
 - fix overzealous assertion (M1531906) (af9a8236e) (cb67f8ea7)
- import changes from tenfourfox:
 - #620: initial support for sticky reader (bf39401a5)
 - #620: add reader mode to context menu (cceb528dd) (4855b847d)
- import changes from tenfourfox:
 - #619: M1258041 M1285428 M1274685 (thanks @OlgaTPark) (c2d494215)
 - #621: wallpaper and speculative fix (didn't work, but good to have) (cbcbd24be)
 - #622: M1660537 M1641487(modified) M1645492 (291688840) (82a4aaf95)
- import changes from tenfourfox:
 - #622: update brotli to 1.0.9, woff2 to tip (7c24b77e7)
 - #622: actually add new brotli files (fc50954e6) (b24bcf45c)
- import certdata changes from NSS upstream:
 - Bug 1651211 - Remove EE Certification Centre Root CA root cert. r=KathleenWilson,jcj
 - Bug 1653092 - Disable server trust bit for OISTE WISeKey Global Root GA CA root cert. r=KathleenWilson,jcj
 - Bug 1656077 - Remove Taiwan Government Root Certification Authority root cert. r=KathleenWilson,jcj
 - Bug 1663049 - Add SecureTrust's Trustwave Global root certificates to NSS. r=KathleenWilson,jcj
 - Bug 1663049 - September 2020 batch of root changes, NSS_BUILTINS_LIBRARY_VERSION 2.44. r=jcj (b23ecef1d)

Link to comment
Share on other sites

On 9/12/2020 at 7:07 PM, roytam1 said:
On 9/19/2020 at 6:02 AM, roytam1 said:

 Let me begin by thanking you for continuing to deliver updated builds of your browsers, despite the recent major hardware hardships... (pun intended! :P) :thumbup

 Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are:

Accessible.tlb
AccessibleMarshal.dll
IA2Marshal.dll

I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir :dubbio:; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant...

Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 )

Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them...

It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading...

On 9/19/2020 at 6:02 AM, roytam1 said:

My changes since last build:
- skipped Issue #1653,
rev 6f5cd8a5e

https://github.com/MoonchildProductions/UXP/issues/1653
Clean up Windows widget code

https://github.com/MoonchildProductions/UXP/commit/6f5cd8a
[widget] Clean up Windows widget code some.

Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done...

On 9/19/2020 at 6:02 AM, roytam1 said:

My changes since last build:
- skipped (redacted) branding related commits

I'm really sorry :( to have to bring this up, but don't you expect "upstream" to hear about that?
You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself :(

With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this?

On 9/19/2020 at 6:02 AM, roytam1 said:

Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public?

Thanks for all your hard work and efforts :worship: , thanks in advance for any answers received...

Best greetings :)

Edited by VistaLover
Link to comment
Share on other sites

3 minutes ago, VistaLover said:

Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are:

Accessible.tlb
AccessibleMarshal.dll
IA2Marshal.dll

I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir :dubbio:; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant...

Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 )

Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them...

It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading...

that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation.

 

7 minutes ago, VistaLover said:

Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done...

yes it breaks XP support, for example, it loads DWM in link-time, which XP doesn't even have this DLL.

 

8 minutes ago, VistaLover said:

Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public?

same condition as hyperbola(i.e. no updates), as they aren't update their part, but UXP core still bring new function to them.

Link to comment
Share on other sites

34 minutes ago, VistaLover said:

What do others think on this?

Well, technically we aren't using their branding anymore since they just abandoned what we're using now. We now have a different product to theirs with different branding, which is most of what they wanted.

Though there may still be some sort of trademark attached to their old branding. And Serpent isn't resolved though I don't think they are too pleased about us brand leeches either way (either we piggyback on their current unofficial branding or simply seize/gift ourselves their old branding). And New Moon could still evoke memories of Pale Moon (for an unfortunate few anyway).

Edited by win32
Link to comment
Share on other sites

34 minutes ago, roytam1 said:

that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation.

Thanks for the explanation! :) How do you intend on pursuing this? Will you be going back to a --disable-accessibility build config flag for your future NM28 builds, continue as things stand now or is this simply now out of your control?

34 minutes ago, roytam1 said:

but UXP core still bring new function to them.

... OK then, pretty much as I had it figured out myself... :D

Edited by VistaLover
Link to comment
Share on other sites

5 minutes ago, win32 said:

Though there may still be some sort of trademark attached to their old branding. And Serpent isn't resolved though I don't think they are too pleased about us brand leeches either way (either we piggyback on their current unofficial branding or simply seize/gift ourselves their old branding). And New Moon could still evoke memories of Pale Moon (for an unfortunate few anyway).

... My thoughts exactly! :rolleyes:

Link to comment
Share on other sites

1 hour ago, VistaLover said:

How do you intend on pursuing this? Will you be going back to a --disable-accessibility build config flag for your future NM28 builds, continue as things stand now or is this simply now out of your control?

will go if I remember to do this.

Link to comment
Share on other sites

5 hours ago, VistaLover said:

I'm really sorry :( to have to bring this up, but don't you expect "upstream" to hear about that?

You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself :(

With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this?

I'm not an expert on Open Source licensing either, but apparently someone here is going to have to become one... This whole business is ridiculous. I would prefer to see the great "dispute" settled as well, because it IS in everyone's best interests to NOT be fighting each other, BUT - NOT by simply giving in to the constant threats/intimidation coming down from "on high." I don't speak for anyone but myself, but if it were up to me I would not lift a finger to conform to any "demand" until some degree of mutual respect is established. The first step of which must include "them" putting a stop to the constant disparaging of the "XP (and Vista :angel) community" and "our" choices - as if anyone here needs "their" approval to use any given OS, or gives one iota what "they" think about our choice of that OS.

That being said, I figured the "branding" problem would be simple enough.. just revert that particular change. While "they" will surely be very angry about it, in the end, (AS FAR AS I KNOW) they cannot force the change "retroactive" on already released code/versions/files. Even if they wanted to take the time and go through all of those old versions, and push out another update for each with the change, it would not erase what has already been made public, and is already covered under the "previous" existing license/redistribution conditions.

5 hours ago, VistaLover said:

Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public?

These "private" repository issues are another aspect which we must figure out with regard to the licensing conditions. I see this "behavior" as simply an attempt to create more hassle for anyone who wishes to build the code for themselves.. which most certainly violates the "spirit" of Open Source, and may violate the actual licensing, depending on which licenses are applicable to different parts of the code. The MPL 2.0 (which to my knowledge governs the Firefox code that PM is developed from) contains some interesting specific statements that would seem to be relevant here:

"All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License."
"You may not attempt to alter or restrict the recipients’ rights in the Source Code Form."

"...Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner..."
"You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients’ rights in the Source Code Form under this License."

... so, I see it as a question of whether or not these statements are to be "understood" at face value. If so, then I'm not so certain that "private" repositories and "hoops to jump through" to obtain sources are not in direct violation of this. :unsure:

 

Link to comment
Share on other sites

@dencorso<--

This COPYRIGHT discussion could get fairly complex and lengthy (my guess) ???
Maybe a NEW THREAD that RT participates in it would be a preferred situation ???
On the other hand , whatever RT wants (and others , 'VistaLover' , 'LoneCrusader' , etc) ...
is fine with me. Not attempting to tell anyone what to do , just a suggestion here.

Added Later: I see where 'VistaLover' (message below) said that my suggestion here
was of some merit. So, high praise from 'VL' in my experience. :)

Edited by TechnoRelic
Link to comment
Share on other sites

12 minutes ago, luweitest said:

Just a reminder that recent builds have no asc signature file attached.

... And this is something we've all been informed about... :P

On 9/12/2020 at 6:49 PM, roytam1 said:

Notice: there are no GPG asc sign file for the time being due to GPG key backups are lost.

I'm sure it will be acted upon when convenient... :whistle:

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...