Spec URL: http://home.online.no/~bjornmu/fedora/mysql-community.spec SRPM URL: http://home.online.no/~bjornmu/fedora/mysql-community-5.6.11-1.fc19.src.rpm Description: This is a re-review request for a package rename as described at http://fedoraproject.org/wiki/Package_Renaming_Process. The package has been renamed before from mysql -> MySQL -> community-mysql. Here is review request for a third rename "back" to the more proper name mysql-community. See related review requests: #917740 and #924345. There are several reasons for this renaming: a) mysql-community is the upstream name: https://dev.mysql.com/downloads/mysql/ b) Fedora Package Guidelines says: "When naming a package, the name should match the upstream tarball or project name from which this software came." Ref: https://fedoraproject.org/wiki/Packaging:NamingGuidelines c) openSUSE is using this name. d) Less confusion among users regarding renaming. e) There are no techical reasons to call the package community-mysql (with epoch added to MariaDB). This review also updates the package to latest stable release MySQL Community Server 5.6.11, released on April 18. I have done a scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5317300 MySQL is a multi-user, multi-threaded SQL database server. MySQL is a client/server implementation consisting of a server daemon (mysqld) and many different client programs and libraries. The base package contains the standard MySQL client programs and generic MySQL files. Fedora Account System Username: bjornmu
One initial comment, I see no Obsoletes (or Provides) in place to handle naming transition from community-mysql to mysql-community See also: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
(In reply to comment #1) > One initial comment, I see no > > Obsoletes (or Provides) in place to handle naming transition from > community-mysql > to > mysql-community We could add that, but community-mysql has only ever been in rawhide/alpha. Also, that package did not obsolete the previous name MySQL. What it sort-of obsoletes is the mysql packages in F18 but that's done by MariaDB.
Updated package available here: http://home.online.no/~bjornmu/fedora/mysql-community-5.6.11-2.fc19.src.rpm Spec file here as before: http://home.online.no/~bjornmu/fedora/mysql-community.spec Changes: - Drop mysql-devel and mysql-embedded-devel provides for now - Add obsolets and provides for easy upgrade - Add patch to fix some gcc 4.8 warnings New koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5324424
New updated package: http://home.online.no/~bjornmu/fedora/mysql-community-5.6.12-1.fc19.src.rpm Spec file here as before: http://home.online.no/~bjornmu/fedora/mysql-community.spec Changes: - Upgraded to 5.6.12 which was released last week. - Removed patches errno and editline which have been fixed. - Added patch mysql-5.6.12-openfile-test.patch which skips some tests that fail if openfiles limit < 4161. New koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5498457
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable Issues: ======= - There are some parts of innodb code under BSD: plugin/innodb_memcached/daemon_memcached/daemon/daemon.c so I believe BSD should be included in the spec file. Then BSD license file should be included in the packages as well - /usr/share, /usr/libexec, /usr/include should use macros - It does, but it is expected. It will allways conflicts with MariaDB or community-mysql packages. - Having package with mysql in the beginning means yum will prioritize it before mariadb in case we require mysql as a virtual provide, because mysql-community has a common prefix with mysql virtual name. http://yum.baseurl.org/wiki/CompareProviders The discussion took place here: https://lists.fedoraproject.org/pipermail/devel/2013-April/181220.html https://lists.fedoraproject.org/pipermail/devel/2013-May/182132.html It means that by installing packages requiring "mysql" (currently at least mysqludf_xql and mysqltuner) will install mysql-community instead of mariadb if none has been installed before. For me personally, this is a problem that shouldn't be just omitted. It should be consulted widely on Fedora devel-list to find out if we are ok with such behaviour and just document it or we will rather stick with community-mysql name of the package.. - I believe that conditioned Preset macros are not needed any more: -%if 0%{?systemd_post:1} -%systemd_post mysqld.service -%else -if [ $1 = 1 ]; then - # Initial installation - /bin/systemctl daemon-reload >/dev/null 2>&1 || : -fi -%endif +%systemd_post mysqld.service - install and cp commands could include -p argument - package installs /lib/tmpfiles.d/mysql.conf but it should install /lib/tmpfiles.d/%{name}.conf ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package requires other packages for directories it uses. [x]: Package uses nothing in %doc for runtime. [x]: Package is not known to require ExcludeArch. [x]: Fully versioned dependency in subpackages, if present. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in mysql- community-libs , mysql-community-common , mysql-community-server , mysql- community-embedded , mysql-community-embedded-devel [x]: Package complies to the Packaging Guidelines [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "BSD (4 clause) ISC", "LGPL (v2)", "BSD (2 clause) GPL (v2)", "GPL (v2) (with incorrect FSF address)", "GPL (v3 or later)", "Unknown or generated", "BSD (4 clause)", "GPL", "zlib/libpng GPL (v2)", "GPL (v2 or later)", "zlib/libpng", "ISC", "BSD (3 clause) GPL (v2)", "BSD (3 clause)", "BSD (2 clause)", "GPL (v2)", "Public domain GPL (v2)". 1081 files have unknown license. Detailed output of licensecheck in /home/hhorak/Downloads/mysql56review/review-mysql- community/licensecheck.txt - There are some parts of innodb code under BSD: plugin/innodb_memcached/daemon_memcached/daemon/daemon.c so I believe BSD should be included in the spec file. Then BSD license file should be included in the packages as well [x]: License file installed when any subpackage combination is installed. [!]: Package consistently uses macro is (instead of hard-coded directory names). - /usr/share, /usr/libexec, /usr/include should use macros [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. - It does, but it is expected. It will allways conflicts with MariaDB or community-mysql packages. [x]: Package obeys FHS, except libexecdir and /usr/target. [x]: If the package is a rename of another package, proper Obsoletes and Provides are present. - Seems to comply Renaming guidelines with http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [x]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Large documentation must go in a -doc subpackage. Note: Documentation size is 245760 bytes in 25 files. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: %config files are marked noreplace or the reason is justified. [x]: Each %files section contains %defattr if rpm < 4.4 [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: No %config files under /usr. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). Java: [x]: Bundled jar/class files should be removed before build Maven: [-]: If package contains pom.xml files install it (including depmaps) even when building with ant [x]: Old add_to_maven_depmap macro is not being used Perl: [x]: Package contains the mandatory BuildRequires and Requires:. Note: Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) missing? Python: [-]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [-]: Package meets the Packaging Guidelines::Python [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [x]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [!]: Final provides and requires are sane (see attachments). - Having package with mysql in the beginning means yum will prioritize it before mariadb in case we require mysql as a virtual provide, because mysql-community has a common prefix with mysql virtual name. http://yum.baseurl.org/wiki/CompareProviders The discussion took place here: https://lists.fedoraproject.org/pipermail/devel/2013-April/181220.html https://lists.fedoraproject.org/pipermail/devel/2013-May/182132.html It means that by installing packages requiring "mysql" (currently at least mysqludf_xql and mysqltuner) will install mysql-community instead of mariadb if none has been installed before. [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [!]: Scriptlets must be sane, if used. - I believe that conditioned Preset macros are not needed any more: -%if 0%{?systemd_post:1} -%systemd_post mysqld.service -%else -if [ $1 = 1 ]; then - # Initial installation - /bin/systemctl daemon-reload >/dev/null 2>&1 || : -fi -%endif +%systemd_post mysqld.service [x]: SourceX tarball generation or download is documented. Note: Package contains tarball without URL, check comments [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. - test suite is run outside %check [!]: Packages should try to preserve timestamps of original installed files. - install and cp commands could include -p argument [!]: Files in /run, var/run and /var/lock uses tmpfiles.d when appropriate - package installs /lib/tmpfiles.d/mysql.conf but it should install /lib/tmpfiles.d/%{name}.conf [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present. [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define. Java: [-]: Packages are noarch unless they use JNI Note: mysql-community subpackage is not noarch. Please verify manually [-]: Package uses upstream build method (ant/maven/etc.) ===== EXTRA items ===== Generic: [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 184494080 bytes in /usr/share 1710080 mysql-community-common-5.6.12-1.fc19.x86_64.rpm 178155520 mysql- community-test-5.6.12-1.fc19.x86_64.rpm 30720 mysql-community- libs-5.6.12-1.fc19.x86_64.rpm 2785280 mysql-community- bench-5.6.12-1.fc19.x86_64.rpm 40960 mysql-community- devel-5.6.12-1.fc19.x86_64.rpm 30720 mysql-community- embedded-5.6.12-1.fc19.x86_64.rpm 51200 mysql-community-embedded- devel-5.6.12-1.fc19.x86_64.rpm 163840 mysql- community-5.6.12-1.fc19.x86_64.rpm 1525760 mysql-community- server-5.6.12-1.fc19.x86_64.rpm - caused by large test-suite packaged as a separate sub-package, so not seem like a problem [x]: Rpmlint is run on all installed packages. - See in-line comments, but no blockers. Rpmlint ------- Checking: mysql-community-5.6.12-1.fc19.x86_64.rpm mysql-community-libs-5.6.12-1.fc19.x86_64.rpm mysql-community-common-5.6.12-1.fc19.x86_64.rpm mysql-community-server-5.6.12-1.fc19.x86_64.rpm mysql-community-devel-5.6.12-1.fc19.x86_64.rpm mysql-community-embedded-5.6.12-1.fc19.x86_64.rpm mysql-community-embedded-devel-5.6.12-1.fc19.x86_64.rpm mysql-community-bench-5.6.12-1.fc19.x86_64.rpm mysql-community-test-5.6.12-1.fc19.x86_64.rpm mysql-community.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community.x86_64: W: spelling-error %description -l en_US mysqld -> myself mysql-community.x86_64: W: obsolete-not-provided mysql-cluster mysql-community.x86_64: W: only-non-binary-in-usr-lib mysql-community-common.x86_64: W: no-documentation mysql-community-server.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-server.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/mysqld mysql-community-server.x86_64: E: non-root-user-log-file /var/log/mysqld.log mysql mysql-community-server.x86_64: E: non-root-group-log-file /var/log/mysqld.log mysql mysql-community-server.x86_64: E: non-ghost-file /var/log/mysqld.log mysql-community-server.x86_64: E: zero-length /var/log/mysqld.log - Expected, we need mysqld.log to be created during install (but not changed nor verified using checksum, etc.), since it is not included in a place writable for mysql user. mysql-community-devel.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-devel.x86_64: W: only-non-binary-in-usr-lib mysql-community-devel.x86_64: E: incorrect-fsf-address /usr/include/mysql/byte_order_generic_x86_64.h mysql-community-devel.x86_64: E: incorrect-fsf-address /usr/include/mysql/byte_order_generic_x86.h mysql-community-devel.x86_64: E: incorrect-fsf-address /usr/include/mysql/little_endian.h mysql-community-devel.x86_64: E: incorrect-fsf-address /usr/include/mysql/byte_order_generic.h mysql-community-devel.x86_64: E: incorrect-fsf-address /usr/include/mysql/big_endian.h - should be reported/fixed upstream mysql-community-embedded.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded mysql-community-embedded.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-embedded-devel.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded mysql-community-embedded-devel.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-embedded-devel.x86_64: W: only-non-binary-in-usr-lib mysql-community-bench.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-bench.x86_64: W: spelling-error %description -l en_US benchmarking -> bench marking, bench-marking, benchmark mysql-community-bench.x86_64: E: script-without-shebang /usr/share/sql-bench/graph-compare-results mysql-community-test.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/untrusted-cacert.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/ca-sha512.pem mysql-community-test.x86_64: W: hidden-file-or-dir /usr/share/mysql-test/std_data/.mylogin.cnf mysql-community-test.x86_64: E: zero-length /usr/share/mysql-test/suite/parts/t/disabled.def mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/server-cert-sha512.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/crl-ca-cert.pem mysql-community-test.x86_64: E: zero-length /usr/share/mysql-test/std_data/bug37631.MYD mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/cacert.pem mysql-community-test.x86_64: E: zero-length /usr/share/mysql-test/std_data/cluster_7022_table.MYD mysql-community-test.x86_64: E: zero-length /usr/share/mysql-test/collections/disabled-weekly.list mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/server8k-cert.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/client-cert.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/crl-client-revoked-cert.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/crl-client-cert.pem mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/server-cert.pem mysql-community-test.x86_64: E: zero-length /usr/share/mysql-test/collections/disabled-daily.list mysql-community-test.x86_64: W: pem-certificate /usr/share/mysql-test/std_data/crl-server-cert.pem mysql-community-test.x86_64: W: no-manual-page-for-binary my_safe_process 9 packages and 0 specfiles checked; 16 errors, 29 warnings.
New updated package: http://home.online.no/~bjornmu/fedora/mysql-community-5.6.13-1.fc19.src.rpm Spec file here as before: http://home.online.no/~bjornmu/fedora/mysql-community.spec Changes: - 5.6.13: https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html - Patches now upstream: plugin-bool, va-list and gcc 4.8 - libmysqlclient_r links fixed upstream - Perms on files in -bench fixed upsteam - README encoding fixed upstream - Fix dep on systemd - Unversioned docdir support - Multilib support on arm - Improved multilib support - Always use macros if possible - Add BSD to license - libmysqlclient.so version is 18.1.0, drop 1018 hack - Switch to .xz tarball - Add secure file patch for mtr to pass - Add srv buf patch to fix build when punch hole enabled - Use more explicit list of perl modules in buildreq - Add patch for test unnecessarily using Perl module Env New koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5845715 [Note: as time of posting this update, arm build has not yet completed but I *think* all the tests have passed] This addresses review comments and adds updates etc. As for the *name* of the package, we should take that discussion later.
I've looked at the updated package and it looks fine for me, except the renaming as already mentioned above. So I'm fine with rebasing community-mysql to 5.6.13 for F21, which I'm going to do till the end of this week. However, the devel freeze for F20 was already 20th August, so I'd rather go with F21 only. If you think we should update to 5.6 in F20 as well, I'd like to hear what community on fedora-devel says, since upgrading to 5.6 is still very large leap, so I'd rather not hurry. About sponsorship, I'm not a sponsor, so I can't sponsor you to have full package maintainer account. What I could do is to offer mentoring as per http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
(In reply to Honza Horak from comment #7) > About sponsorship, I'm not a sponsor, so I can't sponsor you to have full > package maintainer account. What I could do is to offer mentoring as per > http://fedoraproject.org/wiki/ > How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer Honza, if you wouldn't mind I can take this review over, finish it and sponsor Bjorn into packager-group. After this you can step in as a mentor and help him improve his skills / knowledge. ;)
(In reply to Björn "besser82" Esser from comment #8) > (In reply to Honza Horak from comment #7) > > About sponsorship, I'm not a sponsor, so I can't sponsor you to have full > > package maintainer account. What I could do is to offer mentoring as per > > http://fedoraproject.org/wiki/ > > How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer > > Honza, if you wouldn't mind I can take this review over, finish it and > sponsor Bjorn into packager-group. After this you can step in as a mentor > and help him improve his skills / knowledge. ;) OK, thanks, of course I agree.
(In reply to Honza Horak from comment #9) > OK, thanks, of course I agree. Allright, taken. ;)
(In reply to Honza Horak from comment #7) > I've looked at the updated package and it looks fine for me, except the > renaming as already mentioned above. So I'm fine with rebasing > community-mysql to 5.6.13 for F21, which I'm going to do till the end of > this week. Damn, I'm still not ready with rebasing to 5.6 in rawhide, since I need to do some more testing. However, I will be couple of days off, till the next weak or so, and I don't want to push an untested build to rawhide and vanish afterwards. So, please, be patient with 5.6 build for F21..
New updated package: http://home.online.no/~bjornmu/fedora/mysql-community-5.6.14-1.fc19.src.rpm Spec file here as before: http://home.online.no/~bjornmu/fedora/mysql-community.spec Changes: * Tue Sep 17 2013 Bjorn Munch <bjorn.munch> - 5.6.14-1 - 5.6.14: https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-14.html - Improve dep/req filtering - Patches now upstream: stack-guard, srv-buf and openfile-test - Refresh mysql-install patch and adjust mysqld-prepare-db-dir New koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6009300
I finally upgraded community-mysql to version 5.6.14. I had to do quite a lot of changes to keep patches we applied to the previous version, but anyway, thanks for the provided SRPM and SPEC file. The build is available in Rawhide, so it will be part of Fedora 21. As already mentioned above, the renaming doesn't seem to me a good idea, so it wasn't done this time. However, in case community (FPC??) approves it, I can live with that.. http://koji.fedoraproject.org/koji/buildinfo?buildID=470410
Ping? Any progress here or this is dead review?
With dnf and soft dependencies we might be able to do more, theoretically. But I'm still not sure if renaming is worth the trouble..
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
Is this review request still valid or can it be closed?
Sorry, this is way outdated and should be closed.