Bug 1046959

Macros should be enclosed by braces.

And so, besides the macros that should be enclosed, is there any problem to fix ?

(In reply to Michael Scherer from comment #2)
> And so, besides the macros that should be enclosed, is there any problem to
> fix ?

I haven't run the fedora-review because the review doesn't pass first on SPEC itself. Also 0.02 is available, please update the package, then it's possible for me to review.

And, %configure will insert the cflags, why did you insert them again in

make CFLAGS="$RPM_OPT_FLAGS" %{?_smp_mflags}?

%check section not usable, because there is a bug in gtest package? If so, where is the bug report?

1) I fail to understand what you mean by "doesn't pass first on SPEC itself", can you clarify ?

I will post a updated with 0.0.2 shortly, didn't see there was a new version since I posted it.

2) for %configure, likely a wrong cut and paste, will remove it in the nextiteration.


3) I didn't report a bug, because this is not a bug.
%check is not usable because it requires the source code of gtest directly, ie it likly use a non public API by using internals of gtest.cc. And so asking to gtest to distribute the code as part of the rpm would likely make others people use it ( so make it public while it likely shouldn't ), which will them be a hack and quite fragile. I will not ask the package to carry a non public API just for a test.

(In reply to Michael Scherer from comment #4)
> 1) I fail to understand what you mean by "doesn't pass first on SPEC
> itself", can you clarify ?

I review packages first from SPEC, if spec is not fine, the review of course will generate many problems. SPEC should be bascially correct.

> I will post a updated with 0.0.2 shortly, didn't see there was a new version
> since I posted it. 

Fine.

> 2) for %configure, likely a wrong cut and paste, will remove it in the
> nextiteration.

Fine.

> 3) I didn't report a bug, because this is not a bug.
> %check is not usable because it requires the source code of gtest directly,
> ie it likly use a non public API by using internals of gtest.cc. And so
> asking to gtest to distribute the code as part of the rpm would likely make
> others people use it ( so make it public while it likely shouldn't ), which
> will them be a hack and quite fragile. I will not ask the package to carry a
> non public API just for a test.

Yes, but you should mention this in the initial comment so that we won't waste time here.

Nice to see you have time, so update the bug and I will review it formally.

0.03 is out.

Spec URL: http://www.zarb.org/~misc/tmp/simple-tpm-pk11.spec
SRPM URL: http://www.zarb.org/~misc/tmp/simple-tpm-pk11-0.03-1.fc22.src.rpm

Koji scratch build :

http://koji.fedoraproject.org/koji/taskinfo?taskID=7135050

changelog invalid. Please add the 0.03 changelog.

Please brackets: %_bindir -> %{_bindir}

Source0 suggestion:

https://github.com/ThomasHabets/simple-tpm-pk11/archive/%{version}.tar.gz#/%{name}-%{version}.tar.gz

puiterwijk's scratch build of simple-tpm-pk11-0.04-1.fc22.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12165732

I just found this review after packaging it myself as well.

Michael: if you wnat a new (fixed) spec and SRPM:
SPEC: https://puiterwijk.fedorapeople.org/simple-tpm-pk11.spec
SRPM: https://puiterwijk.fedorapeople.org/simple-tpm-pk11-0.04-1.fc22.src.rpm

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/simple-tpm-pk11

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/simple-tpm-pk11

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/simple-tpm-pk11

Note: those approval messages were because of a test with pkgdb. This package still needs review.

Hello, anyone still interested in this package ?

I've a tpm device I can test on and I would like to review this package.
Best would be to make a new review with an updated spec file if possible.
Then please make me assigned for the review.

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.

This review request is really old. Do you still intend to complete it? If so, please indicate. If not, please close this issue and make it block FE-DEADREVIEW, or do nothing, in which case automation will close the request in one month.

In can review if needed, but I do not have the device this is used with. Because of that, Nicolas would be a better candidate, if he is still interested and has the device.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.