WG9s: 2.53.16b1pre dated 2023-01-24 22:00 for Linux64 (but not 2023-01-24 17:40) gives an enormously long popup when clicking right on a link. "Open link in new tab" there does nothing. I've scrapped it in favour of the 17:40 build.

tonymec|away: hmm let me try or i might just reboot the silly server

tonymec|away: works fine for me perhaps you need to clear your browser cache or restart your broswer for wome odd reason

some odd reason

but I am just clicking on save link as

open link in new tab works just as well

WG9s: hm. Worked OK for me in the 17:40 build before and after trying the 22:00 build.

strange thing you can't reproduce it.

oh, I thoght you were saying you could not download the 2200 build now i understand this is an issue with running the 2200 seamonkey build let me try tat

WG9s: yes. When I run the 22:00 build I get the problem; when running the 17:40 I don't.

silly me thought you were saying this was a general issue downloading builds with any browser so I was trying using firefox

aha

so I guess this is IanN_Away's issue

hm. Well you're aware of it, I have a temporary solution, and IIUC what you just said sent him a notification. :-)

"temporary solution" = go back to the previous build.

IanN[m]: major issues with your latest 3 landings to 2.53 gitlab

tonymec|away: I backed out IanN's last three gitlab patch queue changes and trying a new build. this should work. I hope he does not get pissed off at me for doing this.,

earlier today frg said that on a different channel and I posted a youtube of the eddie floyd song

:-)

tonymec|away: anyway I exp[ect new build I am doing now to work just fine.

tonymec|away: so new 2023-01-25 02:50 should work better I hope

toneynew build seems to work for me!

tonymec|away: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WG9s: ah, I'll download, install & test it. Wait a few minutes.

OK but sjhould be the same as the one you said alredy worked, unless i screwed up, I reverted the changes to the patch queue and did a new build based on the new patch queue but just to make sure what is in the patch queue actually works,.

if this were a mozilla thing kind of me doing the serif thing try to contact the person who landed the bustage and if i ca 't backout the changes

sherif

not serif

WG9s: build 20230125025033 is GOOD. Problem does not reappear.

tonymec|away: thanks for testiong

WG9s: my pleasure.

just need to get the rest of the platform builds to complete now

tonymec|away: seems i screwed something up with the windows build oops

WG9s: that one I cannot test, I have only Linux64. I might perhaps test a Linux 32 if I have all the necessary 32bit libraries but nothing more exotic.

no seems my builds were too late to not interact with the comm-cntral builds on the windows system. I thought I had fixed this but evidently not,

seems I need to find where i am still removing the file that i use for the later touchches to make all the files have the same timestamp that corresponds to the buildid

ok i fixed it so next time I do a late build will not be an issue

but the windows builds to fix this will be seriously later oh well you are the only one who complained about the earlier builds

tonymec|away: I sent an email to IanN explaining the issue and why I did what I did.

WG9s: I suppose my quick reaction prevented too many users from being hit. ATM it is 5:36 AM central Europe (4:36 UK).

which is why I could not raise IanN he is in the UK

yep

is 11:36 PM here and I am up a little later than normal

:-)

frg_Away: IanN_Away: With the build 20230124220003 from WG9S from today the context menu is messed up. When you right click in the browser window all entries are shown not only the case specific one.

hardys I think there was a prblom . Use the 01/25

IanN_Away: Thanks, I will go back to the last good build from 01/22

frg_Away: was meant for you :)

hardys I think the old 01/24 build should be ok archive.mozilla.org/pub/seamonkey/n…023/01/2023-01-24-17-40-00-comm-253

guys, i need help, the latest version of SeaMonkey won't launch for me. I'm on Mac OS X 10.9

Genaker: I did a build using an older SDK it is here can you try this one? wg9s.com/comm-253/seamonkey-2.53.16b1pre.en-US.mac.dmg

if this does not work I will try a build with SDK version 10.11 this one uses 10.12

I'm trying it now

It's giving me a "Minimum OS Version Requirement not met" error.

OK I will try something welse tomorrow morning

