10:37:00 nsITobin don't think so. Tools should have the same layout. Just a different base. 12:48:56 it chilly this morning 12:49:09 Good morning #SeaMonkey 12:51:45 nsITobin greetings 12:53:11 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. 12:53:45 Tools seem to have much less bloat indeed. Needed only to remove vctip.exe 12:55:28 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 12:55:37 tossing a coin if I should fix 2.49 for the 141 toolset 12:56:03 VS2017 can no longer compile 2.53 so removed from it. 12:57:11 what would 2.49 offer that seamonkey on uxp wouldn' 12:57:28 aside from XP compat 12:58:06 frg: are you still releasing updates for 2.49? 12:58:08 security ones 12:58:38 nope. Would just be for the xp fans to self compile. 13:01:49 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 13:04:03 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. 13:04:57 yeah pain alreayd trying to balance these envs and keep them clean and free of mangling 13:06:43 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 13:07:07 but i get efficiency 13:07:48 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 13:07:50 Works for 3.2 too so they can all co exist. 13:08:22 2.49 would be riding mb 2.x right? 13:08:32 Nope 3.2 13:21:18 nsITobin wondered if /build/windows_toolchain.py was used. Now I know. Not :) 13:21:47 so out the door with a bunch of hardcoded msvc references. 13:22:37 doesn't that bust start_shell_vs* files hacked to continue providing the vars to the build system? 13:23:19 19 The ``build/windows_toolchain.py`` script is used to build and manage 13:23:19 20 Windows toolchain archives containing Visual Studio executables, SDKs, 13:23:19 21 etc. 13:23:47 no all in build/moz.configure/toolchain.configure and friends. 13:23:59 See Bug 1289641 13:24:03 OH that's part of bootstrap 13:24:15 or .. was 13:24:16 lol 13:24:30 or would have been 13:24:35 depends on your perspective 13:25:18 either way automated mozinfra 13:25:41 gitlab 2.53 updated for it 14:04:26 nsITobin rust compiles in central are still great.... https://ibb.co/fVZb0xp9 14:04:35 10 forking GB 14:04:43 version? 14:04:52 cause 1.82 is behaving memory wise 14:04:56 for j6 14:05:38 but then again linking libxul has taken that much ram before on windows 14:07:03 -j8 with latest 1.85 14:07:12 libxul could have linked in shared xpcom dlls instead of rolled in and NONE of this would have ever been a damned issue 14:07:25 for fifteen bloody years now 14:08:18 It is no longer 2010 so I can live with 8 GB for all but not 10GB plus compiles plus something 14:09:26 fits into a 16gb windows vm i am fine.. beyond that i am screwed 14:10:54 Hey now its 18GB for rust. Have assigned 24GB to the vm. 14:11:28 19 and 98% mem usage 14:16:14 nsITobin STATUS_STACK_BUFFER_OVERRUN and needs more ram. 14:16:34 Totally whacko 14:17:45 yep 14:17:53 I need to look into rust, because now I'm wondering how come it can get so high memory consumption 14:18:04 is it doing links in parallel or something? 14:18:12 njsg: they fucked it up cause 1.82 works fine 14:18:59 its always gonna be high memory consumption but this is ridiculous 14:19:03 I can go back to 1.82 but not sure it would help. j8 and normal optimize might be it. 14:19:44 Needs more electrolytes! 14:23:50 1.83 MAY be fine too but 4+ seems to have an "issue" 14:24:05 gonna try .. know in 70 minutes 14:26:07 I think everyone should take advantage of these cpp apps going rust to learn rust so it can be translated back to plain C 14:26:19 and of course the web gonna be the web and there's people saying this is okay because unused ram is wasted 14:26:25 solve two issues at the same time 14:26:26 lol 14:26:35 look, there are good ways to use RAM, this almost surely isn't one of them :-P 14:26:47 njsg: the world wide web or the walled garden corperate mandated open web 14:26:57 cause there is a difference in my book 14:27:44 living standards are not formal standards they are endrun mandates by socially and economically more powerful groups 14:29:18 unused ram is wasted? 14:30:45 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 14:31:13 apparently the only place where the usage of ram isn't advocated in this way is several Microsoft operating systems 14:31:18 that is kinda tough when all my ram is being used for one series of operations 14:31:43 having such behaviour in applications and utilities seems to go counter the idea of a system where, yes, you do other stuff 14:32:31 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 14:32:55 now its just.. wasted cpu time and electricity 14:33:03 cause efficiency doesn't matter 14:33:03 I miss the "you own the world" memory model of Windows 9x :D 14:33:21 now you can't even really own your own files on a cellphone 14:35:36 does destiny.manifest ring any bells? 14:35:47 Meeting time in 27 minutes - https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09 14:35:57 today? 14:36:03 k 14:44:49 nsITobin yes as in 18 minutes 14:48:42 IanN_Away: sent you CCI details :) 15:03:20 Meeting time - https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09 15:04:35 hi .* 15:04:48 hi njsg 15:04:49 greetings 15:05:03 are we expecting rsx11m? 15:05:45 or has rsx11m succumed to DST? 15:05:54 either way... 15:05:56 Who's taking minutes? 15:06:03 I think he wanted to attend 15:06:07 me 15:06:14 thanks 15:06:22 summer time might have derailed him :) 15:06:33 Nominees for Friends of the Fish Tank? 15:06:53 welcome rsx11m 15:06:57 IanN for still trying to make cZ a better place. 15:07:03 Hi rsx11m 15:07:08 Sorry, a bit late today... 15:07:11 rsx11m: hi 15:07:14 Hi * 15:07:15 seconded 15:07:30 rsx11m: blame DST 15:07:36 always ;-) 15:07:52 failing that POTUS 15:08:13 Action Items 15:08:25 bau 15:09:40 Status of the SeaMonkey Infrastructure 15:11:18 ewong is still on the configs and has set up some tasks on the Windows builder. 15:11:43 Old Linux and Windows builder are gone. 15:12:08 or should be very very soon 15:12:41 yeah. ewong is also looking at signing 15:14:11 Status of the SeaMonkey Source Tree 15:15:02 nsITobin and I made central complie again. Mostly him. 15:15:26 ^compile 15:15:43 central patch queue updated for it. 15:16:54 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. 15:17:18 SO VS2019 and Vs2022 can be used also the build tools. 15:18:26 rust 1.83 for central seems largely ram behaved as well 15:18:45 1.84/85 seem to have memory leak issues 15:19:08 (is it memory leak or just increased usage? any visible difference in compile times or CPU usage?) 15:19:37 something to research njsg 15:20:06 where are we on rust for 253? cause I still been using 1.73 15:20:22 1.73 forever for now 15:20:23 wasn't there an upper limit to allow NT 6.1? 15:20:34 yes and macOS 10.11 15:20:52 so this ram thing may not go away 15:21:03 If we set macOS 10.12 as minimum I need to check but it is either 1.75 or 1.76 then. 15:22:14 1.73 seems stable for now. 15:24:03 Release Train 15:24:37 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. 15:25:44 Release Train 15:26:05 already there :) 15:26:33 Skip Betas yet? 15:26:36 Extensions Tracking 15:26:40 * njsg goes check the signals and switches to receive the trains properly 15:26:49 nsITobin not planned 15:27:13 bau. I still need to look into the add-on sdk but no time. 15:27:14 is the add-ons sdk worth keeping? 15:28:06 beyond devtools? 15:28:20 There was one add-on which was still being updated but we broke it. 15:28:50 "Drak Backgorund and Light text" 15:28:56 ^Dark 15:29:23 Not happy about it but complaints are few. 15:29:30 https://addons.thunderbird.net/en-US/seamonkey/addon/dark-bg-light-text-seamonkey/ 15:29:37 Still would like to fix it. 15:29:44 is that the one? 15:29:59 yes 15:31:06 jetpack extension 15:31:13 well that answers my question 15:32:25 I presume it is https://github.com/m-khvoinitsky/dark-background-light-text-extension/tree/jetpack 15:32:57 that matches xpi contents 15:32:59 IanN: 15:33:17 yes but the webext version in master 15:34:06 so fix jetpack version or work out what's needed to get webext version working 15:34:11 did it ever have a normal extension form? 15:35:32 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 15:36:15 webext is crap and needs soo much work. And with manifest v3 it gets crappier. 15:36:56 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 15:37:24 but you'll be able to do nothing, across "all" browsers! 15:37:24 but this is an agrument that can go on for years.. and has.. soo enough out of me on it for now ;) 15:38:06 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 :) 15:38:39 duplos maybe 15:39:32 2.Next, Feature List, Planning and Roundtable 15:40:00 yeah with v3 it is Duplo. With v4 it will probabably be prefabricated :) 15:40:54 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. 15:42:04 would a site to report broken sites be useful to us with some annotations? 15:42:26 have checkboxes users can check for which clients they tried 15:42:27 etc 15:43:59 depends if it will capture new, useful information 15:44:24 and of the SNR 15:44:45 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 15:44:47 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 15:46:38 I'll let it simmer in mah brain for a while 15:47:04 thanks 15:48:06 AOB 15:48:24 not from me, bau :-( 15:48:57 just DST again 15:49:03 bau 15:49:09 yepp, 14:00 UTC next time 15:49:16 ah yes 15:49:25 next meeting is on the EU DST day 15:49:27 set your alarm clocks! 8-) 15:49:48 Everyone who wants/needs CCI FTP access get at me for initial creds 15:51:55 thanks 15:52:14 If someone wants a new Windows prerelease build let me know. 15:52:35 linux and mac are handled for 253 right? 15:52:38 i'll call it a meeting, thanks for your time today, next meeting in 3 weeks, same bat channel, same DST adjusted bat time 15:52:53 :) 15:53:02 nsITobin yes 15:53:09 nsITobin: yes, should be being built automagically 15:53:10 bye then! 15:53:12 ewong is on Windows 15:53:15 c u rsx11m 15:53:29 rsx11m: cya 15:53:58 good thing is the cci ftp will still be useful for adhoc build trading or indvidiual test builds 15:54:05 happy day and cu here as away 15:54:11 once windows builds are automagical again 15:54:33 nsITobin yes still good for adhoc stuff as now. 15:55:09 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.. 15:56:11 still useful for excersizing the codebase and getting reletive speed comparisons on operations that aren't as useless as today's benchmarks.. 15:56:23 i have found crashes that way 16:24:57 missed the meeting due to some CRT tinkering 16:25:07 does anyone want some 25 year old Compaq display full of curves? :D 16:38:32 you gonna drop it off? 16:38:37 cause if so I'll take it 16:38:50 https://imgur.com/a/Bb2xLGN you just have to pay shipping from Venezuela :P 16:39:39 speakers still work? 16:39:47 cause I recall em not being TOO terrible 16:40:05 but that might have eben a different model 16:40:20 they STILL work 16:40:32 and they sound awful if you pump too much volume into them 16:40:47 set them to moderate volume and they will sound... more or less OKaysh 17:09:41 frg_Away: well.. there is always this https://addons.palemoon.org/addon/swarth/ 17:10:17 could be reexpanded to include more content types and re-adapted for seamonkey possibily 17:12:05 IF I find some time I will try to fix the breakage. If not possible might be time to nuke jetpack. 17:13:14 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. 17:13:33 jetpack for devtools-only* 17:15:09 but an advantage is 253 is close to that so mozprogression is likely prefered rather than me hacking around it. 17:19:25 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.. 17:20:09 what change busted jetpack? 17:22:42 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. 17:23:55 is seamonkey fully on dom promises now? 17:24:10 or was it js engine promises 17:24:21 one was transitioned to from the other 17:24:59 anythoing up to 60 should be more or less in plus later fixes 17:25:18 https://repo.palemoon.org/MoonchildProductions/UXP/issues/521 17:26:03 Beyond the jetpack remoavl point for sure. Only did it partially 17:26:54 well 7 years ago i guess we deemed jetpack promises as a reason to almost eradicate jetpack 17:28:46 doesn't mean jack tho 17:30:21 confirmed, 253 has everything mozilla did to sdk promise.js 17:33:26 nothing has been changed for jetpack in UXP for 7 years save some revovals from elsewhere 17:33:42 ... yeah this is gonna be a joy to try and fix 17:34:22 and stuff that makes it more .. not australis friendly 17:40:17 Might be contentaccessible missing somewhere but just a hunch 17:44:17 hmm possible 17:52:21 Most stupid task of the day done: https://ibb.co/wFF2jpk4 17:52:57 when did you add that damned tab line to .49 lol 17:53:37 long ago and I like it :) 17:54:37 you also like not having xpfe style grippies.. even I got over them finally.. more trouble than they were worth 17:55:04 FranklinDM turned it into an extension for Pale Moon 17:55:33 there are like half a dozen extensions for Pale Moon with SeaMonkey/Borealis functionality it's kinda ridiculous.. 17:55:51 Well they are still there and can be enabled in prefs. I also like choice. 17:57:28 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 17:59:03 is the infobars-only pref still in 253 cause I like infobars vs doorhanger popups 18:03:37 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. 18:15:07 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 18:16:23 https://gitlab.com/frg/seamonkey-249-patches/-/commit/4bbce995ec134606d6b8b6d0f2c769711cff9996 18:16:25 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. 18:16:26 https://ibb.co/Z1GcZPGH 18:16:27 https://ibb.co/PskJFLSF 18:18:00 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 18:18:55 since you are indicating further backports will be leaving 2019 compat anyway windows 7 for building isn't sustainable 18:19:15 even for test builds which is fine 18:20:44 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. 19:09:47 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 19:11:11 almost sounds like I know what I'm doing .. that's conserning.. FOR SOME :P 20:19:46 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. 20:20:24 for an alignment difference it seems 20:37:23 i have this suspicion that once thunderbird goes git it will be comm as a subdir in a single mozilla repo a thunderbird branch.. 20:39:09 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 20:39:23 and launched it with Firefox.exe 20:39:28 -app 20:40:35 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 20:41:47 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/ 20:42:00 would also be git friendly 20:42:05 i actually know how to do it 20:44:30 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 20:46:21 know what we UXP dumbasses SHOULD have been researching is how to wrap a webextension AS a toolkit extension.. with an adapter bootstrap 20:48:50 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. 20:50:16 ugh i wish i knew more javascript 20:58:11 suppose i should stick to attainable things until I know more javascript :P 21:09:19 "moar Javascript solves everything" -- a Googler 21:14:25 yeah well when seamonkey has a WebExtensions.jsm or gets their bindings ported to xul webcomponents then I will know enough javascript 21:38:39 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. 21:40:37 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.. 21:43:21 need a hammer, quick! 21:43:30 don't have a hammer will this rock do? 21:43:51 accidentally hit the "offline mode" button :P 21:44:03 airplane mode 21:44:13 for web clients 21:44:25 offline mode is handy on occasion 21:44:43 what would be nice is an extension that allows you to display cached versions directly somehow 21:48:47 frg_Away: before you go and pass out for the night, is hg copy or hg rename compatible with mq? 21:49:16 or do i have to do it then import it 21:50:22 yes I usually do it viaTortoise hg because I usually not remember the syntax. 21:51:35 feels like I been fighting with the build system for a decade.. and i have :P 21:53:27 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 21:57:01 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. 21:57:11 ^skeleton 21:58:00 See the xul xhtml stuff in the queue 21:58:56 I think I know what you are talking about but will look again 21:59:47 Bug 1611647. There it is a move 22:01:13 BASH! 22:01:26 i need to sit down and learn how to use sed 22:03:37 Bill did it 22:08:58 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. 22:12:07 yeah Bill's version is deff more my style than this readline while loop eval rg thing Mozilla did.. 22:16:52 https://linuxcommandlibrary.com/man/rg 22:17:49 tool made in rust 22:18:27 where as bill's script should work on msys1 2 and linux as long as hg exists