15:34:52 <nsITobin> frg_Away: https://i.ibb.co/NFmBLmt/image.png python 3.9 from mb40
15:34:54 <nsITobin> same error
15:34:57 <nsITobin> ultimently
15:35:59 <nsITobin> doesn't matter if export system python is there or not
15:36:17 <nsITobin> i don't think seamonkey's build system can even pick up artifact python even if it wanted to
15:39:17 <nsITobin> idgi this vm previously built seamonkey with this give or take an option same mozconfig
15:39:51 <nsITobin> and I am constantly having this problem
20:32:34 <frg> nsITobin does not find rust. Does rustup default 1.73.0-x86_64-pc-windows-msvc work in the 3.4 build shell?
20:33:20 <frg> If not you need to add .cargo/bin from the directory where it is installed to the path.
20:33:24 <nsITobin> just a sec.. assigning more ram to my windows 10 sm build vm
20:33:51 <nsITobin> that.. should already be dealt with cause I previously built seamonkey few months back on windows on this vm
20:33:56 <nsITobin> but i will check again
20:34:40 <frg> cargo is usually in $WIN_HOME/.cargo/bin
20:35:20 <frg> I added a mozillaa-build\msys\etc\profile.d\profile-rustup.sh:
20:35:21 <frg> #!/bash/sh
20:35:23 <frg> if test -n "$MOZILLABUILD"; then
20:35:24 <frg>     WIN_HOME=$(cd "$HOME" && pwd)
20:35:26 <frg>     PATH="$WIN_HOME/.cargo/bin:$PATH"
20:35:27 <frg>     export PATH
20:35:29 <frg> fi
20:35:30 <nsITobin> hold on
20:35:40 <nsITobin> ok why is rust required?
20:39:56 <nsITobin> maybe i am misremembering
20:41:20 <nsITobin> more pressing is why I can't seem to parse this output for the key error you seem to be able to spot
20:42:12 <nsITobin> i suppose it is entirely possible I nuked rust and cargo when I cleaned up after 115 prep..
20:42:12 <frg_Away> says checkinf for rustc ... not found and then it goes downhill
20:42:39 <nsITobin> yeah why doesn't it stop there as fatal then? I think it used to?
20:43:06 <nsITobin> anyway kicked off FINALLY
20:44:26 <nsITobin> I am gonna test adding VMWare to the accel whitelist if everything cursory works because unlike Mozilla you aren't storing telemetry reports about gfx failures in VMs cause of some edge case test
20:46:06 <nsITobin> if hwaccel works in VM ware I can actually test and improve SeaMonkey for Windows 11 users without having to resort to hopes and guesses or risking the integrety of my data.
20:46:58 <nsITobin> last copy of windows 11 i ran identified my php and bash scripts as potentally unwanted files over the network and killed em.
20:52:06 <nsITobin> frg_Away: rust code errored out.. i set it to 1.73
20:52:20 <nsITobin> wait
20:52:48 <nsITobin> right on windows it matters which target
20:53:31 <nsITobin> I hate Mozilla for this.
20:53:37 <nsITobin> Just sayin'
20:58:16 <nsITobin> to PROPERLY answer your question.. if you go get rustup-init.exe and do it then rustup is avilable from the msys1 shell
20:58:24 <nsITobin> frg_Away
21:06:45 <nsITobin> https://dpaste.org/5drrt/raw
21:59:41 <Harzilein> funny you mention msys1 specifically
22:08:52 <nsITobin> why Harzilein
22:26:48 <Harzilein> it's slightly off-topic, but msys2 nuking (not archiving) its 32 bit world ensuring it can never be reproduced again was when i decided that floss developers on windows are too pragmatic for their own good :D
22:35:21 <tomman> "point at the drawing where Mr. Pentium Pro touched you"
22:35:40 <tomman> yeah, that's a massive dick move
22:36:10 <tomman> one thing is deprecating unmaintained targets, but another one is completely erasing history
22:41:27 <frg> nsITobin you need rust 1.73.0 or apply patch from bug 1896958. If you do apply the patch the binary will no longer run on Windows 7 and probably 8.1 too thanks to rust removing support for it. Did I mention that rust s*cks?
22:41:52 <tomman> what your rust needs is some thick oil :D
22:43:42 <frg_Away> a thermal lance would also work...
22:59:06 <nsITobin> i have rust 1.73 the exact target you specified and its a windows 10 LTSC 2019 build vm
23:00:00 <nsITobin> i was making chicken soft tacos
23:00:02 <nsITobin> for dinner
23:00:08 <nsITobin> and now having my three milk cake
23:00:11 <nsITobin> becuase I made one
23:01:01 <nsITobin> mix three types of milk... bake a cake poke the cake pour the milks on top put whipcream on top of that after a few hours plus some berries there you go 3 milk cake they charged 40 dollars for at the grocery store
23:01:05 <nsITobin> i made it for 12
23:02:25 <frg_Away> nsITobin then it should work.
23:04:13 <frg_Away> and happy munching
23:06:53 <nsITobin> maybe it wants cake
23:07:36 <nsITobin> ripped it all out and trying once more
23:07:45 <nsITobin> and I'll add cake
23:07:48 <nsITobin> see if it builds
23:07:54 <frg_Away> nsITobin the rust version with the error is not 1.73
23:08:03 <frg_Away> higher for sure
23:08:32 <nsITobin> yeah rustup was resisting.. its working now i deleted it and told it to get that exact version FIRST off
23:09:23 <nsITobin>  0:04.94 checking rustc version... 1.73.0
23:09:23 <nsITobin>  0:04.99 checking cargo version... 1.73.0
23:09:32 <nsITobin> msvc version
23:09:54 <nsITobin> ./mach build
23:09:56 <nsITobin> er
23:10:22 <frg_Away> make sure you nuke the object dir.
23:15:09 <nsITobin> well it seems Windows 7 has re-entered BinOC Extended Support
23:15:11 <nsITobin> lol
23:19:40 <nsITobin> to refresh i want to add https://bugzilla.mozilla.org/show_bug.cgi?id=1429587 to seamonkey .. if it seems to work. The bug just.. deadended after being r+ because of a chromium issue and nothing since then really..
23:19:42 <nsITobin> frg_Away:
23:20:03 <nsITobin> and firefox getting a software renderer
23:25:39 <frg_Away> vbos uses vmsvga under Linux. If it does not break tat we can try. I have nothing but trouble with older gfx drivers in vbox and even outside a vmSeaMonky will choke on most pre 2020 something drivers
23:27:06 <nsITobin> well its not actually a functional change all the patch really does is make VMWare's video driver known to its self and thus allows it to have acceleration .. its why I can't figure why this didn't get merged in even if it isn't perfect
23:28:01 <nsITobin> or why when it works perfectly on UXP Moonchild, who uses VMWare as well, has never applied it.
23:31:14 <frg_Away> that is what I mean. If it allow hw accelaration using vmware with old gfx drivers it might go south pretty fast and no way to detect. Can check with older Thinkpasd and linux vbox vm.
23:33:07 <nsITobin> which drivers does vbox use?
23:34:51 <frg_Away> under linux vmsvga which seems to be vmware based. -Otherwise own driver which is blacklisted.
23:35:22 <nsITobin> well if it uses vmware's svga driver under the linux it MIGHT just work
23:35:52 <nsITobin> but windows guests on virtualbox would be unaffected
23:36:20 <nsITobin> as that uses whatever their windows driver is which won't have VMWare's id
23:37:07 <nsITobin> I dunno if I have EVER gotten hardware acceleration on windows under virtualbox to work
23:37:22 <nsITobin> i always had terrible sound clipping when playing music tho
23:41:13 <frg_Away> I just don't want to make it worse with older drivers
23:44:53 <nsITobin> good i got a build.. now to manually apply the patch
23:56:10 <nsITobin> hey you already have VendorParallels
23:56:32 <nsITobin> i'll still do it manually but I bet this patch may str8 up apply
23:58:19 <nsITobin> vendorqualcomm?