kk

sup fools

i know I asked this question before but can seamonkey be built with 2022?

and would you like it to be built with 2022?

lol]'

CaptainTobin: are you asking about vs2022? we have switched to building with clang-cl

CaptainTobin 17.3 broke it. I was too lazy to fix it yet. Compile error in some hash stuff because of changed VS2022 headers. Using Latest VS2019 for now.

should be fine to build it using the dlls form the vs2022 redist dir

clang works too for sure.

VS2019 gives a link error for x86 but this one is bad anyway. Crashes with heavy media use. So switched offical x86 to clang.

Genaker: not sure whay you get that error. I set the env variable MACOSX_DEPLOYMENT_TARGET to 10.9 so if you are running 10.9 I donlt thnk you should get that error

That's weird.

HMMM

yeah it says 10.9.5

I am going back to how my builds were a wek or so ago using sdk10.11 and not specifyinf a deplyment target at all

Genacker I suspect it is end of the line for 10.9 to 10.11 forums.mozillazine.org/viewtopic.ph…4d9dee5f6ce59cf3fb76870fd#p14948508

We didn't plan for it but if we don't find a solution we need to document 10.12 as the minimum unfortunately. Also stop updates for sure.

frg_Away: says he does not think a build using sdk 10.11 will work but I think it will as long as I do not try to specify "ac_add_options --with-macos-sdk=<path to sdk>"

I can't update past 10.9..

the build does a version check for the sdk but only if you specify via that config option

up until recently i thought i was building with 10.12 but was actually using 10.11 I have no idea why that would have stopped working I will try that tomorrow unfortunately my regular nightly builds are running now so would have to interrupt that to do a test build now but can in the morning

that shouldn't be too difficult to resolve

i just will not use clang

sorry but i won't

now when you say 2019 it is 2019 not 2015's compiler in 2019

right?

I likely will drop x86 completely at the end of this year

keep the ability but it is Best Effort(tm)

Yes native support for VS2017 VS2019 and VS2022 is in for both x86 and x64. VS2019 x86 broken VS2022 x86 and x64 currently broken.

yes builds using the 2019 and 1017 compiler can;t speak for 2015 still working or not

since I am not taking in jxr i can take my time getting to 2022 tho i will have resolve issues more and more so going 2022 is fine for me

I think Palemmon fixed the x86 link error but not sure.

well see frg has more info becuase I am building using clang

frg_Away: yeah but did they fix it properly

rememer I am the build system "expert"

heh

but using the vs2019 rediust dirs and inldue files for both x86 abd x64

8 years of build system being a primary responsibility to learn

VS2019 toolset in VS022 can be used too but this needs changes. Did this for VS2019 in 52/2.49.5

well you MIGHT have to readapt my patch to be more mozilla-like but if UXP and in turn my shit can go 2022 you can too and it IS actually my area of supposed expertise..

yeah i'd recommend not pulling that nonsense if one can avoid it

the newer vs older compiler thing

makes my diabeetus hurt

so using the dlls from the vs2019 redist and also using SDK version 10.0.19041.0

sdk version is mostly arbitary

as long as it is 8+

unless you directly backported more bs

Is that not where it gets the inlcude files from?

but since mozilla dumpped vs there shouldn't have been much to port in that case

well i mean is the one that ships with VS or at least windows 8.1+

The x86 stuff was some weird one. Given that I stopped caring about x86 and just see that the clang build still builds didn't look too much into it. The code breakage was/is wierd and I wonder why it doesn't break with clang. But no c++ expert.

at the base 50s era

well bigint for no good reason is being shat out to all the frameworks and bigint at our level even evolved won't be able to do bigint on 32bit regardless

quite frankly I have not understood the windows builds since mozila stopped using cygwin

WG9s: well where are you IN understanding so i can fill in the gaps

and onlhy reason to not build using cygwin was they could not get the flash plugin to work and now they no longer support that anyway

it is too late in the day to give you a top down explaination for how it theoretically works

