10:34:27 <frg_Away> nsITobin don't think so. Tools should have the same layout. Just a different base.
12:46:23 <nsITobin> it chilly this morning
12:46:36 <nsITobin> Good morning #SeaMonkey
12:49:12 <frg> nsITobin greetings
12:50:38 <frg> 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:51:12 <frg> Tools seem to have much less bloat indeed. Needed only to remove vctip.exe
12:52:55 <nsITobin> 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:53:04 <frg> tossing a coin if I should fix 2.49 for the 141 toolset
12:53:30 <frg> VS2017 can no longer compile 2.53 so removed from it.
12:54:37 <nsITobin> what would 2.49 offer that seamonkey on uxp wouldn'
12:54:55 <nsITobin> aside from XP compat
12:55:33 <nsITobin> frg: are you still releasing updates for 2.49?
12:55:35 <nsITobin> security ones
12:56:04 <frg> nope. Would just be for the xp fans to self compile.
12:59:16 <nsITobin> 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:01:30 <frg> 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:02:23 <nsITobin> yeah pain alreayd trying to balance these envs and keep them clean and free of mangling
13:04:10 <nsITobin> 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:04:34 <nsITobin> but i get efficiency
13:05:15 <frg> 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:05:17 <frg> Works for 3.2 too so they can all co exist.
13:05:49 <nsITobin> 2.49 would be riding mb 2.x right?
13:05:59 <frg> Nope 3.2
13:18:45 <frg> nsITobin wondered if /build/windows_toolchain.py was used. Now I know. Not :)
13:19:14 <frg> so out the door with a bunch of hardcoded msvc references.
13:20:04 <nsITobin> doesn't that bust start_shell_vs* files hacked to continue providing the vars to the build system?
13:20:46 <nsITobin> 19 The ``build/windows_toolchain.py`` script is used to build and manage
13:20:46 <nsITobin> 20 Windows toolchain archives containing Visual Studio executables, SDKs,
13:20:46 <nsITobin> 21 etc.
13:21:14 <frg> no all in build/moz.configure/toolchain.configure and friends.
13:21:26 <frg> See Bug 1289641
13:21:30 <nsITobin> OH that's part of bootstrap
13:21:42 <nsITobin> or .. was
13:21:43 <nsITobin> lol
13:21:57 <nsITobin> or would have been
13:22:02 <nsITobin> depends on your perspective
13:22:45 <nsITobin> either way automated mozinfra
13:23:08 <frg> gitlab 2.53 updated for it
14:01:52 <frg> nsITobin rust compiles in central are still great.... https://ibb.co/fVZb0xp9
14:02:02 <frg> 10 forking GB
14:02:10 <nsITobin> version?
14:02:19 <nsITobin> cause 1.82 is behaving memory wise
14:02:23 <nsITobin> for j6
14:03:05 <nsITobin> but then again linking libxul has taken that much ram before on windows
14:04:30 <frg> -j8 with latest 1.85
14:04:39 <nsITobin> libxul could have linked in shared xpcom dlls instead of rolled in and NONE of this would have ever been a damned issue
14:04:52 <nsITobin> for fifteen bloody years now
14:05:45 <frg> It is no longer 2010 so I can live with 8 GB for all but not 10GB plus compiles plus something
14:06:53 <nsITobin> fits into a 16gb windows vm i am fine.. beyond that i am screwed
14:08:21 <frg> Hey now its 18GB for rust. Have assigned 24GB to the vm.
14:08:55 <frg> 19 and 98% mem usage
14:13:41 <frg> nsITobin STATUS_STACK_BUFFER_OVERRUN and needs more ram.
14:14:01 <frg> Totally whacko
14:15:12 <nsITobin> yep
14:15:19 <njsg> I need to look into rust, because now I'm wondering how come it can get so high memory consumption
14:15:31 <njsg> is it doing links in parallel or something?
14:15:39 <nsITobin> njsg: they fucked it up cause 1.82 works fine
14:16:26 <nsITobin> its always gonna be high memory consumption but this is ridiculous
14:16:30 <frg> I can go back to 1.82 but not sure it would help. j8 and normal optimize  might be it.
14:17:11 <frg> Needs more electrolytes!
14:21:17 <nsITobin> 1.83 MAY be fine too but 4+ seems to have an "issue"
14:21:32 <nsITobin> gonna try .. know in 70 minutes
14:23:34 <nsITobin> 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:23:46 <njsg> and of course the web gonna be the web and there's people saying this is okay because unused ram is wasted
14:23:52 <nsITobin> solve two issues at the same time
14:23:53 <nsITobin> lol
14:24:01 <njsg> look, there are good ways to use RAM, this almost surely isn't one of them :-P
14:24:14 <nsITobin> njsg: the world wide web or the walled garden corperate mandated open web
14:24:23 <nsITobin> cause there is a difference in my book
14:25:11 <nsITobin> living standards are not formal standards they are endrun mandates by socially and economically more powerful groups
14:26:45 <nsITobin> unused ram is wasted?
14:28:12 <nsITobin> 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:28:40 <njsg> apparently the only place where the usage of ram isn't advocated in this way is several Microsoft operating systems
14:28:45 <nsITobin> that is kinda tough when all my ram is being used for one series of operations
14:29:10 <njsg> having such behaviour in applications and utilities seems to go counter the idea of a system where, yes, you do other stuff
14:29:58 <nsITobin> 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:30:22 <nsITobin> now its just.. wasted cpu time and electricity
14:30:30 <nsITobin> cause efficiency doesn't matter
14:30:30 <tomman> I miss the "you own the world" memory model of Windows 9x :D
14:30:48 <tomman> now you can't even really own your own files on a cellphone
14:33:03 <nsITobin> does destiny.manifest ring any bells?
14:33:14 <IanN> Meeting time in 27 minutes - https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09
14:33:24 <nsITobin> today?
14:33:30 <nsITobin> k
14:42:16 <frg> nsITobin yes as in 18 minutes
14:46:09 <nsITobin> IanN_Away: sent you CCI details :)
15:00:47 <IanN> Meeting time - https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2025-03-09
15:02:02 <njsg> hi .*
15:02:15 <IanN> hi njsg
15:02:16 <frg> greetings
15:02:30 <IanN> are we expecting rsx11m?
15:03:12 <IanN> or has rsx11m succumed to DST?
15:03:21 <IanN> either way...
15:03:23 <IanN> Who's taking minutes?
15:03:30 <frg> I think he wanted to attend
15:03:33 <frg> me
15:03:41 <IanN> thanks
15:03:49 <frg> summer time might have derailed him :)
15:04:00 <IanN> Nominees for Friends of the Fish Tank?
15:04:20 <IanN> welcome rsx11m
15:04:24 <frg> IanN for still trying to make cZ a better place.
15:04:30 <frg> Hi rsx11m
15:04:35 <rsx11m> Sorry, a bit late today...
15:04:38 <njsg> rsx11m: hi
15:04:41 <rsx11m> Hi *
15:04:42 <njsg> seconded
15:04:56 <IanN> rsx11m: blame DST
15:05:03 <rsx11m> always ;-)
15:05:18 <IanN> failing that POTUS
15:05:40 <IanN> Action Items
15:05:52 <frg> bau
15:07:07 <IanN> Status of the SeaMonkey Infrastructure
15:08:45 <frg> ewong is still on the configs and has set up some tasks on the Windows builder.
15:09:10 <frg> Old Linux and Windows builder are gone.
15:09:35 <frg> or should be very very soon
15:10:08 <IanN> yeah. ewong is also looking at signing
15:11:38 <IanN> Status of the SeaMonkey Source Tree
15:12:29 <frg> nsITobin and I made central complie again. Mostly him.
15:12:53 <frg> ^compile
15:13:09 <frg> central patch queue updated for it.
15:14:21 <frg> 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:14:44 <frg> SO VS2019 and Vs2022 can be used also the build tools.
15:15:53 <nsITobin> rust 1.83 for central seems largely ram behaved as well
15:16:12 <nsITobin> 1.84/85 seem to have memory leak issues
15:16:35 <njsg> (is it memory leak or just increased usage? any visible difference in compile times or CPU usage?)
15:17:04 <nsITobin> something to research njsg
15:17:33 <nsITobin> where are we on rust for 253? cause I still been using 1.73
15:17:49 <frg> 1.73 forever for now
15:17:50 <njsg> wasn't there an upper limit to allow NT 6.1?
15:18:01 <frg> yes and macOS 10.11
15:18:18 <nsITobin> so this ram thing may not go away
15:18:30 <frg> If we set macOS 10.12 as minimum I need to check but it is either 1.75 or 1.76 then.
15:19:41 <frg> 1.73 seems stable for now.
15:21:30 <IanN> Release Train