Bug 1251120

Summary: Rebase to 0.2.0
Product: [Fedora] Fedora Reporter: Jakub Čajka <jcajka>
Component: paflibAssignee: Rajalakshmi <raji>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: jcajka, raji, tulioqm
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-12 09:18:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1071880, 1051573    
Attachments:
Description Flags
Rebase patch none

Description Jakub Čajka 2015-08-06 13:26:38 UTC
Created attachment 1059942 [details]
Rebase patch

Please rebase to latest upstream version. In attachment is patch doing so(without source update/upload). Patch also enables tests run during build. Failed check doesn't cause build to fail as builder might not support the required features, but I still belief that running tests might prove useful in the future especially as they take little(nearly no) time to run.

Successful scratch build:

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2692250

Also current fedora version is FTBFS(http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=339807) in f23+ due to enabled package hardening by default(seems tests fail to build, which seem to get separate build in recent release) and as there is recent release I'm rather opening rebase BZ.


Thanks, 
Jakub

PS: I'm paflib maintainer in RHEL and I also (co-)maintain most of powerpc specific packages there and in Fedora. Could I become a paflib co-maintainer (get commit rights) of paflib?

Comment 1 Tulio Magno Quites Machado Filho 2015-08-06 14:28:40 UTC
(In reply to Jakub Čajka from comment #0)
> Please rebase to latest upstream version. In attachment is patch doing
> so(without source update/upload). Patch also enables tests run during build.
> Failed check doesn't cause build to fail as builder might not support the
> required features, but I still belief that running tests might prove useful
> in the future especially as they take little(nearly no) time to run.

What about opening a pull request for Paflib?
https://github.com/paflib/paflib

That way, your patch can get reviews from more people and with better tools.

We've been trying to integrate other package systems [1] into the master branch, and your patch could help us to do the same for rpm.

[1] https://github.com/paflib/paflib/pull/7

> Also current fedora version is
> FTBFS(http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=339807) in
> f23+ due to enabled package hardening by default(seems tests fail to build,
> which seem to get separate build in recent release) and as there is recent
> release I'm rather opening rebase BZ.

Could you report this test failure at https://github.com/paflib/paflib/issues , please?
Looks like our tests missed that one and we don't want to miss it again.

> PS: I'm paflib maintainer in RHEL and I also (co-)maintain most of powerpc
> specific packages there and in Fedora. Could I become a paflib co-maintainer
> (get commit rights) of paflib?

Why don't we do this like other open source projects?
You send some patches, get reviews and they get accepted.
Does that work for you?

Comment 2 Jakub Čajka 2015-08-07 08:24:19 UTC
First of all I don't have any patches for upstream code to clear any miss understandings.

My changes(contained in attached patch) are only affecting and related to  downstream distribution so I'm posting them for review on respective downstream bug tracker. Any feedback is much appreciated.

I have been consulting the failed test cases with Fedora package maintainer and was planning to report it to the upstream...(I'm busy with more pressing stuff now, will get back to it probably on Monday), also been consulting way to verify that built binary "is correct" if built on "older than P8 HW", and for example forcing correct mcpu/mtune flags if not. OFC sending the patches to the upstream for review if anything needing source code patching would turn up in process.

I'm sorry, but I think that maintaining downstream rpm spec file in upstream repo is not a good idea as rpm is used in multiple different distributions(most notably Fedora, SUSE,...)(note: I'm not familiar with SUSE packaging guidelines) and you will probably and up with rpm spec file that is not compatible with any of respective distribution guidelines(read mandatory packaging rules, for example different changelogs entries in rpm spec due to some events as "Fedora mass rebuild", not matching release numbers,...) or compatible result will still require substantial afford from downstream maintainers. I would also appreciate if upstream repo would contain description how to contribute and for example note about this initiative(to have all things needed for packaging in master branch) in README and respective downstream maintainers should be involved(contacted) which doesn't seems to be the case now(I have became co-maintainer of this package in Fedora later on the same day as this bug was opened and current maintainer haven't mentioned this to me yet, and with lack of upstream documentation...). OFC will open issues on github.

If you are interested in this I would also recommend to watch(or better co-maintain, if Fedora maintainer will agree, I will assist you with the process) the package in Fedora(https://admin.fedoraproject.org/pkgdb/package/paflib/).

I hope this clarifies the matters.

Best regards,

Jakub

Comment 3 Tulio Magno Quites Machado Filho 2015-08-07 12:34:17 UTC
(In reply to Jakub Čajka from comment #2)
> First of all I don't have any patches for upstream code to clear any miss
> understandings.

I'm sorry,  I completely misunderstood you here.
;-)

> My changes(contained in attached patch) are only affecting and related to 
> downstream distribution so I'm posting them for review on respective
> downstream bug tracker. Any feedback is much appreciated.

Ack.
I'm not the Fedora maintainer for this package, but if my code review matters: your changes look good to me.

> I have been consulting the failed test cases with Fedora package maintainer
> and was planning to report it to the upstream...(I'm busy with more pressing
> stuff now, will get back to it probably on Monday),

Sure.  Take your time.
I just wanted to make you feel free to report these bugs upstream.

> also been consulting way
> to verify that built binary "is correct" if built on "older than P8 HW", and
> for example forcing correct mcpu/mtune flags if not. OFC sending the patches
> to the upstream for review if anything needing source code patching would
> turn up in process.

I was referring to your patch to the spec file.
We're trying to maintain a distro agnostic RPM spec file in the project in order to help all distributions to package PAFLib.
If you believe part of this patch is distro agnostic, I'd appreciate to integrate it into our repository.

> I'm sorry, but I think that maintaining downstream rpm spec file in upstream
> repo is not a good idea as rpm is used in multiple different
> distributions(most notably Fedora, SUSE,...)(note: I'm not familiar with
> SUSE packaging guidelines) and you will probably and up with rpm spec file
> that is not compatible with any of respective distribution guidelines(read
> mandatory packaging rules, for example different changelogs entries in rpm
> spec due to some events as "Fedora mass rebuild", not matching release
> numbers,...) or compatible result will still require substantial afford from
> downstream maintainers. I would also appreciate if upstream repo would
> contain description how to contribute and for example note about this
> initiative(to have all things needed for packaging in master branch) in
> README and respective downstream maintainers should be involved(contacted)
> which doesn't seems to be the case now(I have became co-maintainer of this
> package in Fedora later on the same day as this bug was opened and current
> maintainer haven't mentioned this to me yet, and with lack of upstream
> documentation...). OFC will open issues on github.

Our intention is not to provide a spec file that works on all distros.  But we believe that our spec file could help downstream maintainers to update their own files, e.g.: spending less time reading READMEs to find out about --enable-ebb.

> If you are interested in this I would also recommend to watch(or better
> co-maintain, if Fedora maintainer will agree, I will assist you with the
> process) the package in
> Fedora(https://admin.fedoraproject.org/pkgdb/package/paflib/).

As you, I've been busy too and I prefer to avoid this now.
However, I'd appreciate to help you in case you find more issues with PAFlib.

> I hope this clarifies the matters.

Yes, it does.
I'm sorry again for the noise.

Comment 4 Jakub Čajka 2015-08-12 09:18:33 UTC
Built for f23 http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=340389