[EPEL-devel] Re: EPEL playground && mock builds against released repos
On Tue, Sep 15, 2020 at 10:53:10AM +0200, Pavel Raiskup wrote: > Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can > reproduce builds locally with mock. Initially the configuration worked, but > it > has been failing for quite some time now. Dnf isn't able to --installroot: > > No matches found for the following disable plugin patterns: local, > spacewalk > CentOS-8 - Base 12 MB/s | 2.2 MB > 00:00 > CentOS-8 - AppStream 21 MB/s | 5.8 MB > 00:00 > CentOS-8 - PowerTools11 MB/s | 1.9 MB > 00:00 > CentOS-8 - Extras33 kB/s | 7.3 kB > 00:00 > Extra Packages for Enterprise Linux 8 - Playgro 15 MB/s | 6.1 MB > 00:00 > Error: > Problem: conflicting requests > - nothing provides fpc-srpm-macros needed by > epel-rpm-macros-8-16.playground.noarch > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' > to use not only best candidate packages) > > I'm not sure we miss something there, but it looks like the shipped chroot is > broken. The mock bug report [1], and fpc-srpm-macros report [2]. Yeah, looks like the fpc-srpm-macros build for epel8-playground failed. I fired off a build: https://koji.fedoraproject.org/koji/taskinfo?taskID=51522174 but also there's no epel8-playground branch for the package. > Local mock builds are done against CentOS repositories, so I'm not sure where > to > report this problem, if here or to CentOS (but starting here as I believe that > fpc-srpm-macros should go to the playground repo). > > Also another question is whether we can fix the chroot, or not (dropping the > config file from mock-core-configs is an option, too). We should be able to fix it. Once the above lands in the buildroot it should be working again. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2390c71f9c chromium-85.0.4183.83-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0214580ca4 mbedtls-2.16.8-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c5ced83bcc seamonkey-2.53.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing aha-0.5.1-1.el8 amavisd-milter-1.7.1-1.el8 perl-Data-Dumper-Concise-2.023-12.el8 perl-Test-TempDir-0.11-1.el8 pyserial-asyncio-0.4-1.el8 python-blessed-1.17.10-1.el8 python-enlighten-1.6.2-1.el8 python-sseclient-py-1.7-1.el8 xsecurelock-1.7.0-3.el8 Details about builds: aha-0.5.1-1.el8 (FEDORA-EPEL-2020-c0c043c53f) Convert terminal output to HTML Update Information: Update to latest upstream release (v0.5.1) ChangeLog: * Mon Sep 14 2020 Artur Frenszek-Iwicki - 0.5.1-1 - Update to latest upstream release amavisd-milter-1.7.1-1.el8 (FEDORA-EPEL-2020-5c9f9db204) Sendmail milter for amavisd-new using the AM.PDP protocol Update Information: # amavisd-milter ## Bug and compatibility fixes - An empty sender must always be enclosed in angle brackets ChangeLog: * Mon Sep 14 2020 Robert Scheck 1.7.1-1 - Upgrade to 1.7.1 (#1878910) * Mon Jul 27 2020 Fedora Release Engineering - 1.7.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1878910 - amavisd-milter-1.7.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1878910 perl-Data-Dumper-Concise-2.023-12.el8 (FEDORA-EPEL-2020-97732a2b90) A convenient way to reproduce a set of Dumper options Update Information: EPEL8 branches of perl modules, per user request. ChangeLog: References: [ 1 ] Bug #1870746 - EPEL8 Branch Request: perl-Test-TempDir https://bugzilla.redhat.com/show_bug.cgi?id=1870746 [ 2 ] Bug #1870754 - EPEL8 Branch Request: perl-Data-Dumper-Concise https://bugzilla.redhat.com/show_bug.cgi?id=1870754 perl-Test-TempDir-0.11-1.el8 (FEDORA-EPEL-2020-97732a2b90) Temporary files support for testing Update Information: EPEL8 branches of perl modules, per user request. ChangeLog: References: [ 1 ] Bug #1870746 - EPEL8 Branch Request: perl-Test-TempDir https://bugzilla.redhat.com/show_bug.cgi?id=1870746 [ 2 ] Bug #1870754 - EPEL8 Branch Request: perl-Data-Dumper-Concise https://bugzilla.redhat.com/show_bug.cgi?id=1870754 pyserial-asyncio-0.4-1.el8 (FEDORA-EPEL-2020-9295c78a8d) Asynchronous Python Serial Port Extension Update Information: Initial package for Fedora ChangeLog: python-blessed-1.17.10-1.el8 (FEDORA-EPEL-2020-6aa0435ca8) A thin, practical wrapper around terminal capabilities in Python Update Information: Updated to 1.17.10 ChangeLog: * Mon Sep 14 2020 Avram Lubkin -
[EPEL-devel] Re: Proposing an EPEL packaging SIG
On Mon, Sep 14, 2020 at 09:42:36AM -0700, Michel Alexandre Salim wrote: > I wonder if these are two separate concerns though? I agree that being > able to indicate a package should always be branched would be great, > but... epel-sig / epel-wranglers might not find a package relevant in a > new EL release (e.g. say we care about neovim, and want to carry it by > default in new releases, and thus we also care about some of its > dependencies that are not in (RH)EL core -- but the set of dependencies > we care about in EPEL7 != the set in EPEL8 etc. > > ^ if that seems explicit that's because it, uh, is from personal > experience. Yeah, I agree, not everything will want to auto branch... and in fact this will change from time to time as new versions come out, things are retired, etc. > Maybe package.cfg might be where such a metadata live? e.g. if the > epel8 branch of the package has a package.cfg that says "branch for > next release" it gets branched for epel9 -- and inherits that > package.cfg by default. If a package gets opted in once and at some > point is no longer needed in the next epel, just delete that. I don't like that idea... I've heard many many complaints from people about package.cfg files and them messing up merges. I would think at the pagure/src.fp.o level might be better... or if not, then just a simple 'alwaysepelbranch' file or something thats ignored except for this use. > This might also suggest we want to have a delay before automatically > branching so EPEL SIG / Wranglers have time to adjust that package.cfg > after testing the next EL beta. Sure, should be a deliberate process. snip > Hmm. So right now (correct me if I'm wrong), it seems that only the > main admin for a package can override the bugzilla assignee? yeah, I think thats indeed the case. > I'm not sure about how this part would work yet. If at the beginning we > try this out with manual infra ticket, I could imagine the EPEL SIG > member that requests EPEL-SIG comaintainership for a package should ask > the main admin to make them the EPEL assignee, or if it goes through an > infra ticket, ask for infra to make that change? I suppose. I am not keen on adding more infrastructure tickets. If we can do a workflow that consolidates requests/can be automated that would be much better IMHO. > > > One deviation we might want to have from how Python SIG works is... > > > we > > > probably don't want to encourage packagers to add this EPEL SIG as > > > a > > > comaintainer preemptively, but only as needed. > > > > That would defeat the purpose of using epel-sig packages as 'always > > branch' wouldn't it? > > > Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG > has commit access requesting a new branch is not a significant delay > anyway). So 'branch for next' in package.cfg might be a better solution > all around. > > How much tooling change would we need to get collaborators the ability > to request branches if the branch name matches their whitelist, > incidentally? Not sure. Thats a question for Pingou. :) > > The other hazard if that different maintainers have different > > workflows > > and epel-sig folks would need to adjust to those. ie, some people > > want > > master to have epel conditionals and merge back to epel branches, > > some > > don't want that at all. I wonder if it wouldn't make sense to have > > some > > way to indicate to people what workflow is in effect for the package > > (I > > guess spec file comments?) > > > Maybe spec file comments as well as only granting collaborator > (whitelisting epel* branches) instead of commit / admin access if they > don't want EPEL conditionals? yeah. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
This is the second draft. It has added a section in the developer section saying to clean your packages up when you are done playing and testing them. Edit's are still welcome, but I think it covers everything that has been discussed and approved. This will be published about the same time that - fedpkg doesn't require you to build playground when building epel -- https://pagure.io/fedpkg/issue/414 - package.cfg isn't automatically added to epel8 branches when they are created -- https://pagure.io/fedora-infrastructure/issue/9322 == # EPEL PLAYGROUND We have added an additional set of channels for EPEL-8 called playground. It is meant to be sort of like Fedora Rawhide so that packagers can work on versions of software which are too fast moving or will have large API changes from what they are putting in the regular channel. Packages in epel8-playground are primarily to be used in the following manner: * To test out some new version of the package that might not be stable yet. * To test out some new packaging of the package * To test a major version change of the package that they want to land at the next epel8 minor release. * To build a package that will never be stable enough for epel8, but still could be useful to some. ## Consumers / End Users Consumers should be aware that packages in EPEL8-playground are there without any Service Level Expectations. You may want to only cherry pick packages from there as needed. EPEL8-playground is not a full EPEL release. It only has those packages that developers and maintainers are "playing" around with. Because of this, you should not expect to enable only epel-playground and get everything you need. It is expected that you have regular epel enabled whenever you enable epel-playground. ## Developers / Maintainers epel8-playground builds are NOT automatically built when you build in epel8. This is a change from the original vision. #(Remove this sentence after a few years) You must use the epel8-playground branch and build from there, just like you would any other Fedora / EPEL build area. Packages in epel-playground will never be automatically put into regular epel. That is the responsibility of the package maintainer. It is recommended that if a maintainer plans to bring a package that has a large change from epel-playground to regular epel, they do it at minor RHEL releases (ie, 8.3, 8.4). Since end users will be upgrading and paying more attention than usual at those times, it’s a great chance to make larger changes. Be sure to announce those major changes well in advance on epel-devel and epel-announce. When a maintainer is done with their package in playground, they must untag all builds of it out of epel-playground. We do not want epel-playground cluttered with old test packages. Done means either the package has been moved to regular EPEL, and / or the maintainer no longer wants to play and test in epel-playground. Untagging all builds of a package is currently done via a release engineering ticket. EPEL Playground has traits similar to Fedora Rawhide. * Built packages do not need to be tagged with override to get into the epel8-playground build repository. They will be put in the next time the build repository is refreshed. This is usually within 15 to 60 minutes. * The main epel8-playground repository is built once a day, just like Fedora Rawhide. Thus built packages are usually available in epel8-playground the day after they are built. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL playground && mock builds against released repos
On Tue, Sep 15, 2020 at 1:53 AM Pavel Raiskup wrote: > > Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can > reproduce builds locally with mock. Initially the configuration worked, but > it > has been failing for quite some time now. Dnf isn't able to --installroot: > > No matches found for the following disable plugin patterns: local, > spacewalk > CentOS-8 - Base 12 MB/s | 2.2 MB > 00:00 > CentOS-8 - AppStream 21 MB/s | 5.8 MB > 00:00 > CentOS-8 - PowerTools11 MB/s | 1.9 MB > 00:00 > CentOS-8 - Extras33 kB/s | 7.3 kB > 00:00 > Extra Packages for Enterprise Linux 8 - Playgro 15 MB/s | 6.1 MB > 00:00 > Error: > Problem: conflicting requests > - nothing provides fpc-srpm-macros needed by > epel-rpm-macros-8-16.playground.noarch > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' > to use not only best candidate packages) > > I'm not sure we miss something there, but it looks like the shipped chroot is > broken. The mock bug report [1], and fpc-srpm-macros report [2]. > > Local mock builds are done against CentOS repositories, so I'm not sure where > to > report this problem, if here or to CentOS (but starting here as I believe that > fpc-srpm-macros should go to the playground repo). > > Also another question is whether we can fix the chroot, or not (dropping the > config file from mock-core-configs is an option, too). > > [1] https://github.com/rpm-software-management/mock/issues/620 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1875057 > > Pavel > I guess here is probably going to be the best place to start. EPEL Playground is in the middle of changing. It will no longer be a "stand alone" repository. It will be for only those packages that people are using to "play with" large changes to their packages. There will be no more automatic builds of all packages. Because of this, you will need to have the regular EPEL repository enabled in order to use the EPEL-Playground repository. We're right in the middle of this change, but fixing mock now is the best time to do it. It won't hurt anything to add the regular EPEL repository now, when doing the EPEL-Playground mock. Troy p.s. I'll put this in the bugzilla and the issue. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] EPEL playground && mock builds against released repos
Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can reproduce builds locally with mock. Initially the configuration worked, but it has been failing for quite some time now. Dnf isn't able to --installroot: No matches found for the following disable plugin patterns: local, spacewalk CentOS-8 - Base 12 MB/s | 2.2 MB 00:00 CentOS-8 - AppStream 21 MB/s | 5.8 MB 00:00 CentOS-8 - PowerTools11 MB/s | 1.9 MB 00:00 CentOS-8 - Extras33 kB/s | 7.3 kB 00:00 Extra Packages for Enterprise Linux 8 - Playgro 15 MB/s | 6.1 MB 00:00 Error: Problem: conflicting requests - nothing provides fpc-srpm-macros needed by epel-rpm-macros-8-16.playground.noarch (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I'm not sure we miss something there, but it looks like the shipped chroot is broken. The mock bug report [1], and fpc-srpm-macros report [2]. Local mock builds are done against CentOS repositories, so I'm not sure where to report this problem, if here or to CentOS (but starting here as I believe that fpc-srpm-macros should go to the playground repo). Also another question is whether we can fix the chroot, or not (dropping the config file from mock-core-configs is an option, too). [1] https://github.com/rpm-software-management/mock/issues/620 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1875057 Pavel ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
