Bug 683071 - Review Request: php-libvirt - PHP bindings for libvirt virtualization toolkit
Summary: Review Request: php-libvirt - PHP bindings for libvirt virtualization toolkit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-08 13:14 UTC by Michal Novotny
Modified: 2014-02-02 22:38 UTC (History)
7 users (show)

Fixed In Version: php-libvirt-0.4.3-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-16 17:35:15 UTC
tmraz: fedora-review+
tibbs: fedora-cvs+


Attachments (Terms of Use)

Description Michal Novotny 2011-03-08 13:14:18 UTC
Spec URL: http://minovotn.fedorapeople.org/libvirt-php.spec
SRPM URL: http://minovotn.fedorapeople.org/libvirt-php-0.4.1-1.fc14.src.rpm
Description: Libvirt-php is a PHP binding for libvirt to allow management of the virtual machines from your PHP scripts. For more information please refer to: http://libvirt.org/php .

This is my first package but it should be sponsored by rjones however this is the first time I'm doing a package so I hope everything will be OK.

Comment 1 Michal Novotny 2011-03-08 13:24:23 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

Comment 2 Tomas Mraz 2011-03-09 12:52:21 UTC
(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.

Comment 3 Tomas Mraz 2011-03-09 13:33:25 UTC
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.

Comment 4 Michal Novotny 2011-03-09 13:48:49 UTC
(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

Comment 5 Richard W.M. Jones 2011-03-09 13:53:05 UTC
(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?

Comment 6 Tomas Mraz 2011-03-09 13:58:42 UTC
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.

Comment 7 Michal Novotny 2011-03-09 16:58:26 UTC
(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

Comment 8 Michal Novotny 2011-03-10 14:03:53 UTC
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

Comment 9 Michal Novotny 2011-03-10 14:28:45 UTC
(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

Comment 10 Tomas Mraz 2011-03-10 19:02:40 UTC
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.

Comment 11 Michal Novotny 2011-03-11 10:32:20 UTC
(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

Comment 12 Tomas Mraz 2011-03-11 10:54:27 UTC
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.

Comment 13 Michal Novotny 2011-03-11 12:12:39 UTC
(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

Comment 14 Michal Novotny 2011-03-11 12:37:33 UTC
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

Comment 15 Tomas Mraz 2011-03-11 12:43:08 UTC
I think that just

%doc html

in the -doc subpackage should work fine. Then rpmbuild will copy the html files for you.

Comment 16 Michal Novotny 2011-03-11 12:46:46 UTC
(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

Comment 17 Michal Novotny 2011-03-11 13:31:43 UTC
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

Comment 18 Richard W.M. Jones 2011-03-11 13:46:58 UTC
For reference, thread on licensing is here:
https://www.redhat.com/archives/libvir-list/2011-March/thread.html#00406

Comment 19 Tomas Mraz 2011-03-11 13:49:22 UTC
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.

Comment 20 Michal Novotny 2011-03-11 14:39:28 UTC
(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

Comment 21 Richard W.M. Jones 2011-03-11 14:47:26 UTC
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/

Comment 22 Michal Novotny 2011-03-11 14:49:29 UTC
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

Comment 23 Michal Novotny 2011-03-11 14:51:00 UTC
(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

Comment 24 Michal Novotny 2011-03-11 15:10:05 UTC
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

Comment 25 Michal Novotny 2011-03-14 13:08:25 UTC
Tomas, is that OK?

Michal

Comment 26 Tomas Mraz 2011-03-14 17:29:44 UTC
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.

Comment 27 Michal Novotny 2011-03-14 19:55:29 UTC
Ok, thanks for your reply. I'll work on this tomorrow since I feel tired today.

Michal

Comment 28 Michal Novotny 2011-03-15 10:45:09 UTC
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

Comment 29 Tomas Mraz 2011-03-15 11:21:19 UTC
You need to pass also the LDFLAGS during the linking phase.

Comment 30 Michal Novotny 2011-03-15 11:36:54 UTC
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

Comment 31 Tomas Mraz 2011-03-15 21:02:48 UTC
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

Comment 32 Michal Novotny 2011-03-15 21:49:41 UTC
Ok, thanks for the approval :)

Michal

Comment 33 Richard W.M. Jones 2011-03-15 21:57:03 UTC
It's not over yet .. you need to go through the rest
of the steps here:
http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess

Comment 34 Michal Novotny 2011-03-15 22:16:26 UTC
(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

Comment 35 Michal Novotny 2011-03-15 22:16:42 UTC
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

Comment 36 Tomas Mraz 2011-03-15 22:23:50 UTC
Michal, why did you reset the fedora-review flag?

Comment 37 Michal Novotny 2011-03-15 22:26:26 UTC
(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

Comment 38 Tomas Mraz 2011-03-16 07:44:45 UTC
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.

Comment 39 Michal Novotny 2011-03-16 09:10:05 UTC
(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

Comment 40 Jason Tibbitts 2011-03-16 12:26:01 UTC
Git done (by process-git-requests).

Comment 41 Michal Novotny 2011-03-16 12:38:59 UTC
(In reply to comment #40)
> Git done (by process-git-requests).

Thanks a lot!

Michal

Comment 42 Michal Novotny 2011-03-16 12:49:24 UTC
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

Comment 43 Fedora Update System 2011-03-16 12:52:45 UTC
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

Comment 44 Fedora Update System 2011-03-16 12:56:11 UTC
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

Comment 45 Tomas Mraz 2011-03-16 13:08:01 UTC
No, for rawhide the branch request is not needed. Could you try to build it again?

Comment 46 Michal Novotny 2011-03-16 13:34:47 UTC
(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

Comment 47 Michal Novotny 2011-03-23 13:41:48 UTC
(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

Comment 48 Jason Tibbitts 2011-03-23 14:16:28 UTC
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.

Comment 49 Michal Novotny 2011-03-23 15:10:49 UTC
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

Comment 50 Dennis Gilmore 2011-03-23 15:48:50 UTC
we need a koji task to debug this propperly

Comment 51 Michal Novotny 2011-03-23 15:50:11 UTC
(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

Comment 52 Michal Novotny 2011-03-24 08:49:13 UTC
(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

Comment 53 Dennis Gilmore 2011-03-24 14:17:30 UTC
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

Comment 54 Michal Novotny 2011-03-24 14:28:29 UTC
(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

Comment 55 Michal Novotny 2011-03-24 14:37:45 UTC
> please stop by #fedora-admin if you have any questions so we can resolve them

What IRC server? Freenode.net?

Michal

Comment 56 Michal Novotny 2011-03-24 15:32:25 UTC
Solved on IRC. Thanks a lot!

Michal

Comment 57 Fedora Update System 2011-03-24 19:27:45 UTC
php-libvirt-0.4.1-2.fc14 has been pushed to the Fedora 14 stable repository.

Comment 58 Fedora Update System 2011-03-25 06:58:33 UTC
php-libvirt-0.4.1-2.fc15 has been pushed to the Fedora 15 stable repository.

Comment 59 Fedora Update System 2011-08-11 15:57:07 UTC
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

Comment 60 Fedora Update System 2011-08-22 14:54:33 UTC
php-libvirt-0.4.3-1.fc16 has been pushed to the Fedora 16 stable repository.


Note You need to log in before you can comment on or make changes to this bug.