nsITobin don't think so. Tools should have the same layout. Just a different base.

it chilly this morning

Good morning #SeaMonkey

nsITobin greetings

nsITobin just did a 2.53 build with only build tools vs2022 and the 141, 142 and 143 toolsets installed so should be fine for 2019 too.

Tools seem to have much less bloat indeed. Needed only to remove vctip.exe

I will give it a try with the vs2019's vs2019 build tools as currently configured .. while there may not be an issue.. i remember it was hell trying to use 2015 build tools on 2017 AND keep normal 2015 working when I tried to solve it for UXP based on your attempt.. I just wanted it all.. as typical :P

tossing a coin if I should fix 2.49 for the 141 toolset

VS2017 can no longer compile 2.53 so removed from it.

what would 2.49 offer that seamonkey on uxp wouldn'

aside from XP compat

frg: are you still releasing updates for 2.49?

security ones

nope. Would just be for the xp fans to self compile.

well if one wants to give seamonkey 2.49 as a special gift to xp users I think one should do a special final release short of actually compiling it with special branding already in place so they don't have to do anything cause that has been a trouble point in the past.. make a big deal about it.. and then see what happens

Not sure if I want to spend time for doing a release. Would only do it so that I have the option in my build setup and less build envs. So mostly selfish me.

yeah pain alreayd trying to balance these envs and keep them clean and free of mangling

i have to work extra hard to have multiple build eras working on one machine but it comes at the cost of being way easier to bust

but i get efficiency

Have 3.4 and 4.1 separate thanks to the state path now set in start-shell.bat: SET MOZBUILD_STATE_PATH=d:\mozilla-build\workspace34

Works for 3.2 too so they can all co exist.

2.49 would be riding mb 2.x right?

Nope 3.2

nsITobin wondered if /build/windows_toolchain.py was used. Now I know. Not :)

so out the door with a bunch of hardcoded msvc references.

doesn't that bust start_shell_vs* files hacked to continue providing the vars to the build system?

19 The ``build/windows_toolchain.py`` script is used to build and manage

20 Windows toolchain archives containing Visual Studio executables, SDKs,

21 etc.

no all in build/moz.configure/toolchain.configure and friends.

See Bug 1289641

OH that's part of bootstrap

or .. was

lol

or would have been

depends on your perspective

either way automated mozinfra

gitlab 2.53 updated for it

nsITobin rust compiles in central are still great.... ibb.co/fVZb0xp9

10 forking GB

version?

cause 1.82 is behaving memory wise

for j6

but then again linking libxul has taken that much ram before on windows

-j8 with latest 1.85

libxul could have linked in shared xpcom dlls instead of rolled in and NONE of this would have ever been a damned issue

for fifteen bloody years now

It is no longer 2010 so I can live with 8 GB for all but not 10GB plus compiles plus something

fits into a 16gb windows vm i am fine.. beyond that i am screwed

Hey now its 18GB for rust. Have assigned 24GB to the vm.

19 and 98% mem usage

nsITobin STATUS_STACK_BUFFER_OVERRUN and needs more ram.

Totally whacko

yep

I need to look into rust, because now I'm wondering how come it can get so high memory consumption

is it doing links in parallel or something?

njsg: they fucked it up cause 1.82 works fine

its always gonna be high memory consumption but this is ridiculous

I can go back to 1.82 but not sure it would help. j8 and normal optimize might be it.

Needs more electrolytes!

1.83 MAY be fine too but 4+ seems to have an "issue"

gonna try .. know in 70 minutes

I think everyone should take advantage of these cpp apps going rust to learn rust so it can be translated back to plain C

and of course the web gonna be the web and there's people saying this is okay because unused ram is wasted

solve two issues at the same time

lol

look, there are good ways to use RAM, this almost surely isn't one of them :-P

njsg: the world wide web or the walled garden corperate mandated open web

cause there is a difference in my book

living standards are not formal standards they are endrun mandates by socially and economically more powerful groups

unused ram is wasted?

I'm sorry.. I thought this computer was a multiprocessing system.. I do have other shit to do while I am waiting for 70 minutes for mozilla to compile :P

apparently the only place where the usage of ram isn't advocated in this way is several Microsoft operating systems

that is kinda tough when all my ram is being used for one series of operations

