Hi all,
I finally put some time aside to move forward with building RPMs for DPDK 2.0 for the CentOS NFV SIG.
In particular, I used pretty much the same spec file from Red Hat (made sure the RPM release matches what CBS expects for release) and I created package dpdk-2.0.0-1.el7.centos with buildID 1476.
I am guessing I really should have built dpdk-2.0.0-8.el7.centos as I have kept all the changelog intact which goes up to number 8, and also keep it in sync with the Red Hat version? Any comments on that?
Then my next question is that I noticed that following my successful build, kojira created task 16722 in order to create a new repo, which makes sense. According to that, since my RPM has tag nfv7-common-el7-build the dpdk rpm should apear on centos7-updates external repo, right? Following to this (and if I am right so far) shouldn't there be a specific repo for NFV SIG instead of centos7-updates which is a standard external repo?
I have some more questions, but I will pause here if someone could shed some lights, that would be great.
Thanks
Joseph
On Aug 01 10:15, Joseph Gasparakis wrote:
Hi all,
I finally put some time aside to move forward with building RPMs for DPDK 2.0 for the CentOS NFV SIG.
In particular, I used pretty much the same spec file from Red Hat (made sure the RPM release matches what CBS expects for release) and I created package dpdk-2.0.0-1.el7.centos with buildID 1476.
Great!
I am guessing I really should have built dpdk-2.0.0-8.el7.centos as I have kept all the changelog intact which goes up to number 8, and also keep it in sync with the Red Hat version? Any comments on that?
That's up to you, but it would be less confusing if the name-version-release matches what's in the changelogs.
Then my next question is that I noticed that following my successful build, kojira created task 16722 in order to create a new repo, which makes sense. According to that, since my RPM has tag nfv7-common-el7-build the dpdk rpm should apear on centos7-updates external repo, right? Following to this (and if I am right so far) shouldn't there be a specific repo for NFV SIG instead of centos7-updates which is a standard external repo?
There is a specific repo for each tag in koji. When you build in nvf7-common-el7-build, the packages automatically come out the other end in the koji tag: nfv7-common-candidate. You can find all the repos here: http://cbs.centos.org/repos/
Generally the workflow once the packages are built: - Do general smoke tests on the packages from the -candidate repo - `koji tag-pkg` the build into nfv7-common-testing - Do more testing from the nvf7-common-testing repo, once you're happy: - `koji tag-pkg` the build into nfv7-common-release for signing and release
I have some more questions, but I will pause here if someone could shed some lights, that would be great.
Keep them coming!
Thanks
Joseph
--Brian
On Sat, 1 Aug 2015, Brian Stinson wrote:
On Aug 01 10:15, Joseph Gasparakis wrote:
Hi all,
I finally put some time aside to move forward with building RPMs for DPDK 2.0 for the CentOS NFV SIG.
In particular, I used pretty much the same spec file from Red Hat (made sure the RPM release matches what CBS expects for release) and I created package dpdk-2.0.0-1.el7.centos with buildID 1476.
Great!
I am guessing I really should have built dpdk-2.0.0-8.el7.centos as I have kept all the changelog intact which goes up to number 8, and also keep it in sync with the Red Hat version? Any comments on that?
That's up to you, but it would be less confusing if the name-version-release matches what's in the changelogs.
Hmmm... Yeah... Let me sleep over this and see. Since you don't have any strong feelings about it, I tend to think I will maintain my one changelog and when I rebase based on a Red Hat spec file I will be just adding the reference to this spec file. If anybody else has any other thoughts, I will be more than happy to read them.
Then my next question is that I noticed that following my successful build, kojira created task 16722 in order to create a new repo, which makes sense. According to that, since my RPM has tag nfv7-common-el7-build the dpdk rpm should apear on centos7-updates external repo, right? Following to this (and if I am right so far) shouldn't there be a specific repo for NFV SIG instead of centos7-updates which is a standard external repo?
There is a specific repo for each tag in koji. When you build in nvf7-common-el7-build, the packages automatically come out the other end in the koji tag: nfv7-common-candidate. You can find all the repos here: http://cbs.centos.org/repos/
Generally the workflow once the packages are built:
- Do general smoke tests on the packages from the -candidate repo
- `koji tag-pkg` the build into nfv7-common-testing
So, in case of DPDK, do we need to create the smoke tests to run when in the -candidate release? Or this repo is for the brave who want to try "early" stuff and if the package survives a few days without getting bug reports I should promote it to -testing?
Also, I suppose now anybody can access the -candidate repo and download dpdk rpms, right? And the way would be to configure from their yum.conf this new repo by adding a new repo section with:
baseurl=cbs.centos.org/repos/nfv-common-candidate/x86-64/
Anything else?
- Do more testing from the nvf7-common-testing repo, once you're happy:
- `koji tag-pkg` the build into nfv7-common-release for signing and release
Same question as before: do we need more exhaustive tests for the -testing repo?
I have some more questions, but I will pause here if someone could shed some lights, that would be great.
Keep them coming!
Don't we want a git repo to capture the spec files and the extra patches/scripts?
I think with your explanation above I am a bit clearer. If you can also answer the above questions I think I will be pretty much covered.
Here is the last one I have: Don't we want a git repo to capture the spec files and the extra patches/scripts?
Thanks a lot Brian!
Thanks
Joseph
--Brian _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Aug 02 09:46, Joseph Gasparakis wrote:
On Sat, 1 Aug 2015, Brian Stinson wrote:
On Aug 01 10:15, Joseph Gasparakis wrote:
Hi all,
I finally put some time aside to move forward with building RPMs for DPDK 2.0 for the CentOS NFV SIG.
In particular, I used pretty much the same spec file from Red Hat (made sure the RPM release matches what CBS expects for release) and I created package dpdk-2.0.0-1.el7.centos with buildID 1476.
Great!
I am guessing I really should have built dpdk-2.0.0-8.el7.centos as I have kept all the changelog intact which goes up to number 8, and also keep it in sync with the Red Hat version? Any comments on that?
That's up to you, but it would be less confusing if the name-version-release matches what's in the changelogs.
Hmmm... Yeah... Let me sleep over this and see. Since you don't have any strong feelings about it, I tend to think I will maintain my one changelog and when I rebase based on a Red Hat spec file I will be just adding the reference to this spec file. If anybody else has any other thoughts, I will be more than happy to read them.
Then my next question is that I noticed that following my successful build, kojira created task 16722 in order to create a new repo, which makes sense. According to that, since my RPM has tag nfv7-common-el7-build the dpdk rpm should apear on centos7-updates external repo, right? Following to this (and if I am right so far) shouldn't there be a specific repo for NFV SIG instead of centos7-updates which is a standard external repo?
There is a specific repo for each tag in koji. When you build in nvf7-common-el7-build, the packages automatically come out the other end in the koji tag: nfv7-common-candidate. You can find all the repos here: http://cbs.centos.org/repos/
Generally the workflow once the packages are built:
- Do general smoke tests on the packages from the -candidate repo
- `koji tag-pkg` the build into nfv7-common-testing
So, in case of DPDK, do we need to create the smoke tests to run when in the -candidate release? Or this repo is for the brave who want to try "early" stuff and if the package survives a few days without getting bug reports I should promote it to -testing?
Test requirements/strategies are a good discussion point for the next SIG meeting, you might find some points of collaboration there. Feel free to grab those packages for initial testing as well. In addition to individual testers, ci.centos.org is available for SIGs who would like to do regular testing on their packages.
Also, I suppose now anybody can access the -candidate repo and download dpdk rpms, right? And the way would be to configure from their yum.conf this new repo by adding a new repo section with:
baseurl=cbs.centos.org/repos/nfv-common-candidate/x86-64/
I wouldn't encourage advertising these as "early adopter" repos, they are not hooked into our mirror network and don't represent any sort of released content. We don't want people winding up using these as their production yum targets for example, but they are available publicly.
Anything else?
- Do more testing from the nvf7-common-testing repo, once you're happy:
- `koji tag-pkg` the build into nfv7-common-release for signing and release
Same question as before: do we need more exhaustive tests for the -testing repo?
Test rigor is up to you and the SIG. We're in-progress working on some very basic stuff at the project level (yum install foo -> did it break?).
I have some more questions, but I will pause here if someone could shed some lights, that would be great.
Keep them coming!
Don't we want a git repo to capture the spec files and the extra patches/scripts?
The infra team is working on the mechanics for this. We'll have a standard package layout (and the tools to manage it all) similar to dist-git. You can see example layouts from the CentOS 7 Distro sources at http://git.centos.org/project/rpms
I think with your explanation above I am a bit clearer. If you can also answer the above questions I think I will be pretty much covered.
Here is the last one I have: Don't we want a git repo to capture the spec files and the extra patches/scripts?
Thanks a lot Brian!
Thanks
Joseph
Cheers! Brian