Just a quick update:
* I am working to get the final rhel7 content lined up for building against in koji, as soon as that goes live I'll drop a note here.
* When do we want to look at leaving beta status for epel7? I'd suggest we should definitely give CentOS time to release, but should we have any other critera?
* There's a number of broken deps in the repo currently. Before leaving beta should we drop packages with broken deps? I'd really prefer not to ship with any. We could also force all packages with broken deps into testing or something.
* When should we retire the epel7 wiki page for requests? I think personally, I would be ok dropping that now.
Any other thoughts around epel7?
kevin
Hello,
On 16 June 2014 20:15, Kevin Fenzi kevin@scrye.com wrote:
- When do we want to look at leaving beta status for epel7?
I'd suggest we should definitely give CentOS time to release, but should we have any other critera?
I would really, really like to have CentOS 7 available before the final release. CentOS 7 is being built also for i386 and that would mean a lot of semplification into adding packages in EPEL 7. Right now the situation is a bit weird as many multilib dependencies cannot be satisfied and there are many obstacles in getting i386 binaries to run.
Thanks, --Simone
On 16 June 2014 21:03, Simone Caronni negativo17@gmail.com wrote:
On 16 June 2014 20:15, Kevin Fenzi kevin@scrye.com wrote:
- When do we want to look at leaving beta status for epel7?
I'd suggest we should definitely give CentOS time to release, but should we have any other critera?
I would really, really like to have CentOS 7 available before the final release. CentOS 7 is being built also for i386 and that would mean a lot of semplification into adding packages in EPEL 7. Right now the situation is a bit weird as many multilib dependencies cannot be satisfied and there are many obstacles in getting i386 binaries to run.
Another thing, there are packages that are spread into multiple upstream optional channels that make it impossible to include some packages in the distribution.
One thread here:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-June/009600.html
Releng ticket here:
https://fedorahosted.org/rel-eng/ticket/5915
As far as I know in CentOS all packages and subpackages are part of the distribution, so this could be another reason to wait for the CentOS release.
Just my 2c.
Regards, --Simone
On Mon, 16 Jun 2014 21:12:57 +0200 Simone Caronni negativo17@gmail.com wrote:
Another thing, there are packages that are spread into multiple upstream optional channels that make it impossible to include some packages in the distribution.
One thread here:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-June/009600.html
Releng ticket here:
But thats NOT the case there... for some reason those packages aren't appearing in koji buildroots, but they _ARE_ in the base repos.
So, there's a bug/issue there, but not the one you are thinking...
I was hoping to have the final trees setup before trying to debug this.
As far as I know in CentOS all packages and subpackages are part of the distribution, so this could be another reason to wait for the CentOS release.
I don't think I follow here.
kevin
On 16 June 2014 21:29, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 16 Jun 2014 21:12:57 +0200 Simone Caronni negativo17@gmail.com wrote:
Another thing, there are packages that are spread into multiple upstream optional channels that make it impossible to include some packages in the distribution.
One thread here:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-June/009600.html
Releng ticket here:
But thats NOT the case there... for some reason those packages aren't appearing in koji buildroots, but they _ARE_ in the base repos.
So, there's a bug/issue there, but not the one you are thinking...
I was hoping to have the final trees setup before trying to debug this.
Well, the example in the bug is not the exact "proof" but there are other packages which are dispersed in the various channels, so I don't think adding only server-7 and server-7-optional as it is now would suffice.
I was about to point to the RC trees (which included all the variants) but the link has been removed and in my Redhat account I only have Server and RHEV available; so I can't point you to the example. :(
By memory there was Server, Server-optional, Workstation, Workstation Optional, etc.
As far as I know in CentOS all packages and subpackages are part of
the distribution, so this could be another reason to wait for the CentOS release.
I don't think I follow here.
In previous releases CentOS was inserting in the distribution all the packages that make up the full spectrum of RHEL variants, so in version 6 it included for example the Workstation channel and a full Workstation was installable for CentOS 6 (in fact all the content never fit into 1 dvd). As far as I know they are not changing this policy.
By using CentOS as the basis and not RHEL 7 we could have all the channels that are not used at the moment for building.
Regards, --Simone
On 06/16/2014 02:49 PM, Simone Caronni wrote:
In previous releases CentOS was inserting in the distribution all the packages that make up the full spectrum of RHEL variants, so in version 6 it included for example the Workstation channel and a full Workstation was installable for CentOS 6 (in fact all the content never fit into 1 dvd). As far as I know they are not changing this policy.
We aren't.
By using CentOS as the basis and not RHEL 7 we could have all the channels that are not used at the moment for building.
As much as I'd like to see CentOS as the basis for *everything* (I may be a bit biased here), I don't think this is a good idea.
RHEL packages by their very nature will come out first. This puts EPEL in a position to work with them immediately, and to remain impartial across the rebuilding community (springdale/puias, centos, SL, that database company, etc). If CentOS lags behind for some unforseen reason, why put everyone else out until we get our act together? Same with every other rebuild. We know RHEL packages will be out on time every time because they're the ones delivering them.
To me, the only current time it would make sense for CentOS to be the base repo would be for something RHEL doesn't ship, such as x86 or other arch.
On 16 June 2014 16:59, Jim Perrin jperrin@centos.org wrote:
On 06/16/2014 02:49 PM, Simone Caronni wrote:
In previous releases CentOS was inserting in the distribution all the packages that make up the full spectrum of RHEL variants, so in version 6 it included for example the Workstation channel and a full Workstation
was
installable for CentOS 6 (in fact all the content never fit into 1 dvd).
As
far as I know they are not changing this policy.
We aren't.
By using CentOS as the basis and not RHEL 7 we could have all the
channels
that are not used at the moment for building.
As much as I'd like to see CentOS as the basis for *everything* (I may be a bit biased here), I don't think this is a good idea.
RHEL packages by their very nature will come out first. This puts EPEL in a position to work with them immediately, and to remain impartial across the rebuilding community (springdale/puias, centos, SL, that database company, etc). If CentOS lags behind for some unforseen reason, why put everyone else out until we get our act together? Same with every other rebuild. We know RHEL packages will be out on time every time because they're the ones delivering them.
To me, the only current time it would make sense for CentOS to be the base repo would be for something RHEL doesn't ship, such as x86 or other arch.
Well there are 3 reasons I could see:
1) Community alignment. The CentOS people are enterprise-ee and have a better idea of what is important to use in those environments than the Fedora maintainer who may just be building it but not testing or knowing if it works.
2) Let us face it.. building against RHEL is a pain in batookis. We may have to argue over what channels we consider essential and which ones aren't. We have to then deal with the 2-3 packages which show up per release where if something is built against it but you only have Server entitlements now you can't install the mediawiki because it pulled in Workstations TeX libraries. [Made up example.. it was something close to that but I forget which.] You build against CentOS core and what is there you know everyone has.
3) You guys go to a lot of shows and it would be nice if EPEL people could go too :). I guess that is closer to one but more self-serving.
Hello,
thanks for your answers.
On 17 June 2014 00:59, Jim Perrin jperrin@centos.org wrote:
By using CentOS as the basis and not RHEL 7 we could have all the
channels
that are not used at the moment for building.
As much as I'd like to see CentOS as the basis for *everything* (I may be a bit biased here), I don't think this is a good idea.
RHEL packages by their very nature will come out first. This puts EPEL in a position to work with them immediately, and to remain impartial across the rebuilding community (springdale/puias, centos, SL, that database company, etc). If CentOS lags behind for some unforseen reason, why put everyone else out until we get our act together? Same with every other rebuild. We know RHEL packages will be out on time every time because they're the ones delivering them.
Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock buildroots? 32 bit aside, what is the difference for 7? This has been dealt nicely so far.
To me, the only current time it would make sense for CentOS to be the base repo would be for something RHEL doesn't ship, such as x86 or other arch.
Considering we had CentOS in the buildroots, how have updates been managed up to now? From my experience I can see CentOS package updates come almost immediately after RHEL ones.
Regards, --Simone
On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni negativo17@gmail.com wrote:
Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock buildroots? 32 bit aside, what is the difference for 7? This has been dealt nicely so far.
No, EPEL has always used RHEL for builds.
-Jeff
On 17 June 2014 16:07, Jeff Sheltren jeff@tag1consulting.com wrote:
On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni negativo17@gmail.com wrote:
Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock buildroots? 32 bit aside, what is the difference for 7? This has been dealt nicely so far.
No, EPEL has always used RHEL for builds.
Mock is using CentOS:
$ pwd /var/cache/mock/epel-6-x86_64/yum_cache/updates/packages $ ls -al *centos* -rw-rw-r--. 1 root mock 20960 May 20 15:33 centos-release-6-5.el6.centos.11.2.x86_64.rpm -rw-rw-r--. 1 root mock 962780 May 20 15:33 initscripts-9.03.40-2.el6.centos.1.x86_64.rpm $ cat /etc/mock/epel-6-x86_64.cfg | grep -i centos mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates
Don't know for Koji, but probably it's the same. No?
--Simone
On Tue, 17 Jun 2014 16:14:55 +0200 Simone Caronni negativo17@gmail.com wrote:
Mock is using CentOS:
$ pwd /var/cache/mock/epel-6-x86_64/yum_cache/updates/packages $ ls -al *centos* -rw-rw-r--. 1 root mock 20960 May 20 15:33 centos-release-6-5.el6.centos.11.2.x86_64.rpm -rw-rw-r--. 1 root mock 962780 May 20 15:33 initscripts-9.03.40-2.el6.centos.1.x86_64.rpm $ cat /etc/mock/epel-6-x86_64.cfg | grep -i centos mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates
Don't know for Koji, but probably it's the same. No?
no.
koji has not now, nor never used CentOS.
Mock points to centos because there's no way it can point to rhel as it's not feely available to everyone to download.
koji uses RHEL, setup as remote repos so the packages are only usable for it's builds, not downloadable by others.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 17 Jun 2014 16:14:55 +0200 Simone Caronni negativo17@gmail.com wrote:
On 17 June 2014 16:07, Jeff Sheltren jeff@tag1consulting.com wrote:
On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni negativo17@gmail.com wrote:
Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock buildroots? 32 bit aside, what is the difference for 7? This has been dealt nicely so far.
No, EPEL has always used RHEL for builds.
Mock is using CentOS:
$ pwd /var/cache/mock/epel-6-x86_64/yum_cache/updates/packages $ ls -al *centos* -rw-rw-r--. 1 root mock 20960 May 20 15:33 centos-release-6-5.el6.centos.11.2.x86_64.rpm -rw-rw-r--. 1 root mock 962780 May 20 15:33 initscripts-9.03.40-2.el6.centos.1.x86_64.rpm $ cat /etc/mock/epel-6-x86_64.cfg | grep -i centos mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates
Don't know for Koji, but probably it's the same. No?
--Simone
mock uses centos, and it will continue to do so. why? because there is no rhel we can point at. but in koji we build against RHEL always have.
Dennis
Ok, thanks for the multiple explanations :)
On 17 June 2014 16:27, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 17 Jun 2014 16:14:55 +0200 Simone Caronni negativo17@gmail.com wrote:
On 17 June 2014 16:07, Jeff Sheltren jeff@tag1consulting.com wrote:
On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni negativo17@gmail.com wrote:
Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock buildroots? 32 bit aside, what is the difference for 7? This has been dealt nicely so far.
No, EPEL has always used RHEL for builds.
Mock is using CentOS:
$ pwd /var/cache/mock/epel-6-x86_64/yum_cache/updates/packages $ ls -al *centos* -rw-rw-r--. 1 root mock 20960 May 20 15:33 centos-release-6-5.el6.centos.11.2.x86_64.rpm -rw-rw-r--. 1 root mock 962780 May 20 15:33 initscripts-9.03.40-2.el6.centos.1.x86_64.rpm $ cat /etc/mock/epel-6-x86_64.cfg | grep -i centos mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os mirrorlist=
http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates
Don't know for Koji, but probably it's the same. No?
--Simone
mock uses centos, and it will continue to do so. why? because there is no rhel we can point at. but in koji we build against RHEL always have.
Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJToFBfAAoJEH7ltONmPFDR4C8P/j6SxdKIlB/LACHSmqCs1YYv j6jfoGvH88vgBz5YxRd0py1EUr1e0jkBOtgX5Xihl46PtigmDr0hBqIWE4k9f7Wu FJB108jC8kD40nAm6EfJbvYegcSB+qAVCd9CepEETmx6Mj+3LCkOJZj8+3ZWwons zmVqpOkCCEn+HVY2yfV53xFbhYms5POnW84maqsr6NDMqLDRsdXHQ4HRNJvRKkfp BOfbXLnw6P7OPvRmFvz9zu2FImclvqaq3GnAv3xLHYY+d1GzQq4Cb/k5AFfyUyG0 6f4X+wcN4mg7+9bUVvs3qhUQYN4u+iCtfL7OejegLHIPyZ0YsFaARYl21iGbpj3r UfVOX2y0cWUvkD9aj6UGF/CfXPkBtTvhLoODfFVk3z1QlRTu8xLupY9+32comjVe lWJkp4BMFpdhNbslnFs9+Ur4htXl/2JEyzs3LSfzx+Tirio+pVmmcMzV1GZgq4j2 Gda7kLXBfhF/3kNtFxgxCa7UhlCW3ZBcguuhOXalWn6qXpldC/SQJNPjabrIR8Lb WpO40eFmNQXFtqvzkJuRhiEeQzefN0FIyAyBLduVeKw+xtkcUC1Sy17eXLSkxDbo rqk0f28JIR2KQD/1rB2x24S4nhzt1w/RWt3WkMm3cGc9CUkguSDN48/jnN6A5UbN tcAqEmN76oZmZbH/jLGI =qixR -----END PGP SIGNATURE----- _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Mon, 16 Jun 2014 21:03:57 +0200 Simone Caronni negativo17@gmail.com wrote:
Hello,
On 16 June 2014 20:15, Kevin Fenzi kevin@scrye.com wrote:
- When do we want to look at leaving beta status for epel7?
I'd suggest we should definitely give CentOS time to release, but should we have any other critera?
I would really, really like to have CentOS 7 available before the final release.
I don't disagree. ;)
CentOS 7 is being built also for i386 and that would mean a lot of semplification into adding packages in EPEL 7. Right now the situation is a bit weird as many multilib dependencies cannot be satisfied and there are many obstacles in getting i386 binaries to run.
That however, is another kettle of fish. ;)
So, you are suggesting we move to building against CentOS instead of RHEL and support 32bit? Where is the CentOS 32bit effort at?
kevin
On 16 June 2014 21:28, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 16 Jun 2014 21:03:57 +0200 Simone Caronni negativo17@gmail.com wrote:
CentOS 7 is being built also for i386 and that would mean a lot of semplification into adding packages in EPEL 7. Right now the situation is a bit weird as many multilib dependencies cannot be satisfied and there are many obstacles in getting i386 binaries to run.
That however, is another kettle of fish. ;)
So, you are suggesting we move to building against CentOS instead of RHEL and support 32bit? Where is the CentOS 32bit effort at?
As far as I know they are coming out with a completely installable i386 tree on release date. A quick look hints that all of the packages are being built for 32 bit as well:
Kernel example:
http://buildlogs.centos.org/c7.00.04/kernel/20140612172658/
--Simone
On 06/16/2014 02:39 PM, Simone Caronni wrote:
On 16 June 2014 21:28, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 16 Jun 2014 21:03:57 +0200 Simone Caronni negativo17@gmail.com wrote:
CentOS 7 is being built also for i386 and that would mean a lot of semplification into adding packages in EPEL 7. Right now the situation is a bit weird as many multilib dependencies cannot be satisfied and there are many obstacles in getting i386 binaries to run.
That however, is another kettle of fish. ;)
So, you are suggesting we move to building against CentOS instead of RHEL and support 32bit? Where is the CentOS 32bit effort at?
As far as I know they are coming out with a completely installable i386 tree on release date. A quick look hints that all of the packages are being built for 32 bit as well:
We are doing this, however not as the core distribution, but as a special interest group effort. We cannot promise that we can sustain it for the full life of EL7.
I had cornered Kevin and Dennis earlier this year to discuss the possibility of adding the 32bit version as a secondary arch, however they both (wisely) wanted to see how it turned out before committing.
Since we're the only ones doing 32bit that I'm aware of, it has less user impact. Lets get EPEL7 proper out the door first and then openly discuss adding the x86 secondary arch.
On 06/16/2014 12:15 PM, Kevin Fenzi wrote:
Just a quick update:
- I am working to get the final rhel7 content lined up for building against in koji, as soon as that goes live I'll drop a note here.
Great, thanks.
- When do we want to look at leaving beta status for epel7?
I'd suggest we should definitely give CentOS time to release, but should we have any other critera?
That seems like a reasonable criterie.
- There's a number of broken deps in the repo currently. Before leaving beta should we drop packages with broken deps? I'd really prefer not to ship with any. We could also force all packages with broken deps into testing or something.
We need a broken deps report as well. I'm fine with either dropping or moving to testing.
- When should we retire the epel7 wiki page for requests? I think personally, I would be ok dropping that now.
I'm still finding chunks of packages to branch, so I'd like to keep it for a while longer. Still haven't built octave and packages yet.
Any other thoughts around epel7?
I'd still like a python 3 solution that allows us to build python3 packages directly as done in Fedora, but I just don't have time to do much more here.
epel-devel@lists.fedoraproject.org