#1759 Restore xulrunner-stub and xulrunner packaging

Closed
opened 6 months ago by lekma · 22 comments
lekma commented 6 months ago

if yes I have a couple of patches I’d like to submit.

thanks

if yes I have a couple of patches I'd like to submit. thanks
Moonchild changed title from [Question] Is there any interest in restoring xulrunner-stub and xulrunner packaging? to Restore xulrunner-stub and xulrunner packaging 6 months ago

I don’t see why not. It does need some love and will have utility value if done right.

I don't see why not. It does need some love and will have utility value if done right.
Moonchild added the
App: Toolkit
label 6 months ago
Moonchild added the
Assigned
label 6 months ago
lekma commented 6 months ago

Disclaimer: I can only test on linux.

It turns out xulrunner-stub needs libmozglue (it segfaults on dlopen() without it).
Statically linking it produces a binary that is, I think, too big (~180 kB).
Dynamically linking puts it back to a reasonnable size (~52 kB).

If we choose the latter we need to build a shared mozglue as well as a static one for platforms that define MOZ_GLUE_IN_PROGRAM (linux, bsds?). If you have a look at https://repo.palemoon.org/lekma/UXP/commits/branch/xulrunner_packaging the first patch does just that.

For the rest I just tried to restore the missing files from bits and pieces I still had from the time I was working with xulrunner.

As an aside do you know of any archive/repo that has the last version of mozilla including xulrunner?

Disclaimer: I can only test on linux. It turns out xulrunner-stub needs libmozglue (it segfaults on dlopen() without it). Statically linking it produces a binary that is, I think, too big (~180 kB). Dynamically linking puts it back to a reasonnable size (~52 kB). If we choose the latter we need to build a shared mozglue as well as a static one for platforms that define MOZ_GLUE_IN_PROGRAM (linux, bsds?). If you have a look at https://repo.palemoon.org/lekma/UXP/commits/branch/xulrunner_packaging the first patch does just that. For the rest I just tried to restore the missing files from bits and pieces I still had from the time I was working with xulrunner. As an aside do you know of any archive/repo that has the last version of mozilla including xulrunner?
lekma commented 6 months ago

oh and there also is the XULRUNNER_STUB_NAME/--with-xulrunner-stub-name= config option missing.
I don’t think it is that important but we could restore it if need be... (by someone who has a better understanding of the build system than me).

oh and there also is the XULRUNNER_STUB_NAME/--with-xulrunner-stub-name=<appname> config option missing. I don't think it is that important but we could restore it if need be... (by someone who has a better understanding of the build system than me).

If you don’t actually know what you are doing please do nothing at all. I don’t want to have to clean up issues introduced by others.

If you don't actually know what you are doing please do nothing at all. I don't want to have to clean up issues introduced by others.
lekma commented 6 months ago

what are you talking about?
Do you know what we are discussing here?

there is a choice to be made here (linking statically or dynamically), I’m not gonna choose unilaterally without discussing it with the people involved that’s why I’m asking here what people think about this.

If you don’t have anything constructive to contributre towards this choice, please be quiet...

what are you talking about? Do you know what we are discussing here? there is a choice to be made here (linking statically or dynamically), I'm not gonna choose unilaterally without discussing it with the people involved that's why I'm asking here what people think about this. If you don't have anything constructive to contributre towards this choice, please be quiet...

Do not give me orders.

I too would like to make xulrunner more functional than it currently is restoring it to its former glory but there is no reason that linking is even a question here.

It is merely an xre stub like every other UXP application and build system wise it merely needs updated to better conform. I am well aware of what needs done but you seem to be caught up on details that aren’t relevant and have the misconception of trying to treat it as any bog standard gnu application when it isn’t.

So again, if you don’t know exactly what you are doing please do not try to make more of a mess of it than it already is.

Additionally, you will not be allowed to modify global build system templates that affect how all applications are built JUST for xulrunner in its current form. I would just scrap it and start from scratch in that case or consider building a proper UXP Application.

Do not give me orders. I too would like to make xulrunner more functional than it currently is restoring it to its former glory but there is no reason that linking is even a question here. It is merely an xre stub like every other UXP application and build system wise it merely needs updated to better conform. I am well aware of what needs done but you seem to be caught up on details that aren't relevant and have the misconception of trying to treat it as any bog standard gnu application when it isn't. So again, if you don't know exactly what you are doing please do not try to make more of a mess of it than it already is. Additionally, you will not be allowed to modify global build system templates that affect how all applications are built JUST for xulrunner in its current form. I would just scrap it and start from scratch in that case or consider building a proper UXP Application.
lekma commented 6 months ago

Do not give me orders.

well you’re the one who started with the agression... relax

I too would like to make xulrunner more functional than it currently is restoring it to its former glory but there is no reason that linking is even a question here.