I frequently update the compiler section in the meeting notes: wiki.mozilla.org/SeaMonkey/StatusMe…ngs/2023-01-15#.5Bcomm-release56.5D

cygwin is dead

then again so is autoconf 2.13 exactly and msys1

Need to add the VS2022 x64 problem. Only tried recently and found out.

I will need to steal my dpmo text and info back from MCP which includes my OWN properly evaluated compiler compat table

of course now it is a freeforall..

like everywhere else

everywhere but BinOC lol

autoconf 2.13 was copied to the mozilla central tree. Need to backport later but first needs more build stuff applied.

how did they swing license compat?

cause autohell is NOT MPL

or permissive

I know I followed the patch for the mapi headers import but i really don't feel good about having them live in mailnews

they really need to be in my third_party or what remains of legacy other-licenses

CaptainTobin: I think that is why everyting in configure is being moved to moz.configure and moz.build files

same would be true for autohell

they could have moved to newer autohell

mozbuild was all about trying to create a mozilla version of a google concept of cmake

so tryuing to eliminate autodonf altogether

autoconf

now mozbuild is OKAY in my book at my level

mozconfigure is a god damned disaster

i will exterminate it

but yeah.. my crystalized plan going forward is broadly let MCP and co worry about following the GoogleWeb.. I am gonna focus on everything I always wanted to do

and btw Borealis won't ever be released in its current form.

Interlink will get some love and continue as-is i have something way better planned

CaptainTobin The VS2020 could probably be fixed by backporting Bug 1641090. As stated too lazy currently and needs a bit more stuff first to apply clean(er) which i always try to do.

I'll look into it

part 10 removed the offending stuff.

gonna need to for the weave uplift and refresh

man i do NOT want to have to move my fuckin dns server

but i got a smaller server for dns irc and other critical but small services so they can stay operational while more complex server shit is afoot

frg_Away: here is an important question

i will need for that work

how much moz-specific js functionality have you mutated or removed since forking 56

cause weave was orginally written during the pre-jsm extension but post jsm era

so there might be classic mozillaisms we may run into here and there

least I don't have to fix the god damn for loops

Code is 90% at end of 58 minus the really bad parts. I skipped a few sync plates lately. Later stuff in too of course but mostly in other areas.

^skipped sync patches

when I ported the tycho weave client and add-ons manager i had to one by one test everything manually and solve the depercated pythonic-style loops to either es5 or es6 standard loops

there shouldn't BE that many sync patches for weave given the tech was abandoned.

and only partly stayed as part of fxa because fxa was half-assed from the start

also inital transition

here is everything WE did up to the gre-changes

if there is any removed mac bits I'll add them back

so don't worry about that

but i see no reason to bother restoring android

to weave

e4x for-eah bug 1388317 is on my short chop chop list.

for each?

rther

for Each

yes

anyway i repercated it

cause es6 loops still fuck with my brain

as much es6 nonsense does

is that the inverse?

repercate?

js version and legacy generators are out too.

heh

guess i'd have to actually revcerse this patch

Trying to get the parser updated and these deprecated features always were/are in the middle of it.

if i did a retrofit

of the engine

some shit does need to go

but some shit i wanna keep

but thank you that is one important tidbit to consider for a js uplift

is the moz or legacy removals

which means the fe code either needs adapted or the features need to be put back in

and for me that is a case by case basis

cause JS version is important to extensions and chrome code

imo

especially if i want to have that line between eichscript and emcascript

Legacy getters/setters give me much grief too but so far I kept them. Fear for massive add-on breakage.

like the line between xul/xbl and html/googlecomponents

Same for nsIAtom nsAtom conversion

well as I said I am gonna largely let MCP run them selves in circles chasing google tech.. i am more focused on true mozilla tech

least until SOME sort of better plan materalizes

anyway sleep first

nn

tho one tidbit they keep ignoring is style.. there is no reason why we don't have every non-servo or simple css shit

tonymec|away: tonights build with IanN_Away's updated patches seems to work just fine for me. Give it a whirl!

tonymec|away: build is done you get notifiactaion after all the langpacks are done and archived