buc_: who are you?

buc: I am you

heh. whatever method Mozilla uses to name /cache2/ files, there can be duplicated names between different (Mozilla) browsers & instances

C:\000\TMP\SEA\github\cache2\entries\A05EE3C9A097CB806AB235EFF1059206C6C30833

C:\TMP\SEA\258b1\DUMY\cache2\entries\A05EE3C9A097CB806AB235EFF1059206C6C30833

C:\WLIB\Mozilla\USERS\FF78_ESR\cache2\entries\A05EE3C9A097CB806AB235EFF1059206C6C30833

therube: maybe because it's the same file?

_that: no. i've got 6 of that particular file (name) & all are different sizes (& dates)

ok, then my guess was incorrect

Why on gitlab in gitlab.com/seamonkey-project/seamon…ey-2.53-mozilla/-/tree/2_53_8_final there is no more "extensions/inspector" (since it was moved to comm/suite), but the final tarball from archive.mozilla.org/pub/seamonkey/t…urce/seamonkey-2.53.8.source.tar.xz still has it? (BTW, they differ).

Well, is it needed just to remove an extra old "extensions/inspector" before the build? What instance will be actually used when build?

Yet another example of the consequences of disrespecting the basic rules of OpenSource --the binary packages you build must be built directly from the sources you provide.

A way "hg-->binaries" AND "hg-->sources" is a violation. Must be "hg-->sources" and then "sources-->binaries".

The previous issue (because of this way) is: freenode.logbot.info/seamonkey/20201111#c5790620

buc It should be removed from extensions/inspector. That is what I did on the Windows builder.

frg: Maybe fix the tarball while it still in "tmp/"?..

IanN_Away can you regenerate the tarball.

>Yet another example of the consequences of disrespecting the basic rules of OpenSource --the binary packages you build must be built directly from the sources you provide.

Sorry yet another example of nitpicking. If the directory is included it is just dead code and ignored at compile time. That seems to be the case on the Linux builder.

You do know that buildablity is not implicit in providing source code under the MPL

the only requirement under the MPL is to provide MPL covered source code that is used in an executable form

upon request and in a timely manner

no where in any open source license does it say it has to buildable

as long as it is provided it is enough

of course my UXP applications are NOT open source they are propritary like Netscape so I only need to provide that code which is covered by the MPL which means filtering any propritary files out of any distribution of source code

for now they do build in that unofficial unbranded configuration but that may not always be true

at least I use a MPL code and not say MIT/BSD code like microgoogleappleoperasoft does where they don't have to disclose anything and can keep changes to licensed code private forever

Well, in this tarball an extra "extensions/inspector" is a really dead code and spoils nothing. So, IanN may not regenerate the tarball :)

does DOMi even still work with your codebase level?

yes it work in 2.53.9