first time I notice it in discourse, but it does use revert for overflow-y.

so maybe that's Atwood's idea of "1999-era layout", let's use something no IE version supports?

njsg: wanna help me strip down an ancient mozilla codebase to create a library that basically provides xpcom, rdf, and xpinstall as a generic lib?

unable right now, sorry, not saying it won't be possible at some other point, but sadly can't now

well of course not tonight or even this year lol

besides to do it with a minimum of pain i'd basically need fedora 8 or an eq era system to strip it down enough with period tools before making it work with something other than gcc 4.1 at the latest

I mean Fedora 8 came with SeaMonkey 1.1 so 1.8.1 will build on it i already explored that last year and it was gcc 4.1 and i have likewise built it and yes building 1.8.x is NOT at all like building 1.9+

its so painfully primitive

also the tarballs of that era were partly pre-configured and selective to that application.

I see that Atwood didn't respond to the criticism of his usage of "1999-era", but rather under the post wondering if it's revert. I'd say that might have been him focusing on the topic, except his last response is also in the "exaggerating things in years" ballpark... And he also didn't comment on "revert".

frg_Away: you needed vs2022 for something and i was busy at the time sorry

nsITobin If you check the log I wonder if you could put the snipplet in Pale Moon( I assuem you build it?) and try it out.

I don't build anything uxp anymore but LUCKILY i still can.. Snipplet huh let me checks that log

It probbly needs soem surrounding code and not sure how eas to transplant. VS2019 chokes on the void in combination with the ::fp

frg_Away: what am I testing tho VMFunctions between UXP and SM looks completely refactored.. just add the preprocessor define and see if it bitches?

uxp and sm vs 68

yes this is 100% different. Add the define and code needed for it ans see if it compiles I am not sureif it is an easy task. If too time consuming just forget it.

frg_Away: no-go bugzilla.mozilla.org/1530937

There is no way I can do that to UXP

it hasn't followed Mozilla commits since 2018

oki. When I ma home need to set up a vs2022 build vm and see if I cn get the ipc stuff in first so that it builds.

what I can do is attempt the long promised build of sm with vs2022

already rebooted into winders

17 part mid-60s refactor yeah it would have to be adapted heavily and likely is missing other earlier deps that make this garbage possible. This was the constant issue with Moonchild igoring what we could get for free until the pressure kicked in with Pale Moon being basically unable to browse most sites.

nsITobin needs at lleat ipc backports if I am not mistaken.

well like all good mozilla bugs it fails to list its dependancies

oh.. right enhanced bugzilla

enhanced vital bug info into a collapsed div or whatever

1530937 blocks bugzilla.mozilla.org/1506763 which blocks the meta bug bugzilla.mozilla.org/1436250

nsITobin if you have enough contributors you get away with it. If not you reinvent the whel a little and/or do it differently and then it stops because you need to do the next stuff from scratch. One of the reasons the current patch queue exists nd we use rust.

nsITobin it needs probably a 100 others.

indeed.. UXP's solution if they bother or can accomplish it would be unique .. which would also be fine if UXP was THE standard.. but it isn't.

and of course this is all blocking the Fission Performance Tracker

which blocks fission

which is just what they are calling e10s now

frg_Away: same old shit eh?

google funding, webidl, ipc, drm, and fuckin e10s are what killed Mozilla as we knew it.

I think you need 20 contributors minimum to pull it off. And not hobby ones with one commit per month.

fission is a bit different. Wonder why this block it.

because performance

because content and memory size

because the bugs you want to do

;)

and because multiprocess browsers are a terrible wasteful and failed concept

single process has less memory use

I would go for 1 chrome 1 content and one gpu if it was me

frg_Away: so how do you use windows again LOL

I figured it out

nsITobin usre Windws as a shell for VMs mostly :) Seerver 2019 so no lets AI and clopilot the world :)

LTSC 2019

so you have SLIGHTLY more efficient codepaths than me

so what

Taskbar and Startmenu

Open shell meu of course

Yeah I have openshell as well

menue

but a taskbar and startmenu and tray seem babymode

i think its better to work without that jazz

I need get back to building mozillabuild my self so I can produce a package capable of building a number of things

frg_Away: how do i get the thing to see my clang that is installed

0:07.62 checking for the target C compiler... not found

0:07.62 DEBUG: _cc: Trying clang

