frg_Away: i.ibb.co/NFmBLmt/image.png python 3.9 from mb40

same error

ultimently

doesn't matter if export system python is there or not

i don't think seamonkey's build system can even pick up artifact python even if it wanted to

idgi this vm previously built seamonkey with this give or take an option same mozconfig

and I am constantly having this problem

nsITobin does not find rust. Does rustup default 1.73.0-x86_64-pc-windows-msvc work in the 3.4 build shell?

If not you need to add .cargo/bin from the directory where it is installed to the path.

just a sec.. assigning more ram to my windows 10 sm build vm

that.. should already be dealt with cause I previously built seamonkey few months back on windows on this vm

but i will check again

cargo is usually in $WIN_HOME/.cargo/bin

I added a mozillaa-build\msys\etc\profile.d\profile-rustup.sh:

#!/bash/sh

if test -n "$MOZILLABUILD"; then

WIN_HOME=$(cd "$HOME" && pwd)

PATH="$WIN_HOME/.cargo/bin:$PATH"

export PATH

fi

hold on

ok why is rust required?

maybe i am misremembering

more pressing is why I can't seem to parse this output for the key error you seem to be able to spot

i suppose it is entirely possible I nuked rust and cargo when I cleaned up after 115 prep..

says checkinf for rustc ... not found and then it goes downhill

yeah why doesn't it stop there as fatal then? I think it used to?

anyway kicked off FINALLY

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

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.

last copy of windows 11 i ran identified my php and bash scripts as potentally unwanted files over the network and killed em.

frg_Away: rust code errored out.. i set it to 1.73

wait

right on windows it matters which target

I hate Mozilla for this.

Just sayin'

to PROPERLY answer your question.. if you go get rustup-init.exe and do it then rustup is avilable from the msys1 shell

frg_Away

funny you mention msys1 specifically

why 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

"point at the drawing where Mr. Pentium Pro touched you"

yeah, that's a massive dick move

one thing is deprecating unmaintained targets, but another one is completely erasing history

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?

what your rust needs is some thick oil :D

a thermal lance would also work...

i have rust 1.73 the exact target you specified and its a windows 10 LTSC 2019 build vm

i was making chicken soft tacos

for dinner

and now having my three milk cake

becuase I made one

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

i made it for 12

nsITobin then it should work.

and happy munching

maybe it wants cake

ripped it all out and trying once more

and I'll add cake

see if it builds

nsITobin the rust version with the error is not 1.73

higher for sure

yeah rustup was resisting.. its working now i deleted it and told it to get that exact version FIRST off

0:04.94 checking rustc version... 1.73.0

0:04.99 checking cargo version... 1.73.0

msvc version

./mach build

er

make sure you nuke the object dir.

well it seems Windows 7 has re-entered BinOC Extended Support

lol

to refresh i want to add bugzilla.mozilla.org/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..

frg_Away:

and firefox getting a software renderer

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

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

or why when it works perfectly on UXP Moonchild, who uses VMWare as well, has never applied it.

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.

which drivers does vbox use?

under linux vmsvga which seems to be vmware based. -Otherwise own driver which is blacklisted.

well if it uses vmware's svga driver under the linux it MIGHT just work

but windows guests on virtualbox would be unaffected

as that uses whatever their windows driver is which won't have VMWare's id

I dunno if I have EVER gotten hardware acceleration on windows under virtualbox to work

i always had terrible sound clipping when playing music tho

I just don't want to make it worse with older drivers

good i got a build.. now to manually apply the patch

hey you already have VendorParallels

i'll still do it manually but I bet this patch may str8 up apply

vendorqualcomm?