FAQ
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

Search Discussions

  • Thomas Göttgens at Dec 16, 2013 at 10:50 am
    "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 at centos.org
    [mailto:centos-devel-bounces at centos.org] Im Auftrag von Karanbir Singh
    Gesendet: Montag, 16. Dezember 2013 10:57
    An: centos-devel at 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 ?


    --
    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Karanbir Singh at Dec 16, 2013 at 11:43 am

    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


    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    GnuPG Key : http://www.karan.org/publickey.asc
  • Andrew Wyatt at Dec 16, 2013 at 1:47 pm
    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 wrote:

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20131216/841d7fcb/attachment.html
  • Jeff Sheltren at Dec 16, 2013 at 2:18 pm
    On Mon, Dec 16, 2013 at 1:57 AM, Karanbir Singh 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.html


    -Jeff
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20131216/fe07e2d3/attachment.html
  • Karanbir Singh at Dec 16, 2013 at 3:42 pm

    On 12/16/2013 02:18 PM, Jeff Sheltren wrote:
    On Mon, Dec 16, 2013 at 1:57 AM, Karanbir Singh <mail-lists at 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.html

    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 )




    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    GnuPG Key : http://www.karan.org/publickey.asc
  • Jeff Sheltren at Dec 16, 2013 at 3:46 pm
    On Mon, Dec 16, 2013 at 7:42 AM, Karanbir Singh 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!
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20131216/de2803a9/attachment.html
  • Steven Crothers at Dec 17, 2013 at 10:50 pm
    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 at gmail.com



    On Mon, Dec 16, 2013 at 10:46 AM, Jeff Sheltren wrote:
    On Mon, Dec 16, 2013 at 7:42 AM, Karanbir Singh 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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Johnny Hughes at Dec 17, 2013 at 10:53 pm

    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 at 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 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!

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20131217/a5dbcca7/attachment.bin
  • Steven Crothers at Dec 22, 2013 at 7:13 am

    On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes 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 at 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.
  • Karanbir Singh at Dec 23, 2013 at 8:33 am

    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


    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    GnuPG Key : http://www.karan.org/publickey.asc
  • Johnny Hughes at Dec 23, 2013 at 3:09 pm

    On 12/22/2013 01:13 AM, Steven Crothers wrote:
    On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes 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 at 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.




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20131223/d3cdcabd/attachment.bin
  • Lamar Owen at Dec 19, 2013 at 4:22 pm

    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.
  • Les Mikesell at Dec 19, 2013 at 4:43 pm

    On Thu, Dec 19, 2013 at 10:22 AM, Lamar Owen 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.


    --
        Les Mikesell
          lesmikesell at gmail.com
  • Les Mikesell at Dec 19, 2013 at 6:36 pm

    On Thu, Dec 19, 2013 at 10:43 AM, Les Mikesell wrote:
    How about jenkins as the automation wrapper?

    Oh, never mind:
    http://ci.dev.centos.org/


    --
        Les Mikesell
          lesmikesell at gmail.com
  • Lamar Owen at Dec 19, 2013 at 9:41 pm

    On 12/19/2013 01:36 PM, Les Mikesell wrote:
    On Thu, Dec 19, 2013 at 10:43 AM, Les Mikesell wrote:
    How about jenkins as the automation wrapper?
    Oh, never mind:
    http://ci.dev.centos.org/
    :-)
  • Steven Crothers at Dec 22, 2013 at 7:11 am

    On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen 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.
  • Johnny Hughes at Dec 23, 2013 at 3:17 pm

    On 12/22/2013 01:11 AM, Steven Crothers wrote:
    On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen 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.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20131223/d0fbb637/attachment.bin
  • Lamar Owen at Dec 23, 2013 at 4:28 pm

    On 12/22/2013 02:11 AM, Steven Crothers wrote:
    On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen 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.
  • Larry Brigman at Dec 26, 2013 at 8:37 pm
    Is there a mock config that can be used by others yet?




    On Mon, Dec 23, 2013 at 8:28 AM, Lamar Owen wrote:

    On 12/22/2013 02:11 AM, Steven Crothers wrote:
    On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen 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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20131226/8e12a7fe/attachment.html
  • Peter at Dec 26, 2013 at 10:27 pm

    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
  • Lamar Owen at Jan 3, 2014 at 8:10 pm

    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.
  • Karanbir Singh at Jan 3, 2014 at 8:20 pm
    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


    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    GnuPG Key : http://www.karan.org/publickey.asc
  • Les Mikesell at Jan 3, 2014 at 8:44 pm

    On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh 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?


    --
        Les Mikesell
           lesmikesell at gmail.com
  • Matt Rose at Jan 3, 2014 at 9:33 pm

    On 2014-01-03 15:44, Les Mikesell wrote:
    On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh 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
  • Dave Johansen at Jan 3, 2014 at 10:25 pm

    On Fri, Jan 3, 2014 at 1:44 PM, Les Mikesell wrote:

    On Fri, Jan 3, 2014 at 2:20 PM, Karanbir Singh 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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20140103/b3feac99/attachment.html

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedDec 16, '13 at 9:57a
activeJan 3, '14 at 10:25p
posts26
users12
websitecentos.org
irc#centos

People

Translate

site design / logo © 2021 Grokbase