Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Thanks, Jacob
Same here, love to see it supported. I have been compiling the content i need and have some patches to contribute to get them to build
Sent from my iPhone
On Jul 27, 2016, at 10:30 AM, Jacob Carey jacobcvt12@gmail.com wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Thanks, Jacob _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 07/27/2016 07:24 PM, Ed Brand wrote:
Same here, love to see it supported. I have been compiling the content i need and have some patches to contribute to get them to build
Sent from my iPhone
On Jul 27, 2016, at 10:30 AM, Jacob Carey jacobcvt12@gmail.com wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Thanks, Jacob
that's a nice thing to be discussed in flock.
Jacob, I'm just a dumbass user. I install whatever's available because I haven't worked at the kernel level since the early 90's. God I'm old! I just have a killer telescope guiding app I'm working on that needs the extra space for a Postgres DB (which for some reason successfully compiled on my Pi3!)...
Maybe our dreams will be realized soon....
-E
On Wednesday, July 27, 2016, Ed Brand ebrand0007@gmail.com wrote:
Same here, love to see it supported. I have been compiling the content i need and have some patches to contribute to get them to build
Sent from my iPhone
On Jul 27, 2016, at 10:30 AM, Jacob Carey <jacobcvt12@gmail.com
javascript:;> wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for
CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Thanks, Jacob _______________________________________________ Arm-dev mailing list Arm-dev@centos.org javascript:; https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org javascript:; https://lists.centos.org/mailman/listinfo/arm-dev
On 27/07/16 15:30, Jacob Carey wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Fabian started working on it, with results here : http://armv7.dev.centos.org/repodir/epel-pass-1/ its just a rpmbuild run through all of epel at the time, i am sure he could use some help ( or actually, I think it would be great to have someone from the community space step up and just take ownership of this )
Regards
On 27 July 2016 at 18:51, Karanbir Singh mail-lists@karan.org wrote:
On 27/07/16 15:30, Jacob Carey wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Fabian started working on it, with results here : http://armv7.dev.centos.org/repodir/epel-pass-1/ its just a rpmbuild run through all of epel at the time, i am sure he could use some help ( or actually, I think it would be great to have someone from the community space step up and just take ownership of this )
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
Regards
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
On 07/28/2016 07:09 AM, Johnny Hughes wrote:
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
To discuss this in a bit more detail:
1. If we are going to actually try to do what EPEL does on alt arches (That is, recruit individual maintainers for individual packages for different arches) .. then we need to do this on CBS
(hopefully that will not be necessary, hopefully EPEL will do this so that CentOS does not have to do a completely different program that is the same thing as EPEL).
2. If, in the interim (before EPEL does build these arches), we want to try to produce the things that build with little or no modification on a best effort type build .. well then, we would want to use the distro build system for the flexibility it gives. (You can build each arch independently, one arch does not impact the others, you can have modified packages between arches, etc. much more easily not using koji).
So, it really depends on what we are trying to accomplish.
On 28/07/16 13:18, Johnny Hughes wrote:
On 07/28/2016 07:09 AM, Johnny Hughes wrote:
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
To discuss this in a bit more detail:
- If we are going to actually try to do what EPEL does on alt arches
(That is, recruit individual maintainers for individual packages for different arches) .. then we need to do this on CBS
(hopefully that will not be necessary, hopefully EPEL will do this so that CentOS does not have to do a completely different program that is the same thing as EPEL).
- If, in the interim (before EPEL does build these arches), we want to
try to produce the things that build with little or no modification on a best effort type build .. well then, we would want to use the distro build system for the flexibility it gives. (You can build each arch independently, one arch does not impact the others, you can have modified packages between arches, etc. much more easily not using koji).
So, it really depends on what we are trying to accomplish.
the key here is to build the user story. at the moment there is none, all the above is the provider side which is easily replaced / discarded / rehashed as needed.
There are willing users on this thread. Just need access to the build systems. Is there a fedora group/SIG/sponsorship needed?
On 07/28/2016 08:23 AM, Karanbir Singh wrote:
On 28/07/16 13:18, Johnny Hughes wrote:
On 07/28/2016 07:09 AM, Johnny Hughes wrote:
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
To discuss this in a bit more detail:
- If we are going to actually try to do what EPEL does on alt arches
(That is, recruit individual maintainers for individual packages for different arches) .. then we need to do this on CBS
(hopefully that will not be necessary, hopefully EPEL will do this so that CentOS does not have to do a completely different program that is the same thing as EPEL).
- If, in the interim (before EPEL does build these arches), we want to
try to produce the things that build with little or no modification on a best effort type build .. well then, we would want to use the distro build system for the flexibility it gives. (You can build each arch independently, one arch does not impact the others, you can have modified packages between arches, etc. much more easily not using koji).
So, it really depends on what we are trying to accomplish.
the key here is to build the user story. at the moment there is none, all the above is the provider side which is easily replaced / discarded / rehashed as needed.
IMO what is needed is the definitive decision from the project maintainers on what the "correct" way of producing the EPEL package builds is.
Putting all the EPEL7 packages through mock is fairly trivial and wouldn't take more than a matter of days to churn through on an 8-core ARMv8 with tons of RAM.
The part that would be human-intensive is resolving the FTBFS issues for the (relatively small) number of packages that hit those.
On 2016-07-28 13:31, Ed Brand wrote:
There are willing users on this thread. Just need access to the build systems. Is there a fedora group/SIG/sponsorship needed?
On 07/28/2016 08:23 AM, Karanbir Singh wrote:
On 28/07/16 13:18, Johnny Hughes wrote:
On 07/28/2016 07:09 AM, Johnny Hughes wrote:
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote:
I believe it is still going through pass-2 or so. There are a couple of problems in that a couple of things which could be 'jump-started' from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora arm32 was not as available then. This means having to go to newer versions than what is in EPEL so the two chains do not meet. I have finally finished my move across the country and am able to start trying to get these together for a build tree. I will be happy to help people in the community if they step up.
thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
To discuss this in a bit more detail:
- If we are going to actually try to do what EPEL does on alt
arches (That is, recruit individual maintainers for individual packages for different arches) .. then we need to do this on CBS
(hopefully that will not be necessary, hopefully EPEL will do this so that CentOS does not have to do a completely different program that is the same thing as EPEL).
- If, in the interim (before EPEL does build these arches), we want
to try to produce the things that build with little or no modification on a best effort type build .. well then, we would want to use the distro build system for the flexibility it gives. (You can build each arch independently, one arch does not impact the others, you can have modified packages between arches, etc. much more easily not using koji).
So, it really depends on what we are trying to accomplish.
the key here is to build the user story. at the moment there is none, all the above is the provider side which is easily replaced / discarded / rehashed as needed.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 28/07/16 13:37, Gordan Bobic wrote:
IMO what is needed is the definitive decision from the project maintainers on what the "correct" way of producing the EPEL package builds is.
yup
lets thrash that out, arm32 isnt really project run, its a community supported effort thats largely unorganised. Fabian took it up on evenings and weekends to get it moving forward, and it was great bootstrap - but perhaps its time to organise the group better.
Johnny and I spoke a bit around this issue on IRC a few minutes back, for now it might be best to keep churning where the packages are - and then try to organise the effort collaboratively ( ie. lets not block the existing process waiting to get better organised ).
regards
Putting all the EPEL7 packages through mock is fairly trivial and wouldn't take more than a matter of days to churn through on an 8-core ARMv8 with tons of RAM.
The part that would be human-intensive is resolving the FTBFS issues for the (relatively small) number of packages that hit those.
On 2016-07-28 13:31, Ed Brand wrote:
There are willing users on this thread. Just need access to the build systems. Is there a fedora group/SIG/sponsorship needed?
On 07/28/2016 08:23 AM, Karanbir Singh wrote:
On 28/07/16 13:18, Johnny Hughes wrote:
On 07/28/2016 07:09 AM, Johnny Hughes wrote:
On 07/28/2016 06:57 AM, Karanbir Singh wrote:
On 28/07/16 01:26, Stephen John Smoogen wrote: > I believe it is still going through pass-2 or so. There are a couple > of problems in that a couple of things which could be 'jump-started' > from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora > arm32 > was not as available then. This means having to go to newer versions > than what is in EPEL so the two chains do not meet. I have finally > finished my move across the country and am able to start trying > to get > these together for a build tree. I will be happy to help people > in the > community if they step up. > thanks Stephen,
Would it help if we were to get some arm32 builders online behind cbs.centos.org / koji ?
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
To discuss this in a bit more detail:
- If we are going to actually try to do what EPEL does on alt arches
(That is, recruit individual maintainers for individual packages for different arches) .. then we need to do this on CBS
(hopefully that will not be necessary, hopefully EPEL will do this so that CentOS does not have to do a completely different program that is the same thing as EPEL).
- If, in the interim (before EPEL does build these arches), we
want to try to produce the things that build with little or no modification on a best effort type build .. well then, we would want to use the distro build system for the flexibility it gives. (You can build each arch independently, one arch does not impact the others, you can have modified packages between arches, etc. much more easily not using koji).
So, it really depends on what we are trying to accomplish.
the key here is to build the user story. at the moment there is none, all the above is the provider side which is easily replaced / discarded / rehashed as needed.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 28/07/16 13:09, Johnny Hughes wrote:
IMHO, we need to decide one way to try to build EPEL for alternative arches. If we want to use CBS, then we can do that.
Currently for both arm32 and aarch64 we are using the distro build and not koji for EPEL build.
but do we need to ? specially since that excludes anyone from being able to help, and the epel process has been exceptionally slow, given that it was kicked off in Feb.
ideally, epel would do the arch builds on their own - but the lack of interest there just points at us helping a community come and do it here right ?
I don't really have a preference but we need to define the process and stick to it and not keep hopping around.
We do need koji arm32 builders for SIG content regardless of how we do EPEL.
But shifting systems mid stream (ie, we are building EPEL now) is not the best idea.
I dont think it would be midstream, we can just resend the entire rpm stack up into cbs and there are more cbs builders for ex for aarch64.
On 28/07/16 00:51, Karanbir Singh wrote:
On 27/07/16 15:30, Jacob Carey wrote:
Hi all,
About a year ago, someone posted here and asked if there were plans for CentOS to host a repository for EPEL7 for ARM. I can't find any more recent discussions so my question is - what can I do to help maintain/introduce such an auxiliary repository?
Fabian started working on it, with results here : http://armv7.dev.centos.org/repodir/epel-pass-1/ its just a rpmbuild run through all of epel at the time, i am sure he could use some help ( or actually, I think it would be great to have someone from the community space step up and just take ownership of this )
Regards
Yes, at the moment it's more a less a (dumb) wrapper script that : - rsync epel SRPMS and watch new packages - submit those in the epel build queue (plague build farm)
We initially launched that as some people had a need for specific pkgs from Epel for their CentOS armhfp installs (like openvpn, etc) My hope was that it would be then be built "officially" upstream (so Epel level) but I don't know their plan
-
Ed Anderson -
Ed Brand -
Fabian Arrotin -
Gordan Bobic -
Itamar Reis Peixoto -
Jacob Carey -
Johnny Hughes -
Karanbir Singh -
Stephen John Smoogen