We have a problem. All the PHP software, including the old MediaWiki, is so old that it's still using numerous deprecated functions such as the old mysql_*() functions that have been removed from PHP in 2015.
I'll proceed with importing the converted data into MariaDB, but existing software won't function unless we get a dead pre-7.0 version of PHP running (for things like Software Index), or upgrade.third party software (such as MediaWiki). On Sun, Sep 4, 2022 at 7:39 PM Ivan Vučica <i...@vucica.net> wrote: > > I got all 4 .sql files to load on my local MariaDB. > > Continuing tomorrow. > > On Sun, Sep 4, 2022 at 7:17 PM Ivan Vučica <i...@vucica.net> wrote: > > > > I'm doing the barest minimum of the changes. If the original machine > > had MyISAM, I'm using MyISAM. If the installed software was using > > MyISAM, I don't want to find out the hard way that the schemas were > > mis-defined (given that MyISAM has, particularly back in that era, > > been much more liberal with basic concepts such as foreign keys). > > > > I want to minimize the amount of fronts I have to fight MySQL on. I'm > > even thinking of dropping down to latin1 and figuring out what to do > > later. > > > > I would not choose to start with MyISAM (and where possible I'd also > > use Postgres rather than MySQL/MariaDB). > > > > > > > > On Sun, Sep 4, 2022 at 7:13 PM Andreas Fink <af...@list.fink.org> wrote: > > > > > > why you dont use innodb as engine? much less troubles in case of crashes > > > and reboots > > > > > > > > > > > > On Sonntag, Sept. 04, 2022 at 8:02 PM, Ivan Vučica <i...@vucica.net> > > > wrote: > > > Update: > > > - I added wiki.gnustep.org to DNS as well -- it was an omission not to > > > add it. Please REFRAIN FROM EDITS until further notice as YOUR EDITS > > > WILL NOT BE MIGRATED. > > > - I am still fighting MySQL/MariaDB: > > > - the previous server has an unknown default character set/collation > > > (latin1 and not utf8, likely, as I managed to import _gsweb with it) > > > - aside from timezone precision of "14" not meaning what the authors > > > of schemas meant, it's also deprecated (this was the quickest of the > > > fixes, just replace timestamp(14) with new maximum timestamp(6) > > > - second fastest fix was TYPE=MyISAM changing into ENGINE=MyISAM > > > - the previous server has an unknown timezone configured, and even > > > worse, it is unclear what timezone the dates in the dump are in > > > - specifically, some of the dates are failing to be inserted as > > > they appear to be happening during nonexistent hours during March > > > timezone switches > > > - entertaining thing: varchar(255) is fine as primary key fitting > > > inside MyISAM's 1000 bytes maximum .... as long as utf8mb4 is not the > > > character set in use > > > - 4 * 255 = 1020 > > > - even though I suspect the old default was latin1, I am using > > > utf8 which still fits inside 1000 bytes > > > > > > Now, after a few hours of fighting this, I've only completed the first > > > out of five databases (gnustep_gsweb.sql, which might not even be in > > > use). > > > > > > The next one, gnustep_mediawiki, is already being painful. > > > > > > I am unlikely to be done today. > > > > > > On Tue, Aug 30, 2022 at 10:59 PM Marco Cawthorne <ma...@icculus.org> > > > wrote: > > > > > > > > > On 2022-08-30 14:28:54 -0700 Ivan Vučica <i...@vucica.net> wrote: > > > > > > I've spent some time today on playing with Ansible thinking it may be > > > better to do it sooner rather than later. I'll leave that aside for > > > now. > > > > > > By the time I got to look at restoring MySQL databases, it simply got > > > late. Turns out that the database dumps need to be manually fixed > > > before they can be imported: schemas have changed between the version > > > on the old server and MariaDB 10.x that I have on the new one. It > > > should be relatively easy, if possibly labor intensive. > > > > > > I'll leave it for tomorrow. > > > > > > > > > Thank you for all the work you do and for keeping us updated. > > > And thanks to Gregory for the quick redirects. At last we can browse most > > > of the documentation again. > > > > > > Marco Cawthorne > > > > > >