0301|02:46:24 < Sompi> One day I started reading forum posts from an old Finnish programming forum, from 2005 <-- out of curiosity, which forum?

«Help us improve your Bugzilla@Mozilla experience In addition to cookies necessary for this site to function, we’d like your permission to set some additional that will improve your experience.[...]»

I can't wait for Mozilla to bundle a clippy-like AI assistant with the next ESR.

frg_Away: i checked the ftp log are you not able to login? can you check and see if this fixed it?

cron job is set to hourly now and ACTUALLY enabled this time

I set it up then later disabled it so I could land the panel template change to the sm template rather than the protomoon one I initally used for expediency reasons.. I am not sure it ever actually ran on the 24 hour sched..

nsITobin. I think I was able to do so.

only real mod i had to do to conform my static content template to smarty was add foreach blocks .. smarty is nice or .. was

central is worse than ever btw

nsITobin looks like I have an incorrect password for ftp or bad settings

Is this different from the main site password?

well yours SHOULD be the same i manually replaced the token with the password I sent you

I changed the main password. Seems the ftp on is not good.

so the "token" is the ftp password encoded into the berkley db it only seems to work with if not pam_unix

another ftp server proftpd is supposted to be better but I need to find time to install and mess with it see if it would indeed fit better than vsftpd

I spent 2 weeks or so trying to get vsftpd to do what the manual said.. fell back to working methods if a bit adhoc

I suppose I should alter the user root page to actually EXPLAIN that.. might be helpful :P

if proftpd proves to be fully pam compatible then my pamscript will work and your password would be your password not a generated ftp password and a secure site password

OH

ffs

frg_Away: security error files were owned by different user than the main config.. i didn't know it had this but actually that is a GOOD security feature means something created by php from the web can't be used to override security .. has to be owned by root who owns the main conf

should work now if you use the token listed on the user settings page

token as password?

on ftp yes

works now. Thanks

stole the idea from betaarchive actually since their entire community is powered by phpbb and phpbb isn't known for ftp so logiced out how they do their thing.. just no ip lock

oh .. the cron job to update symlinks based on files.. i totally forgot to write that

Is there any work still done on Seamonkey's rendering engine or is that just pure maintenance mode at this point? Curious since it's been using the Firefox 60 gecko for 5 years now, but that's post-quantum so it feels like some development effort was at least being put in in 2019/2020

(Sorry if there's an FAQ or something I missed.)

Internal level is at about 60 plus many many fixes and backports.

You can check changes here:

Awesome, thanks.

Tekk: do you really need it to seeing as they are patch repos?

yes unfortunately

nsITobin: Strictly speaking I don't need to see the patches, but there's not much point in them being linked if I don't look at them ;)

I just loaded it up in another browser.

cause I been really thinking.. what is the overwhelming tragity of gitlab not working .. all the time .. in seamonkey while hosting on gitlab and heptapod.. and it is nothing that prevents using anything except the site's UX

sooo

annoying and unfortunate but also not as blocking as you may think

Because dogfooding is generally considered a good practice?

well yeah but that's a different issue.. beyond getting sm code

Yeah, my issue wasn't getting the code itself. I could've eyeballed a git checkout with that.

The purpose of the question was more to feel out whether it'd be worth opening issues about rendering problems. No point if SM is in pure maintenance mode aside from security patches, but if its Gecko is being worked on (which it apparently is) then there might be value in it.

Ther eis no pooint opening issues about rendering issues. We know what is missing and try to remedy it. I can file bugs all day and not get anything else done.

Gotcha

well as a matter of record SeaMonkey's release codebase is dirived originally from gecko/56 but for most intents and purposes especially xul wise its hovering around 60ish while web compat features are a bit of a different perspective.. you could safely say 60ish except for those things that were backported from well beyond 60..

Bugs for mail and news and internal things like bookmarking issue are a different issue but website compat is something we need to solve via backports.

"unfortunately" mail's always worked pretty well for me, jus tleaving the annoying backports.

just leaving*

Tekk: have to understand too seamonkey is in a bit of a final transition of being completely cut from any Mozilla dependancies so kinda inbetween bug trackers and wikis and yadda yadda .. I am trying to add what I can and organize and list other community provided pieces of infra and services.. Things that won't bust in seamonkey because it is FOR seamonkey.

Oh no, I completely understand that. I assume gitlab used to work completely fine before they broke it for no reason.

off and on I suspect

it WAS working last year some time I thought

I really wish I kept a list last time I tried using seamonkey as my main so that I could compare

Every few weeks they do updates which are even better than the old ones. Except for compatibility and general usage among other things....

Minor non-browser breakage: donating seems to be broken

When I click on the donate button it just sends me to the paypal fundraiser hub, which returns no search results for seamonkey

Tekk: don't forget we have even larger issues than forge front end sites.. stick around for the daily cf seige report from the tomman

papal now needs dynamic imports. But might also be country specfic.

Maybe? I've got a Canadian IP atm. I can look again on a US IP later.

Works for me in Germany.

I suspect the actual donation would fail with some web error after login.

Mystery partially solved. Clicking on the donate button takes you to that generic hub page. Clicking the "PayPal" link works

frg_Away: something is wrong with the central patches repo

Both work here but a stated might be country specific.

i was checking out a fresh copy seamonkey-central-patches

and

Resolving deltas: 100% (1342/1342), done.

error: invalid path 'mozilla-central/patches/9999999-allow-sandbox-null-dll-blocklist-suite.patch.'

fatal: unable to checkout working tree

warning: Clone succeeded, but checkout failed.

You can inspect what was checked out with 'git status'

and retry with 'git restore --source=HEAD :/'

unless it is bloody msys2

pretty sure this patch is gone and or renamed.

trying from gitbash real quick

Make sure you have a clean copiy without workign changes.

$ git restore --source=HEAD :/

error: invalid path 'mozilla-central/patches/9999999-allow-sandbox-null-dll-blocklist-suite.patch.'

gitbash

the repository is corrupt

it may be fixable and then can be forcepushed i expect.. but I don't know how to fix the git index

that patch gitlab.com/frg/seamonkey-central-pa…ocklist-suite.patch.?ref_type=heads

but i don't understand why it ends with a period

or why git can't deal with it

but this patch is required if you want to actually execute seamonkey.exe and not get an instacrash

and use mach run

checking tho it may be windows related

git config core.protectNTFS false

Might be me too dumb to do it right

no its git

Should not end with a point

well that shouldn't matter

and isn't the issue

issuing git config core.protectNTFS false fixed it.. need to do it globally

the number of settings I am having to set to retain clone and go git functionality is starting to grate on me

last time this happened to me it WAS a corrupt repo .. we are approching where security protections are harder to seperate from errors

If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem, e.g. conflict with 8.3 "short" names. Defaults to true on Windows, and false elsewhere.

the dot at the end is not compatible with 8.3 mangling i guess

so it failed

until I told it otherwise

technically your fault but I call it an error in expectation on git's side and lousy 8.3 mangling

because in windows that is still a valid filename

just not for dos compat

well.. wait now..

so on file system it shows the file without the dot so.. git has handling for these ... they want to remove it so they put a pref in to disable it by default

Fixed the repo

ok i am changing it to be you are correct they changed it to be less .. accomidating

VERIFIED FIXED

i wouldn't have noticed this if i kept using the tarballs

Not sure f I did it accidently or Bill but I usually don't mess with mozilla stuff.

i know earlier git would have handled it transparently

well i built firefox and thunderbird yesterday to see the state of things.. it's not great.. but I have an updated baseline.. see what suite is doing now that everything is all fresh and cloned

patches applied tho the nss entropy patch the target has changed .. will need refreshed eventually

in m-c

Hunk #1 succeeded at 29 with fuzz 1 (offset 0 lines).

wait my m-c checkout isn't updated cause bundle..

frg_Away: oldconfigure is almost empty and confvars is basically only capable of simple assignments now.. I am spot patching suite/moz.configure but it will need better cleanup

build kicked off finally

:)