0:07.62 ERROR: Cannot find the target C compiler

0:07.67 *** Fix above errors and then restart with\

bootstrap is broken

ImportError: cannot import name 'WasiSysrootInstall' from 'mozboot.linux_common' (d:\binoc\workstation\projects\mozilla-

253\python/mozboot\mozboot\linux_common.py)

why its selecting linux i dunno

I did a mach boostart with mozilla.central long ago

yeah well its broken now

using MY start-vs2022.bat i get vs reconized.. but fails tro find CBINDGEN

which seems to be rust libs

I can't get every rust lib manually

WindowsTobin cbindgen goes into c:\Users\NO1\.mozbuild\cbindgen\

nut used currently bit will change.

well i can't build seamonkey on windows

because the infrastructure as a service on the fly install is busted

WindowsTobin grab mozilla-esr115 and do mach bootstrap

that won't help.. each tree gets a different .mozbuild subdir

its unique for each tree

unless .. i'll attempt it.

bbl

yeah it didn't work

anyone else have any suggestions

aside from doing this manually with zero guide

mach bootstrap thinks it is running on linux

and without mach bootstrap i have no way of getting this code to build.. in addition I was correct that mach bootstrap is tree specific.

yeah no this is all screwed up

so mach bootstrap is horribly busted and I don't think there is any fixing it without a deep dive into it

so that means frg.. and everyone.. Windows building is impossible from scratch

without an already working system setup for it

oh hold on..

well this may explain it.. esr115's bootstrap quit early and didn't actually complete its task.. now it is.. hopefully it will be able to pick up the bits.. then i will figure out how to override this

Personally I think this msvc adhoc thing is illegal because I didn't explicitly agree to the EULA for Visual Studio

there configure is now satsified i hope

ok so part of the bootstrap downloads tools that should be in mozillabuild.. we can eliminate those totally when I get mozillabuild production going for SeaMonkey.. visual studio cna be addressed by start-shell again i already have that.. and cargo bs will need another script .. bypassing this mess.. cause fixing it would get in the way of the queue

frg_Away: it's building now

and it errored out

WindowsTobin I have a guide but it is outdated. Can send it to you.

Are you using mozbuild 3.4?

yeah

stock

not mine

i got the thing bootstrapped with esr115 now .. i have a compile error lol

I replaced the nsis inside it with 3.08 but otherwise should work.

well yeah if i was using vs2019 lol 2022 errored out... but so many warnings and no color have to restart the build and supress all warnings

no need for a VS2022 start bat.

frg_Away: there is if you want to use the system installed version but i am not using that right now

unless seamonkey isn't 100% isolated like mozilla is now

I honestly can't make heads or tails of these issues except we have a mismatch of code with partal patches something you warned me about some months ago

but no matter

no it isn't stilla bastard between 78 and 91 bbuild system wise

Are you building the current 2.53 patch queue? Then use export MACH_USE_SYSTEM_PYTHON=1 in your shell script.

release

first

i can't actually do the patch queue on windows.. its too slow

hg qpush --all takes a bit yes :)

well its cloning repos that is the issue for me

i cannot clone mozilla using hg on windows anymore

sm is just takes forever

ok warning supressed clobber build kicked off see what it is unhappy with

recent hg not ancient 4.xxx?

which I am surprised about since UXP went from 2015 to 2022 with barely any changes

frg_Away: whatever mozillabuild provides

WindowsTobin 2022 choked on ipc code which was added after 52.

We discussid it once and I eported the patch which will fix it but failed to document it. The fix as usual needed prerequisites unless you want to mess with ipc.

frg_Away: dpaste.org/713L4

i dunno what to do with THAT

also.. i am very non-plussed at that condition existing

Did the file end with crlf instead of lf by accident ?

rust packages are checksummed

windows line endings

bad

LICENSE-APACHE

looks like it was all commited with windows line endings

frg_Away: and because they are hashed dos2unix won't just solve it

WindowsTobin Are you suing a tarball or gitlab?

no wait

gitlab.. but my git should be configured to leave lineendings alone

Given that I picked this for the builder and IanN_Away for th Linux build it should be ok.

let me look what is in my config

you should add a gitattributes file to prevent this

I do it for all my repos

* -text

.gitattributes

frg_Away: I am surprised it didn't come up earlier

doesn't client.mk explicitly have a check for this

