EPEL quick epel7 update

[Kevin Fenzi]

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

[Simone Caronni]

Hello,

On 16 June 2014 20:15, Kevin Fenzi  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

[Simone Caronni]

On 16 June 2014 21:03, Simone Caronni  wrote:
> On 16 June 2014 20:15, Kevin Fenzi  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

[Kevin Fenzi]

On Mon, 16 Jun 2014 21:12:57 +0200
Simone Caronni  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:
>
> https://fedorahosted.org/rel-eng/ticket/5915

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

[Simone Caronni]

On 16 June 2014 21:29, Kevin Fenzi  wrote:
> On Mon, 16 Jun 2014 21:12:57 +0200
> Simone Caronni  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:
> >
> > https://fedorahosted.org/rel-eng/ticket/5915
>
> 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

[Jim Perrin]

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.

[Stephen John Smoogen]

On 16 June 2014 16:59, Jim Perrin  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.

[Simone Caronni]

Hello,

thanks for your answers.

On 17 June 2014 00:59, Jim Perrin  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

[Jeff Sheltren]

On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni 
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

[Simone Caronni]

On 17 June 2014 16:07, Jeff Sheltren  wrote:
> On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni 
> 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

[Mathieu Bridon]

On Tue, 2014-06-17 at 16:14 +0200, Simone Caronni wrote:
> Mock is using CentOS:

[... snip ...]
> Don't know for Koji, but probably it's the same. No?

No, Koji uses RHEL as an external repo, and points its mock configs to
it.

[Kevin Fenzi]

On Tue, 17 Jun 2014 16:14:55 +0200
Simone Caronni  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

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 17 Jun 2014 16:14:55 +0200
Simone Caronni  wrote:
> On 17 June 2014 16:07, Jeff Sheltren  wrote:
> > On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni
> >  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-----

[Simone Caronni]

Ok, thanks for the multiple explanations :)

On 17 June 2014 16:27, Dennis Gilmore  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 17 Jun 2014 16:14:55 +0200
> Simone Caronni  wrote:
> > On 17 June 2014 16:07, Jeff Sheltren  wrote:
> > > On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni
> > >  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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[Kevin Fenzi]

On Mon, 16 Jun 2014 21:03:57 +0200
Simone Caronni  wrote:
> Hello,
>
> On 16 June 2014 20:15, Kevin Fenzi  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

[Simone Caronni]

On 16 June 2014 21:28, Kevin Fenzi  wrote:
> On Mon, 16 Jun 2014 21:03:57 +0200
> Simone Caronni  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

[Jim Perrin]

On 06/16/2014 02:39 PM, Simone Caronni wrote:
> On 16 June 2014 21:28, Kevin Fenzi  wrote:
> > On Mon, 16 Jun 2014 21:03:57 +0200
> > Simone Caronni  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.

[Orion Poplawski]

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.