It is merely an xre stub like every other UXP application and build system wise it merely needs updated to better conform. I am well aware of what needs done but you seem to be caught up on details that aren’t relevant and have the misconception of trying to treat it as any bog standard gnu application when it isn’t.

that’s the point!
mozglue has inflated dramatically since v45 and now linking it statically (which made sense a long time ago) produces very big binaries (we might have a different opinion on this).
this is why this is an opportunity to fix this. my suggestion only affects xulrunner-stub, the linking for other GeckoPrograms isn’t touched (I cannot be 100% sure of this because I can only test on linux).

but, I don’t really care either way, that is why I submitted the question, I can live with a simple wrapper around XRE_Main that is 180 kB, but I thought maybe others would prefer a slimmer binary.

So again, if you don’t know exactly what you are doing please do not try to make more of a mess of it than it already is.

you seem to be under the impression that you are THE only person having insight on how this works (it’s kinda funny).

> Do not give me orders. > well you're the one who started with the agression... relax > I too would like to make xulrunner more functional than it currently is restoring it to its former glory but there is no reason that linking is even a question here. > > It is merely an xre stub like every other UXP application and build system wise it merely needs updated to better conform. I am well aware of what needs done but you seem to be caught up on details that aren't relevant and have the misconception of trying to treat it as any bog standard gnu application when it isn't. > that's the point! mozglue has inflated dramatically since v45 and now linking it statically (which made sense a long time ago) produces very big binaries (we might have a different opinion on this). this is why this is an opportunity to fix this. my suggestion only affects xulrunner-stub, the linking for other GeckoPrograms isn't touched (I cannot be 100% sure of this because I can only test on linux). but, I don't really care either way, that is why I submitted the question, I can live with a simple wrapper around XRE_Main that is 180 kB, but I thought maybe others would prefer a slimmer binary. > So again, if you don't know exactly what you are doing please do not try to make more of a mess of it than it already is. > you seem to be under the impression that you are THE only person having insight on how this works (it's kinda funny).

Yeah well slimmer binaries by kilobytes are NOT a valid consern here. You are still not going to alter global build templates just for xulrunner and if that is a deal breaker tell me now so I can remove the application tree and put an end to speculation over it here and now.

Aside from basic configure options that may need to be restored you should not need to alter the build system its self to accomplish anything except the build files for xulrunner.

You SHOULD also keep in mind that a lot has changed since xulrunner was last fully operational as well as UXP has changed since it was m-esr52. It is xulrunner that has to be adapted not UXP. Use the current UXP Applications like Pale Moon to gain insight into how to conform xulrunner.

Yeah well slimmer binaries by kilobytes are NOT a valid consern here. You are still not going to alter global build templates just for xulrunner and if that is a deal breaker tell me now so I can remove the application tree and put an end to speculation over it here and now. Aside from basic configure options that may need to be restored you should not need to alter the build system its self to accomplish anything except the build files for xulrunner. You SHOULD also keep in mind that a lot has changed since xulrunner was last fully operational as well as UXP has changed since it was m-esr52. It is xulrunner that has to be adapted not UXP. Use the current UXP Applications like Pale Moon to gain insight into how to conform xulrunner.
lekma commented 6 months ago

Yeah well slimmer binaries by kilobytes are NOT a valid consern here.

all right then.

You are still not going to alter global build templates just for xulrunner

xulrunner-stub only

and if that is a deal breaker tell me now so I can remove the application tree and put an end to speculation over it here and now.

(???) please, by all means, delete the tree if that makes you happy...

(this conversation was very strange, you’re a very funny human being)

