FAQ

On Fri, Jun 28, 2013 at 7:51 AM, Baptiste AGASSE wrote:
Hi,

I tried to rebuild JBoss EAP 6.0.1 (which was used bay RHEV engine) and RHEV 3.1 from SRPMs some months ago without success (missing some dependencies). I used mock. A week ago I've successfuly built JBoss EAP 6.1 Final from sources (with some little changes because Redhat don't publish some maven plugins and dependencies like slf4j, byteman, hibernate3, junit).

Have a nice day.

Regards.

---
Baptiste

Thanks Baptiste. After reading docs about RHEV, I have discarded
(rebuilding RHEV and RHEM is too much). But not RedHat Storage Server.
Reading about it, I see it is based in RHEL EUS 6.2.z and not RHEL 6.4
as I had been assumed.


I have located the updates that RedHat has released for RHEL 6.2.z
since Centos ceased to publish patches for 6.2 release.


My question: If I not wrong, mock uses jails or chroot environments to
rebuild packages. Can I use a CentOS 6.4 x86_64 host to rebuild all
patches released by RedHat for RHEL 6.2.z and Storage Server 2.0
without problems?? Does someone has tested?


P.D: Sorry for the cross posting to centos-devel, but maybe it is an
interesting question to publish in centos-devel list.

Search Discussions

  • Manuel Wolfshant at Jun 28, 2013 at 1:25 pm

    On 06/28/2013 04:21 PM, C. L. Martinez wrote:
    On Fri, Jun 28, 2013 at 7:51 AM, Baptiste AGASSE
    wrote:
    Hi,

    I tried to rebuild JBoss EAP 6.0.1 (which was used bay RHEV engine) and RHEV 3.1 from SRPMs some months ago without success (missing some dependencies). I used mock. A week ago I've successfuly built JBoss EAP 6.1 Final from sources (with some little changes because Redhat don't publish some maven plugins and dependencies like slf4j, byteman, hibernate3, junit).

    Have a nice day.

    Regards.

    ---
    Baptiste
    Thanks Baptiste. After reading docs about RHEV, I have discarded
    (rebuilding RHEV and RHEM is too much). But not RedHat Storage Server.
    Reading about it, I see it is based in RHEL EUS 6.2.z and not RHEL 6.4
    as I had been assumed.

    I have located the updates that RedHat has released for RHEL 6.2.z
    since Centos ceased to publish patches for 6.2 release.

    My question: If I not wrong, mock uses jails or chroot environments to
    rebuild packages. Can I use a CentOS 6.4 x86_64 host to rebuild all
    patches released by RedHat for RHEL 6.2.z and Storage Server 2.0
    without problems?? Does someone has tested?
    mock does not care about the build host, as long as it can a) read the
    source rpm and b) properly access the repositories needed to create the
    chroot.
  • C. L. Martinez at Jun 28, 2013 at 1:40 pm

    My question: If I not wrong, mock uses jails or chroot environments to
    rebuild packages. Can I use a CentOS 6.4 x86_64 host to rebuild all
    patches released by RedHat for RHEL 6.2.z and Storage Server 2.0
    without problems?? Does someone has tested?
    mock does not care about the build host, as long as it can a) read the
    source rpm and b) properly access the repositories needed to create the
    chroot.

    Perfect. Last question: is mock the best to rebuild rpms packages??
    Exists another??
  • Manuel Wolfshant at Jun 28, 2013 at 1:45 pm

    On 06/28/2013 04:40 PM, C. L. Martinez wrote:
    My question: If I not wrong, mock uses jails or chroot environments to
    rebuild packages. Can I use a CentOS 6.4 x86_64 host to rebuild all
    patches released by RedHat for RHEL 6.2.z and Storage Server 2.0
    without problems?? Does someone has tested?
    mock does not care about the build host, as long as it can a) read the
    source rpm and b) properly access the repositories needed to create the
    chroot.
    Perfect. Last question: is mock the best to rebuild rpms packages??
    for the time being, yes

    Exists another??
    yes

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedJun 28, '13 at 1:21p
activeJun 28, '13 at 1:45p
posts4
users2
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase