11:32:27 <nsITobin> good morning WG9s
11:33:02 <WG9s> good morning!
11:35:22 <nsITobin> all I need is to know what you want me to make this Buoy do https://postimg.cc/crdZQsDb
11:42:49 <WG9s> nsITobin: if you are asking me please send this in other than an image.  It is completely illegible to me
11:43:34 <nsITobin> can you click on it to zoom it out?
11:43:50 <nsITobin> or is postimage just crap
11:44:23 <nsITobin> here is imgbb https://ibb.co/JxXSCGT
11:44:38 <nsITobin> its just a window with a menubar a browser control and devtools
11:44:39 <WG9s> i trid soming before i asked for other than image
11:45:27 <WG9s> the subwindow with the actual error is illegiable and zomming is of zero help
11:45:50 <WG9s> cantl you just give me the test of the error or a complete log from the build or something
11:48:04 <nsITobin> I am confused.
11:49:31 <nsITobin> I need to reboot back to windows
12:10:38 <frg_Away> hi nsITobin
12:10:59 <nsITobin> sup
12:14:06 <nsITobin> just poking around about pages on this Buoy component i whipped up a little while back on central.. considering hooking up that overlay emulation and spawning navigator.xhtml
12:14:32 <nsITobin> last I attempted it was around 122
13:29:38 <njsg> 0730|12:44:29 <+nsITobin> here is imgbb https://ibb.co/JxXSCGT <- https://i.ibb.co/CJxSWYy/image.png if it helps
13:30:11 <nsITobin> its cool thanks njsg
13:30:12 <njsg> but I don't think this was about an error, just showing it working with comm-central?
13:30:41 <nsITobin> ye .. i need to work on being more clear
13:39:23 <njsg> postimg.cc has a download image link that, at least with "open in browser" can be opened as an image
13:40:06 <njsg> ibb.co has an image_src <link> that can be reached from the website navigation bar
13:40:50 <njsg> (under "More")
14:10:38 <nsITobin> postimg seems to go down a lot or has lately
14:10:45 <nsITobin> I just need a paste/img bin
16:59:32 <nsITobin> https://i.ibb.co/QFvGTfH/image.png
17:30:30 <WG9s> nsITobin: are you applying the gitlab seamonkey-central-patches patch queues?
17:30:50 <nsITobin> yeah
17:31:00 <nsITobin> that does a lot
17:32:42 <WG9s> OK just on first blush my take was maybe not appling the patches for bug TOP-1611647-1-rename-xul-suite.patch and TOP-1611647-2-fix-xul-references-suite.patch
17:33:13 <WG9s> shich have to do with changing comm-central to handle change .xul files to .xhtml
17:33:47 <nsITobin> I think I can make suiteglue partly work by jsm'ing it but that is quick on the slate for removal and sys.mjs would ahve to swiftly follow to get seamonkey to start normally
17:34:21 <nsITobin> least enough to spew errors
17:35:17 <nsITobin> some of these issues are gonna still bare down with backports
17:35:35 <WG9s> but since errors seemded to be about .xhtml files i suspected this bug 2 parts one rename all files with .xul extensions to .xhtml the second hanges the filenmes in all the references
17:36:42 <WG9s> if you are adding more .xul files you might need my script that redoes the renames and rereferences .xul files do not work in central
17:38:49 <WG9s> the sehll script here takes new changes into account to fix the patch for this https://gitlab.com/frg/seamonkey-central-patches/-/blob/master/scripts/xul2xhtml.sh?ref_type=heads
17:39:52 <nsITobin> WG9s: I been studying very closely what they been up to https://dpaste.org/oGGiG
17:39:59 <nsITobin> it irks me
17:40:02 <nsITobin> but.. i learned
17:40:56 <WG9s> anyway if doing central patches don;t use .xul extenyion use .xhtml instead
17:41:04 <nsITobin> indeed
17:41:12 <nsITobin> still seems dumb
17:41:22 <nsITobin> an internal extension shouldn't REALLY matter
17:41:39 <nsITobin> just what a few lines to make sure it opens in the right parser
17:42:00 <WG9s> but .xhtml is a web standard thing .xul is a mozilla thing
17:42:27 <nsITobin> yeah and about: protocol hides most chrome urls ;)
17:43:07 <WG9s> so the stupid scritp changes all .sul files inthe repo to .xhtml and a scond patch that finds all referwnces in the code to .sul files and changes thenm to .xhtml
17:43:31 <nsITobin> still this is about as XUL as xhtml can get anymore as near as I can figure from other examples throughout the codebase
17:44:09 <nsITobin> they have some xbl replacements as xul customelements but that's just transitional
17:44:15 <WG9s> you would think who cares but they removed the special code for .xul fiels form m-c becuase id you just rename them to .xhtml the code for that takes care of them
17:44:29 <WG9s> so no longer need special case for .xul files
17:44:49 <nsITobin> sad
17:45:15 <WG9s> maybe they need to chage it to say there is only xytml
17:45:20 <WG9s> shtml
17:45:25 <WG9s> xhtml
17:45:32 <WG9s> third time is the charm
17:46:25 <nsITobin> register the domain name redirect it back to XUL
17:46:59 <WG9s> ;-)
17:47:26 <nsITobin> WG9s: IF IT STOPPED HERE.. i MIGHT be willing to embrase it but we know it doesn't
17:47:32 <nsITobin> that's the thing about modern mozilla
17:47:37 <nsITobin> as a .. whatever it is
17:47:57 <WG9s> I am big on redirects and meta refresh pages in the archive for my nightly builds becuase seems no way to do symlinks
17:48:21 <nsITobin> symlinks can be a pain
17:49:24 <nsITobin> i think it is funny out of all of it.. composer of all things is SLIGHTLY functional
17:50:05 <WG9s> so like was about to send you an exapmle but seems the seamonkey project archive site is now down, or at least not reachable via version from the US
17:50:16 <nsITobin> u'd think Mozilla would ressurect the editor ui for them selves for chrome html usage
17:53:44 <WG9s> so like https://archive.seamonkey-project.org/nightly/comm-253-latest/index.html is an index.html page with a meta refresh instead of https://archive.seamonkey-project.org/nightly/comm-253-latest  being a symlink to the latest build
17:59:37 <WG9s> nsITobin: so already a typo in my automation scipt change
18:00:01 <WG9s> somehow pusddd instead of pushd
18:00:28 <WG9s> well pushdd instead of pushd but you get the idea
18:48:59 <nsITobin> frg_Away: I am at the mangling my own patches stage of my hg mq learning
18:49:35 <frg_Away> have mq fun
18:49:45 <nsITobin> i am :)
21:21:45 <nsITobin> aaand a pull from c-c just busted me
21:21:58 <nsITobin> says run mach tb-rust vendor do it and it fails
21:22:35 <nsITobin>  0:00.65 [INFO] Updating gkrust in our workspace
21:22:35 <nsITobin> error: invalid escape sequence
21:22:36 <nsITobin> expected `b`, `f`, `n`, `r`, `t`, `u`, `U`, `\`, `"`
21:22:36 <nsITobin>   --> Cargo.toml:23:23
21:22:36 <nsITobin>    |
21:22:36 <nsITobin> 23 | cmake = { path = "..\..\build\rust\cmake" }
21:22:47 <nsITobin> GREAT system..
21:31:13 <WG9s> seems frg broke something whn yu ceck-out c-c dot from changeset 30c2520e5b0ec3fe26c2c8c69f24352732f37463
21:31:29 <WG9s> foit
21:32:00 <WG9s> that is the last changeset from before when frg screwed the pooch
21:33:11 <WG9s> not sure his stuff is the reason but looks suspicious
21:37:28 <nsITobin> how does adding a few urls to debugqa do this?!
21:37:45 <WG9s> not sure at all
21:37:50 <nsITobin> looks like rust
21:38:06 <WG9s> just bustage seems c-c only and only these 3 changes
21:39:26 <nsITobin> now i get a toml.decoder.TomlDecodeError: Reserved escape sequence used (line 18 column 1 char 294)
21:42:54 <WG9s> checking out the eatlier changeset did not help so must be a m-c change that broke something
21:44:13 <WG9s> I suspect something was chacked in no m-c that broke enable thunderbird-rust
21:44:27 <WG9s> try building with that disabled maybe?
21:44:58 <WG9s> oh stuipd me tested earlier changes wrong
21:45:42 <WG9s> testign correctly based on rgular chanset in about 5 mins
21:45:59 <WG9s> but then about 20 mins later to know
21:48:25 <nsITobin> oh well it IS just central anyway.. I don't need to get all I MUST DO THIS NAOW about it .. learned some more progressed fullilling one of the things I said i would do.. learned more about hg mq.. all in all a good day of hackin on codestuffs
21:49:25 <WG9s> JUt seems to be boken when i ws trying to test tomething
21:51:30 <WG9s> if it is the frg stuff i would think mostlikely Bug 1909853 becuase it touches mailnews which is where the enable-thunderbird-rust comes into play
21:53:52 <njsg> but was there a change in Cargo.toml?
21:53:58 <nsITobin> yes
21:54:06 <nsITobin> and a new rust component added
21:54:09 <nsITobin> in cc
21:54:35 <nsITobin> hold on i may be dumb and thowing WG9s off.. always a possibility
21:56:00 <WG9s> but m builds are failing and so are the thunderbird builds failurews started with frg's 3 patches landed
21:56:32 <WG9s> so unless something landed around same time on m-c that borke this is supect the feg patches
21:56:38 <WG9s> frg
21:58:02 <WG9s> nsITobin: frg is gone for the day i am trying to taise IanN_Away
21:58:42 <nsITobin> well i was on rev 42116 i see another sync vendoreed rust libs with moziilla central, repackage thunderbird as a debian package, my ui patch, a chat patch and esr links to debugqa.. how can frg's patches break hg like is it something in the header? or
21:59:37 <nsITobin> I am gonna try purging .mozillabuild .cargo and .rustup see if completely "fresh" it works
21:59:50 <WG9s> well could caus the error i am seeing not sure why your weeoe looks differnet
21:59:58 <njsg> wait, why the backslashes?
22:00:13 <nsITobin> I am on windows
22:00:15 <nsITobin> atm
22:00:22 <nsITobin> but
22:00:35 <nsITobin> aren't all paths in mozilla regular slashes
22:00:42 <nsITobin> to the build system
22:00:47 <nsITobin> save internal python
22:00:54 <nsITobin> maybe that's why
22:01:05 <WG9s> no if you are in windows seems either slash works sometimes
22:01:36 <WG9s> this is one of the things i complained about in the dos days
22:02:22 <nsITobin> Rust dependencies are out of sync. Run `mach tb-rust vendor`
22:02:23 <WG9s> Microsoft decided to go the DWC VMS ay of things fielnames are case insensitive options use a / as the dleimiter so not avilable to use as a path delimeter
22:02:24 <njsg> DOS itself could handle another separator, third party software is probablya trickier quesiton
22:02:25 <nsITobin> run it
22:02:27 <nsITobin> it fails
22:02:50 <njsg> now Windows NT, my guess would be it translates internally too?
22:03:28 <WG9s> dos version one allowed you to change the command option delimeter and i ran at the time changing it to - but in vrsion 2 they elimiated that and came up with path delimiter is \
22:03:41 <WG9s> and i don;t remeber there being a way to change
22:04:03 <WG9s> they seems to be tageting making it be a DEC VMS replacement on a smaller platform
22:04:53 <WG9s> all worked berrer in the msdos they stole to sell to IBM
22:05:09 <WG9s> tomake pcdos
22:05:26 <njsg> nsITobin: is there more than one error about escape sequences? because Cargo.toml:23:23 looks a bit off
22:05:50 <njsg> I mean, the code printed afterwards has a *valid* escape at column 23
22:14:24 <nsITobin> well my build output is a bit manged because i am not using the msys2 terminal but just through oldstyle conhost..
22:16:44 <nsITobin> njsg WG9s here https://dpaste.org/eRnpw/raw
22:16:50 <nsITobin> cleaned it up.. slightly
22:17:46 <nsITobin> this is tip *-central + patches
22:17:58 <nsITobin> now
22:18:35 <WG9s> ok that is now the same error i get has to do with tying to get the audioipc2-client rust package s i think is thunderbird-rust related
22:19:46 <nsITobin> well good that's progress we both see the same thing.. that's a good sign.. for sanity at least
22:20:21 <nsITobin> as you know I been encountering pretty much every quirk there is that can block someone building
22:21:15 <WG9s> nsITobin: are you ring to build seamonkey?
22:21:29 <nsITobin> atm yes
22:21:43 <nsITobin> could try Mozilla Thunderthighs
22:21:45 <nsITobin> i mean
22:21:59 <nsITobin> Thunderbird
22:22:12 <WG9s> does it word if you disable-thunderbird-rust?
22:22:32 <nsITobin> well won't opengpg fail to build without thunderbird rust?
22:22:44 <nsITobin> pgp
22:22:49 <nsITobin> whatever it is
22:22:54 <WG9s> i am trying to build under linux 64 so fails if disalbe-thunderbitd-rust anyway
22:23:23 <nsITobin> no it was that exchange protocol
22:23:41 <WG9s> lst i kne seamnkey did not try to build openpgp becuase under 2.53 it can still use the enigmail add-on
22:24:13 <WG9s> one of the things needed to change for central it needs to build openpgp i think
22:25:04 <WG9s> but it currently is not so pgp for seamonkey central does not do pgp as far as i know
22:25:32 <WG9s> becuase it teuite an add-on of a type no longer supported and does not include the opengpg that TB does
22:25:35 <nsITobin> they did remove a dependancy on the appcore component part that shouldn't have been linked from mailnews
22:25:47 <WG9s> that is what I thought the current state of this was
22:25:50 <nsITobin> also configure completed successfully
22:26:02 <nsITobin> which means m-c is in .. well mozorder
22:26:07 <nsITobin> and thunderbird busted comm
22:26:55 <WG9s> one of the three bugs frg landed at the same time the TB build issue began removed a lot of supposeldy unused mailnews code i am thinking pethaps he got a bit carried away in removal
22:32:54 <WG9s> ibf my build in progress sorrks then when you clone form comm-central speciy changeset
22:33:27 <WG9s> 30c2520e5b0ec3fe26c2c8c69f24352732f37463
22:34:59 <WG9s> that is last good build before the bustage if you look at treeherder for comm-cdntal
22:39:26 <nsITobin> I do not buy it's frg's changes unless the patches them selves managled comm-central the repo somehow.. his changes don't affect anyone or rust
22:39:44 <WG9s> my build still fails so wonder if something changed onm-c that needs a redo syncing
22:40:11 <nsITobin> I am gonna try a local backout of the last thunderbird rust-sync
22:40:21 <nsITobin> see what that does
22:41:39 <nsITobin> oh look configure completed
22:41:42 <nsITobin> WG9s:
22:42:03 <nsITobin> now doesn't mean it won't compile error out.. but
22:43:03 <WG9s> i would suspect one of these patches as causing this
22:43:08 <WG9s> https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=ab17014f4b8f237c9d5fe7b88f8a89c49d0ffe7c
22:43:23 <nsITobin> no still saying crap about audioipc2-client
22:43:28 <nsITobin> unable to update
22:43:54 <WG9s> and i bet this one since it way audio ipc right in the chck-in comment
22:44:37 <nsITobin> 0:10.83   Unable to update https://github.com/mozilla/audioipc?rev=c200b1efa8d4a567b875b46ce7c395ca172fae5b#c200b1ef
22:45:10 <WG9s> it would seem this reuites a comm rust sync which was not performed
22:45:39 <nsITobin> why does that url have an anchor on it?
22:54:10 <njsg> this? https://github.com/mozilla/audioipc/commit/c200b1efa8d4a567b875b46ce7c395ca172fae5b.diff
22:54:38 <njsg> nsITobin: the anchor is the start of the commit hash. I chalk it down to github being github
22:55:04 <njsg> why is the address not /commit/? or is that being output by the build system?
22:55:19 <nsITobin> by the build system
22:55:29 <nsITobin> couldn't update
22:55:42 <nsITobin> yeah i don't understand how rust crates work
22:56:09 <WG9s> nsITobin: so if you backout the patch for bug 1910523 that should fix it untll we can get a new sync run it is not an extra sync that is the issue is a missing one that bug requires a sync which never happened.
22:56:36 <WG9s> wasiest way to fix for now is to backit out
22:57:43 <WG9s> easiest
23:06:16 <WG9s> nsITobin: TB folk figured it out and just did a sync so all should be well now
23:06:40 <nsITobin> oh
23:06:53 <nsITobin> i was just about to hopefully confirm it was all their fault
23:07:01 <nsITobin> :P
23:07:59 <nsITobin> I had to revert the mozilla part and the comm part to return cargo back to its prior state.. guess what I get to do now WG9s lol
23:08:21 <WG9s> put it all back?
23:08:45 <nsITobin> YES!
23:42:11 <nsITobin> here we go WG9s https://web.archive.org/web/20130116073227/http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey even has burning builds