Bug 683071
| Summary: | Review Request: php-libvirt - PHP bindings for libvirt virtualization toolkit | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Novotny <minovotn> |
| Component: | Package Review | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | areis, dennis, fedora-package-review, j, notting, rjones, tmraz |
| Target Milestone: | --- | Flags: | tmraz:
fedora-review+
j: fedora-cvs+ |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | php-libvirt-0.4.3-1.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-16 17:35:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Michal Novotny
2011-03-08 13:14:18 UTC
Here's the Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2894059 . There was no arch-override and it compiled for i386 and x86_64 systems fine so I guess the other platforms don't have PHP support. Michal (In reply to comment #1) > Here's the Koji build: > There was no arch-override and it compiled for i386 and x86_64 systems fine so I guess the > other platforms don't have PHP support. Not really - Fedora primary architectures are i386 (i686) and x86_64 only. The other architectures are secondary and handled by a different koji instance and builds are initiated separately by the secondary arch builders. The tarball at the source URL and in the .src.rpm differs. According to the https://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme the package should be named php-libvirt instead of libvirt-php. Note that you have included the html doc in both main package and the -doc subpackage. Also the %doc must be on the same line as the filename specification. The licensing is confusing/wrong - in the README you specify that the license is GPL (if so, there should be COPYING with the correct GPL version). In the .spec file there is License: PHP. The source files do not contain any copyright statements nor license names - these are not required but they are recommended. (In reply to comment #3) > The tarball at the source URL and in the .src.rpm differs. > > According to the https://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme > the package should be named php-libvirt instead of libvirt-php. > Well, originally the project was named php-libvirt but it got renamed to comply with the names at http://libvirt.org/git . This was not my idea however I already got used to the libvirt-php name. > Note that you have included the html doc in both main package and the -doc > subpackage. Also the %doc must be on the same line as the filename > specification. This is because rpmlint was complaining the main package was not having any documentation. Shouldn't be I having it in the main package then? > > The licensing is confusing/wrong - in the README you specify that the license > is GPL (if so, there should be COPYING with the correct GPL version). In the > .spec file there is License: PHP. The source files do not contain any copyright > statements nor license names - these are not required but they are recommended. Oh, I'll fix it. I guess this was done by multiple people contributing to this so it made some kind of mess there however for the PHP modules the licence should be a PHP licence, right? Or should be easily be GPL licence as well since it's just about the module/extension? Michal (In reply to comment #4) > (In reply to comment #3) > > The tarball at the source URL and in the .src.rpm differs. > > > > According to the https://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme > > the package should be named php-libvirt instead of libvirt-php. > > > > > Well, originally the project was named php-libvirt but it got renamed to comply > with the names at http://libvirt.org/git . This was not my idea however I > already got used to the libvirt-php name. Don't confuse the upstream name and the Fedora name. They can be different if we need them to be. > > Note that you have included the html doc in both main package and the -doc > > subpackage. Also the %doc must be on the same line as the filename > > specification. > > This is because rpmlint was complaining the main package was not having any > documentation. Shouldn't be I having it in the main package then? You can ignore rpmlint if you think it is getting things wrong, although it's often a good idea to add a small comment in the spec file. In this case, how about putting the README and license file (eg. COPYING) into the main package, and the rest of the documentation in the -doc subpackage. > > > > The licensing is confusing/wrong - in the README you specify that the license > > is GPL (if so, there should be COPYING with the correct GPL version). In the > > .spec file there is License: PHP. The source files do not contain any copyright > > statements nor license names - these are not required but they are recommended. > > > Oh, I'll fix it. I guess this was done by multiple people contributing to this > so it made some kind of mess there however for the PHP modules the licence > should be a PHP licence, right? Or should be easily be GPL licence as well > since it's just about the module/extension? You really need to be clear about licensing before anything can be incorporated into Fedora. It's a legal requirement and could get people into trouble. Maybe clarify this with upstream on libvir-list? Basically everything was already answered by Richard. The licensing must be clear and the Fedora package name can be different from the upstream tarball name. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > The tarball at the source URL and in the .src.rpm differs. > > > > > > According to the https://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme > > > the package should be named php-libvirt instead of libvirt-php. > > > > > > > > > Well, originally the project was named php-libvirt but it got renamed to comply > > with the names at http://libvirt.org/git . This was not my idea however I > > already got used to the libvirt-php name. > > Don't confuse the upstream name and the Fedora name. They can > be different if we need them to be. > Well, I maintain the upstream for libvirt-php. If the names can be different then I rename the project for Fedora. > > > Note that you have included the html doc in both main package and the -doc > > > subpackage. Also the %doc must be on the same line as the filename > > > specification. > > > > This is because rpmlint was complaining the main package was not having any > > documentation. Shouldn't be I having it in the main package then? > > You can ignore rpmlint if you think it is getting things wrong, > although it's often a good idea to add a small comment in the > spec file. Oh, ok. I won't be putting docs in the main package then. > > In this case, how about putting the README and license file (eg. COPYING) > into the main package, and the rest of the documentation in the > -doc subpackage. > > > > > > > The licensing is confusing/wrong - in the README you specify that the license > > > is GPL (if so, there should be COPYING with the correct GPL version). In the > > > .spec file there is License: PHP. The source files do not contain any copyright > > > statements nor license names - these are not required but they are recommended. > > > > > > Oh, I'll fix it. I guess this was done by multiple people contributing to this > > so it made some kind of mess there however for the PHP modules the licence > > should be a PHP licence, right? Or should be easily be GPL licence as well > > since it's just about the module/extension? > > You really need to be clear about licensing before anything > can be incorporated into Fedora. It's a legal requirement and > could get people into trouble. Maybe clarify this with upstream > on libvir-list? Well, upstream libvir-list has nothing to do with the binding since I maintain the PHP bindings. However I should ask about the licence. Michal Spec URL: http://minovotn.fedorapeople.org/php-libvirt.spec SRPM URL: http://minovotn.fedorapeople.org/php-libvirt-0.4.1-2.fc14.src.rpm Description: Libvirt bindings for PHP is just a libvirt bindings for PHP platform to allow management of the virtual machines from your PHP scripts. For more information please refer to http://libvirt.org/php . Tomas, could you please review it? Thanks, Michal (In reply to comment #8) > Spec URL: http://minovotn.fedorapeople.org/php-libvirt.spec > SRPM URL: http://minovotn.fedorapeople.org/php-libvirt-0.4.1-2.fc14.src.rpm > Description: Libvirt bindings for PHP is just a libvirt bindings for PHP > platform to allow management of the virtual machines from your PHP scripts. For > more information please refer to http://libvirt.org/php . > > Tomas, could you please review it? > > Thanks, > Michal Also, there's Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2900658 Michal The php-libvirt-0.4.1.tar.gz in the src.rpm and the http://libvirt.org/sources/php/php-libvirt-0.4.1.tar.gz tarballs still differ. The upstream project is still named libvirt-php - perhaps the tarball should stay with the name libvirt-php and just name the src.rpm package php-libvirt? Also I see the license was changed to LGPLv2+ - at least according to the LICENSE and README files - have you got an approval from all of the contributors to the project to change the license? You cannot change the license from GPLv2 to LGPLv2+ without it as the GPLv2 is stronger - more restrictive license. Also the LICENSE and probably also the README file should stay in the base package as %doc and should not go into the doc subpackage. (In reply to comment #10) > The php-libvirt-0.4.1.tar.gz in the src.rpm and the > http://libvirt.org/sources/php/php-libvirt-0.4.1.tar.gz tarballs still differ. > I don't know how could they still differ however I'll check it later after the rest of the issues are solved. > The upstream project is still named libvirt-php - perhaps the tarball should > stay with the name libvirt-php and just name the src.rpm package php-libvirt? > The upstream project will still be named libvirt-php. We're talking about Fedora name and not upstream name since upstream name will not change. I was having some issues having the tarball named libvirt-php since after renaming the project to php-libvirt it was looking for libvirt-php file instead. When I altered the source to use php-libvirt it was working fine however the upstream tarball named php-libvirt had to exist and therefore I changed to this. > Also I see the license was changed to LGPLv2+ - at least according to the > LICENSE and README files - have you got an approval from all of the > contributors to the project to change the license? You cannot change the > license from GPLv2 to LGPLv2+ without it as the GPLv2 is stronger - more > restrictive license. > > Also the LICENSE and probably also the README file should stay in the base > package as %doc and should not go into the doc subpackage. Well, where exactly should it go since all files installed by the main package are just /etc/php.d/php-libvirt.ini and /usr/lib/php/modules/php-libvirt.so so where should the README and LICENSE files go? Should they be copied to the docs directory even if user don't install the -doc package? Thanks, Michal There is no need to change the tarball name. You just have to use '%setup -q -n libvirt-php-%{version}' in such case.
As for the second question. The %doc directive will automatically place the file inside the docs directory. There is no need to have the docs directory specified explicitly.
(In reply to comment #12) > There is no need to change the tarball name. You just have to use '%setup -q -n > libvirt-php-%{version}' in such case. Thanks. I've managed to solve it somehow. There were still some issues but it's solved. > > As for the second question. The %doc directive will automatically place the > file inside the docs directory. There is no need to have the docs directory > specified explicitly. Well, it's not that since when I'm having definition like this: %files %defattr(-,root,root,-) %doc LICENSE README %{php_extdir}/php-libvirt.so %config(noreplace) %{php_confdir}/php-libvirt.ini %files -n php-libvirt-doc %defattr(-,root,root,-) %doc %dir %{_datadir}/doc/%{name}-%{version} %{_datadir}/doc/%{name}-%{version}/html in my SPEC file then I'm getting following error: ... Processing files: php-libvirt-doc-0.4.1-2.fc14.i686 error: File not found: /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1/html RPM build errors: File not found: /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1/html but I don't know how to fix it the right way since it's working fine when %doc is not filled for the main package but it's filled just for the -doc package. The /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1/html path doesn't exist at all in this case and it existed when %doc of the main package was empty. Michal Well, I found out what causes this issue. Here's the output of RPMbuild: + umask 022 + cd /home/mig/RPMS/BUILD + cd libvirt-php-0.4.1 + DOCDIR=/home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + export DOCDIR + rm -rf /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + /bin/mkdir -p /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + cp -pr LICENSE README /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + exit 0 The issue is that the HTML files are being created and installed using make in the docs subdirectory of the package however it's being removed and substituted by LICENSE and README files instead. Can I somehow disable the rm -rf step ? Michal I think that just %doc html in the -doc subpackage should work fine. Then rpmbuild will copy the html files for you. (In reply to comment #15) > I think that just > > %doc html > > in the -doc subpackage should work fine. Then rpmbuild will copy the html files > for you. Well, not really since I'm still getting: + cd /home/mig/RPMS/BUILD + cd libvirt-php-0.4.1 + DOCDIR=/home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + export DOCDIR + rm -rf /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + /bin/mkdir -p /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + cp -pr LICENSE README /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1 + exit 0 It removes everything in the docs directory and therefore it can't copy anything. Can I disable the "rm -rf" step somehow? Michal Well,I've put everything into one package since the docs are small. Also, the contributors wrote their fine with the licence change to LGPLv2+. Spec URL: http://minovotn.fedorapeople.org/php-libvirt.spec SRPM URL: http://minovotn.fedorapeople.org/php-libvirt-0.4.1-2.fc14.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2904134 Description: Libvirt bindings for PHP is just a libvirt bindings for PHP platform to allow management of the virtual machines from your PHP scripts. For more information please refer to http://libvirt.org/php . Michal For reference, thread on licensing is here: https://www.redhat.com/archives/libvir-list/2011-March/thread.html#00406 OK, fine.
There is double call to configure in the spec.%configure
%configure
./configure --with-html-dir=%{_datadir}/doc --with-html-subdir=%{name}-%{version}/html --libdir=%{php_extdir}
The %configure is a macro that expands to the configure call.
(In reply to comment #19) > OK, fine. > > There is double call to configure in the spec.%configure > %configure > ./configure --with-html-dir=%{_datadir}/doc > --with-html-subdir=%{name}-%{version}/html --libdir=%{php_extdir} > > The %configure is a macro that expands to the configure call. Well, if I change: %build %configure ./configure --with-html-dir=%{_datadir}/doc --with-html-subdir=%{name}-%{version}/html --libdir=%{php_extdir} make %{?_smp_mflags} to: %build %configure make %{?_smp_mflags} then I'm getting errors about unpackaged files: Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386 error: Installed (but unpackaged) file(s) found: /usr/share/doc/libvirt-php-0.4.1/html/32favicon.png /usr/share/doc/libvirt-php-0.4.1/html/api-reference.html /usr/share/doc/libvirt-php-0.4.1/html/compiling.html /usr/share/doc/libvirt-php-0.4.1/html/contact.html /usr/share/doc/libvirt-php-0.4.1/html/contributions.html /usr/share/doc/libvirt-php-0.4.1/html/deployment.html /usr/share/doc/libvirt-php-0.4.1/html/dev-api-reference.html /usr/share/doc/libvirt-php-0.4.1/html/docs.html /usr/share/doc/libvirt-php-0.4.1/html/downloads.html /usr/share/doc/libvirt-php-0.4.1/html/examples.html /usr/share/doc/libvirt-php-0.4.1/html/footer_corner.png /usr/share/doc/libvirt-php-0.4.1/html/footer_pattern.png /usr/share/doc/libvirt-php-0.4.1/html/generic.css /usr/share/doc/libvirt-php-0.4.1/html/index.html /usr/share/doc/libvirt-php-0.4.1/html/libvirt-header-bg.png /usr/share/doc/libvirt-php-0.4.1/html/libvirt-php-header-logo.png /usr/share/doc/libvirt-php-0.4.1/html/libvirt.css /usr/share/doc/libvirt-php-0.4.1/html/links.html /usr/share/doc/libvirt-php-0.4.1/html/main.css /usr/share/doc/libvirt-php-0.4.1/html/news.html /usr/share/doc/libvirt-php-0.4.1/html/references.html /usr/share/doc/libvirt-php-0.4.1/html/roadmap.html /usr/share/doc/libvirt-php-0.4.1/html/sitemap.html /usr/share/doc/libvirt-php-0.4.1/html/todo.html /usr/share/doc/libvirt-php-0.4.1/html/windows.html RPM build errors: Installed (but unpackaged) file(s) found: /usr/share/doc/libvirt-php-0.4.1/html/32favicon.png /usr/share/doc/libvirt-php-0.4.1/html/api-reference.html /usr/share/doc/libvirt-php-0.4.1/html/compiling.html /usr/share/doc/libvirt-php-0.4.1/html/contact.html /usr/share/doc/libvirt-php-0.4.1/html/contributions.html /usr/share/doc/libvirt-php-0.4.1/html/deployment.html /usr/share/doc/libvirt-php-0.4.1/html/dev-api-reference.html /usr/share/doc/libvirt-php-0.4.1/html/docs.html /usr/share/doc/libvirt-php-0.4.1/html/downloads.html /usr/share/doc/libvirt-php-0.4.1/html/examples.html /usr/share/doc/libvirt-php-0.4.1/html/footer_corner.png /usr/share/doc/libvirt-php-0.4.1/html/footer_pattern.png /usr/share/doc/libvirt-php-0.4.1/html/generic.css /usr/share/doc/libvirt-php-0.4.1/html/index.html /usr/share/doc/libvirt-php-0.4.1/html/libvirt-header-bg.png /usr/share/doc/libvirt-php-0.4.1/html/libvirt-php-header-logo.png /usr/share/doc/libvirt-php-0.4.1/html/libvirt.css /usr/share/doc/libvirt-php-0.4.1/html/links.html /usr/share/doc/libvirt-php-0.4.1/html/main.css /usr/share/doc/libvirt-php-0.4.1/html/news.html /usr/share/doc/libvirt-php-0.4.1/html/references.html /usr/share/doc/libvirt-php-0.4.1/html/roadmap.html /usr/share/doc/libvirt-php-0.4.1/html/sitemap.html /usr/share/doc/libvirt-php-0.4.1/html/todo.html /usr/share/doc/libvirt-php-0.4.1/html/windows.html So apparently the configure is not being called with arguments required and it's being called with those arguments: + ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info instead so the --with-html-dir and --with-html-subdir arguments are missing there. Michal Michal, I think instead of having us debugging this package one Bugzilla comment at a time, which is very inefficient because Bugzilla is not a good comms tool, it would be better if you read some RPM documentation which would explain how these macros (and RPM itself) are supposed to work. This should be a good start: http://rpm.org/wiki/Docs#Books http://www.rpm.org/max-rpm-snapshot/ The most interesting thing is that if I change:
%files
%defattr(-,root,root,-)
%doc LICENSE README html
%{php_extdir}/php-libvirt.so
%config(noreplace) %{php_confdir}/php-libvirt.ini
to:
%files
%defattr(-,root,root,-)
%doc LICENSE README html
%{php_extdir}/php-libvirt.so
%config(noreplace) %{php_confdir}/php-libvirt.ini
%{_datadir}/doc/%{name}-%{version}/html
in the SPEC file then it keeps saying:
+ /bin/mkdir -p /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1
+ cp -pr LICENSE README html /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1
+ exit 0
RPM build errors:
File not found: /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1/html
but:
$ ls /home/mig/RPMS/BUILDROOT/php-libvirt-0.4.1-2.fc14.i386/usr/share/doc/php-libvirt-0.4.1/html
shows the files exist there but according to rpmbuild they cannot be found.
Michal
(In reply to comment #21) > Michal, I think instead of having us debugging this package > one Bugzilla comment at a time, which is very inefficient > because Bugzilla is not a good comms tool, it would be better > if you read some RPM documentation which would explain how > these macros (and RPM itself) are supposed to work. > > This should be a good start: > > http://rpm.org/wiki/Docs#Books > http://www.rpm.org/max-rpm-snapshot/ Ok, good. I'll read it. Thanks, Michal Ok, I've already found how it could be done without having a double call to configure. It was much simpler than I thought. New version of the SRPM and SPEC file are available now: Spec URL: http://minovotn.fedorapeople.org/php-libvirt.spec SRPM URL: http://minovotn.fedorapeople.org/php-libvirt-0.4.1-2.fc14.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2904343 Description: Libvirt bindings for PHP is just a libvirt bindings for PHP platform to allow management of the virtual machines from your PHP scripts. For more information please refer to http://libvirt.org/php . Michal Tomas, is that OK? Michal I have still some additional requests. The build process is still not quite right - the CPPFLAGS/CFLAGS/LDFLAGS passed from the rpmbuild are ignored when the .c code is compiled and the .so linked. This makes the debuginfo empty which is why you disabled it. But that isn't acceptable, you have to patch the build so the debuginfo can be extracted. Also in the %changelog - do not use the .fcxx dist suffix as the package can be rebuilt on various dist releases. Ok, thanks for your reply. I'll work on this tomorrow since I feel tired today. Michal Well, it may take some time since I'm having it in the Makefile.am file but it's still not generating the debuginfo package: CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -I/usr/include/libxml2 CPPFLAGS: <empty> LDFLAGS: <empty> LIBS: -lvirt -lxml2 but: objdump -h php-libvirt.so | grep debug 25 .debug_aranges 00000020 00000000 00000000 00011b74 2**0 26 .debug_pubnames 00000d0e 00000000 00000000 00011b94 2**0 27 .debug_info 00008ea6 00000000 00000000 000128a2 2**0 28 .debug_abbrev 00000427 00000000 00000000 0001b748 2**0 29 .debug_line 00001a4d 00000000 00000000 0001bb6f 2**0 30 .debug_str 000040ea 00000000 00000000 0001d5bc 2**0 31 .debug_loc 000030d7 00000000 00000000 000216a6 2**0 32 .debug_pubtypes 00001a8f 00000000 00000000 0002477d 2**0 33 .debug_ranges 00000018 00000000 00000000 0002620c 2**0 so the code is apparently compiled with debug sections however it's failing to generate the -debuginfo package because of following error: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id ~RPMS/BUILD/libvirt-php-0.4.1 find: `debug': No such file or directory So some time is needed to figure this out. Michal You need to pass also the LDFLAGS during the linking phase. Already done and -debuginfo package seems to be generated correctly. New version of the SRPM and SPEC file are available now: Spec URL: http://minovotn.fedorapeople.org/php-libvirt.spec SRPM URL: http://minovotn.fedorapeople.org/php-libvirt-0.4.1-2.fc14.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2913330 Description: Libvirt bindings for PHP is just a libvirt bindings for PHP platform to allow management of the virtual machines from your PHP scripts. For more information please refer to http://libvirt.org/php . Michal OK, rpmlint is silent: rpmlint -v php-libvirt-0.4.1-2.fc13.src.rpm php-libvirt-0.4.1-2.fc13.x86_64.rpm php-libvirt-debuginfo-0.4.1-2.fc13.x86_64.rpm php-libvirt.src: I: checking php-libvirt.src: I: checking-url http://libvirt.org/php (timeout 10 seconds) php-libvirt.src: I: checking-url http://libvirt.org/sources/php/libvirt-php-0.4.1.tar.gz (timeout 10 seconds) php-libvirt.x86_64: I: checking php-libvirt.x86_64: I: checking-url http://libvirt.org/php (timeout 10 seconds) php-libvirt-debuginfo.x86_64: I: checking php-libvirt-debuginfo.x86_64: I: checking-url http://libvirt.org/php (timeout 10 seconds) 3 packages and 0 specfiles checked; 0 errors, 0 warnings. The package should now comply with the Fedora packaging guidelines. APPROVED Ok, thanks for the approval :) Michal It's not over yet .. you need to go through the rest of the steps here: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess (In reply to comment #33) > It's not over yet .. you need to go through the rest > of the steps here: > http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess I know about this. I'm currently summarizing the SCM admin request. Thanks anyway, Michal New Package SCM Request ======================= Package Name: php-libvirt Short Description: Libvirt bindings for PHP is just a libvirt bindings for PHP platform to allow management of the virtual machines from your PHP scripts. For more information please refer to http://libvirt.org/php Owners: minovotn Branches: f14 f15 InitialCC: virtmaint Michal, why did you reset the fedora-review flag? (In reply to comment #36) > Michal, why did you reset the fedora-review flag? Oh, did I ? Bugzilla told me something about midair-collision like it does but when I reloaded the bug information again then it changed the flags again. I'm having issues with that rather often for Xen component :( Could you please set the fedora-review flag again please? Thanks, Michal Michal, I have set it again when I posted the previous comment. But then you reset it again as you posted comment 37. If you get the mid-air collision, always copy your comment text and load the bug from scratch to avoid this. (In reply to comment #38) > Michal, I have set it again when I posted the previous comment. But then you > reset it again as you posted comment 37. If you get the mid-air collision, > always copy your comment text and load the bug from scratch to avoid this. Well, this is the strange thing about mid-air collisions. I did experience it just once - for comment 35 but not comment 37 and also sometimes I'm not given the mid-air collision and the flags are just changed without any attention from the site user. I'm not the only one that experienced this AFAIK but unfortunately I'm not sure when it exactly happens, i.e. how reproducible this is and what are the exact steps to do that to file a report against Bugzilla itself. Michal Git done (by process-git-requests). (In reply to comment #40) > Git done (by process-git-requests). Thanks a lot! Michal Oh, just one thing I can't find answer to. If I put the master (dist-rawhide) branch to koji using `fedpkg build` I'm getting "BuildError: package php-libvirt not in list for tag dist-f16". Shouldn't master branch go to the dist-rawhide that should be devel branch by default? Do I have to create a new SCM request later to support dist-f16 branch too? I'm unable to find those information on http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_a_Fedora_Account :( Also, when trying to sign the package for bodhi I was getting error: $ fedpkg update Creating a new update for php-libvirt-0.4.1-2.fc15 Password for minovotn: Creating a new update for php-libvirt-0.4.1-2.fc15 php-libvirt-0.4.1-2.fc15 not tagged as an update candidate $ What should I do about this? Thanks, Michal php-libvirt-0.4.1-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/php-libvirt-0.4.1-2.fc14 php-libvirt-0.4.1-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/php-libvirt-0.4.1-2.fc15 No, for rawhide the branch request is not needed. Could you try to build it again? (In reply to comment #45) > No, for rawhide the branch request is not needed. Could you try to build it > again? Oh, tried to build the master branch again and now it passed. Thanks, Michal (In reply to comment #40) > Git done (by process-git-requests). Jason, could you please take a look to the repo settings? I'm getting build errors: BuildError: Error running GIT command "git clone -n git://pkgs.fedoraproject.org/libvirt-php /var/lib/mock/dist-f14-build-1031235-153333/root/tmp/scmroot/libvirt-php", see checkout.log for details Or can I override it somehow in the SPEC file to refer to the already existing repo, i.e. the repo git://pkgs.fedoraproject.org/php-libvirt ? Thanks, Michal The repo settings are fine as far as I can see. I don't have any control or indeed any understanding of why koji would attempt to checkout a "libvirt-php" package (which doesn't exist) and you haven't given me sufficient information to find the actual build. The only thing I did is that I pushed several new commits to the repository and then I did "fedpkg push" and "fedpkg build" which failed so therefore I didn't went to "fedpkg update" since build failed. Were my steps to update it wrong? Michal we need a koji task to debug this propperly (In reply to comment #50) > we need a koji task to debug this propperly Understood, it's http://koji.fedoraproject.org/koji/taskinfo?taskID=2936376. Thanks, Michal (In reply to comment #51) > (In reply to comment #50) > > we need a koji task to debug this propperly > > Understood, it's http://koji.fedoraproject.org/koji/taskinfo?taskID=2936376. > > Thanks, > Michal Dennis, now I tried this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2939989 . The issue is certainly the name of the repository since I'm able to see: $ git clone -n git://pkgs.fedoraproject.org/libvirt-php /var/lib/mock/dist-f14-build-1032252-153441/root/tmp/scmroot/libvirt-php fatal: The remote end hung up unexpectedly Cloning into /var/lib/mock/dist-f14-build-1032252-153441/root/tmp/scmroot/libvirt-php... in the checkout.log (http://koji.fedoraproject.org/koji/getfile?taskID=2939990&name=checkout.log). The Fedora name for the project should be php-libvirt and not libvirt-php . Can I override the libvirt-php to php-libvirt just for this case e.g. in the SPEC file or somewhere? Thanks, Michal michal you have something wrong on your end fedpkg clone php-libvirt Cloning into php-libvirt... remote: Counting objects: 10, done. remote: Compressing objects: 100% (8/8), done. remote: Total 10 (delta 2), reused 0 (delta 0) Receiving objects: 100% (10/10), done. Resolving deltas: 100% (2/2), done. [dennis@pegasus fedora]$ cd php-libvirt/ [dennis@pegasus php-libvirt (master)]$ ls php-libvirt.spec sources [dennis@pegasus php-libvirt (master)]$ fedpkg giturl git://pkgs.fedoraproject.org/php-libvirt?#6f03e2e5c153adde33948771cdc9ecec88d0102d [dennis@pegasus php-libvirt (master)]$ your submitting the task as libvirt-php did you rename something locally? what commands are you running? its failing because the task you are creating is for a git module that does not exist. the module in this bug is there and correct. please stop by #fedora-admin if you have any questions so we can resolve them (In reply to comment #53) > michal you have something wrong on your end > > > fedpkg clone php-libvirt > Cloning into php-libvirt... > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remote: Total 10 (delta 2), reused 0 (delta 0) > Receiving objects: 100% (10/10), done. > Resolving deltas: 100% (2/2), done. > [dennis@pegasus fedora]$ cd php-libvirt/ > [dennis@pegasus php-libvirt (master)]$ ls > php-libvirt.spec sources > [dennis@pegasus php-libvirt (master)]$ fedpkg giturl > git://pkgs.fedoraproject.org/php-libvirt?#6f03e2e5c153adde33948771cdc9ecec88d0102d > [dennis@pegasus php-libvirt (master)]$ > Oh, I see. However I don't know how to fix it now. Basically I'm having 2 repositories there. One is master which is libvirt-php - upstream. Second is for Fedora and it's called php-libvirt. I don't know what's wrong however the issue there is that it's trying to access the libvirt-php instead of php-libvirt. I don't know whether I can override it somehow to try to clone php-libvirt instead of libvirt-php :( I have just switched the branch to f14 branch using `fedpkg switch-branch f14` and then I put in some commits I wanted to, did the `fedpkg push` and tried `fedpkg build` which is failing and therefore I can't do the `fedpkg update` (I didn't even try since build is failing). Any idea what can I do now ? Thanks, Michal > please stop by #fedora-admin if you have any questions so we can resolve them
What IRC server? Freenode.net?
Michal
Solved on IRC. Thanks a lot! Michal php-libvirt-0.4.1-2.fc14 has been pushed to the Fedora 14 stable repository. php-libvirt-0.4.1-2.fc15 has been pushed to the Fedora 15 stable repository. php-libvirt-0.4.3-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/php-libvirt-0.4.3-1.fc16 php-libvirt-0.4.3-1.fc16 has been pushed to the Fedora 16 stable repository. |