having such behaviour in applications and utilities seems to go counter the idea of a system where, yes, you do other stuff

well windows historically without memory protection and shit has to ensure it has enough for its self and later MUST ensure it has enough for its self so it can mediate everything

now its just.. wasted cpu time and electricity

cause efficiency doesn't matter

I miss the "you own the world" memory model of Windows 9x :D

now you can't even really own your own files on a cellphone

does destiny.manifest ring any bells?

Meeting time in 27 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09

today?

k

nsITobin yes as in 18 minutes

IanN_Away: sent you CCI details :)

Meeting time - wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09

hi .*

hi njsg

greetings

are we expecting rsx11m?

or has rsx11m succumed to DST?

either way...

Who's taking minutes?

I think he wanted to attend

me

thanks

summer time might have derailed him :)

Nominees for Friends of the Fish Tank?

welcome rsx11m

IanN for still trying to make cZ a better place.

Hi rsx11m

Sorry, a bit late today...

rsx11m: hi

Hi *

seconded

rsx11m: blame DST

always ;-)

failing that POTUS

Action Items

bau

Status of the SeaMonkey Infrastructure

ewong is still on the configs and has set up some tasks on the Windows builder.

Old Linux and Windows builder are gone.

or should be very very soon

yeah. ewong is also looking at signing

Status of the SeaMonkey Source Tree

nsITobin and I made central complie again. Mostly him.

^compile

central patch queue updated for it.

For 2.53 I removed VS2017 support becuase the compiler can no longer be used. We need later c++ features. Added support for VS2022 but only for the VS2019 toolset currently.

SO VS2019 and Vs2022 can be used also the build tools.

rust 1.83 for central seems largely ram behaved as well

1.84/85 seem to have memory leak issues

(is it memory leak or just increased usage? any visible difference in compile times or CPU usage?)

something to research njsg

where are we on rust for 253? cause I still been using 1.73

1.73 forever for now

wasn't there an upper limit to allow NT 6.1?

yes and macOS 10.11

so this ram thing may not go away

If we set macOS 10.12 as minimum I need to check but it is either 1.75 or 1.76 then.

1.73 seems stable for now.

Release Train

still no eta for 2.53.21 I didn't do much soruce wise for the last 3 weeks but didn't notice any urgent fix needed either.

Release Train

already there :)

Skip Betas yet?

Extensions Tracking

nsITobin not planned

bau. I still need to look into the add-on sdk but no time.

is the add-ons sdk worth keeping?

beyond devtools?

There was one add-on which was still being updated but we broke it.

"Drak Backgorund and Light text"

^Dark

Not happy about it but complaints are few.

Still would like to fix it.

is that the one?

yes

jetpack extension

well that answers my question

I presume it is github.com/m-khvoinitsky/dark-backg…d-light-text-extension/tree/jetpack

that matches xpi contents

IanN:

yes but the webext version in master

so fix jetpack version or work out what's needed to get webext version working

did it ever have a normal extension form?

IanN: betting on webextensions on this codebase ever working without modifications to the extensions them selves simply wasn't possible 10 versions ahead certainly not 75

webext is crap and needs soo much work. And with manifest v3 it gets crappier.

beyond content blockers and site specific moding extensions.. what is the appeal of webextensions.. they can't DO much more than that or what some webapi says

but you'll be able to do nothing, across "all" browsers!

but this is an agrument that can go on for years.. and has.. soo enough out of me on it for now ;)

It is mostly lego and the real support is in the browser but this is something we can debate for years so i won't start it :)

duplos maybe

2.Next, Feature List, Planning and Roundtable

yeah with v3 it is Duplo. With v4 it will probabably be prefabricated :)

bau. Real life took over lately and I wasn't much in the modd for more but need to work on wip. Another site I use frequently broke because of js.

would a site to report broken sites be useful to us with some annotations?

have checkboxes users can check for which clients they tried

etc

depends if it will capture new, useful information

and of the SNR

nsITobin I can file breakage all day. We just need to fix some of it so I would say now. 90% es class fields, dynamic imports, BigInt and the css

perhaps it'd be better to round up suggestions of things to check first in a tutorial-ish text, unless there's already such a page somewhere

I'll let it simmer in mah brain for a while

thanks

AOB

