On 19/04/16 00:10, Lalatendu Mohanty wrote:

Hi,

I have some questions about the work flow we are following for fixing stuff for CentOS ARM . For example I am trying to make docker run on Pi3. So I tried to rebuild it on Pi3 using centos-7-armhfp.cfg [1] and failed because of a dependency error i.e. no Package found for go-md2man>= 1.0.4.

I am sure, to build docker for Pi3 I need to build the dependency chain. But the question is how do I know if a certain is dependency chain is already fixed in CentOS ARM project and I can reuse the packages. Basically I do not want to redo the stuff which is already fixed and available for reuse. Is there a repository for these?

The second question is if I get successful at rebuild a package with some changes, how do contribute it back so that others can reuse the stuff? I guess the answer is I should send the patch to arm-dev mailing list.

Not sure if we have a wiki page for this kind of information. If we have please point me to that.

[1] http://armv7.dev.centos.org/repodir/centos-7-armhfp.cfg

Thanks, Lala

So, let's discuss the way you can verify what you need and where to find it.

For your go-md2man req, you can see (from x86_64) that it's coming from the updates repo (and src.rpm being http://vault.centos.org/7.2.1511/updates/Source/SPackages/golang-github-cpug...)

Now you can search in: - http://armv7.dev.centos.org/rpmbuild/* (for the build logs) and - http://armv7.dev.centos.org/repodir/* (for the built pkgs)

Where it doesn't help (and so plague doesn't show it under /rpmbuild/*) is that for pkg that have a ExclusiveArch , in the prep job (and so before really trying to build it), it just reports (by mail) :

<quote> Package /srv/armv7/rpmbuild/srpm_upload_dir/c71511-updates-1/golang-1.4.2-9.el7.src.rpm does not build on any architectures this build system supports. Package: ['x86_64'] Build System: ['armv7hl'] </quote>

And same for golang-1.4.2-9.el7.src.rpm itself.

So if you want to build docker for armhfp, you'd have first to verify that base components like those requirements can be built and that they work fine. I guess there is a reason if upstream had a specific ExclusiveArch setting in the .spec. OTOH, we built some pkgs in the same situation like corosync/pacemaker/libqb where a functional patch was the only required thing to make it usable on armhfp. (see as an example http://armv7.dev.centos.org/repodir/c7-buildroot-patched-SRPMS/patches/libqb...)

Now you're right about patch proposals : once you get a pkg to build and that it's working at the functional level, you can send a patch to this list. From that point, two possibilities : - it's a pkg that it's not in base/updates => you can rebuild/test it in your repo - it's a pkg from base/updates => you can rebuild/test it in your own repo (like for example http://armv7.dev.centos.org/repodir/c7-containers-tools/) and once you confirm that it works, we'll rebuild it (with the needed patch) and it will then be available in the base/udpates repo (and so also signed/pushed to mirror.centos.org)