I've been talking to flo who's the maintainer of the percona database software amongst others, he told me to create a PR to get this port committed as he didn't have time. Fix: Attaching finished port Who ever commits this needs to add conflicts for percona[0-9][0-9]-xtradb-cluster* to these ports: databases/mysql55-server databases/mysql56-server databases/mariadb-server databases/mariadb55-server Patch attached with submission follows:
Class Changed From-To: update->change-request Fix category (new ports should be change-requests) (via the GNATS Auto Assign Tool)
Seems to need this in my make.conf, that was ports-mgmt/poudriere is happy to make packages for it: WITH_MYSQL_VER=56p Otherwise databases/p5-DBD-mysql defaults to depending on databases/mysql55-client and that conflicts with the archive's WANT_MYSQL_VER= 56p. Cheers
Hi! Thanks. However the software works fine with the mysql55-client if it were to already be installed. How do i specify the makefile to install the 56p-client if no other mysql client exists? Best regards Daniel John Ko skrev 2014-05-06 05:37: > Seems to need this in my make.conf, that was ports-mgmt/poudriere is > happy to make packages for it: > > WITH_MYSQL_VER=56p > > Otherwise databases/p5-DBD-mysql defaults to depending on > databases/mysql55-client and that conflicts with the archive's > WANT_MYSQL_VER= 56p. > > Cheers
Not sure... I think you have it right?? It's when I use poudriere to automat= e package building that it conflicts because p5-DBD-mysql depends by default= on mysql55-client and poudriere builds each separately in a clean jail. As I suggested, the easy workaround was to tell poudriere to use the percona= client for building p5-DBD-mysql. in a poudriere jail's make.conf: WITH_MYSQL_VER=3D56p I should note, after packaging and installing, I have trouble running it wit= h wsrep (replication) on. Might be a databases/galera issue which I'll try rebuilding with debug on. Any tips on getting a cluster running? Thanks! -- John _ On May 11, 2014, at 5:49, Daniel Ylitalo <daniel@blodan.se> wrote: Hi! Thanks. However the software works fine with the mysql55-client if it were to alread= y be installed. How do i specify the makefile to install the 56p-client if no other mysql cl= ient exists? Best regards Daniel John Ko skrev 2014-05-06 05:37: > Seems to need this in my make.conf, that was ports-mgmt/poudriere is happy= to make packages for it: >=20 > WITH_MYSQL_VER=3D56p >=20 > Otherwise databases/p5-DBD-mysql defaults to depending on databases/mysql5= 5-client and that conflicts with the archive's WANT_MYSQL_VER=3D 56p. >=20 > Cheers
How does your my.cnf config look like? You should be getting the wsrep error in the mysql error log // Daniel John Ko skrev 2014-05-11 12:14: > Not sure... I think you have it right?? It's when I use poudriere to automate package building that it conflicts because p5-DBD-mysql depends by default on mysql55-client and poudriere builds each separately in a clean jail. > > As I suggested, the easy workaround was to tell poudriere to use the percona client for building p5-DBD-mysql. > in a poudriere jail's make.conf: > WITH_MYSQL_VER=56p > > > > I should note, after packaging and installing, I have trouble running it with wsrep (replication) on. > Might be a databases/galera issue which I'll try rebuilding with debug on. > > Any tips on getting a cluster running? > > Thanks! > -- > John > _ > > On May 11, 2014, at 5:49, Daniel Ylitalo <daniel@blodan.se> wrote: > > Hi! > > Thanks. > > However the software works fine with the mysql55-client if it were to already be installed. > > How do i specify the makefile to install the 56p-client if no other mysql client exists? > > Best regards > Daniel > > John Ko skrev 2014-05-06 05:37: >> Seems to need this in my make.conf, that was ports-mgmt/poudriere is happy to make packages for it: >> >> WITH_MYSQL_VER=56p >> >> Otherwise databases/p5-DBD-mysql defaults to depending on databases/mysql55-client and that conflicts with the archive's WANT_MYSQL_VER= 56p. >> >> Cheers
Note that you have to set a root password on the initial note before you can join a new node. (And the password needs to be set in the my.cnf wsrep_sst_auth="" param Ie: wsrep_sst_auth="root:asdasd123" // Daniel Daniel Ylitalo skrev 2014-05-11 12:17: > How does your my.cnf config look like? > > You should be getting the wsrep error in the mysql error log > > // Daniel > > > John Ko skrev 2014-05-11 12:14: >> Not sure... I think you have it right?? It's when I use poudriere to >> automate package building that it conflicts because p5-DBD-mysql >> depends by default on mysql55-client and poudriere builds each >> separately in a clean jail. >> >> As I suggested, the easy workaround was to tell poudriere to use the >> percona client for building p5-DBD-mysql. >> in a poudriere jail's make.conf: >> WITH_MYSQL_VER=56p >> >> >> >> I should note, after packaging and installing, I have trouble running >> it with wsrep (replication) on. >> Might be a databases/galera issue which I'll try rebuilding with >> debug on. >> >> Any tips on getting a cluster running? >> >> Thanks! >> -- >> John >> _ >> >> On May 11, 2014, at 5:49, Daniel Ylitalo <daniel@blodan.se> wrote: >> >> Hi! >> >> Thanks. >> >> However the software works fine with the mysql55-client if it were to >> already be installed. >> >> How do i specify the makefile to install the 56p-client if no other >> mysql client exists? >> >> Best regards >> Daniel >> >> John Ko skrev 2014-05-06 05:37: >>> Seems to need this in my make.conf, that was ports-mgmt/poudriere is >>> happy to make packages for it: >>> >>> WITH_MYSQL_VER=56p >>> >>> Otherwise databases/p5-DBD-mysql defaults to depending on >>> databases/mysql55-client and that conflicts with the archive's >>> WANT_MYSQL_VER= 56p. >>> >>> Cheers >
Looks like I can't even boot up the first node: More in my gist here: https://gist.github.com/johnko/f22c87931e31246598eb # grep mysql /etc/rc.conf mysql_limits="YES" mysql_dbdir="/server/mysql/data" mysql_optfile="/server/mysql/my.cnf" mysql_enable="YES" mysql_args="" ##### # cat /server/mysql/my.cnf [mysqld] datadir = /server/mysql/data tmpdir = /server/mysql/tmp log-error = /var/log/mysql-error.log slow-query-log-file = /var/log/mysql-slow.log port = 3306 innodb_autoinc_lock_mode = 2 wsrep_sst_method = xtrabackup-v2 wsrep_provider = /usr/local/lib/libgalera_smm.so wsrep_provider_options = "gmcast.listen_addr=tcp://127.0.0.1:4567" wsrep_cluster_name = mycluster wsrep_node_name = NXQCSO-NXQCSO wsrep_node_address = 127.0.0.1 wsrep_slave_threads = 8 wsrep_sst_auth = "sst:25awfaSADF4toih4t" server-id = 1 wsrep_cluster_address=gcomm://
Oops just found out my umask was 077... which means my /server/mysql/data didn't let galera write to it it appears to work now: # pgrep -lf mysql 64880 /usr/local/libexec/mysqld --defaults-extra-file=/server/mysql/my.cnf --basedir=/usr/local --datadir=/server/mysql/data --plugin-dir=/usr/local/lib/mysql/plugin --user=mysql --log-error=/server/mysql/data/NXQCSO-NXQCSO.err --pid-file=/server/mysql/data/NXQCSO-NXQCSO.pid --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1 64249 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/server/mysql/my.cnf --user=mysql --datadir=/server/mysql/data --pid-file=/server/mysql/data/NXQCSO-NXQCSO.pid -- John _ On Sun, May 25, 2014 at 8:50 PM, John Ko <john@johnko.ca> wrote: > Looks like I can't even boot up the first node: > > More in my gist here: > https://gist.github.com/johnko/f22c87931e31246598eb > > # grep mysql /etc/rc.conf > mysql_limits="YES" > mysql_dbdir="/server/mysql/data" > mysql_optfile="/server/mysql/my.cnf" > mysql_enable="YES" > mysql_args="" > > ##### > > # cat /server/mysql/my.cnf > [mysqld] > datadir = /server/mysql/data > tmpdir = /server/mysql/tmp > log-error = /var/log/mysql-error.log > slow-query-log-file = /var/log/mysql-slow.log > port = 3306 > innodb_autoinc_lock_mode = 2 > wsrep_sst_method = xtrabackup-v2 > wsrep_provider = /usr/local/lib/libgalera_smm.so > wsrep_provider_options = "gmcast.listen_addr=tcp://127.0.0.1:4567" > wsrep_cluster_name = mycluster > wsrep_node_name = NXQCSO-NXQCSO > wsrep_node_address = 127.0.0.1 > wsrep_slave_threads = 8 > wsrep_sst_auth = "sst:25awfaSADF4toih4t" > server-id = 1 > wsrep_cluster_address=gcomm:// > > >
I honestly had a hard time following what was going on here (maybe the conversion to bugzilla is partly to blame) but it seems like there's no more problem. If I misunderstood, feel free to reopen the PR.
ah, wait, this is a new port submission. See form letter then (below): ================== Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs 3) at least this: https://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks!
I'm fed up with trying to get this port through, the original phar is already staged and works fine in poudriere. If you dont want it in ports then just feel free to close this ticket, I cba to care anymore as waiting 3 months for a reply stating something that the port already is compatible with is just sad.
(In reply to daniel from comment #11) > I'm fed up with trying to get this port through, the original phar is > already staged and works fine in poudriere. How can I believe that without seeing an actual testport log. More than 50% of the submitted ports fail when subjected to it. > If you dont want it in ports then just feel free to close this ticket, I cba > to care anymore as waiting 3 months for a reply stating something that the > port already is compatible with is just sad. I won't hesitate to do this. As the only person walking through 1650 PRs that I know of trying to get bugzilla into shape, I jump at the chance to close a ticket. I won't lose a second of sleep. I had nothing to do with previous absence of replies. Your call: you prove log or you tell me to close PR definitely.
(In reply to John Marino from comment #12) > Your call: you prove log or you tell me to close PR definitely. grr, typo: you _provide_ log ...
Created attachment 145851 [details] Update to latest release w/minor fixes Latest stable release requires some minor tweaks to a few of the patches. Minor mod to the plist file for directory removal.
Created attachment 145852 [details] Poudriere testport output Output of `poudriere testport` for the recently attached .shar.
Scott, this looks real good. I have only two concerns. 1) on this line: Xpost-install: X @${MKDIR} ${STAGEDIR}/var/db/mysql X @${RM} -rf ${STAGEDIR}${PREFIX}/xinetd.d The "@" on the RM command masks the file removal. It is against policy to mask installation steps (with mkdir being the exception so the first line is ok) 2) you have "flo@freebsd.org" being listed as the maintainer. This is unusual. Did flo agree to this? I see on the description "I've been talking to flo who's the maintainer of the percona database software amongst others, he told me to create a PR to get this port committed as he didn't have time." That doesn't mean he agreed to maintain the port. So either somebody else needs to be listed as the maintainer, or flo needs to explicitly approve this PR and agree to the maintainer. Do you want me add him to the PR or should somebody else be the maintainer?
A good chunk of this port came from the originally posted .shar and I was just making the necessary mods to get the current stable release to patch and build correctly, and pass Poudriere's testport process. As I can't recall ever personally seeing xinetd in use on my FBSD servers over the past.. too many years, that line may just need to be dropped. The plist as it is, is 99% makeplist. With the maintainer assignment, that also came from the original .shar. Making an ass out of you and me, with it not being previously mentioned as a problem I assumed it was fine. I'll define it to be whatever makes people happy.
(In reply to Scott Larson from comment #17) > A good chunk of this port came from the originally posted .shar and I was > just making the necessary mods to get the current stable release to patch > and build correctly, and pass Poudriere's testport process. That's strange, I could sworn I heard "original phar is already staged and works fine in poudriere." :) > As I can't > recall ever personally seeing xinetd in use on my FBSD servers over the > past.. too many years, that line may just need to be dropped. The issue is the command is masked, meaning we have to remove the "@" symbol, that's all. > The plist as it is, is 99% makeplist. > With the maintainer assignment, that also came from the original .shar. > Making an ass out of you and me, with it not being previously mentioned as a > problem I assumed it was fine. I'll define it to be whatever makes people > happy. I see you have three choices: 1) Put yourself there 2) Daniel realizes that in fact his port needed more work and that you just did him a big favor, and agrees to be the maintainer. 3) You add flo in the CC and ask if he will maintain it. I think you'd have a 50/50% chance of success with that. It doesn't hurt to ask. Those options are listed in order of speed to get this PR to "patch-ready" status.
I was planning on doing a update once the initial port was commited. I didn't see any point in doing it yet as this wasn't the case. Thanks for doing that Scott. I'm a heavy user of the software so I'd be willing to maintain it. If Scott feels like doing it though, I'm good with that. I have not confirmed that flo wants to be the maintainer so thats off the table I guess.
I'll move it to patch ready based on either Scott or Daniel will be maintainer, but we need to have a definitive answer by the time this is committed.
actually decide quickly because this is the second oldest patch-ready PR now which means it's near the top of the list (some of us try to take the PRs waiting the longest first)
As Scott seems to be away put me as maintainer and if he wants to take it at a later point I'll just create a new PR.
okay, daniel is the maintainer until further notice.
I took the shar and made a few corrections including cosmetic stuff. It did build, but it failed the run-depends stage: ====>> Checking for filesystem violations... done =======================<phase: run-depends >============================ ===> percona56-XtraDB-Cluster-5.6.19.67.0 depends on file: /usr/local/bin/soca t - not found ===> Verifying install for /usr/local/bin/socat in /usr/ports/net/socat ===> Installing existing package /packages/All/socat-1.7.2.4.txz [Release100-default-job-01] Installing socat-1.7.2.4... done ===> Returning to build of percona56-XtraDB-Cluster-5.6.19.67.0 ===> percona56-XtraDB-Cluster-5.6.19.67.0 depends on file: /usr/local/lib/libg alera_smm.so - not found ===> Verifying install for /usr/local/lib/libgalera_smm.so in /usr/ports/data bases/galera ===> Installing existing package /packages/All/galera-25.3.5_1.txz [Release100-default-job-01] Installing icu-53.1... done [Release100-default-job-01] Installing icu-53.1... done [Release100-default-job-01] Installing icu-53.1... done [Release100-default-job-01] Installing icu-53.1... done Message for boost-libs-1.55.0_3: You have built the Boost library with thread support. Don't forget to add -pthread to your linker options when linking your code. ===> Returning to build of percona56-XtraDB-Cluster-5.6.19.67.0 ===> percona56-XtraDB-Cluster-5.6.19.67.0 depends on file: /usr/local/bin/innobackupex - not found ===> Verifying install for /usr/local/bin/innobackupex in /usr/ports/databases/xtrabackup ===> Installing existing package /packages/All/xtrabackup-2.1.7_1.txz [Release100-default-job-01] Installing libgpg-error-1.13_1... done [Release100-default-job-01] Installing libgpg-error-1.13_1... done pkg-static: mysql55-client-5.5.39 conflicts with percona56-client-5.6.19.67.0 (installs files into the same place). Problematic file: /usr/local/bin/msql2mysql Failed to install the following 1 package(s): /packages/All/xtrabackup-2.1.7_1.txz *** Error code 70 Stop. make: stopped in /usr/ports/databases/percona56-xtradb-cluster ===> Cleaning for percona56-XtraDB-Cluster-5.6.19.67.0 build of /usr/ports/databases/percona56-xtradb-cluster ended at Tue Aug 19 00:09:37 CEST 2014 build time: 00:04:33 Any idea what's pulling in both mysql and percona clients ?
I think it's this MYSQL_ONLY line. Another thing, I see a run depends on gcc47, that is sending up red flags EVERYWHERE. What's going on with that and why not have "USE_GCC=yes" if gcc is required?
Scott's log shows mysql-client wasn't added as run time dependency.
Looking through the port I submitted I don't see a MYSQL_ONLY definition, and running the test on my package build server it doesn't attempt a conflicting install. Further down in the Makefile it has WANT_MYSQL_VER defined as 56p. At least in my case it pulls in the correct percona56 client. As for the GCC bits, that likely doesn't need to be there at all. My schedule is slammed until Friday but I can comb through this thing to do more cleanup.
(In reply to Scott Larson from comment #27) > Looking through the port I submitted I don't see a MYSQL_ONLY definition, > and running the test on my package build server it doesn't attempt a > conflicting install. Further down in the Makefile it has WANT_MYSQL_VER > defined as 56p. At least in my case it pulls in the correct percona56 > client. As for the GCC bits, that likely doesn't need to be there at all. My > schedule is slammed until Friday but I can comb through this thing to do > more cleanup. This is what I am talking about: X# MySQL-Server part X.if !defined(CLIENT_ONLY) XUSE_MYSQL= yes XWANT_MYSQL_VER= 56p X XCONFLICTS_INSTALL= mysql[0-9][0-9]-server-* mariadb[0-9][0-9]-server-* percona5.[0-57-9]-server-* percona[0-46-9][0-9]-server-* X XUSE_RC_SUBR= mysql-server I meand "CLIENT_ONLY". That pulls in mysql. How come you aren't seeing it?
I'm going to give it a look when I get home from work today, we seem to be in different timezones :) What I can figure, if USE_MYSQL is specified with WANT_MYSQL_VER=56p it should only try to pull the percona 56 client, shouldnt it? Or have I completly misunderstood the meaning of those options?
Hmm, I'm not able to reproduce the mysql client conflict, it installs the percona client fine. The run dependency on gcc needs to be there because libgalera needs some gcc libs to work properly. If you check files/mysql-server.in you'll see that the library path is appended with the gcc libs (line 51)
(In reply to daniel from comment #30) > Hmm, I'm not able to reproduce the mysql client conflict, it installs the > percona client fine. I take it, then, that you are not testing with poudriere? > The run dependency on gcc needs to be there because libgalera needs some gcc > libs to work properly. devel/galera has a RUN_DEPENDS on gcc47 so I don't think you need it. galera pulls it in when galera is pulled in
wait, you have a poudriere log so you must be using it.
let's try a different tact. Since that section is pulling mysql, why not just delete the section? Either it's needed or it's not.
(In reply to John Marino from comment #28) > This is what I am talking about: > > X# MySQL-Server part > X.if !defined(CLIENT_ONLY) > XUSE_MYSQL= yes > XWANT_MYSQL_VER= 56p > X > XCONFLICTS_INSTALL= mysql[0-9][0-9]-server-* mariadb[0-9][0-9]-server-* > percona5.[0-57-9]-server-* percona[0-46-9][0-9]-server-* > X > XUSE_RC_SUBR= mysql-server > > > I meand "CLIENT_ONLY". That pulls in mysql. How come you aren't seeing it? In my Poudriere environment I've got DEFAULT_VERSIONS=mysql=56p defined in the global make options which is probably why I don't see the conflict. However looking through the bsd.database.mk file it seems like the WANT_MYSQL_VER=56p in the port Makefile should ensure it attempts to use the Percona port.
(In reply to Scott Larson from comment #34) > In my Poudriere environment I've got DEFAULT_VERSIONS=mysql=56p defined in > the global make options which is probably why I don't see the conflict. That also renders your poudriere logs invalid. > However looking through the bsd.database.mk file it seems like the > WANT_MYSQL_VER=56p in the port Makefile should ensure it attempts to use the > Percona port. Then a dependency must have pulled it in. Not sure. you should create a new jail in your poudriere, one that has no custom make.conf and build this in that jail. Then you should be able to see this. I would be very surprised if you can't reproduce this in a stock jail.
any updates here?
Sorry, havent had time this weekend. I'll sort the mysql client issue out the upcoming week. I know I'm off work thursday/friday. One can't administer the cluster without a mysql client so it really needs to be there just as with a regular mysql-server.
I've sorted things out and now know why things happened the way they were. The thing is as follows; 1. This port depends on a mysql 5.6 client (preferable perconas) 2. This port depends on databases/xtrabackup which in turn depends on p5-DBD-mysql which pulls mysql with USE_MYSQL=yes 3. p5-DBD-mysql does not request any special version and works fine with 5.5 and 5.6 In a production environment this would not conflict because; 1. This port installs the 5.6 client 2. When we then try to install the dependendies, p5-DBD-mysql checks if there already is a mysql client installed, (yes, we just installed the 5.6 client) and uses that and would not have tried to install the 5.5 default client Poudriere fails to see the connection between the 5.6 client already being installed before runnig p5-DBD-mysql Anyhow, to get rid of the problem I've added an option to install the Percona 5.6 client which is not default so everyone should be happy. There is also another problem, the latest version does unfortunately not run. So I have to figure out what has been changed since my first shar. At the moment I dont know if its in libgalera or in xtradb cluster
The issue is that databases/galera is built with net/asio instead of gcc in FreeBSD >= 10 and therefor makes Percona XtraDB Cluster fail. So I guess we can throw this port in the trash for now :\ I'm attaching my final shar if anyone wants to have a go at it. It works fine if you go to databases/galera and comment out the stuff that makes it use net/asio instead of gcc and then recompile and try to start xtradb-cluster again.
Created attachment 146617 [details] Final working shar (if you modify databases/galera)
Created attachment 146618 [details] Poudriere testport log for Final working shar
I'm sorry that the final problem is out of your control to fix. I'll mark this port "OBE"