not from me, bau :-(

just DST again

bau

yepp, 14:00 UTC next time

ah yes

next meeting is on the EU DST day

set your alarm clocks! 8-)

Everyone who wants/needs CCI FTP access get at me for initial creds

thanks

If someone wants a new Windows prerelease build let me know.

linux and mac are handled for 253 right?

i'll call it a meeting, thanks for your time today, next meeting in 3 weeks, same bat channel, same DST adjusted bat time

:)

nsITobin yes

nsITobin: yes, should be being built automagically

bye then!

ewong is on Windows

c u rsx11m

rsx11m: cya

good thing is the cci ftp will still be useful for adhoc build trading or indvidiual test builds

happy day and cu here as away

once windows builds are automagical again

nsITobin yes still good for adhoc stuff as now.

I need to get a dromaeo instance up online .. I don't have my modified PM-related sources so I will have to logic it out again to work it..

still useful for excersizing the codebase and getting reletive speed comparisons on operations that aren't as useless as today's benchmarks..

i have found crashes that way

missed the meeting due to some CRT tinkering

does anyone want some 25 year old Compaq display full of curves? :D

you gonna drop it off?

cause if so I'll take it

imgur.com/a/Bb2xLGN you just have to pay shipping from Venezuela :P

speakers still work?

cause I recall em not being TOO terrible

but that might have eben a different model

they STILL work

and they sound awful if you pump too much volume into them

set them to moderate volume and they will sound... more or less OKaysh

frg_Away: well.. there is always this addons.palemoon.org/addon/swarth

could be reexpanded to include more content types and re-adapted for seamonkey possibily

IF I find some time I will try to fix the breakage. If not possible might be time to nuke jetpack.

de-jetpacking devtools blocks removing jetpack, prior but aborted alt plan is to localize jetpack for add-ons sdk only altering many dozens of urls but I've done it before.

jetpack for devtools-only*

but an advantage is 253 is close to that so mozprogression is likely prefered rather than me hacking around it.

i seem to recall looking into dejetpaking devtools when mozilla did it.. went off on some research to see if i could backport it at the time.. but devtools had a lot of work done in the 50s so it was not new enough to SIMPLY do it.. a somewhat updated 56 based devtools tho.. very close to when they did it..

what change busted jetpack?

nsITobin not sure. That is the problem. Suspect one of the security backports IanN did for resources but was some time ago. Fixed one error in jetpack but now it might be something in the add-on. There are still problems in jetpack wrt async and promises but they usually are harmless and affect only errors logges when deinstalling.

is seamonkey fully on dom promises now?

or was it js engine promises

one was transitioned to from the other

anythoing up to 60 should be more or less in plus later fixes

Beyond the jetpack remoavl point for sure. Only did it partially

well 7 years ago i guess we deemed jetpack promises as a reason to almost eradicate jetpack

doesn't mean jack tho

confirmed, 253 has everything mozilla did to sdk promise.js

nothing has been changed for jetpack in UXP for 7 years save some revovals from elsewhere

... yeah this is gonna be a joy to try and fix

and stuff that makes it more .. not australis friendly

Might be contentaccessible missing somewhere but just a hunch

hmm possible

Most stupid task of the day done: ibb.co/wFF2jpk4

when did you add that damned tab line to .49 lol

long ago and I like it :)

you also like not having xpfe style grippies.. even I got over them finally.. more trouble than they were worth

FranklinDM turned it into an extension for Pale Moon

there are like half a dozen extensions for Pale Moon with SeaMonkey/Borealis functionality it's kinda ridiculous..

Well they are still there and can be enabled in prefs. I also like choice.

the core communicator has some smart design in it.. namely accessibility to functions via menu and button and often context menu too and normally a shortcut key.. this is something Firefox busted in a lot of ways with the toolkit aesthetic and certainly after australis

is the infobars-only pref still in 253 cause I like infobars vs doorhanger popups

If it is in its probably broken and untested but I don't remember. I know that I did a lot of notification changes and I am not the brightest css bulb in the house.

i am not spectacular at css either .. Have gotten better these past years but not an expert and likely won't ever be as css chanegs into a scripting language

And now back to something useful. But at least I can now build 2.49, 2.53 and central in one vm with only the VS2022 build tools installed.

