buc no longer around?

buc comes and goes

mostly not here

hey a-865

how are you?

and GrannyGoose

im good thanks dude

an how\ are you

seamonkey needs to be rebuilt in Fedora koji as it failed when it was rebuilt with ICU73.2 i think it was

I use 2.53.17b1 in my CZ profile (here), but Buc's 2.53.16 for my email profile, for sane/universal time/date formats from iso8601

long time since using a distro's build of SM or FF

i dunno who has to rebuild it in Fedora but im aware a few people do use it, i wouldnt kn ow how many co-maintainers buc has for seamonkey in fedora

fedora is what I use for my nightly builds they use clang-16

WELP they did it.. they shipped the intl api change without bothering to add any other dep for platform compatibility as well as martok the implementer has deemed an issue reproducible 100% of the time as unreproducible but don't worry he added a test case which does nothing for anything.

why is it every single time I think I got shit settled and are ready to move crap like this happens

I guess Moonchild got what he wanted.. to become Mozilla and Firefox.. too bad he became the WRONG one..

Guess i should abandon my webclient ambitions completely and just strip my known-working former codebase into an Interlink MailNews codebase and just otherwise be done with their nonsense and do what I wanna do.

what do you think frg_Away

Up to you. I am doing what makes me happy and this is keeping suite alive. That I help users with it is a byproduct :) As for backporting I think it is mozilla codebase minus bad stuff as we do it unless you have many more resources/coders at hand.

well i suppose IF i am not gonna be looking to do innovative radical nsInsaneo things then the seamonkey's evo56 base would be more attractive

just to keep interlink viable and get back to helping YOU guys out just by doing things without a huge commitment or affiliation.. that is quite attractive as a viable option

thank you for inspiring it frg.. i will consider a little more

besides, who is gonna advance mailnews core features? Athenian200? lol

I do know who IS backporting mailnews core bits and bobs

.. You

Interlink the project that started with MCP bs and sarcasim bridges me back to where I started.. SeaMonkey .. do interlink halp out here and there.. fork xpfe and kde shit.. loose about 20-40 more lbs.. and find some more money and i could be doing well.. it certainly is a goal worthy of my attention

one question: if I say hey this is busted .. you gonna give a crap?

not fix it then and there but .. give a crap

use that as a vector to also do the other shit i said i was gonna do for you like vs improvements, the sync shit, etc.. rust tho

MattATobin The TB part in our base is fully functional. We use it for A/B tests. Same for browser. Suite tests are busted forever now and with the others working we can use these tests.

i'd duplicate the app directory and just clone it into place into comm into mozilla just to keep it simple and keep mail/ as a baseline compairson but yeah it would mean doing interlink from scratch but maybe it is time.. and i of course know how to make my own private copies of anything I'd need.

test suit isn't a big deal for me

neither is l10n

well I ain't out to redefine your project or codebase just have a mail client and help out a bit.

tried that.. didn't work lol

also..

less xref work to maintain

if i do this lol

FEELS like a good idea

have to think about it .. but given uxp became unviable again i am a bit over the codebase its self now

thank you frg_Away

for whatever you .. did?

being here

that's it being here

another question: and this IS relating to a change I would like to make to the suite.. I would very very very much like to restore build time conditionals for --disable-mailnews and add --disable-composer so that with those two options SeaMonkey just has a standalone build mode and I would take express responsibility for maintaining that build configuration. This way I don't HAVE to be pressured into creating my own web client.. can just bri

just build without.. would you be okay with this?

just throw those two options, some branding, and boom standalone navigator and restoration and expansion of something not possible since pre-toolkit

it kinda was one of the first things I wanted to contribute back in the day

and started this

come ooooon it is just some ifdefs and configure options lol

don't be a NeilAway lol

I am gonna be thinking about this for the next week as I take a trip to indiana and won't be able to do shit lol

Untangling these parts would not be easy. Would probably mean ifdefs and code changes all over the place. Something for IanN to decide but I would only do it if suite in central dies and is removed by our "friends". Otherwise most uplifts would need to be rebased.

actually it is VERY easy

because it was DESIGNED that way

it just wasn't maintained when they went from xpinstall to nsis

and xpfe to toolkit

because libxul and MOZ_XUL_APP conflicted with modularity

i literally just followed the bug progression last night actually

also i was there at the time

lol

also i have removed mailnews and composer from navigator at least three times now

once in 2010

depending on the changes from 52 on to overlays and such it likely ain't much more trivial than last time I did it

cause HOW I did it?

restoring the conditionals first

then removed .. i just have to .. not remove.

much less trivial*

at the 52 level there were no platform changes required simply build files and a few conditionals for the component integration overlays and a few pieces of js

well you know what? since it is so trivial .. for me at this point .. I'll do it and just letcha look at it and if you and our good and dear friend IanN_Away approves then you can bring it in.. if not i'll file it away until someone complains just enough about navigator to make it happen which after five years it still ain't lol

i still have to figure out how to hell to build the thing tho do you have applicable build instructions that match the evo codebase?

hai WG9s

WG9s: which version of mozillabuild and how do i get rust?

or is that in the mozillabuild package

rustc

i assume THESE are about right except i already know you have the mapi headers in-tree now web.archive.org/web/20180516123634/…_Instructions/Windows_Prerequisites

and i believe you said mozillabuild 3.4

GrannyGoose: It seems it falied to build under the latest Fedora devel due to (yet another) python3 issues, not icu-73.2 itself.

what is the nature of the issue buc

MattATobin: "ModuleNotFoundError: No module named 'imp'", see kojipkgs.fedoraproject.org//work/tasks/977/103240977/build.log

I delayed it until 2.53.17 final is ready

doesn't quite answer my question?

.

oh it sent anyway

stupid matrix

oh well

i just looked at my 'History' (something i don't typically do), & it goes back to 2015 ;-)

welcome back mister frg

WG9s: your webserver seems to be down

each branch in the repo is basically master with selected c-c patches backported every single time correct? is there a canonical 2.53 trunk

I am using mozbuild 3.4 and VS2019 19.11 latest Windows sdk 19041. rust 1.66.1 but anything later should work too.

On the way to mozbuild 4 but msys2 need further changes. One step at a time.

is the comm under mozilla basically only defined by these set_defconf values in the application's moz.configure now?

buc if you have a fix for the py3 issue which is backwards comaptible I can put it into the final. 2.53.17.

MattATobin It is all over the place. I lost track long ago. Just backported and in some places optimized our code.

actually it is not too bad i mean the comm files them selves should be better updated especially moz.build since it would be available as well as makefiles .. save things like the main mozbuild and build.mk stuff like that

virtualenv mazbuild base but that is just to support Must have a build or whatever

also mozconfigure support code

oh that's a mozconfig okay

yeah basically you have no comm build system whatsoever what comm is now .. is just comm vs mozilla dir variables

neat

tho i wonder why you even need it if you are building anyway.. There is no real reason to have this unless you want to maintain the now-ability to change comm/ arbitrarily except where it is still hardcoded

now you know the state ;)

i was following jcrammer's work on this at the time but i kinda lost track

MattATobin comm build system is mostly gone. Just some extensions. I think stuff like commtopsrcdir are on the way out and I have removed much of it in suite already.

frg: It seems python3.12 build is still broken under Fedora Rawhide. Firefox is not built with python3.12 with similar errors. So just wait for Firefox team to resolve the issue :)

frg: for python-3.12 bugzilla.mozilla.org/1743785 is needed anyway.

so I should if possible go ahead and just use normal paths when I fork mail/ to whatever/

or just wait for whenever you ditch em lol

that will be it