00:00:14 <njsg> first time I notice it in discourse, but it does use revert for overflow-y.
00:00:39 <njsg> so maybe that's Atwood's idea of "1999-era layout", let's use something no IE version supports?
00:04:20 <nsITobin> 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?
00:05:37 <njsg> unable right now, sorry, not saying it won't be possible at some other point, but sadly can't now
00:06:16 <nsITobin> well of course not tonight or even this year lol
00:07:33 <nsITobin> 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
00:09:03 * njsg is overflown with faint memories of GCC 3.x era and some ABI changes
00:10:43 <nsITobin> 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+
00:11:04 <nsITobin> its so painfully primitive
00:11:31 <nsITobin> also the tarballs of that era were partly pre-configured and selective to that application.
10:01:18 <njsg> 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".
14:21:04 <nsITobin> frg_Away: you needed vs2022 for something and i was busy at the time sorry
14:22:20 <frg_Away> 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.
14:23:12 <nsITobin> I don't build anything uxp anymore but LUCKILY i still can.. Snipplet huh let me checks that log
14:23:21 <frg_Away> It probbly needs soem surrounding code and not sure how eas to transplant.  VS2019 chokes on the void in combination with the ::fp
14:30:38 <nsITobin> 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?
14:30:51 <nsITobin> uxp and sm vs 68
14:32:12 <frg_Away> 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.
14:40:31 <nsITobin> frg_Away: no-go https://bugzilla.mozilla.org/show_bug.cgi?id=1530937
14:40:39 <nsITobin> There is no way I can do that to UXP
14:41:08 <nsITobin> it hasn't followed Mozilla commits since 2018
14:41:51 <frg_Away> 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.
14:42:17 <nsITobin> what I can do is attempt the long promised build of sm with vs2022
14:42:37 <nsITobin> already rebooted into winders
14:44:04 <nsITobin> 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.
14:44:07 <frg_Away> nsITobin needs at lleat ipc backports if I am not mistaken.
14:44:49 <nsITobin> well like all good mozilla bugs it fails to list its dependancies
14:45:54 <nsITobin> oh.. right enhanced bugzilla
14:46:09 <nsITobin> enhanced vital bug info into a collapsed div or whatever
14:46:55 <nsITobin> 1530937 blocks https://bugzilla.mozilla.org/show_bug.cgi?id=1506763 which blocks the meta bug https://bugzilla.mozilla.org/show_bug.cgi?id=1436250
14:47:02 <frg_Away> 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.
14:47:42 <frg_Away> nsITobin it needs probably a 100 others.
14:48:37 <nsITobin> 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.
14:50:02 <nsITobin> and of course this is all blocking the Fission Performance Tracker
14:50:06 <nsITobin> which blocks fission
14:50:27 <nsITobin> which is just what they are calling e10s now
14:50:34 <nsITobin> frg_Away: same old shit eh?
14:51:13 <nsITobin> google funding, webidl, ipc, drm, and fuckin e10s are what killed Mozilla as we knew it.
14:51:16 <frg_Away> I think you need 20 contributors minimum to pull it off. And not hobby ones with one commit per month.
14:51:56 <frg_Away> fission is a bit different. Wonder why this block it.
14:52:06 <nsITobin> because performance
14:52:10 <nsITobin> because content and memory size
14:52:15 <nsITobin> because the bugs you want to do
14:52:17 <nsITobin> ;)
14:53:16 <nsITobin> and because multiprocess browsers are a terrible wasteful and failed concept
14:53:33 <nsITobin> single process has less memory use
14:54:31 <frg_Away> I would go for 1 chrome 1 content and one gpu if it was me
14:56:59 <nsITobin> frg_Away: so how do you use windows again LOL
14:57:29 <MattATobin> I figured it out
15:01:21 <frg_Away> nsITobin usre Windws as a shell for VMs mostly :) Seerver 2019 so no lets AI and clopilot the world :)
15:02:24 <MattATobin> LTSC 2019
15:02:40 <MattATobin> so you have SLIGHTLY more efficient codepaths than me
15:02:41 <MattATobin> so what
15:03:24 <MattATobin> Taskbar and Startmenu
15:03:48 <frg_Away> Open shell meu of course
15:03:55 <MattATobin> Yeah I have openshell as well
15:04:01 <frg_Away> menue
15:04:17 <MattATobin> but a taskbar and startmenu and tray seem babymode
15:04:37 <MattATobin> i think its better to work without that jazz
15:14:04 <WindowsTobin> I need get back to building mozillabuild my self so I can produce a package capable of building a number of things
15:16:38 <WindowsTobin> frg_Away: how do i get the thing to see my clang that is installed
15:17:15 <WindowsTobin>  0:07.62 checking for the target C compiler... not found
15:17:16 <WindowsTobin>  0:07.62 DEBUG: _cc: Trying clang
15:17:16 <WindowsTobin>  0:07.62 ERROR: Cannot find the target C compiler
15:17:16 <WindowsTobin>  0:07.67 *** Fix above errors and then restart with\
15:20:19 <WindowsTobin> bootstrap is broken
15:20:38 <WindowsTobin> ImportError: cannot import name 'WasiSysrootInstall' from 'mozboot.linux_common' (d:\binoc\workstation\projects\mozilla-
15:20:39 <WindowsTobin> 253\python/mozboot\mozboot\linux_common.py)
15:20:46 <WindowsTobin> why its selecting linux i dunno
15:21:13 <frg_Away> I did a mach boostart with mozilla.central long ago
15:21:36 <WindowsTobin> yeah well its broken now
15:22:11 <WindowsTobin> using MY start-vs2022.bat i get vs reconized.. but fails tro find CBINDGEN
15:22:27 <WindowsTobin> which seems to be rust libs
15:22:35 <WindowsTobin> I can't get every rust lib manually
15:23:45 <frg_Away> WindowsTobin cbindgen goes into c:\Users\NO1\.mozbuild\cbindgen\
15:24:06 <frg_Away> nut used currently bit will change.
15:24:24 <WindowsTobin> well i can't build seamonkey on windows
15:24:45 <WindowsTobin> because the infrastructure as a service on the fly install is busted
15:25:01 <frg_Away> WindowsTobin grab mozilla-esr115 and do mach bootstrap
15:25:54 <WindowsTobin> that won't help.. each tree gets a different .mozbuild subdir
15:25:58 <WindowsTobin> its unique for each tree
15:30:14 <nsITobin> unless .. i'll attempt it.
15:35:40 <frg_Away> bbl
15:43:51 <WindowsTobin> yeah it didn't work
15:49:25 <WindowsTobin> anyone else have any suggestions
15:49:41 <WindowsTobin> aside from doing this manually with zero guide
15:52:34 <WindowsTobin> mach bootstrap thinks it is running on linux
15:53:06 <WindowsTobin> 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.
16:00:26 <WindowsTobin> yeah no this is all screwed up
16:02:15 <WindowsTobin> so mach bootstrap is horribly busted and I don't think there is any fixing it without a deep dive into it
16:02:54 <WindowsTobin> so that means frg.. and everyone.. Windows building is impossible from scratch
16:03:10 <WindowsTobin> without an already working system setup for it
16:05:52 <WindowsTobin> oh hold on..
16:07:42 <WindowsTobin> 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
16:08:40 <WindowsTobin> Personally I think this msvc adhoc thing is illegal because I didn't explicitly agree to the EULA for Visual Studio
16:17:23 <WindowsTobin> there configure is now satsified i hope
16:20:20 <WindowsTobin> 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
16:20:29 <WindowsTobin> frg_Away: it's building now
16:21:23 <WindowsTobin> and it errored out
16:21:31 <frg_Away> WindowsTobin I have a guide but it is outdated. Can send it to you.
16:21:44 <frg_Away> Are you using mozbuild 3.4?
16:21:47 <WindowsTobin> yeah
16:21:49 <WindowsTobin> stock
16:21:51 <WindowsTobin> not mine
16:22:09 <WindowsTobin> i got the thing bootstrapped with esr115 now .. i have a compile error lol
16:23:12 <frg_Away> I replaced the nsis inside it with 3.08 but otherwise should work.
16:23:50 <WindowsTobin> 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
16:23:57 <frg_Away> no need for a VS2022 start bat.
16:24:17 <WindowsTobin> frg_Away: there is if you want to use the system installed version but i am not using that right now
16:25:00 <WindowsTobin> unless seamonkey isn't 100% isolated like mozilla is now
16:25:31 <WindowsTobin> 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
16:25:48 <WindowsTobin> but no matter
16:25:59 <frg_Away> no it isn't stilla bastard between 78 and 91 bbuild system wise
16:27:58 <frg_Away> Are you building the current 2.53 patch queue? Then use export MACH_USE_SYSTEM_PYTHON=1 in your shell script.
16:28:05 <WindowsTobin> release
16:28:07 <WindowsTobin> first
16:28:23 <WindowsTobin> i can't actually do the patch queue on windows.. its too slow
16:29:10 <frg_Away> hg qpush --all takes a bit yes :)
16:29:22 <WindowsTobin> well its cloning repos that is the issue for me
16:29:31 <WindowsTobin> i cannot clone mozilla using hg on windows anymore
16:29:35 <WindowsTobin> sm is just takes forever
16:30:41 <WindowsTobin> ok warning supressed clobber build kicked off see what it is unhappy with
16:30:59 <frg_Away> recent hg not ancient 4.xxx?
16:31:02 <WindowsTobin> which I am surprised about since UXP went from 2015 to 2022 with barely any changes
16:31:14 <WindowsTobin> frg_Away: whatever mozillabuild provides
16:32:00 <frg_Away> WindowsTobin 2022 choked on ipc code which was added after 52.
16:33:14 <frg_Away> 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.
16:35:33 <WindowsTobin> frg_Away: https://dpaste.org/713L4
16:36:38 <WindowsTobin> i dunno what to do with THAT
16:36:55 <WindowsTobin> also.. i am very non-plussed at that condition existing
16:37:18 <frg_Away> Did the file end with crlf instead of lf by accident ?
16:37:40 <frg_Away> rust packages are checksummed
16:38:06 <WindowsTobin> windows line endings
16:38:45 <frg_Away> bad
16:39:42 <WindowsTobin> LICENSE-APACHE
16:39:50 <WindowsTobin> looks like it was all commited with windows line endings
16:41:39 <WindowsTobin> frg_Away: and because they are hashed dos2unix won't just solve it
16:41:59 <frg_Away> WindowsTobin Are you suing a tarball or gitlab?
16:42:01 <WindowsTobin> no wait
16:42:18 <WindowsTobin> gitlab.. but my git should be configured to leave lineendings alone
16:43:02 <frg_Away> Given that I picked this for the builder and IanN_Away for th Linux build it should be ok.
16:43:38 <frg_Away> let me look what is in my config
16:44:27 <WindowsTobin> you should add a gitattributes file to prevent this
16:44:31 <WindowsTobin> I do it for all my repos
16:45:00 <WindowsTobin> * -text
16:45:44 <WindowsTobin> .gitattributes
16:46:41 <WindowsTobin> frg_Away: I am surprised it didn't come up earlier
16:46:49 <WindowsTobin> doesn't client.mk explicitly have a check for this
16:47:41 <frg_Away> we didn't add anything here
16:48:38 <frg_Away> I have
16:48:40 <frg_Away> [core]
16:48:40 <WindowsTobin> 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.
16:48:41 <frg_Away> 	repositoryformatversion = 0
16:48:43 <frg_Away> 	filemode = false
16:48:44 <frg_Away> 	bare = false
16:48:46 <frg_Away> 	logallrefupdates = true
16:48:47 <frg_Away> 	symlinks = false
16:48:49 <frg_Away> 	ignorecase = true
16:48:52 <frg_Away> in my locl copy
16:49:48 <frg_Away> basically.  have set up some more things. Long time since I set it up fresh. Should I sent you my last pdfs?
16:49:55 <WindowsTobin> basically expect me to rewrite this page soonish lol https://www.seamonkey-project.org/dev/code-development
16:51:57 <frg_Away> 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
16:53:34 <WindowsTobin> 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
16:56:11 <frg_Away> 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.
17:11:04 <WindowsTobin> can't agree more
17:11:38 <WindowsTobin> and yeah 128 will be where I make Mark III for real. Still need that PWARunner
17:12:22 <WindowsTobin> but just a second.. sandwich pepperoni needs eaten
17:17:21 <WindowsTobin> anyway
17:17:38 <WindowsTobin> yeah this should now work until it errors out on an ACTUAL error right frg_Away
17:19:25 <WindowsTobin> ok its into rust
17:19:35 <frg_Away> If it goes over mach configure it should build
17:19:37 <WindowsTobin> oh
17:19:49 <WindowsTobin> 4:14.21 Some errors have detailed explanations: E0044, E0557, E0635, E0703.
17:19:49 <WindowsTobin> 4:14.21 For more information about an error, try `rustc --explain E0044`.
17:19:49 <WindowsTobin> 4:14.24 error: could not compile `packed_simd` (lib) due to 45 previous errors
17:19:49 <WindowsTobin> 4:14.24 warning: build failed, waiting for other jobs to finish...
17:20:40 <frg_Away> WindowsTobin what is your rust version?
17:21:10 <WindowsTobin> $ rustc --version
17:21:10 <WindowsTobin> rustc 1.79.0 (129f3b996 2024-06-10)
17:21:34 <WindowsTobin> error[E0044]: foreign items may not have type parameters
17:21:40 <WindowsTobin> over and over again
17:21:52 <frg_Away> rustup default 1.73.0-x86_64-pc-windows-msvc
17:21:54 <frg_Away> rustup target add i686-pc-windows-msvc
17:22:31 <frg_Away> or apply Bug 1896958
17:22:34 <WindowsTobin> oh
17:22:44 <WindowsTobin> config.guess assumes win32
17:26:25 <frg_Away> The i686 target is only needed if you build x86. I usually don't.
17:27:29 <WindowsTobin> 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
17:28:04 <frg_Away> The error is because of rust 1.79
17:28:06 <WindowsTobin> but i think that can't be done without an explicit choice from start-shell
17:28:30 <WindowsTobin> yeah but I assumed i was building 64 because I long patched that lol
17:28:53 <WindowsTobin> do i need a clobber for this?
17:29:13 <WindowsTobin> apperently not?
17:29:26 <frg_Away> no
17:30:03 <WindowsTobin> good to know will make a nice refreshed build instructions
17:30:24 <WindowsTobin> aaaand errored on IPC
17:31:40 <frg_Away> I use
17:31:42 <frg_Away> ac_add_options --target=x86_64-pc-mingw32
17:31:43 <frg_Away> ac_add_options --host=x86_64-pc-mingw32
17:31:44 <frg_Away> Not sure if hist is still needed
17:33:15 <WindowsTobin> 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
17:33:55 <WindowsTobin> and mach bootstrap writes the mozconfig anyway and its firefox by default failing that which has pre-configured mozconfigs
17:34:36 <WindowsTobin> result?
17:34:38 <WindowsTobin> $ build/autoconf/config.guess
17:34:38 <WindowsTobin> i686-pc-mingw32
17:36:23 <frg_Away> 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.
17:43:42 <WindowsTobin> frg_Away: this is erroring out in hash_tables
17:43:56 <WindowsTobin> no template named hash_compare did I mean std:_Uhash_compare
17:44:17 <frg_Away> yupp rings a bell.
17:44:18 <WindowsTobin> this is coming off hash_map in the ask
17:50:50 <WindowsTobin> i think I fixed it frg_Away
17:51:53 <WindowsTobin> no
17:51:55 <WindowsTobin> nevermind
17:51:57 <WindowsTobin> ugh
17:53:22 <frg_Away> My fix would be bug 1641090 but needs prerequisites
17:56:39 <WindowsTobin> what did you change in ipc that caused this
17:57:25 <frg_Away> I nothing. Came with 56
18:00:15 <WindowsTobin> right you said a change between 52 and 56
18:00:18 <WindowsTobin> wonder what it is
18:01:54 <frg_Away> I see its older code so uxp might have fixed it
18:02:24 <WindowsTobin> checking
18:04:37 <frg_Away> https://repo.palemoon.org/MoonchildProductions/UXP/commit/f369fbd6f7d2b0c74d482511bb16afbfc7856d11
18:05:00 <WindowsTobin> https://repo.palemoon.org/MoonchildProductions/UXP/commit/f369fbd6f7d2b0c74d482511bb16afbfc7856d11
18:05:15 <WindowsTobin> well
18:05:17 <WindowsTobin> shit
18:05:19 <WindowsTobin> frg_Away:
18:05:21 <WindowsTobin> LOL
18:05:39 <WindowsTobin> https://repo.palemoon.org/MoonchildProductions/UXP/issues/2000
18:06:21 <WindowsTobin> hey _nuke_ care to offer any insight?
18:07:10 <WindowsTobin> frg_Away: want me to try and port the UXP solution?
18:07:20 <WindowsTobin> since I am already .. in here
18:08:13 <WindowsTobin> 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
18:08:13 <frg_Away> yes will do a top patch then and credit brian. When we com to the real deal I can remove it
18:21:59 <WindowsTobin> frg_Away: https://dpaste.org/htR0i
18:22:03 <WindowsTobin> now this lol
18:30:03 <frg_Away> will tak a look tomorrow. Early sleep
18:55:45 <WindowsTobin> looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1441651
18:55:49 <WindowsTobin> would fix it
20:07:37 <nsITobin> https://bugzilla.mozilla.org/show_bug.cgi?id=1905962
20:07:48 <nsITobin> https://bugzilla.mozilla.org/show_bug.cgi?id=1905964
22:47:40 <nsITobin> sup
23:20:25 <nsITobin> yeah done banging my had against stuff
23:20:45 <nsITobin> for the day
23:21:18 <nsITobin> hi IrisZzz
23:22:05 <IrisZzz> hi