[arch-general] PCYNLITX project and its innovations ( for multi-threading )
PCYNLITX platform offers completely new programming technology which can be named as Programmable Meta-Programming System and PCYNLITX platform is just a particular application of this new programming methodology. Basically, PCYNLITX is an intelligent integrated development environment ( IDE ) which can produce an application-specific multi-threading library based on your needs and assists you in multi-thread software development process. PCYNLITX is not a multi-threading library. Instead, it is a multi-threading library generator. You can find out very comprehensive documentation about pcynlitx project from both project web site and source code repository. The addresses of the project web page and source code repository are given in below links. www.pcynlitx.tech https://sourceforge.net/projects/pcynlitx The outcome of the PCYNLITX platform acts as an autonomous thread management system provides deterministic scheduling of the threads. You can control the thread with the numbers given by you and determine the relation of the threads. In other words, different from the other multi-threading tools, you can directly schedule the threads independently from the operating system. The scientific journal of the project is under review on IEEE Transactions on Software Engineering. Currently, the PCYNLITX platform only works on Linux based operating systems and the other versions ( Windows and McOSx ) are under development. The License of the PCYNLITX platform is GNU GPLv3 Free Software License. You can find out many other documents including scientific introduction of the project (“Technical Introduction” ), code examples and GUI tutorial form the project web sites. You can also find out a documents introducing std::thread programming, pthread programming and OpenMP programming on the web sites. Currently, ubuntu, debian and fedora distros are supported and arch linux version of the pcynlitx will be available soon. I am always waiting your valuable comments and contributions. Thanks and best regards. Erkam Murat Bozkurt M.Sc in Control Systems
Re: [arch-general] maria update to 10.4.6 breaks akonadi's db [solved]
The solution found at https://bbs.archlinux.org/viewtopic.php?id=184192 fixed 'em all. Tried tipp #1 (backup, restore, upgrade) on two machines, which worked impeccably, but resetted some settings of kmail to default. Tipp #2 (create db mysql, upgrade) on the 3rd machine was the easiest one and left akonadi usable in a sec. No more errors nor problems left; problem was the missing of db mysql/* inside ~/.local/share/akonadi/db_data/ On Friday, 28 June 2019, 10:12:36 CEST you wrote: > Little progress... > The man of mysql_upgrade states it: > > --datadir=path > Old option accepted for backward compatibility but ignored > > > So I did a fresh login and let akonadi/mariadb starts. I then stopped > akonadi and re-used it's socket: > # mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf -- > datadir=$HOME/.local/share/akonadi/db_data/ > --socket=/tmp/akonadi-XXX.n8sdoz/ mysql.socket > --pid-file=/tmp/akonadi-XXX.n8sdoz/mysql.pid > > I can connect to the mariadb instance now and let some commands fly, > according to https://mariadb.com/kb/en/library/mysql_upgrade/ : > > # mysqlcheck --no-defaults --check-upgrade --auto-repair --all-databases -- > socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > # mysqlcheck --no-defaults --all-databases --fix-db-names --fix-table-names > -- write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > # mysqlcheck --no-defaults --check-upgrade --all-databases --auto-repair -- > write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > The output is always > > > akonadi.collectionattributetable OK > > akonadi.collectionmimetyperelation OK > > akonadi.collectionpimitemrelation OK > > akonadi.collectiontableOK > > akonadi.flagtable OK > > akonadi.mimetypetable OK > > akonadi.parttable OK > > akonadi.parttypetable OK > > akonadi.pimitemflagrelationOK > > akonadi.pimitemtable OK > > akonadi.pimitemtagrelation OK > > akonadi.relationtable OK > > akonadi.relationtypetable OK > > akonadi.resourcetable OK > > akonadi.schemaversiontable OK > > akonadi.tagattributetable OK > > akonadi.tagremoteidresourcerelationtable OK > > akonadi.tagtable OK > > akonadi.tagtypetable OK > > But when ending this mariadb instance and restarting akonadi, the horror of > errors from post #1 starts all over again :( > > On Friday, 28 June 2019, 08:55:24 CEST you wrote: > > On Friday, 28 June 2019, 07:49:16 CEST you wrote: > > > On Fri, 28 Jun 2019, at 07:41, Oliver Jaksch via arch-general wrote: > > > > Updated three of my KDE clients by terminal (not logged in by display > > > > manager/DM) and ran > > > > > > > > # systemctl restart mariadb.service && mariadb-upgrade -u root > > > > -p > > > > > > This doesn't affect akonadi's data since it is located someplace else at > > > a > > > > > > non-system location: > > > /usr/bin/mysqld > > > --defaults-file=$HOME/.local/share/akonadi/mysql.conf > > > > > > --datadir=$HOME/.local/share/akonadi/db_data/ --s > > > ocket=/tmp/akonadi-xxx.LdhzVw/mysql.socket > > > --pid-file=/tmp/akonadi-xxx.LdhzVw/mysql.pids > > > > Yes, I know that, but I thought that akonadi would run a similar upgrade > > by > > itself when started and necessary. Wasn't that the case in the past? > > > > > I suggest you look into actually upgrading akonadi's DB first. For that, > > > you probably can pass --defaults-file and --datadir as-is to > > > mariadb-upgrade (and the upgrade should be executed as the user akonadi > > > is running as, not root). > > > > Thanks for that good starting point. But, alas, it gives me a > > # mysql_upgrade: the '--datadir' option is always ignored > > > > ...but this gives me hope for further investigations (=search engine). > > Will > > try and report; chances are good as it's friday and it's quiet today :)
Re: [arch-general] Mariadb Tables Still Compatible with Backup Server Running Earlier Version?
"David C. Rankin" on Thu, 2019/06/27 21:29:
> This is more a general question following the mariadb feature update to
> 10.4.6-1. Do the tables remain compatible with servers running earlier
> versions of mariadb?
You should not expect the binary format to be compatible.
> What happens if a backup from an earlier version has to be rolled into the
> new version?
That should work without problem. Just make sure to run mariadb-upgrade again.
> Or more importantly, can a backup from the new version be used to update
> servers running earlier versions of mariadb?
This should be handled with care. Most dumps should work - as long as you do
not use features not available in earlier versions.
You should *not* restore the mysql schema into an older server.
> (I have the same database running on Arch with backup handled by openSuSE,
> still running 10.0.35)
Hmm... Wondering what this means. You run mysqldump from an openSuSE system
or is the older mariadb server involved?
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgp5GHig8yto6.pgp
Description: OpenPGP digital signature
Re: [arch-general] Maria update
Am 28.06.19 um 11:49 schrieb Christian Hesse: > mick howe via arch-general on Fri, 2019/06/28 > 01:37: >> Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' >> in the MariaDB Servers datadir, errno: 13 > > What's the permission of /var/lib/mysql directory? I guess these were borked > before without being noticed. My systems have 0700 with mysql:mysql. > That is normal if you run mariadb-upgrade as an unprivileged user. It will work if you execute it as root or the mysql user. Your database has been upgraded successfully, but the logfile has not been written. You can ignore the error if you don't need the logfile.
Re: [arch-general] Maria update
mick howe via arch-general on Fri, 2019/06/28
01:37:
> Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info'
> in the MariaDB Servers datadir, errno: 13
What's the permission of /var/lib/mysql directory? I guess these were borked
before without being noticed. My systems have 0700 with mysql:mysql.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgp54SrhRghLU.pgp
Description: OpenPGP digital signature
Re: [arch-general] maria update to 10.4.6 breaks akonadi's db
Little progress... The man of mysql_upgrade states it: --datadir=path Old option accepted for backward compatibility but ignored So I did a fresh login and let akonadi/mariadb starts. I then stopped akonadi and re-used it's socket: # mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf -- datadir=$HOME/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-XXX.n8sdoz/ mysql.socket --pid-file=/tmp/akonadi-XXX.n8sdoz/mysql.pid I can connect to the mariadb instance now and let some commands fly, according to https://mariadb.com/kb/en/library/mysql_upgrade/ : # mysqlcheck --no-defaults --check-upgrade --auto-repair --all-databases -- socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket # mysqlcheck --no-defaults --all-databases --fix-db-names --fix-table-names -- write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket # mysqlcheck --no-defaults --check-upgrade --all-databases --auto-repair -- write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket The output is always > akonadi.collectionattributetable OK > akonadi.collectionmimetyperelation OK > akonadi.collectionpimitemrelation OK > akonadi.collectiontableOK > akonadi.flagtable OK > akonadi.mimetypetable OK > akonadi.parttable OK > akonadi.parttypetable OK > akonadi.pimitemflagrelationOK > akonadi.pimitemtable OK > akonadi.pimitemtagrelation OK > akonadi.relationtable OK > akonadi.relationtypetable OK > akonadi.resourcetable OK > akonadi.schemaversiontable OK > akonadi.tagattributetable OK > akonadi.tagremoteidresourcerelationtable OK > akonadi.tagtable OK > akonadi.tagtypetable OK But when ending this mariadb instance and restarting akonadi, the horror of errors from post #1 starts all over again :( On Friday, 28 June 2019, 08:55:24 CEST you wrote: > On Friday, 28 June 2019, 07:49:16 CEST you wrote: > > On Fri, 28 Jun 2019, at 07:41, Oliver Jaksch via arch-general wrote: > > > Updated three of my KDE clients by terminal (not logged in by display > > > manager/DM) and ran > > > > > > # systemctl restart mariadb.service && mariadb-upgrade -u root > > > -p > > > > This doesn't affect akonadi's data since it is located someplace else at a > > > > non-system location: > > /usr/bin/mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf > > > > --datadir=$HOME/.local/share/akonadi/db_data/ --s > > ocket=/tmp/akonadi-xxx.LdhzVw/mysql.socket > > --pid-file=/tmp/akonadi-xxx.LdhzVw/mysql.pids > > Yes, I know that, but I thought that akonadi would run a similar upgrade by > itself when started and necessary. Wasn't that the case in the past? > > > I suggest you look into actually upgrading akonadi's DB first. For that, > > you probably can pass --defaults-file and --datadir as-is to > > mariadb-upgrade (and the upgrade should be executed as the user akonadi > > is running as, not root). > > Thanks for that good starting point. But, alas, it gives me a > # mysql_upgrade: the '--datadir' option is always ignored > > ...but this gives me hope for further investigations (=search engine). Will > try and report; chances are good as it's friday and it's quiet today :)