> Yeah well slimmer binaries by kilobytes are NOT a valid consern here. all right then. > You are still not going to alter global build templates just for xulrunner xulrunner-stub only > and if that is a deal breaker tell me now so I can remove the application tree and put an end to speculation over it here and now. (???) please, by all means, delete the tree if that makes you happy... (this conversation was very strange, you're a very funny human being)
lekma closed this issue 6 months ago

And this is why you are suspect and I stepped in. Entirely unwilling to justify conserns put to you while making assurances you repeatedly can’t actually be sure of by your own statements.

You were only thinking of your own selfish priorities and not the good of everyone.

Work on xulrunner or any platform component must take into account not only the original intent they were created for but must consider any and all ramifications to all dependant applications.

But a modern web kodi media python nutbar wouldn’t understand that would they?

And this is why you are suspect and I stepped in. Entirely unwilling to justify conserns put to you while making assurances you repeatedly can't actually be sure of by your own statements. You were only thinking of your own selfish priorities and not the good of everyone. Work on xulrunner or any platform component must take into account not only the original intent they were created for but must consider any and all ramifications to all dependant applications. But a modern web kodi media python nutbar wouldn't understand that would they?
lekma commented 6 months ago

And this is why you are suspect and I stepped in.

you seem to be living in a strange alternate reality

But a modern web kodi media python nutbar wouldn’t understand that would they?

wow! you must be fun at parties

> And this is why you are suspect and I stepped in. you seem to be living in a strange alternate reality > > But a modern web kodi media python nutbar wouldn't understand that would they? wow! you must be fun at parties

Here is the last question: Are you willing to prove me wrong in my assessment?

Here is the last question: Are you willing to prove me wrong in my assessment?

So a ton of aggravated back-and-forth here. Condense it for me, please, without getting in each other’s hair. What’s the problem, exactly?

Statically linking it produces a binary that is, I think, too big (~180 kB).

This isn’t 1995. C’mon, man.

So a ton of aggravated back-and-forth here. Condense it for me, please, without getting in each other's hair. What's the problem, exactly? > Statically linking it produces a binary that is, I think, too big (~180 kB). This isn't 1995. C'mon, man.

I think they are a selfish hack with no idea what they are actually doing and if they do get something going it will only be for their own personal benefit at the cost of all of us which would never be permitted or have to be reverted in the end thus making this whole exercise pointless.

I think they are a selfish hack with no idea what they are actually doing and if they do get something going it will only be for their own personal benefit at the cost of all of us which would never be permitted or have to be reverted in the end thus making this whole exercise pointless.
lekma commented 6 months ago

This isn’t 1995. C’mon, man.

now I feel old :)

> This isn't 1995. C'mon, man. > > now I feel old :)

Shoving a half-assed incomplete pull request in our faces for an issue you flippantly closed is NOT a good way to endear yourself to me.

Shoving a half-assed incomplete pull request in our faces for an issue you flippantly closed is NOT a good way to endear yourself to me.
mattatobin removed the
Assigned
label 6 months ago
lekma commented 6 months ago

Shoving a half-assed incomplete pull request in our faces for an issue you flippantly closed is NOT a good way to endear yourself to me.

you are confusing me
I’m not shoving anything into anyone’s face.
the pr was meant to fix this issue with minimal change (as you asked). did I miss something?

> Shoving a half-assed incomplete pull request in our faces for an issue you flippantly closed is NOT a good way to endear yourself to me. you are confusing me I'm not shoving anything into anyone's face. the pr was meant to fix this issue with minimal change (as you asked). did I miss something?

That is what incomplete means. You are directed to do it properly or not do it at all.

Perhaps you are confused because you don’t understand what is required to restore xulrunner to a fully working state. As I have stated.

I also never asked for a pull request and it does only part of the job and what I told you not to do. So stop.

That is what incomplete means. You are directed to do it properly or not do it at all. Perhaps you are confused because you don't understand what is required to restore xulrunner to a fully working state. As I have stated. I also never asked for a pull request and it does only part of the job and what I told you not to do. So stop.
lekma commented 6 months ago

That is what incomplete means. You are directed to do it properly or not do it at all.

what does ‘properly’ entails exactly if you don’t mind my asking?

Perhaps you are confused because you don’t understand what is required to restore xulrunner to a fully working state. As I have stated.

(you have never stated what was needed)

the pr covers exactly the bug, it restores xulruner-stub (in a working state) and restore the possibility of packaging xulrunner, that was the whole scope of this bug.

@Moonchild: would you mind reviewing pr #1760, because I’m not really good with riddles, If there is something missing then I’ll happily fix it, but afaict this is good (again I only tested it on linx).

> That is what incomplete means. You are directed to do it properly or not do it at all. > what does 'properly' entails exactly if you don't mind my asking? > Perhaps you are confused because you don't understand what is required to restore xulrunner to a fully working state. As I have stated. > (you have never stated what was needed) the pr covers exactly the bug, it restores xulruner-stub (in a working state) and restore the possibility of packaging xulrunner, that was the whole scope of this bug. @Moonchild: would you mind reviewing pr #1760, because I'm not really good with riddles, If there is something missing then I'll happily fix it, but afaict this is good (again I only tested it on linx).
Moonchild reopened this issue 6 months ago

Why was this closed, to begin with, if there’s further discussion?

I’m assuming this should be buildable from the UXP source root. If so, either i’m doing something wrong or the build patch is incomplete.

I can’t review anything if I can’t build, so here’s what I tried:

a mozconfig:

ac_add_options --target=x86_64-pc-mingw32
ac_add_options --host=x86_64-pc-mingw32

mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_MAKE_FLAGS="-j20"
mk_add_options MOZ_OBJDIR=../../obj-xulrunner-x64

ac_add_options --enable-application=xulrunner
ac_add_options --enable-optimize="-O2 -GS- -favor:AMD64"

ac_add_options --enable-jemalloc
ac_add_options --enable-strip

