hi,
I've started the builds for centos7beta, so far its ging good ( in that 3 packages of 3 attempted have built, so its going to be a while before we have a true picture on the state of srpms ).
What I'd like to also do is get a public instance of the buildsystem online that allows everyone else the ability to submit their own packages for builds against the existing rhel7b1 code and parse / process the output ( purely for testing ).
Think of it as a getting-ready-for-seven sort of an effort.
One challenge in the mix is going to be that EPEL isnt building for EL7 as yet, and lots of people rely on EPEL for their own deps. We could help things by pushing all of EPEL6 through, and provide feedback on the EPEL lists....
thoughts ?
"All of EPEL6" is quite an effort, why don't submit the dependency SRPM's from EPEL with your own SRPM to build against 7?
-----Ursprüngliche Nachricht----- Von: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] Im Auftrag von Karanbir Singh Gesendet: Montag, 16. Dezember 2013 10:57 An: centos-devel@centos.org Betreff: [CentOS-devel] a public build tool for seven
hi,
I've started the builds for centos7beta, so far its ging good ( in that 3 packages of 3 attempted have built, so its going to be a while before we have a true picture on the state of srpms ).
What I'd like to also do is get a public instance of the buildsystem online that allows everyone else the ability to submit their own packages for builds against the existing rhel7b1 code and parse / process the output ( purely for testing ).
Think of it as a getting-ready-for-seven sort of an effort.
One challenge in the mix is going to be that EPEL isnt building for EL7 as yet, and lots of people rely on EPEL for their own deps. We could help things by pushing all of EPEL6 through, and provide feedback on the EPEL lists....
thoughts ?
On 12/16/2013 10:50 AM, Thomas Göttgens wrote:
"All of EPEL6" is quite an effort, why don't submit the dependency SRPM's from EPEL with your own SRPM to build against 7?
that would be far easier
but, i dont intend to rebuild all of epel - just submit it all in, for stuff that does not build, the best I can do is provide feedback to the people who own that package in epel - there is no way i can actually parse and fix / process packages as well :)
- KB
I've built a few things from EPEL 6, mock and mock's deps came over without issue. I've had to pull a few things down from Fedora 19 also but not a lot. I wouldn't expect all of EPEL 6 to build, but most of the core things people rely on would probably be OK.
Nothing I've been working on is in a public repo, but I could fix that after I get back to the environment and can upload it if it would help.
On Mon, Dec 16, 2013 at 3:57 AM, Karanbir Singh mail-lists@karan.orgwrote:
hi,
I've started the builds for centos7beta, so far its ging good ( in that 3 packages of 3 attempted have built, so its going to be a while before we have a true picture on the state of srpms ).
What I'd like to also do is get a public instance of the buildsystem online that allows everyone else the ability to submit their own packages for builds against the existing rhel7b1 code and parse / process the output ( purely for testing ).
Think of it as a getting-ready-for-seven sort of an effort.
One challenge in the mix is going to be that EPEL isnt building for EL7 as yet, and lots of people rely on EPEL for their own deps. We could help things by pushing all of EPEL6 through, and provide feedback on the EPEL lists....
thoughts ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Dec 16, 2013 at 1:57 AM, Karanbir Singh mail-lists@karan.orgwrote:
One challenge in the mix is going to be that EPEL isnt building for EL7 as yet, and lots of people rely on EPEL for their own deps. We could help things by pushing all of EPEL6 through, and provide feedback on the EPEL lists....
It looks like EPEL will be building for EL7 pretty soon. It may be worth waiting on instead of trying to rebuild a lot of stuff locally.
https://lists.fedoraproject.org/pipermail/epel-devel/2013-December/008935.ht...
-Jeff
On 12/16/2013 02:18 PM, Jeff Sheltren wrote:
On Mon, Dec 16, 2013 at 1:57 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
One challenge in the mix is going to be that EPEL isnt building for EL7 as yet, and lots of people rely on EPEL for their own deps. We could help things by pushing all of EPEL6 through, and provide feedback on the EPEL lists....It looks like EPEL will be building for EL7 pretty soon. It may be worth waiting on instead of trying to rebuild a lot of stuff locally.
https://lists.fedoraproject.org/pipermail/epel-devel/2013-December/008935.ht...
excellent, but i still need something to stress this little machine of mine, so it might be worth doing a mass submittion anyway ( besides, it might be helpful to people doing the epel packages / maintainers since I dont believe epel7 is going to be a mass rebuild )
On Mon, Dec 16, 2013 at 7:42 AM, Karanbir Singh mail-lists@karan.orgwrote:
excellent, but i still need something to stress this little machine of mine, so it might be worth doing a mass submittion anyway ( besides, it might be helpful to people doing the epel packages / maintainers since I dont believe epel7 is going to be a mass rebuild )
Sounds good to me!
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have no idea. Steven Crothers steven.crothers@gmail.com
On Mon, Dec 16, 2013 at 10:46 AM, Jeff Sheltren jeff@tag1consulting.com wrote:
On Mon, Dec 16, 2013 at 7:42 AM, Karanbir Singh mail-lists@karan.org wrote:
excellent, but i still need something to stress this little machine of mine, so it might be worth doing a mass submittion anyway ( besides, it might be helpful to people doing the epel packages / maintainers since I dont believe epel7 is going to be a mass rebuild )
Sounds good to me!
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 12/17/2013 04:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have no idea. Steven Crothers steven.crothers@gmail.com
Because we don't use koji, and I don't think we want to
On Mon, Dec 16, 2013 at 10:46 AM, Jeff Sheltren jeff@tag1consulting.com wrote:
On Mon, Dec 16, 2013 at 7:42 AM, Karanbir Singh mail-lists@karan.org wrote:
excellent, but i still need something to stress this little machine of mine, so it might be worth doing a mass submittion anyway ( besides, it might be helpful to people doing the epel packages / maintainers since I dont believe epel7 is going to be a mass rebuild )
Sounds good to me!
On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes johnny@centos.org wrote:
On 12/17/2013 04:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have no idea. Steven Crothers steven.crothers@gmail.com
Because we don't use koji, and I don't think we want to
While I appreciate brevity and the ability to get the point without project manager jibjab, that answer really leaves a lot to be desired for.
SRPMs come in, RPMs come out.
Seems like the perfect solutions to me.
All you're doing is rebuilding, there is no secret sauce involved. Why not make it easier? It'll dep solve, build everything in proper order and build individual mock roots for each and every RPM ensuring that the build is clean.
Curious as to why you don't want to.
On 12/22/2013 07:13 AM, Steven Crothers wrote:
All you're doing is rebuilding, there is no secret sauce involved. Why not make it easier?
I believe Johnny's point is that what we have in place now is a lot easier, better customised and suited for what we are doing. we'd need to re-write all the automation for koji again, for the only sake of having a different program call mock.
You also mentioned koji does ordering, care to expand on that a bit ?
- KB
On 12/22/2013 01:13 AM, Steven Crothers wrote:
On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes johnny@centos.org wrote:
On 12/17/2013 04:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have no idea. Steven Crothers steven.crothers@gmail.com
Because we don't use koji, and I don't think we want to
While I appreciate brevity and the ability to get the point without project manager jibjab, that answer really leaves a lot to be desired for.
SRPMs come in, RPMs come out.
Seems like the perfect solutions to me.
All you're doing is rebuilding, there is no secret sauce involved. Why not make it easier? It'll dep solve, build everything in proper order and build individual mock roots for each and every RPM ensuring that the build is clean.
Curious as to why you don't want to.
Well, I can tell you that it does not seem like the perfect solution to us .. at least not to me. The goal here is to call mock with an SRPM. Koji can do that, so can the system we use. We have a system that calls mock and we have other automation around that system that has taken us years to make. We have no intention (at this point) in redesigning our system. Koji did not exist when we started our method to create builds.
If we were creating a system from scratch now, then maybe we might use koji .. then again, maybe not.
We think our entire system, from end to end, works better than koji for our process ... unless we are convinced otherwise, we won't be changing.
How is our process different ... the vast majority of SRPMs that we get do not need modification and an RPMs get built directly from the upstream SRPMs, submitted to our build system. A relatively small number of SRPMs need to be changed, but even these changed SRPMs are not in a git (or other VCS tree) where we modify it as we go along. We need to import the new SRPM into in over top our old one (which will revert our changes from before and add in the new changed from upstream), make some predetermined changes to the new code that we have figured out before (which were already in the old version, but were just overwritten by the import) and make sure those changes work in the new code, then create an SRPM and send it to the build.
We also may encounter SRPMs with "hidden build requirements", where there is something in the upstream build root that is not called out in the SRPM. For example, upstream may have package_xyz in their build root, but it is not as a BuildRequires in the SRPM. We need a way to get package_xyz into the build root, for building this SRPM, BUT we don't want to change the SRPM to include it as a build requires, since our goal is to not change SRPMS. We feed back to upstream that package_xyz needs to be a BuildRequires for that SRPM (via bugzilla.redhat.com) and change our configuration to build with package_xyz in the buildroot in the interim. An example is that in the past, sqlite-devel and crash-devel was required to be added into the EL5 build tree to build the systemtap SRPM.
So some of our packages are built directly from the upstream SRPMS, some are modified in a VCS (either git or svn depending on EL5 or EL6) and the modified SRPMs are built, and still other SRPMs need hidden build requirements solved. We have a process by which we accomplish this that we don't think needs to be modified at this time. Maybe we can be convinced otherwise, but for now we like what we have.
On 12/17/2013 05:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have
While on the surface it sounds like a good idea, the fact of the matter is that CentOS rebuilds from already built source RPMS. This is not the normal use case for Koji, where sources, patches, and specs are its input.
I say that from the point of view of actually having rebuilt the whole of CentOS 5 source RPMS for IA64 (starting point was Scientific Linux CERN 5.4 IA64, the last IA64 SLC release, and I stepwise built up through 5.9. I haven't had the time to set up automatic rebuilds or to rebuild 5.10 as yet, and it's not a high priority). Koji is overkill, as even those source RPMS that need modifying and/or rebranding aren't many.
The plumbing would be nice to automate, but I found that much of what I had to do to get stuff to build wasn't easy to automate. Particularly going from 5.5 to 5.6 (I seem to remember a pretty significant delay in the official CentOS 5.6 release, and I actually found out why that was the case when actually rebuilding the packages). Manually iterating mock to build each package in sequence was necessary, and most of the time spent was spent waiting for builds to finish.
The single biggest thing to remember is that RHEL is not self-hosting and would fail the normal Fedora builds-itself-from-source testing. This is a point that really cannot be overemphasized.
I'm glad to see things get started a bit earlier and more publicly than with CentOS 6; kudos to the team so far for this.
On Thu, Dec 19, 2013 at 10:22 AM, Lamar Owen lowen@pari.edu wrote:
The plumbing would be nice to automate, but I found that much of what I had to do to get stuff to build wasn't easy to automate.
How about jenkins as the automation wrapper? It can already do about any build/test/publish operation with the work queued across some number of build nodes, and on the odd chance that you need to do something no one has done before it can be extended with plugins. It is a nice tool to make the results visible while maintaining some access control on the operations.
On Thu, Dec 19, 2013 at 10:43 AM, Les Mikesell lesmikesell@gmail.com wrote:
How about jenkins as the automation wrapper?
Oh, never mind: http://ci.dev.centos.org/
On 12/19/2013 01:36 PM, Les Mikesell wrote:
On Thu, Dec 19, 2013 at 10:43 AM, Les Mikesell lesmikesell@gmail.com wrote:
How about jenkins as the automation wrapper?
Oh, never mind: http://ci.dev.centos.org/
:-)
On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen lowen@pari.edu wrote:
On 12/17/2013 05:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have
While on the surface it sounds like a good idea, the fact of the matter is that CentOS rebuilds from already built source RPMS. This is not the normal use case for Koji, where sources, patches, and specs are its input.
I don't believe that is true, releasing Red Hat built binaries would be directly against the Red Hat licensing agreement.
C6 is/should be built from SRPMs, Johnny builds each package in his environment.
I do recall seeing the build server hostnames in the RPMs even occasionally.
On 12/22/2013 01:11 AM, Steven Crothers wrote:
On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen lowen@pari.edu wrote:
On 12/17/2013 05:50 PM, Steven Crothers wrote:
Why not run a CentOS Koji, or perhaps request access/space to the Fedora Koji (unlikely)?
Koji is the "standard" both for Fedora and EPEL, and I once heard it's used internally at Red Hat as well, as far as to what extent, I have
While on the surface it sounds like a good idea, the fact of the matter is that CentOS rebuilds from already built source RPMS. This is not the normal use case for Koji, where sources, patches, and specs are its input.
I don't believe that is true, releasing Red Hat built binaries would be directly against the Red Hat licensing agreement.
C6 is/should be built from SRPMs, Johnny builds each package in his environment.
I do recall seeing the build server hostnames in the RPMs even occasionally.
We *DO* build directly from the upstream sources for most packages .. as in the SRPM we initially submit to our buildsystem is the upstream SRPM. The only time we don't do that is if we need to modify the SRPM first to remove branding. In those cases, the SRPM is imported into a VCS (either git or svn), changes made, and a new SRPM generated and that new SRPM is submitted into our build system.
Mock, when it produces the RPMs, produces both an SRPM and the binary RPMs as output. We release the SRPM and RPMs that are built from the original submitted SRPM.
On 12/22/2013 02:11 AM, Steven Crothers wrote:
On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen lowen@pari.edu wrote:
While on the surface it sounds like a good idea, the fact of the matter is that CentOS rebuilds from already built source RPMS. This is not the normal use case for Koji, where sources, patches, and specs are its input.
I don't believe that is true, releasing Red Hat built binaries would be directly against the Red Hat licensing agreement.
Binaries? Where did I mention binary RPMS? Source RPMS == SRPMS, right? The source RPM (SRPM) is spit out from the same build process that makes the binary RPM (thus, why I called them 'already built'). The input to building RPMS is in SOURCES and SPECS in the build tree; SRPMS are not the input, they are part of the output of the process and encapsulate the input to the process in a convenient and rebuildable wrapper that also holds some essential build information that is not found in the normal SOURCES and SPECS input.
C6 is/should be built from SRPMs, Johnny builds each package in his environment.
The environment used is the one built up by mock in the buildroot; sometimes some customizations have to be added to make this work (hand-injecting buildrequires, as Johnny mentioned, is part of the process; there are ways to automate 'hand' injection without modifying the source RPM (SRPM, if you prefer)). I've done this myself, rebuilding CentOS 5 on IA64, and it was educational.
Koji is built to best handle the case for building from SOURCES and SPECS (which are in a revision control system, ideally), not from already built source RPMS (SRPMS). It will rebuild from SRPM, but it's overkill for that use case.
Again, I say that from first-hand experience in actually doing a rebuild, this isn't speculation on my part here. Go back and read the archives; I was one who, until actually trying it, thought koji might be a good thing (it's in the archives, as I already said). I had to have it proven to me, and I proved it to myself that koji is overkill for this purpose.
Is there a mock config that can be used by others yet?
On Mon, Dec 23, 2013 at 8:28 AM, Lamar Owen lowen@pari.edu wrote:
On 12/22/2013 02:11 AM, Steven Crothers wrote:
On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen lowen@pari.edu wrote:
While on the surface it sounds like a good idea, the fact of the matter is that CentOS rebuilds from already built source RPMS. This is not the normal use case for Koji, where sources, patches, and specs are its input.
I don't believe that is true, releasing Red Hat built binaries would be directly against the Red Hat licensing agreement.
Binaries? Where did I mention binary RPMS? Source RPMS == SRPMS, right? The source RPM (SRPM) is spit out from the same build process that makes the binary RPM (thus, why I called them 'already built'). The input to building RPMS is in SOURCES and SPECS in the build tree; SRPMS are not the input, they are part of the output of the process and encapsulate the input to the process in a convenient and rebuildable wrapper that also holds some essential build information that is not found in the normal SOURCES and SPECS input.
C6 is/should be built from SRPMs, Johnny builds each package in his
environment.
The environment used is the one built up by mock in the buildroot; sometimes some customizations have to be added to make this work (hand-injecting buildrequires, as Johnny mentioned, is part of the process; there are ways to automate 'hand' injection without modifying the source RPM (SRPM, if you prefer)). I've done this myself, rebuilding CentOS 5 on IA64, and it was educational.
Koji is built to best handle the case for building from SOURCES and SPECS (which are in a revision control system, ideally), not from already built source RPMS (SRPMS). It will rebuild from SRPM, but it's overkill for that use case.
Again, I say that from first-hand experience in actually doing a rebuild, this isn't speculation on my part here. Go back and read the archives; I was one who, until actually trying it, thought koji might be a good thing (it's in the archives, as I already said). I had to have it proven to me, and I proved it to myself that koji is overkill for this purpose.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 12/27/2013 09:37 AM, Larry Brigman wrote:
Is there a mock config that can be used by others yet?
I'm not aware of any public mock config yet. epel 7 still doesn't have mock in the repo and the latest mock from Fedora rawhide doesn't have a config for epel 7, but the buildsys-build group is in the epel7 repo so you can just copy the epel 6 config file and tweak it to change version numbers and repository paths, etc, plus remove a few repos that don't currently exist. When I do that I'm able to init a mock chroot just fine. I haven't tried to build a package yet, but I highly doubt there will be any significant issues with that.
Peter
On 12/16/2013 04:57 AM, Karanbir Singh wrote:
I've started the builds for centos7beta, so far its ging good ( in that 3 packages of 3 attempted have built, so its going to be a while before we have a true picture on the state of srpms ).
What I'd like to also do is get a public instance of the buildsystem online that allows everyone else the ability to submit their own packages for builds against the existing rhel7b1 code and parse / process the output ( purely for testing ).
Karanbir, just in case anyone else hasn't done so, I want to thank you for the good updates at seven.centos.org
They are much appreciated.
Hi,
On 01/03/2014 08:10 PM, Lamar Owen wrote:
Karanbir, just in case anyone else hasn't done so, I want to thank you for the good updates at seven.centos.org
excellent! I am glad they are helpful. this weekend I intend to wraggle with the wordpress api and see if i can get the 'tobuild list' populated automagically nightly.
btw, one interesting thing is that the rss is not nearly as popular as people actually hitting the site. that just makes me think that there is something wrong with the world.
- KB
On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh mail-lists@karan.org wrote:
btw, one interesting thing is that the rss is not nearly as popular as people actually hitting the site. that just makes me think that there is something wrong with the world.
I'd blame the demise of google reader and the related android app... Is there anything else that works with a single setup and tracks 'new/unread' items across any browser or phone app access?
On 2014-01-03 15:44, Les Mikesell wrote:
On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh mail-lists@karan.org wrote:
btw, one interesting thing is that the rss is not nearly as popular as people actually hitting the site. that just makes me think that there is something wrong with the world.
I'd blame the demise of google reader and the related android app... Is there anything else that works with a single setup and tracks 'new/unread' items across any browser or phone app access?
Newsblur (http://www.newsblur.com) works great for me. Decent web interface, plus apps for iOS and Android.
Not free, but worth every penny, and not interested in tracking your every move online.
Matt
On Fri, Jan 3, 2014 at 1:44 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh mail-lists@karan.org wrote:
btw, one interesting thing is that the rss is not nearly as popular as people actually hitting the site. that just makes me think that there is something wrong with the world.
I'd blame the demise of google reader and the related android app... Is there anything else that works with a single setup and tracks 'new/unread' items across any browser or phone app access?
I switched to http://feedly.com/ when Google Reader stopped. It has a web interface fairly similar to Google Reader and also has a decent Android app.
-
Andrew Wyatt -
Dave Johansen -
Jeff Sheltren -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Larry Brigman -
Les Mikesell -
Matt Rose -
Peter -
Steven Crothers -
Thomas Göttgens