01:57:01 <tonymec|away> WG9s: 2.53.16b1pre dated 2023-01-24 22:00 for Linux64 (but not 2023-01-24 17:40) gives an enormously long popup when clicking right on a link. "Open link in new tab" there does nothing. I've scrapped it in favour of the 17:40 build.
02:19:47 <WG9s> tonymec|away: hmm let me try or i might just reboot the silly server
02:21:14 <WG9s> tonymec|away: works fine for me perhaps you need to clear your browser cache or restart your broswer for wome odd reason
02:21:40 <WG9s> some odd reason
02:22:47 <WG9s> but I am just clicking on save link as
02:23:16 <WG9s> open link in new tab works just as well
02:24:39 <tonymec|away> WG9s: hm. Worked OK for me in the 17:40 build before and after trying the 22:00 build.
02:25:22 <tonymec|away> strange thing you can't reproduce it.
02:25:43 <WG9s> oh, I thoght you were saying you could not download the 2200 build now i understand this is an issue with running the 2200 seamonkey build let me try tat
02:26:45 <tonymec|away> WG9s: yes. When I run the 22:00 build I get the problem; when running the 17:40 I don't.
02:27:51 <WG9s> silly me thought you were saying this was a general issue downloading builds with any browser so I was trying using firefox
02:28:06 <tonymec|away> aha
02:30:07 <WG9s> so I guess this is IanN_Away's issue
02:31:35 <tonymec|away> hm. Well you're aware of it, I have a temporary solution, and IIUC what you just said sent him a notification. :-)
02:32:15 <tonymec|away> "temporary solution" = go back to the previous build.
02:43:56 <WG9s> IanN[m]: major issues with your latest 3 landings to 2.53 gitlab
02:58:27 <WG9s> tonymec|away: I backed out IanN's last three gitlab patch queue changes and trying a new build.  this should work.  I hope he does not get pissed off at me for doing this.,
02:59:57 * tonymec|away hits head: WG9s: knock on wood
03:00:47 <WG9s> earlier today frg said that on a different channel and I posted a  youtube of the eddie floyd song
03:01:01 <tonymec|away> :-)
03:02:21 <WG9s> https://www.youtube.com/watch?v=TU4i-A8nx98
03:05:24 * tonymec|away hasn't got a working sound system anyway <-- WG9s
03:24:10 <WG9s> tonymec|away: anyway I exp[ect new build I am doing now to work just fine.
03:55:26 <WG9s> tonymec|away: so new 2023-01-25 02:50 should work better I hope
03:57:59 <WG9s> toneynew build seems to work for me!
03:58:51 <WG9s> tonymec|away: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
03:59:52 <tonymec|away> WG9s: ah, I'll download, install & test it. Wait a few minutes.
04:01:23 <WG9s> OK but sjhould be the same as the one you said alredy worked, unless i screwed up, I reverted the changes to the patch queue and did a new build based on the new patch queue but just to make sure what is in the patch queue actually works,.
04:03:31 <WG9s> if this were a mozilla thing kind of me doing the serif thing try to contact the person who landed the bustage and if i ca 't backout the changes
04:03:56 <WG9s> sherif
04:04:01 <WG9s> not serif
04:11:56 <tonymec|away> WG9s: build 20230125025033 is GOOD. Problem does not reappear.
04:17:14 <WG9s> tonymec|away: thanks for testiong
04:17:35 <tonymec|away> WG9s: my pleasure.
04:17:54 <WG9s> just need to get the rest of the platform builds to complete now
04:21:11 <WG9s> tonymec|away: seems i screwed something up with the windows build oops
04:22:55 <tonymec|away> WG9s: that one I cannot test, I have only Linux64. I might perhaps test a Linux 32 if I have all the necessary 32bit libraries but nothing more exotic.
04:24:02 <WG9s> no seems my builds were too late to not interact with the comm-cntral builds on the windows system.  I thought I had fixed this but evidently not,
04:25:00 <WG9s> seems I need to find where i am still removing the file that i use for the later touchches to make all the files have the same timestamp that corresponds to the buildid
04:26:26 <WG9s> ok i fixed it so next time I do a late build will not be an issue
04:27:24 <WG9s> but the windows builds to fix this will be seriously later oh well you are the only one who complained about the earlier builds
04:36:20 <WG9s> tonymec|away: I sent an email to IanN explaining the issue and why I did what I did.
04:39:21 <tonymec|away> WG9s: I suppose my quick reaction prevented too many users from being hit. ATM it is 5:36 AM central Europe (4:36 UK).
04:40:04 <WG9s> which is why I could not raise IanN he is in the UK
04:40:17 <tonymec|away> yep
04:40:29 <WG9s> is 11:36 PM here and I am up a little later than normal
04:40:40 <tonymec|away> :-)
10:11:35 <hardys> frg_Away: IanN_Away: With the build 20230124220003 from WG9S from today the context menu is messed up. When you right click in the browser window all entries are shown not only the case specific one.
10:12:53 <frg_Away> hardys I think there was a prblom . Use the  01/25
10:15:37 <hardys> IanN_Away: Thanks,  I will go back to the last good build from 01/22
10:16:58 <hardys> frg_Away: was meant for you :)
10:20:45 <frg_Away> hardys  I think the old 01/24 build should be ok https://archive.mozilla.org/pub/seamonkey/nightly/2023/01/2023-01-24-17-40-00-comm-253/
21:51:18 <Genaker> guys, i need help, the latest version of SeaMonkey won't launch for me. I'm on Mac OS X 10.9
21:58:24 <WG9s> Genaker: I did a build using an older SDK it is here can you try this one? https://www.wg9s.com/comm-253/seamonkey-2.53.16b1pre.en-US.mac.dmg
21:58:51 <WG9s> if this does not work I will try a build with SDK version 10.11 this one uses 10.12
21:59:44 <Genaker> I'm trying it now
22:03:41 <Genaker> It's giving me a "Minimum OS Version Requirement not met" error.
22:05:34 <WG9s> OK I will try something welse tomorrow morning
22:06:08 <Genaker> kk
22:08:07 <CaptainTobin> sup fools
22:08:37 <CaptainTobin> i know I asked this question before but can seamonkey be built with 2022?
22:08:45 <CaptainTobin> and would you like it to be built with 2022?
22:08:46 <CaptainTobin> lol]'
22:10:41 <WG9s> CaptainTobin: are you asking about vs2022?  we have switched to building with clang-cl
22:11:10 <frg_Away> CaptainTobin 17.3 broke it. I was too lazy to fix it yet. Compile error in some hash stuff because of changed VS2022 headers. Using Latest VS2019 for now.
22:11:22 <WG9s> should be fine to build it using the dlls form the vs2022 redist dir
22:11:31 <frg_Away> clang works too for sure.
22:13:01 <frg_Away> VS2019 gives a link error for x86 but this one is bad anyway. Crashes with heavy media use. So switched offical x86 to clang.
22:14:32 <WG9s> Genaker: not sure whay you get that error.  I set the env variable MACOSX_DEPLOYMENT_TARGET to 10.9 so if you are running 10.9 I donlt thnk you should get that error
22:14:52 <Genaker> That's weird.
22:15:13 <Genaker> HMMM
22:15:31 <Genaker> yeah it says 10.9.5
22:15:44 <WG9s> I am going back to how my builds were a wek or so ago using sdk10.11 and not specifyinf a deplyment target at all
22:16:02 <frg_Away> Genacker I suspect it is end of the line for 10.9 to 10.11 http://forums.mozillazine.org/viewtopic.php?f=5&p=14948508&sid=ffe3ff64d9dee5f6ce59cf3fb76870fd#p14948508
22:17:00 <frg_Away> We didn't plan for it but if we don't find a solution we need to document 10.12 as the minimum unfortunately. Also stop updates for sure.
22:17:27 <WG9s> frg_Away: says he does not think a build using sdk 10.11 will work but I think it will as long as I do not try to specify "ac_add_options --with-macos-sdk=<path to sdk>"
22:17:57 <Genaker> I can't update past 10.9..
22:17:58 <WG9s> the build does a version check for the sdk but only if you specify via that config option
22:19:53 <WG9s> up until recently i thought i was building with 10.12 but was actually using 10.11  I have no idea why that would have stopped working I will try that tomorrow unfortunately my regular nightly builds are running now so would have to interrupt that to do a test build now but can in the morning
22:21:46 <CaptainTobin> that shouldn't be too difficult to resolve
22:21:51 <CaptainTobin> i just will not use clang
22:21:56 <CaptainTobin> sorry but i won't
22:22:15 <CaptainTobin> now when you say 2019 it is 2019 not 2015's compiler in 2019
22:22:28 <CaptainTobin> right?
22:23:16 <CaptainTobin> I likely will drop x86 completely at the end of this year
22:23:32 <CaptainTobin> keep the ability but it is Best Effort(tm)
22:23:32 <frg_Away> Yes native support for VS2017 VS2019 and VS2022 is in for both x86 and x64. VS2019 x86 broken VS2022 x86 and x64 currently broken.
22:23:37 <WG9s> yes builds using the 2019 and 1017 compiler can;t speak for 2015 still working or not
22:23:59 <CaptainTobin> since I am not taking in jxr i can take my time getting to 2022 tho i will have resolve issues more and more so going 2022 is fine for me
22:24:07 <frg_Away> I think Palemmon fixed the x86 link error but not sure.
22:24:13 <WG9s> well see frg has more info becuase I am building using clang
22:24:24 <CaptainTobin> frg_Away: yeah but did they fix it properly
22:24:31 <CaptainTobin> rememer I am the build system "expert"
22:24:36 <CaptainTobin> heh
22:24:45 <WG9s> but using the vs2019 rediust dirs and inldue files for both x86 abd x64
22:24:52 <CaptainTobin> 8 years of build system being a primary responsibility to learn
22:25:22 <frg_Away> VS2019 toolset in VS022 can be used too but this needs changes. Did this for VS2019 in 52/2.49.5
22:25:37 <CaptainTobin> well you MIGHT have to readapt my patch to be more mozilla-like but if UXP and in turn my shit can go 2022 you can too and it IS actually my area of supposed expertise..
22:25:54 <CaptainTobin> yeah i'd recommend not pulling that nonsense if one can avoid it
22:26:01 <CaptainTobin> the newer vs older compiler thing
22:26:15 <CaptainTobin> makes my diabeetus hurt
22:26:50 <WG9s> so using the dlls from the vs2019 redist and also using SDK version 10.0.19041.0
22:27:23 <CaptainTobin> sdk version is mostly arbitary
22:27:28 <CaptainTobin> as long as it is 8+
22:27:39 <CaptainTobin> unless you directly backported more bs
22:27:42 <WG9s> Is that not where it gets the inlcude files from?
22:27:51 <CaptainTobin> but since mozilla dumpped vs there shouldn't have been much to port in that case
22:28:16 <CaptainTobin> well i mean is the one that ships with VS or at least windows 8.1+
22:28:30 <frg_Away> The x86 stuff was some weird one. Given that I stopped caring about x86 and just see that the clang build still builds didn't look too much into it. The code breakage was/is wierd and I wonder why it doesn't break with clang. But no c++ expert.
22:28:33 <CaptainTobin> at the base 50s era
22:29:06 <CaptainTobin> well bigint for no good reason is being shat out to all the frameworks and bigint at our level even evolved won't be able to do bigint on 32bit regardless
22:29:12 <WG9s> quite frankly I have not understood the windows builds since mozila stopped using cygwin
22:29:43 <CaptainTobin> WG9s: well where are you IN understanding so i can fill in the gaps
22:30:05 <WG9s> and onlhy reason to not build using cygwin was they could not get the flash plugin to work and now they no longer support that anyway
22:30:06 <CaptainTobin> it is too late in the day to give you a top down explaination for how it theoretically works
22:30:22 <frg_Away> I frequently update the compiler section in the meeting notes: https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2023-01-15#.5Bcomm-release56.5D
22:30:25 <CaptainTobin> cygwin is dead
22:30:36 <CaptainTobin> then again so is autoconf 2.13 exactly and msys1
22:30:51 <frg_Away> Need to add the VS2022 x64 problem. Only tried recently and found out.
22:31:19 <CaptainTobin> I will need to steal my dpmo text and info back from MCP which includes my OWN properly evaluated compiler compat table
22:31:34 <CaptainTobin> of course now it is a freeforall..
22:31:43 <CaptainTobin> like everywhere else
22:31:48 <CaptainTobin> everywhere but BinOC lol
22:32:00 <frg_Away> autoconf 2.13 was copied to the mozilla central tree. Need to backport later but first needs more build stuff applied.
22:32:17 <CaptainTobin> how did they swing license compat?
22:32:22 <CaptainTobin> cause autohell is NOT MPL
22:32:31 <CaptainTobin> or permissive
22:33:16 <CaptainTobin> I know I followed the patch for the mapi headers import but i really don't feel good about having them live in mailnews
22:33:32 <CaptainTobin> they really need to be in my third_party or what remains of legacy other-licenses
22:33:35 <frg_Away> https://bugzilla.mozilla.org/show_bug.cgi?id=1663863
22:33:37 <WG9s> CaptainTobin: I think that is why everyting in configure is being moved to moz.configure and moz.build files
22:33:38 <CaptainTobin> same would be true for autohell
22:33:53 <CaptainTobin> they could have moved to newer autohell
22:34:10 <CaptainTobin> mozbuild was all about trying to create a mozilla version of a google concept of cmake
22:34:17 <WG9s> so tryuing to eliminate autodonf altogether
22:34:22 <WG9s> autoconf
22:34:29 <CaptainTobin> now mozbuild is OKAY in my book at my level
22:34:34 <CaptainTobin> mozconfigure is a god damned disaster
22:34:39 <CaptainTobin> i will exterminate it
22:35:41 <CaptainTobin> but yeah.. my crystalized plan going forward is broadly let MCP and co worry about following the GoogleWeb.. I am gonna focus on everything I always wanted to do
22:35:53 <CaptainTobin> and btw Borealis won't ever be released in its current form.
22:36:13 <CaptainTobin> Interlink will get some love and continue as-is i have something way better planned
22:38:07 <frg_Away> CaptainTobin The VS2020 could probably be fixed by backporting Bug 1641090. As stated too lazy currently and needs a bit more stuff first to apply clean(er) which i always try to do.
22:38:24 <CaptainTobin> I'll look into it
22:38:30 <frg_Away> part 10 removed the offending stuff.
22:38:41 <CaptainTobin> gonna need to for the weave uplift and refresh
22:39:17 <CaptainTobin> man i do NOT want to have to move my fuckin dns server
22:39:48 <CaptainTobin> but i got a smaller server for dns irc and other critical but small services so they can stay operational while more complex server shit is afoot
22:40:19 <CaptainTobin> frg_Away: here is an important question
22:40:26 <CaptainTobin> i will need for that work
22:40:42 <CaptainTobin> how much moz-specific js functionality have you mutated or removed since forking 56
22:41:03 <CaptainTobin> cause weave was orginally written during the pre-jsm extension but post jsm era
22:41:35 <CaptainTobin> so there might be classic mozillaisms we may run into here and there
22:42:00 <CaptainTobin> least I don't have to fix the god damn for loops
22:42:04 <frg_Away> Code is 90% at end of 58 minus the really bad parts. I skipped a few sync plates lately. Later stuff in too of course but mostly in other areas.
22:42:23 <frg_Away> ^skipped sync patches
22:42:43 <CaptainTobin> when I ported the tycho weave client and add-ons manager i had to one by one test everything manually and solve the depercated pythonic-style loops to either es5 or es6 standard loops
22:43:10 <CaptainTobin> there shouldn't BE that many sync patches for weave given the tech was abandoned.
22:43:24 <CaptainTobin> and only partly stayed as part of fxa because fxa was half-assed from the start
22:43:35 <CaptainTobin> also inital transition
22:45:23 <CaptainTobin> here is everything WE did up to the gre-changes
22:45:25 <CaptainTobin> https://code.binaryoutcast.com/projects/aura-central/commits/TRUNK/services
22:45:54 <CaptainTobin> if there is any removed mac bits I'll add them back
22:45:59 <CaptainTobin> so don't worry about that
22:46:05 <CaptainTobin> but i see no reason to bother restoring android
22:46:23 <CaptainTobin> to weave
22:46:26 <frg_Away> e4x for-eah bug 1388317  is on my short chop chop list.
22:46:55 <CaptainTobin> for each?
22:47:00 <CaptainTobin> rther
22:47:04 <CaptainTobin> for Each
22:47:14 <frg_Away> yes
22:47:33 <CaptainTobin> anyway i repercated it
22:47:41 <CaptainTobin> cause es6 loops still fuck with my brain
22:47:47 <CaptainTobin> as much es6 nonsense does
22:48:00 <CaptainTobin> is that the inverse?
22:48:02 <CaptainTobin> repercate?
22:48:07 <frg_Away> js version and legacy generators are out too.
22:48:07 <CaptainTobin> heh
22:48:38 <CaptainTobin> guess i'd have to actually revcerse this patch
22:48:42 <frg_Away> Trying to get the parser updated and these deprecated features always were/are in the middle of it.
22:48:46 <CaptainTobin> if i did a retrofit
22:48:49 <CaptainTobin> of the engine
22:49:02 <CaptainTobin> some shit does need to go
22:49:06 <CaptainTobin> but some shit i wanna keep
22:49:21 <CaptainTobin> but thank you that is one important tidbit to consider for a js uplift
22:49:26 <CaptainTobin> is the moz or legacy removals
22:49:39 <CaptainTobin> which means the fe code either needs adapted or the features need to be put back in
22:49:45 <CaptainTobin> and for me that is a case by case basis
22:49:55 <CaptainTobin> cause JS version is important to extensions and chrome code
22:49:58 <CaptainTobin> imo
22:50:12 <CaptainTobin> especially if i want to have that line between eichscript and emcascript
22:50:19 <frg_Away> Legacy getters/setters give me much grief too but so far I kept them. Fear for massive add-on breakage.
22:50:40 <CaptainTobin> like the line between xul/xbl and html/googlecomponents
22:50:40 <frg_Away> Same for nsIAtom nsAtom conversion
22:51:45 <CaptainTobin> well as I said I am gonna largely let MCP run them selves in circles chasing google tech.. i am more focused on true mozilla tech
22:52:11 <CaptainTobin> least until SOME sort of better plan materalizes
22:54:58 <frg_Away> anyway sleep first
22:55:01 <frg_Away> nn
22:55:10 <CaptainTobin> tho one tidbit they keep ignoring is style.. there is no reason why we don't have every non-servo or simple css shit
23:10:41 <WG9s_> tonymec|away: tonights build with IanN_Away's updated patches seems to work just fine for me.  Give it a whirl!
23:22:12 <WG9s> tonymec|away: build is done you get notifiactaion after all the langpacks are done and archived