set rust 1.82 as oldest configure would accept 4 cores and 16 gigs of ram.. see if it will overflow or not

6 cores but j4*

frg_Away: are we using thunderbird workspace hack .. i can't remember

nsITobin I think it was needed. Bill tried without. When I find the time need to make it work.

so this build is gonna fail.. that's ok .. I remember when he was bashing his head up against it some time ago

i also remember something about an improperly referenced mailnews component calling into mail.. but I think that was unrelated

well improper from OUR perspective

anyway

pgp maybe?

guess I will find out soon enough for sure

pgp

how can time be moving faster but the past feels further and further away when its been less than a year since I last messed with central

last month feels years away and next year will be here in a few weeks..

or am i just getting old..

rust 1.82 seems so far to be behaving its self ram wise

but yeah i couldn't stand to be on bare metal windows.. anymore without all my files and my direct line into the file system of my servers.. I am even MORE convinced that all Linux really lacks is an actual Windows Explorer level shell and management system.. no de or webpanel can replace what Windows has had for 30 damned years now without actually REPLACING it.. they all sidestep everything roundabout it sortof.. Windows 7 in a vm with samba

passing through sshfs just gives me EVERYTHING at the cost of the virtualization overhead

Client: HexChat 2.14.3 • OS: Rocky Linux release 8.10 (Green Obsidian) • CPU: AMD Ryzen 5 2600X Six-Core Processor (3.88GHz) • Memory: Physical: 30.5 GiB Total (27.5 GiB Free) Swap: 7.8 GiB Total (7.8 GiB Free) • Storage: 7.2 TB / 9.4 TB (2.2 TB Free) • VGA: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] @ Advanced Micro Devices, Inc. [AMD] Family 17h • Uptime: 5h 8m 0s

build succeeded guess it is set default on..

nsITobin There are a few others I would like to get rid off too. Persollay also trying to backport to 2.53 if possible. Lots of them already in 2.53.

I'll do the sm version of this to restore buildability but the build files need a real pass cleanup and conform to current comm "standard"

if for no other reason than to make applying changes simpler

I don't think it is taht bad. Mostly formatting e.g. single instead of double quotes because of not linting.

first things first.. solve this bustage following the bug and then try and hunt down bugs to bring inapproperate toolkit expectations on app code like specific language files or customizableui existing because devtools expects it.. that way fe is still totally broken but everything mozilla expects is there.

there is toolkit dtd removals requiring a mass patch to change the dir= attr value to hardcoded ltr i think that was global.dtd removal there is also another removal that needs a mass patch .. about related or .. something

I think the workaround patch was needed depending on the build time. comm central rust crates are not always in sync with central.

nn

rest well