I need to redo my ntlite 2019 .. it's corrupt from prior removals with updates.. but to BUILD IT ALL.. i would have to go back to 2019 not my lovely windows 7 vm

since you are indicating further backports will be leaving 2019 compat anyway windows 7 for building isn't sustainable

even for test builds which is fine

VS2019 should be fine for some time. Have long ago kicked the 7 build vm. It was too slow compared to 8.1 and 10.

In bug 1817633 patch landed that ported part of bug 1816266 which includes removing THUDERBIRD_VERSION so part 4 for bug 1952288 which was going to remove SEAMONKEY_VERSION is also gonna pick up the remaining applicable bits for suite vs thunderbird in 1816266

almost sounds like I know what I'm doing .. that's conserning.. FOR SOME :P

frg_Away: fyi when I post these updated patches to 1952288 top 1611647-2-fix-xul-references-suite will need qrefeshed again when the queue is updated.

for an alignment difference it seems

i have this suspicion that once thunderbird goes git it will be comm as a subdir in a single mozilla repo a thunderbird branch..

the IRONIC thing is if they had the xpcom binary component loader (for internal) they could have xulrunner'd thunderbird with just having to finally fix MOZ_INCOMPLETE_EXTERNAL_LINKAGE.. but they doing it sillywise

and launched it with Firefox.exe

-app

and do DIST_SUBDIR .. incomplete external linkage not withstanding the rest of the changes would take a person such as my self a few weeks maybe a month of solid work.. not difficult just time consuming and test heavy

if thunderbird was SMERT they would restore the tree as it was intended to be restored by merging comm back into mozilla at topsrcdir not subdir/

would also be git friendly

i actually know how to do it

supposing they do go gitbranch wise off m-c comm as a directory makes even less sense.. which explains why they want to merge everything under MAIL and just have mail as the appdir .. kinda incidious actually

know what we UXP dumbasses SHOULD have been researching is how to wrap a webextension AS a toolkit extension.. with an adapter bootstrap

jetpack had embedded webextesnions but that was just a transitional state when both technologies were present.. basically replace jetpack with a similar abstraction layer that just does what jetpack did.. translate webextesnion shit to mozilla shit.. and there you go.. there shouldn't be any reason MOST of webextensions basic functions can't be redirected to toolkit methods via an adapter framework of some sort.. Not how Mozilla did it.

ugh i wish i knew more javascript

suppose i should stick to attainable things until I know more javascript :P

"moar Javascript solves everything" -- a Googler

yeah well when seamonkey has a WebExtensions.jsm or gets their bindings ported to xul webcomponents then I will know enough javascript

Personally I am ok with comm. When this all goes to git I suspect suite will be left in the dust anyway. Web extensions work in our tree for a Firefox build and only missing some pieces. Could be added to SeaMonkey but not really into it any time soon.

they can TRY and forget and block me reminding them.. but anything Mozilla does while in the trenches can be dealt with.. it's the gap that's the big bitch with central that and the calls from components.. FIX ME FIX ME YOU KNOW YOU WANNA.. have to keep it in check..

need a hammer, quick!

don't have a hammer will this rock do?

accidentally hit the "offline mode" button :P

airplane mode

for web clients

offline mode is handy on occasion

what would be nice is an extension that allows you to display cached versions directly somehow

frg_Away: before you go and pass out for the night, is hg copy or hg rename compatible with mq?

or do i have to do it then import it

yes I usually do it viaTortoise hg because I usually not remember the syntax.

feels like I been fighting with the build system for a decade.. and i have :P

ian wanted me to use hg copy to source thunderbird files over to suite directly and then lightly modify em on the devtools cc bug

easiets if more than a few files is just do a skeletop patch with on pop it and edit it directly. I made a habit of doing this in 2 patches. First the copy. second the changes. IF anything changes to the source it is really hard to fix rejects with a qrefresh if only one patch.

^skeleton

See the xul xhtml stuff in the queue

I think I know what you are talking about but will look again

Bug 1611647. There it is a move

BASH!

i need to sit down and learn how to use sed

Bill did it

i like his script better than mozilla's though they both could use comments and taking a few arguments would be nice like.. specifing repo source cause localclone would be faster, temp clone checkout location, and patch location so it could be directed to the repo.