WIN32_REDIST_DIR=$VCINSTALLDIR/redist/x64/Microsoft.VC140.CRT
WIN_UCRT_REDIST_DIR="C:/Program Files (x86)/Windows Kits/10/Redist/10.0.19041.0/ucrt/DLLs/x64"

with this, mach build inside the UXP source root fails.

Why was this closed, to begin with, if there's further discussion? I'm assuming this should be buildable from the UXP source root. If so, either i'm doing something wrong or the build patch is incomplete. I can't review anything if I can't build, so here's what I tried: a mozconfig: ``` ac_add_options --target=x86_64-pc-mingw32 ac_add_options --host=x86_64-pc-mingw32 mk_add_options AUTOCLOBBER=1 mk_add_options MOZ_MAKE_FLAGS="-j20" mk_add_options MOZ_OBJDIR=../../obj-xulrunner-x64 ac_add_options --enable-application=xulrunner ac_add_options --enable-optimize="-O2 -GS- -favor:AMD64" ac_add_options --enable-jemalloc ac_add_options --enable-strip WIN32_REDIST_DIR=$VCINSTALLDIR/redist/x64/Microsoft.VC140.CRT WIN_UCRT_REDIST_DIR="C:/Program Files (x86)/Windows Kits/10/Redist/10.0.19041.0/ucrt/DLLs/x64" ``` with this, `mach build` inside the UXP source root fails.

You have been flouting my authority from the first consern put to you and it stops here. Perhaps you are not aware of to whom you are speaking but I am the UXP Coordinator and I am telling YOU that what you are doing is half-assed and incomplete. You do NOT get to decide what the issue is or if your fix resolves it.

You editied that build template to hardcode a vlue for that xr-stub which I told you NOT TO DO but you did it anyway. I told you that complete restoration of xulrunner was more involved you responded by closing the issue. I told you that the only global build system bits you needed to have to do is basic configure work, you ignored it.

You absolutely don’t understand why it is incomplete, you can’t test anything but linux, you make assumptions that are wrong and assurances that you can’t be sure of and all because you don’t understand exactly what it is you need to accomplish to bring xulrunner back into complete working order.

THEN you continue to ignore all that and then try and pull and end run around back to Moonchild. Well I am not going to tollerate that kind of bullshit not from someone who shows up out of the blue and pretends to know what is going on. This isn’t the Pale Moon Forums and this discussion is quite concluded. Your patch has been rejected and I am not at ALL confident in your ablity to commit anything to OUR tree.

Please move along.

You have been flouting my authority from the first consern put to you and it stops here. Perhaps you are not aware of to whom you are speaking but I am the UXP Coordinator and I am telling YOU that what you are doing is half-assed and incomplete. You do NOT get to decide what the issue is or if your fix resolves it. You editied that build template to hardcode a vlue for that xr-stub which I told you NOT TO DO but you did it anyway. I told you that complete restoration of xulrunner was more involved you responded by closing the issue. I told you that the only global build system bits you needed to have to do is basic configure work, you ignored it. You absolutely don't understand why it is incomplete, you can't test anything but linux, you make assumptions that are wrong and assurances that you can't be sure of and all because you don't understand exactly what it is you need to accomplish to bring xulrunner back into complete working order. THEN you continue to ignore all that and then try and pull and end run around back to Moonchild. Well I am not going to tollerate that kind of bullshit not from someone who shows up out of the blue and pretends to know what is going on. This isn't the Pale Moon Forums and this discussion is quite concluded. Your patch has been rejected and I am not at ALL confident in your ablity to commit anything to OUR tree. Please move along.
Moonchild closed this issue 6 months ago

If we want to restore xulrunner (do we?) then we obviously need an outline in a meta somewhere before anyone can work on it, if I understand all of this correctly.

Just forcing a stub build and packaging isn’t going to fix xulrunner itself which needs to happen first (since it’s apparently severely bitrotted), and this issue was therefore premature -- it should happen later (and honoring the various configurable parts of it like the stub name) if at all.

Now everyone go have some tea and cool respective heads. This needs a lot more structure and can’t be quickied, and arguing in repo issues isn’t constructive.

Perhaps lead-in dev discussion on the forum would be a good idea before jumping ahead and tossing in an issue and PR.

If we want to restore xulrunner (do we?) then we obviously need an outline in a meta somewhere before anyone can work on it, if I understand all of this correctly. Just forcing a stub build and packaging isn't going to fix xulrunner itself which needs to happen first (since it's apparently severely bitrotted), and this issue was therefore premature -- it should happen later (and honoring the various configurable parts of it like the stub name) if at all. Now everyone go have some tea and cool respective heads. This needs a lot more structure and can't be quickied, and arguing in repo issues isn't constructive. Perhaps lead-in dev discussion on the forum would be a good idea before jumping ahead and tossing in an issue and PR.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
3 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.