Re: EPEL Python 3 for 7?
On Fri, 17 Jan 2014 08:00:58 -0500 Stephen Gallagher wrote: > My thoughts are these (in no particular order). > * Treat this branch like Rawhide. All builds targeted at this are > composed to a repo. Signing is nice, but not mandatory in my opinion. It's pretty much impossible to sign rawhide style repos. ;) > * When rhel7.1 comes out, there is no automatic movement from > epel7-pending into the epel branch. We open a merge window where > packages are allowed to merge from the epel7-pending git branch. > Merging a major upgrade outside this window is forbidden. At this > time, any packager that believes their package is ready for prime-time > may manually perform a merge, build and submission to Bodhi. ok. How long does the merge window last? Can people push to stable during this? Or everything stays in testing until the window closes? > I think we could set a policy of "merge window opens one week after > official RHEL release and remains open for two/three weeks after > that". Packages have to go through Bodhi approval for upgrade (perhaps > we mandate at least one positive karma review on major upgrades?) > which may take longer than the merge window, but they have to be > submitted within that time. This leaves people using enterprise linux rebuilds in a bad place since they don't have the new release to test with. Only once they have upgraded would they be able to be sure the packages are good for the new release. This also means that many folks will delay the update on many of their machines (7.0->7.1) until the window is over and they can update epel stuff at the same time. Otherwise they have to schedule 2 big updates (the 7.0->7.1 and the epel merge window closing). > The majority isn't necessarily as interesting as the popular packages. Well, it's like anything else... "I don't care about any packages except this specific ones that I really really care about" :) > There are plenty of people out there who want to see new Django, > Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade > in EPEL 6 today because they aren't fully backwards-compatible. Well, Django is a interesting one... whats wrong with the forward compat packages there? Install Django14 Update to Django15 and do the incompatible update lather, rinse, repeat. I know, the pain there is the packaging... > COPRs is really a workaround for (IMHO) a failure of policy in EPEL to > remain useful as the world moves ahead. It's pretty unrealistic to > expect volunteer package maintainers to support their packages for the > same duration that Red Hat supports RHEL (currently ten years for RHEL > 5 and 6). I think we're discouraging community inclusion if we don't > offer people a policy that allows them to keep their package closer to > upstream for reduced maintenance effort. Well, I think lots of people do find EPEL useful. I know I do. It's a balancing act. Lots of different groups want different things. Additionally, it's hard to say what most EPEL consumers want because they aren't very vocal, they just consume. ;) What about Toshios ideas of allowing conflicts: We add a EPEL specific guideline that allows forward compat packages to NOT be parallel installable, as long as they conflict with the other versions of that package. Would that get us to a better place? That reduces the problems with making parallel installable compat packages, you simply need to adjust the names and pass review. kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 01:57:18PM -0500, Matthew Miller wrote: > On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote: > > > Packages for Infrastructure and Clouds, I think). I was thinking about > > > this > > > more recently in the context of "things we need for Fedora.next in the > > > coming year or so". The new repo might target both EL and Fedora and > > > provide > > > alternative versions maintained on, say, a 3-year lifecycle. > > Yeah -- I think that something like this could be good. A repo with > > a 3 year lifecycle may make sense for RHEL more than Fedora as the > > basesystem we're building on is still active at the end of that period. > > I'm thinking here about SCLs (or possibly other stack/env tech) that might > target current supported Fedora but have a longer lifecyle of its own (with > best-effort compatibility for three years). > > I keep coming back to this idea because it's what people ask me for. :) > Ah I see. I think present thinking around SCLs has revolved around lifetime for indivudal SCLs but having a repository wide lifetime could be either better or a useful additional guarantee. -Toshio pgpC7ZOTAYkVO.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote: > > Packages for Infrastructure and Clouds, I think). I was thinking about this > > more recently in the context of "things we need for Fedora.next in the > > coming year or so". The new repo might target both EL and Fedora and provide > > alternative versions maintained on, say, a 3-year lifecycle. > Yeah -- I think that something like this could be good. A repo with > a 3 year lifecycle may make sense for RHEL more than Fedora as the > basesystem we're building on is still active at the end of that period. I'm thinking here about SCLs (or possibly other stack/env tech) that might target current supported Fedora but have a longer lifecyle of its own (with best-effort compatibility for three years). I keep coming back to this idea because it's what people ask me for. :) -- Matthew Miller-- Fedora Project-- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote: > On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote: > > > system.so we've mostly decided that things in the system shouldn't use > > > SCLs > > > to work. So we still need to solve the problem of newer python > > > interpreter > > > and newer django framework for use with apps that EPEL ships. > > What about having a separate EPEL repo for SCLs and/or these newest version > > of things? Like you mentioned before, this takes more work, but if then > > those that want the stable base can have it and those that want the newest > > can have it as well. > The problem I'm raising is that SCLs don't solve the problem that sgallagh is wanting to address by current policy. He has applications (ReviewBoard) that need newer versions of a framework (django) in order to run. For us to ship reviewboard in EPEL, we'd need to figure out if we want to allow that and how. Possible options are: * ReviewBoard is in its own SCL. The SCL deps on the appropriate django SCL. * ReviewBoard is not in an SCL and we allow mainstream packages to dep on SCLs. We need to figure out guidance on how a package can enable an scl for its own use as well. Either of these may exacerbate the problem of an enabled scl polluting other applications (especially hard if we get into invoking other processes from that application... env variables like LD_LIBRRY_PATH will probably get passed onto the invoked process). > Or possibly an additional sub-project separate from EPEL. The idea has been > kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra > Packages for Infrastructure and Clouds, I think). I was thinking about this > more recently in the context of "things we need for Fedora.next in the > coming year or so". The new repo might target both EL and Fedora and provide > alternative versions maintained on, say, a 3-year lifecycle. > Yeah -- I think that something like this could be good. A repo with a 3 year lifecycle may make sense for RHEL more than Fedora as the basesystem we're building on is still active at the end of that period. pgpRdL8QZ1AjJ.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote: > > system.so we've mostly decided that things in the system shouldn't use SCLs > > to work. So we still need to solve the problem of newer python interpreter > > and newer django framework for use with apps that EPEL ships. > What about having a separate EPEL repo for SCLs and/or these newest version > of things? Like you mentioned before, this takes more work, but if then > those that want the stable base can have it and those that want the newest > can have it as well. Or possibly an additional sub-project separate from EPEL. The idea has been kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra Packages for Infrastructure and Clouds, I think). I was thinking about this more recently in the context of "things we need for Fedora.next in the coming year or so". The new repo might target both EL and Fedora and provide alternative versions maintained on, say, a 3-year lifecycle. -- Matthew Miller-- Fedora Project-- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/16/2014 10:14 AM, Kevin Fenzi wrote: > > On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher > > wrote: > > > >> Perhaps this would be a good time to reopen the conversation of > >> minor-release policy changes? > > > > Sure. > > > >> RHEL releases approximately every six months with a minor > >> release. It seems fair to allow major EPEL upgrades to occur in > >> sync with those releases as well. > >> > >> So my suggestion would be that EPEL should have two branches for > >> EPEL 7: the epel7 branch and the epel7-pending branch. The idea > >> of this second branch would be sort of an EPEL Rawhide, where > >> major upgrades can be staged. Then, when RHEL releases a minor > >> update (such as RHEL 7.1), we have a (one-month?) integration > >> period where we ensure that packages in epel7-pending work on the > >> newest minor release and then they are merged back to epel7. If > >> they miss this merge window, they have to wait until the next > >> minor release. > >> > >> This allows us a regular, planned ability to move to newer EPEL > >> packages, without destabilizing EPEL in general. > > > > ok, issues/thoughts: > > > > * Another branch is a fair bit more work rel-eng and infra wise. > > Would they be completely seperate? How do we merge them at a update > > point? > > > > ie, say I have foo. I have 1.0 in epel7 and push 1.2 to > > epel7-pending. Does the epel7-pending one use bodhi? Does it get > > signed and composed and push to a repo somewhere? now, say rhel7.1 > > comes out. How do we reconcile the two branches/trees/composes? > > > > My thoughts are these (in no particular order). > * Treat this branch like Rawhide. All builds targeted at this are > composed to a repo. Signing is nice, but not mandatory in my opinion. > * When rhel7.1 comes out, there is no automatic movement from > epel7-pending into the epel branch. We open a merge window where > packages are allowed to merge from the epel7-pending git branch. > Merging a major upgrade outside this window is forbidden. At this > time, any packager that believes their package is ready for prime-time > may manually perform a merge, build and submission to Bodhi. > > > > * The change point seems like it would be kinda fluid, which would > > not be great expectation wise. Ie, say rhel7.1 comes out. How long > > after that do we wait to push the changes? We can't really do it > > the same time, as we won't know for sure what that will be. We > > could do it as soon as it's public, but then enterprise rebuilds > > aren't ready yet. We could wait for CentOS, but then do we wait for > > SL? OEL? Do we tell users "it can happen some random time after a > > minor release, please pay attention"? > > > > I think we could set a policy of "merge window opens one week after > official RHEL release and remains open for two/three weeks after > that". Packages have to go through Bodhi approval for upgrade (perhaps > we mandate at least one positive karma review on major upgrades?) > which may take longer than the merge window, but they have to be > submitted within that time. > > > > * The majority of epel packages I think don't care about this. > > It's only a subset. Perhaps we could do something with them? Move > > them to coprs, get them in as CentOS variants, something? > > > > The majority isn't necessarily as interesting as the popular packages. > There are plenty of people out there who want to see new Django, > Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade > in EPEL 6 today because they aren't fully backwards-compatible. > > COPRs is really a workaround for (IMHO) a failure of policy in EPEL to > remain useful as the world moves ahead. It's pretty unrealistic to > expect volunteer package maintainers to support their packages for the > same duration that Red Hat supports RHEL (currently ten years for RHEL > 5 and 6). I think we're discouraging community inclusion if we don't > offer people a policy that allows them to keep their package closer to > upstream for reduced maintenance effort. > Yes, this makes the experience better for maintainers, but makes the experience worse for users and developers of existing tools/infrastructure. All the RHEL users I know choose it because they want a stable platform that isn't changing every 6 months to a year. Like Toshio mentioned before, existing projects want what's there to stay there and new projects want the latest and greatest. The EL mentality is "stable and predictable" and the Fedora mentality is "latest and greatest", so I think that both options are there for those that want them and I don't think that changing EL to be more Fedora like is a good thing. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Thu, Jan 16, 2014 at 6:28 PM, Toshio Kuratomi wrote: > On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote: > > > > Wouldn't this be a perfect use case for Software Collections? > > > > > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/ > > Software_Collections_Guide/index.html > > > I was considering this earlier and I'm a bit conflicted about that. > There's > several problems with this. The most obvious is that SCLs are rather > coarse > grained and we want to solve this for both the coarse grained stuff like > (python interpreter) and fine grained things (like upgrading a single > library) > > The second problem is that we don't just want these things for users to > use. We also > want them for our own use. But SCLs are meant to be isolated from the > system.so we've mostly decided that things in the system shouldn't use SCLs > to work. So we still need to solve the problem of newer python interpreter > and newer django framework for use with apps that EPEL ships. > What about having a separate EPEL repo for SCLs and/or these newest version of things? Like you mentioned before, this takes more work, but if then those that want the stable base can have it and those that want the newest can have it as well. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL mock configs for epel7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 10:40 AM, Miro Hrončok wrote: > Dne 16.1.2014 16:38, Ken Dreyer napsal(a): >> Would anyone mind sharing their mock configurations for EPEL 7? > > I've got this http://ur1.ca/gfot7 > That's pretty close to https://bugzilla.redhat.com/show_bug.cgi?id=1041480#c4 which is what we're using for the COPR epel7 mock config now. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLZKuwACgkQeiVVYja6o6Pu/ACgmb8eB8xBCH2GJwTlt3TEKEQg P5YAmQEgmBPE/SGouFILzYGx4Ym6ini+ =DHVy -END PGP SIGNATURE- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 10:14 AM, Kevin Fenzi wrote: > On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher > wrote: > >> Perhaps this would be a good time to reopen the conversation of >> minor-release policy changes? > > Sure. > >> RHEL releases approximately every six months with a minor >> release. It seems fair to allow major EPEL upgrades to occur in >> sync with those releases as well. >> >> So my suggestion would be that EPEL should have two branches for >> EPEL 7: the epel7 branch and the epel7-pending branch. The idea >> of this second branch would be sort of an EPEL Rawhide, where >> major upgrades can be staged. Then, when RHEL releases a minor >> update (such as RHEL 7.1), we have a (one-month?) integration >> period where we ensure that packages in epel7-pending work on the >> newest minor release and then they are merged back to epel7. If >> they miss this merge window, they have to wait until the next >> minor release. >> >> This allows us a regular, planned ability to move to newer EPEL >> packages, without destabilizing EPEL in general. > > ok, issues/thoughts: > > * Another branch is a fair bit more work rel-eng and infra wise. > Would they be completely seperate? How do we merge them at a update > point? > > ie, say I have foo. I have 1.0 in epel7 and push 1.2 to > epel7-pending. Does the epel7-pending one use bodhi? Does it get > signed and composed and push to a repo somewhere? now, say rhel7.1 > comes out. How do we reconcile the two branches/trees/composes? > My thoughts are these (in no particular order). * Treat this branch like Rawhide. All builds targeted at this are composed to a repo. Signing is nice, but not mandatory in my opinion. * When rhel7.1 comes out, there is no automatic movement from epel7-pending into the epel branch. We open a merge window where packages are allowed to merge from the epel7-pending git branch. Merging a major upgrade outside this window is forbidden. At this time, any packager that believes their package is ready for prime-time may manually perform a merge, build and submission to Bodhi. > * The change point seems like it would be kinda fluid, which would > not be great expectation wise. Ie, say rhel7.1 comes out. How long > after that do we wait to push the changes? We can't really do it > the same time, as we won't know for sure what that will be. We > could do it as soon as it's public, but then enterprise rebuilds > aren't ready yet. We could wait for CentOS, but then do we wait for > SL? OEL? Do we tell users "it can happen some random time after a > minor release, please pay attention"? > I think we could set a policy of "merge window opens one week after official RHEL release and remains open for two/three weeks after that". Packages have to go through Bodhi approval for upgrade (perhaps we mandate at least one positive karma review on major upgrades?) which may take longer than the merge window, but they have to be submitted within that time. > * The majority of epel packages I think don't care about this. > It's only a subset. Perhaps we could do something with them? Move > them to coprs, get them in as CentOS variants, something? > The majority isn't necessarily as interesting as the popular packages. There are plenty of people out there who want to see new Django, Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade in EPEL 6 today because they aren't fully backwards-compatible. COPRs is really a workaround for (IMHO) a failure of policy in EPEL to remain useful as the world moves ahead. It's pretty unrealistic to expect volunteer package maintainers to support their packages for the same duration that Red Hat supports RHEL (currently ten years for RHEL 5 and 6). I think we're discouraging community inclusion if we don't offer people a policy that allows them to keep their package closer to upstream for reduced maintenance effort. >> In order to not make this a willy-nilly breakage every six >> months, we might want to set some limits (or at least guidelines) >> on what is or is not allowed to upgrade at the minor release. But >> I'd be fine with deferring making such decisions until we have a >> demonstrated need (i.e. fix it only if packages/EPEL is actually >> breaking). > > Sure, agreed. > > kevin > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLZKYoACgkQeiVVYja6o6N1OQCfdjqz1iSCBa2UuHmNJXgwvLHv oIwAoIfjRDbLiIreJ9bIIFflNaAg1vY6 =8gY5 -END PGP SIGNATURE- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL epel beta report: 20140117 changes
Compose started at Fri Jan 17 08:15:03 UTC 2014 Broken deps for x86_64 -- ansible-1.4.3-1.el7.noarch requires python-paramiko ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) gnucash-docs-2.6.0-1.el7.noarch requires gnucash >= 0:2.2.1-4 imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) inn-2.5.3-18.el7.x86_64 requires perl(MIME::Parser) koji-vm-1.8.0-2.el7.noarch requires python-virtinst mimedefang-2.74-1.el7.x86_64 requires perl(MIME::Words) mimedefang-2.74-1.el7.x86_64 requires perl(MIME::Tools) >= 0:5.410 mimedefang-2.74-1.el7.x86_64 requires perl(MIME::Parser) mod_perl-2.0.8-5.20131031svn1537408.el7.x86_64 requires perl(Linux::Pid) mod_perl-2.0.8-5.20131031svn1537408.el7.x86_64 requires perl(BSD::Resource) perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires ruby(shadow) puppet-3.4.2-2.el7.noarch requires hiera >= 0:1.0.0 python-fedora-flask-0.3.32.3-4.el7.noarch requires python-flask python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 skeinforge-12.03.14-16.el7.noarch requires pypy snmptt-1.4-0.7.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.7.beta2.el7.noarch requires perl(Config::IniFiles) wxGTK-devel-2.8.12-8.el7.x86_64 requires bakefile Broken deps for ppc64 -- TurboGears-1.1.3-8.el7.noarch requires python-simplejson >= 0:1.9.1 ansible-1.4.3-1.el7.noarch requires python-paramiko ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-client-0.9.7-1.el7.noarch requires python-simplejson bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) fedmsg-0.7.2-1.el7.noarch requires python-simplejson fedmsg-0.7.2-1.el7.noarch requires python-requests gnucash-docs-2.6.0-1.el7.noarch requires gnucash >= 0:2.2.1-4 golang-github-gorilla-context-devel-0-0.21.git708054d.el7.noarch requires golang golang-github-kr-pty-devel-0-0.15.git3b1f648.el7.noarch requires golang golang-googlecode-net-devel-0-0.11.hg84a4013f96e0.el7.noarch requires golang >= 0:1.2 imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) inn-2.5.3-18.el7.ppc64 requires perl(MIME::Parser) koji-vm-1.8.0-2.el7.noarch requires python-virtinst mimedefang-2.74-1.el7.ppc64 requires perl(MIME::Words) mimedefang-2.74-1.el7.ppc64 requires perl(MIME::Tools) >= 0:5.410 mimedefang-2.74-1.el7.ppc64 requires perl(MIME::Parser) mod_perl-2.0.8-5.20131031svn1537408.el7.ppc64 requires perl(Linux::Pid) mod_perl-2.0.8-5.20131031svn1537408.el7.ppc64 requires perl(BSD::Resource) perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires ruby(shadow) puppet-3.4.2-2.el7.noarch requires hiera >= 0:1.0.0 python-django-1.5.4-2.el7.noarch requires python-simplejson python-fedora-0.3.32.3-4.el7.noarch requires python-simplejson python-fedora-0.3.32.3-4.el7.noarch requires python-requests python-fedora-flask-0.3.32.3-4.el7.noarch requires python-flask python-requests-kerberos-0.3-2.el7.noarch requires python-requests >= 0:1.0 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 python-toscawidgets-0.9.12-4.el7.noarch requires python-simplejson python-turboflot-0.7.0-4.el7.noarch requires python-simplejson python-turbojson-1.3.2-5.el7.noarch requires python-simplejson >= 0:1.9.1 python-tw2-core-2.1.5-4.el7.noarch requires python-simplejson >= 0:2.0 python-webflash-0.1-0.8.a9.el7.noarch requires python-simplejson skeinforge-12.03.14-16.el7.noarch requires pypy snmptt-1.4-0.7.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.7.beta2.el7.noarch requires perl(Config::IniFiles) wxGTK-devel-2.8.12-8.el7.ppc64 requires bakefile New package: aspell-en-7.1-5.el7 English dictionaries for Aspell New package: ckeditor-4.1-1.el7 WYSIWYG text editor to be used inside web pages New package: gnucash-docs-2.6.0-1.el7 Help files and documentation for the GnuCash personal finanace manager New package: golang-googlecode-net-0-0.11.hg84a4013f96e0.el7 Supplementary Go networking libraries New package: grid-packaging-tools-3.6.7-1.el7