we didn't add anything here

I have

[core]

SO.. PROCEEDURE: Make sure git is set not to change line endings.. clone esr115 and run mach bootstrap option 2 .. clone seamonkey sources .. do a mozconfig .. do mach build and hope it works.

repositoryformatversion = 0

filemode = false

bare = false

logallrefupdates = true

symlinks = false

ignorecase = true

in my locl copy

basically. have set up some more things. Long time since I set it up fresh. Should I sent you my last pdfs?

basically expect me to rewrite this page soonish lol seamonkey-project.org/dev/code-development

WindowsTobin be my guest. Dragging my feet for 2 years now. Always find something else more urgent to do. Given that I get maybe one inquiery in a year I masked it task 999991 :) But should be done

Also, frg_Away if esr115 provides the correct bootstrap bits.. I could strip down esr115 to just its build system and use it as a standalone mach bootstrap as an easy shortcut

e need to provide our own solution down the lne. esr128 is already in the works and mozilla removes packages from its servers ocassionally. not even sur bootstrappin 102 still works.

can't agree more

and yeah 128 will be where I make Mark III for real. Still need that PWARunner

but just a second.. sandwich pepperoni needs eaten

anyway

yeah this should now work until it errors out on an ACTUAL error right frg_Away

ok its into rust

If it goes over mach configure it should build

oh

4:14.21 Some errors have detailed explanations: E0044, E0557, E0635, E0703.

4:14.21 For more information about an error, try `rustc --explain E0044`.

4:14.24 error: could not compile `packed_simd` (lib) due to 45 previous errors

4:14.24 warning: build failed, waiting for other jobs to finish...

WindowsTobin what is your rust version?

$ rustc --version

rustc 1.79.0 (129f3b996 2024-06-10)

error[E0044]: foreign items may not have type parameters

over and over again

rustup default 1.73.0-x86_64-pc-windows-msvc

rustup target add i686-pc-windows-msvc

or apply Bug 1896958

oh

config.guess assumes win32

The i686 target is only needed if you build x86. I usually don't.

well i don't feel like lookinh up the target and host mozconfigure vars to make it 64bit unless it fails .. config.guess needs patched to know it is on 64bit windows and use target for 32bit least imo

The error is because of rust 1.79

but i think that can't be done without an explicit choice from start-shell

yeah but I assumed i was building 64 because I long patched that lol

do i need a clobber for this?

apperently not?

no

good to know will make a nice refreshed build instructions

aaaand errored on IPC

I use

ac_add_options --target=x86_64-pc-mingw32

ac_add_options --host=x86_64-pc-mingw32

Not sure if hist is still needed

yes because without choosing a architectured start-shell config.guess will evaluate against the bitness of the msys env which is 32bit.. Mozilla didn't fix this i believe because in the end they use a bunch of pre-written mozconfig and msys2 is win64 so config.guess should report correctly and win32 is fast irrelevant cause no plugins to care about

and mach bootstrap writes the mozconfig anyway and its firefox by default failing that which has pre-configured mozconfigs

result?

$ build/autoconf/config.guess

i686-pc-mingw32

WindowsTobin did msys2 patches against my wip branch but ended in python hell with missing preliminary patches. msys2 worked but the build didin't find some include. Myckel is looking into it when he finds some time.

frg_Away: this is erroring out in hash_tables

no template named hash_compare did I mean std:_Uhash_compare

yupp rings a bell.

this is coming off hash_map in the ask

i think I fixed it frg_Away

no

nevermind

ugh

My fix would be bug 1641090 but needs prerequisites

what did you change in ipc that caused this

I nothing. Came with 56

right you said a change between 52 and 56

wonder what it is

I see its older code so uxp might have fixed it

checking

well

shit

frg_Away:

LOL

hey _nuke_ care to offer any insight?

frg_Away: want me to try and port the UXP solution?

since I am already .. in here

i assumed this was strictly an msvc issue but apperently not which is why I wasn't focused on it cause athenian200 was doing the vsuplift

yes will do a top patch then and credit brian. When we com to the real deal I can remove it

frg_Away: dpaste.org/htR0i

now this lol

will tak a look tomorrow. Early sleep

looks like bugzilla.mozilla.org/1441651

would fix it

sup

yeah done banging my had against stuff

for the day

hi IrisZzz

hi