Mailing List Archive

Hi Gordan,

I'm not sure how long you've been using ATrpms, but I believe someone would
need to step up and handle the builds and any issues that crop up. We
cannot just pile more work on Axel as I believe he's already overloaded.
:-)

A few of us have discussed helping Axel set up a new build system to
automate more of the tasks (like koji for Fedora). It really hasn't taken
off just yet.

Would you be willing to dedicate time to help build the ARM version of
packages?

/Brian/

On Wed, May 2, 2012 at 7:39 AM, Gordan Bobic <gordan@redsleeve.org> wrote:

> Hi,
>
> I was wondering if there might perhaps be interest in supporting ARM
> packages in the atrpms repositories.
>
> As some of you may already be aware, a 3rd party port el6 for ARM called
> RedSleeve has recently had an initial alpha release. Dag Wieers has already
> voiced his support and intent to include ARM packages in repoforge/rpmforge
> (see his comment here: http://www.redsleeve.org/**about/<http://www.redsleeve.org/about/>)
>
> So, Axel, would you be interested in expanding atrpms coverage to include
> el6 ARM packages?
>
> Best regards.
>
> Gordan
>
> ______________________________**_________________
> atrpms-users mailing list
> atrpms-users@atrpms.net
> http://lists.atrpms.net/**mailman/listinfo/atrpms-users<http://lists.atrpms.net/mailman/listinfo/atrpms-users>
>

On 02/05/2012 13:48, Brian Long wrote:
> Hi Gordan,
>
> I'm not sure how long you've been using ATrpms,

Years.

> but I believe someone
> would need to step up and handle the builds and any issues that crop up.

Indeed, but most packages tend to build and work OK. So as a first pass,
having everything that builds as is from src.rpms would be nice. I'd be
more than happy to look into any build failures. I can take all of
atrpms src.rpm packages and rebuild them myself, but I don't want to
diminish the value of other repositories by effectively usurping the
work of the maintainers thus far.

If there is no interest in supporthing ARM, then fine, I'll fork and
maintain the ARM repository myself (same way I keep up with upstream -
this wouldn't be any different).

> We cannot just pile more work on Axel as I believe he's already
> overloaded. :-)

I get that, see above.

> A few of us have discussed helping Axel set up a new build system to
> automate more of the tasks (like koji for Fedora). It really hasn't
> taken off just yet.

I'm in the process of putting together a koji for RedSleeve, but in
fairness I am not too sure what the advantage is relative to the
increase in complexity, compared to simply having a NFS path with all
the src.rpms and a 10 line shell script that puts down lock files and
fires up mock to build each package in turn (and copies the built
packages to a repository path, and saves the logs for any build
failures). Sure, koji is a bit more "enterprisey", but I just don't see
any fundamental benefit.

> Would you be willing to dedicate time to help build the ARM version of
> packages?

Absolutely, see above. The reason I ask is because I just had to build
mediawiki for el6-arm (from the atrpms src.rpm). This sort of thing
crops up all the time so I figured I can't be the only one that would
find this sort of thing useful. And of course it's nice not having to do
_everything_ myself. ;)

Gordan

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

Hi all,

I certainly interested in anything that interests ATrpms users. What
is needed to build ARM packages? Can one cross-build on x86_64? qemu?

But Brian is also right, the current pressing matter is to alter the
infrastructure in such a way to allow more contributors to have higher
levels of access including root access to some resources. ATM ATrpms
is hosted at the FU Berlin, and Jens Dreger, both a good friend of
mine and one of the higher IT responsibles around there, wants to help
upgrading/restructuring the hardware setup allowing for more degrees
of freedom.

But how can we help you ATM? BTW we are also not using koji, but self
written scripts. But maybe for scaling reasons koji does make
sense. So perhaps you'd even like to kojify ATrpms even outside of
ARM? :)

On Wed, May 02, 2012 at 02:00:15PM +0100, Gordan Bobic wrote:
> On 02/05/2012 13:48, Brian Long wrote:
> >Hi Gordan,
> >
> >I'm not sure how long you've been using ATrpms,
>
> Years.
>
> >but I believe someone
> >would need to step up and handle the builds and any issues that crop up.
>
> Indeed, but most packages tend to build and work OK. So as a first
> pass, having everything that builds as is from src.rpms would be
> nice. I'd be more than happy to look into any build failures. I can
> take all of atrpms src.rpm packages and rebuild them myself, but I
> don't want to diminish the value of other repositories by
> effectively usurping the work of the maintainers thus far.
>
> If there is no interest in supporthing ARM, then fine, I'll fork and
> maintain the ARM repository myself (same way I keep up with upstream
> - this wouldn't be any different).
>
> > We cannot just pile more work on Axel as I believe he's already
> >overloaded. :-)
>
> I get that, see above.
>
> >A few of us have discussed helping Axel set up a new build system to
> >automate more of the tasks (like koji for Fedora). It really hasn't
> >taken off just yet.
>
> I'm in the process of putting together a koji for RedSleeve, but in
> fairness I am not too sure what the advantage is relative to the
> increase in complexity, compared to simply having a NFS path with
> all the src.rpms and a 10 line shell script that puts down lock
> files and fires up mock to build each package in turn (and copies
> the built packages to a repository path, and saves the logs for any
> build failures). Sure, koji is a bit more "enterprisey", but I just
> don't see any fundamental benefit.
>
> >Would you be willing to dedicate time to help build the ARM version of
> >packages?
>
> Absolutely, see above. The reason I ask is because I just had to
> build mediawiki for el6-arm (from the atrpms src.rpm). This sort of
> thing crops up all the time so I figured I can't be the only one
> that would find this sort of thing useful. And of course it's nice
> not having to do _everything_ myself. ;)
>
> Gordan
>
> _______________________________________________
> atrpms-users mailing list
> atrpms-users@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-users
>

--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On 05/05/2012 09:03 AM, Axel Thimm wrote:
> Hi all,
>
> I certainly interested in anything that interests ATrpms users. What
> is needed to build ARM packages? Can one cross-build on x86_64? qemu?

You could use a cross compiler, but this would be against the usual
RH/Fedora build "rules" that require that all packages should be built
natively on the target architecture.

Qemu is an option but it can be quite painfully slow.

Having said that, there are a lot of affordable well supported ARM
machines that could be used, e.g. CuBox and hopefully soon the Raspberry Pi.

[...]


> But how can we help you ATM? BTW we are also not using koji, but self
> written scripts. But maybe for scaling reasons koji does make
> sense. So perhaps you'd even like to kojify ATrpms even outside of
> ARM? :)

I've been planning to get an ARM koji farm up and running in the near
future for precisely this reason. Since that is likely to sit idle most
of the time (except when a large set of packages are updated upstream),
there is no reason why this farm couldn't be used for building atrpms
packages for ARM. It would also mean that another maintainer (i.e. you
for atrpms packages) could submit packages for building. I am sure a
pattern list could then be applied to separate out the packages into
different suitable groups (upstream, atrpms, extras, etc.).

Gordan

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users