[EPEL-devel] Re: EPEL 10 status update
On Sat, 7 Sep 2024 09:09:49 -0700 Kevin Fenzi wrote: > On Sat, Sep 07, 2024 at 04:11:07PM GMT, Paul Howarth wrote: > > On Fri, 6 Sep 2024 19:19:46 -0500 > > Carl George wrote: > > > We were able to get all of the in-between builds processed, and > > > have re-enabled the new compose method. We've also re-enabled > > > the build targets, and verified that a new build got an automatic > > > update that moved to stable automatically, just like rawhide. > > > Builds that are marked stable should be available in the > > > buildroot as soon as the regen-repo task finishes, and then > > > composed nightly. This pipeline should stay the same until the > > > official EPEL 10 launch in Q4. That's when we'll switch to the > > > standard EPEL pipeline, with manually created updates, a default > > > one week testing period, and bodhi composes. > > > > > > Packagers can resume building for epel10 at their leisure. Let us > > > know if anything doesn't seem to be working as expected. > > > > Prior to this change, I was able to edit the automatic update and > > add a bugzilla ticket reference to it so that the EPEL 10 branch > > request ticket would be closed when the update was pushed to stable. > > > > Now, instead of having to add the bugzilla reference and push the > > update to testing manually at the start of the update process, I > > need to go and close the associated ticket manually at the end of > > the process. It would be nice if this could be automated too. > > See https://bodhi.readthedocs.io/en/latest/user/fedora-flavored-markdown.html > > you can add rhbz#n to your changelog/git commit and bodhi will see > it and associate that bug with that update. Yes, I do that for Fedora builds but EPEL is generally re-using the same Fedora commits rather than creating new ones, and I like to keep the branches in sync. I can live with it. Regards, Paul. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 10 status update
On Fri, 6 Sep 2024 19:19:46 -0500 Carl George wrote: > We were able to get all of the in-between builds processed, and have > re-enabled the new compose method. We've also re-enabled the build > targets, and verified that a new build got an automatic update that > moved to stable automatically, just like rawhide. Builds that are > marked stable should be available in the buildroot as soon as the > regen-repo task finishes, and then composed nightly. This pipeline > should stay the same until the official EPEL 10 launch in Q4. That's > when we'll switch to the standard EPEL pipeline, with manually created > updates, a default one week testing period, and bodhi composes. > > Packagers can resume building for epel10 at their leisure. Let us > know if anything doesn't seem to be working as expected. Prior to this change, I was able to edit the automatic update and add a bugzilla ticket reference to it so that the EPEL 10 branch request ticket would be closed when the update was pushed to stable. Now, instead of having to add the bugzilla reference and push the update to testing manually at the start of the update process, I need to go and close the associated ticket manually at the end of the process. It would be nice if this could be automated too. Regards, Paul. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: arch-specific package in CS10 blocking EPEL 10 request
On Wed, 4 Sep 2024 09:15:23 +0100 Paul Howarth wrote: > I got a request to build rgb for EPEL 10 > (https://bugzilla.redhat.com/show_bug.cgi?id=2309102), which is not > surprising as I did the same for EPEL 9. A local test build of that package > failed due to a missing dependency of 'pkgconfig(xorg-macros)', so I > requested an EPEL 10 build of xorg-x11-util-macros to resolve that > (https://bugzilla.redhat.com/show_bug.cgi?id=2309121). > > That package request was then declined: > > fedpkg request-branch epel10 > Could not execute request_branch: This package is already an EL > package, therefore it cannot be in EPEL. If this is a mistake > > Looking at the compose metadata, it appears that xorg-x11-util-macros > is in CRB, but only for the aarch64 architecture. And now, for an unrelated package, I have the opposite problem: perl-DateTime fails to build because one of its dependents, perl-Specio (noarch) depends on perl-XString, which is in CRB ... except on aarch64. I raised https://issues.redhat.com/browse/CS-2515 (hopefully the right place) See also: https://bugzilla.redhat.com/show_bug.cgi?id=2309388 Regards, Paul. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] arch-specific package in CS10 blocking EPEL 10 request
I got a request to build rgb for EPEL 10 (https://bugzilla.redhat.com/show_bug.cgi?id=2309102), which is not surprising as I did the same for EPEL 9. A local test build of that package failed due to a missing dependency of 'pkgconfig(xorg-macros)', so I requested an EPEL 10 build of xorg-x11-util-macros to resolve that (https://bugzilla.redhat.com/show_bug.cgi?id=2309121). That package request was then declined: fedpkg request-branch epel10 Could not execute request_branch: This package is already an EL package, therefore it cannot be in EPEL. If this is a mistake Looking at the compose metadata, it appears that xorg-x11-util-macros is in CRB, but only for the aarch64 architecture. So, my questions are: 1. Is this intentional (seems unlikely, given that this is fundamental to building just about anything using xorg-x11), and 2. If this *is* intentional, what should be done to facilitate building rgb and similarly-affected packages in EPEL? Any thoughts? Regards, Paul. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On Mon, 30 Jan 2023 21:13:11 -0700 Orion Poplawski wrote: > So, I'm wondering if we should have some kind of (at least > semi-)coordinated plan for updating ansible collections in EPEL? > > My initial thought is we would sort of piggy back on to what the > "ansible" community collection bundles on top of the ansible-core > package provided by RedHat. So, currently in EL8.7 we have: > > ansible-core-2.13.3 > > and EPEL ships: > > ansible-6.3.0 - which corresponds to the ansible community package > that ships with ansible-2.13.3. > > Then we would endeavor to ship the individual package collection > versions that are contained in that package, .e.g: (taken from the > MANIFEST.json files): > > ansible.posix 1.4.0 > ansible.utils 2.6.1 > chocolatey.chocolatey 1.3.0 > community.docker 2.7.1 > community.general 5.5.0 > community.libvirt 1.2.0 > community.mysql 3.4.0 > community.rabbitmq 1.2.2 > containers.podman 1.9.4 > netbox.netbox 3.7.1 Sounds like a reasonable plan to me. > For reference, currently in epel we have: ... > ansible-collection-community-libvirt.noarch 1.1.0-3.el8 > epel I updated ansible-collection-community-libvirt to 1.2.0: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5 > I don't really have a particular agenda here, just trying to solicit > people's thoughts. Personally I like minimal installs so I have been > only using ansible-core + collections on the systems I maintain and > would like to continue to see them be usable together. I too just use ansible-core + collections on the systems I maintain. Regards, Paul. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL7 packages still in epel-testing
On Wed, 20 Apr 2022 14:48:47 -0700 Troy Dawson wrote: > gnucash-2.6.21-1.el72018-04-15 (1466) Should be safe to unpush this one because gnucash-2.6.21-4.el7 should be in epel7 stable for 2 years: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa8e8965dc Paul. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On Fri, 14 Jan 2022 07:02:23 -0500 Josh Boyer wrote: > 2) Moving content to CRB in RHEL is not a silver bullet solution in > many scenarios. If it's strictly for build dependencies, CRB works > well. If an EPEL package has a runtime requires on CRB content, that > is less desirable. RHEL CodeReady Linux Builder (CRB) content is > unsupported, not enabled by default, and not intended to be used at > runtime in production. EPEL itself is clearly in the same unsupported > category, but requiring another unsupported repo at runtime may lead > to unintentional surprises for many users. The EPEL documentation specifically says to enable CRB/PowerTools if you're using EPEL: https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages NOTE for RHEL 8 users with certificate subscriptions: EPEL packages assume that the 'codeready-builder' repository is enabled. You can do this with: subscription-manager repos --enable "codeready-builder-for-rhel-8-$(arch)-rpms" NOTE for CentOS 8 and CentOS Stream 8 users: EPEL packages assume that the 'powertools' repository is enabled. You can do this with: dnf config-manager --set-enabled powertools Whilst that is for EL-8 I don't see why it would be different for EL-9. In particular, for interpreted languages like perl there are a large number of runtime dependencies from EPEL packages to packages in CRB. Paul. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Continuing playground discussion
On Fri, 4 Sep 2020 07:18:31 -0700 Troy Dawson wrote: > Step 4 - Untag all the things that are "older" in playground > -- currently that is a releng process. There is no way for a > maintainer to retire their package from playground. > -- This needs to happen some time (3 months?) after step 2 is > finished. A time that we can see that people have manually built > their package in playground, versus the automatic builds. So that the > "older" packages are obvious. Isn't it likely that builds with the same NEVR (apart from the disttag) in playground as in EPEL-8 proper are automatic builds rather than manual ones? That would certainly reflect my own usage, where almost all of my packages would be the same, but my manual build of proftpd is different. Paul. ___ 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: Modules again
On Tue, 19 May 2020 19:00:25 +0100 Paul Howarth wrote: > On Tue, 19 May 2020 09:21:46 -0700 > Kevin Fenzi wrote: > > > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen > > wrote: > > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > > wrote: > > > > On Tue, 19 May 2020 09:07:30 -0400 > > > > Stephen John Smoogen wrote: > > > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > > wrote: > > > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs > > > > for this, and that has epel-8-x86_64.cfg, which pulls in > > > > centos-8.tpl, which has the PowerTools repo defined and not > > > > disabled. > > > > > > > > (I generally use my own configs and don't touch the original > > > > ones, so I know that if I try the original ones from upstream > > > > then they should work as intended) > > > > > > > > Note that the error message doesn't say it can't find > > > > Judy-devel, it says that it (and Judy) is/are excluded. I don't > > > > know why that is. > > > > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > > problems, the system is trying to pull in mariadb which filters it > > > out and mariadb-devel which has it in. So when it sees the filters > > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > > it might break my system do it anyway!' flag but I don't see one > > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > > one of the reasons for grobisplitter being used. > > > > You should be able to set: > > > > module_hotfixes = True > > > > in your dnf/yum/mock config. > > > > From the dnf man page: > > > > "Set this to True to disable module RPM filtering and make all RPMs > > from the repository available. The default is False. This allows > > user to create a repository with cherry-picked hotfixes that are > > included in a package set on a modular system." > > Ah, setting that option for the PowerTools repo allows the build to > work. Now if only there was a way to do that from the command line so > I didn't have to touch the mock config. And now in CentOS 8.2 Judy-devel is missing from the PowerTools repo and so it doesn't work again. Ho hum. Paul. ___ 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: Modules again
On Wed, 20 May 2020 08:10:42 +0200 Petr Pisar wrote: > On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote: > > On Tue, 19 May 2020 09:07:30 -0400 > > Stephen John Smoogen wrote: > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > wrote: > > > > On Mon, 18 May 2020 22:29:54 -0600 > > > > Orion Poplawski wrote: > > > > > > > > > On 5/17/20 6:34 AM, Paul Howarth wrote: > > > > > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > > > > > > > > > A koji scratch build somehow works: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > > > > > > > > > But a local build does not: > > > > > > > > > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > > > > > ... > > > > > > Error: > > > > > > Problem: conflicting requests > > > > > >- package > > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is > > > > > > excluded > > > > > >- package > > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is > > > > > > excluded > > > > > > > > > > > > Adding a repo with a local build of Judy doesn't help; that > > > > > > gets excluded too. > > > > > > > > > > > > Any clues? > > > > > > > > > > > > Paul. > > > > > > > > > > Judy-devel appears to be part of the mariadb-devel module. > > > > > Locally I can do: > > > > > > > > > > dnf module enable mariadb-devel > > > > > dnf install Judy-devel > > > > > > > > > > This was discovered with: > > > > > > > > > > dnf module provides Judy-devel > > > > > > > > > > on RHEL 8.2, though that does not appear to work on CentOS > > > > > 8.1. > > > > > > > > > > For mock, this seems to work: > > > > > > > > > > mock -r epel-8-x86_64 --config-opts > > > > > module_enable=mariadb-devel --config-opts module_enable= > > > > > gtkwave-3.3.104-2.el8.src.rpm > > > > > > > > I tried that and it didn't make any difference for me (building > > > > on F-31). Maybe I need to wait for CentOS 8.2? > > > > > > > > > > > Hmm do you have the Powertools enabled in that Mock? I see > > > Judy-devel in the CentOS-8.1 tree in Powertools. > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > which has the PowerTools repo defined and not disabled. > > > > (I generally use my own configs and don't touch the original ones, > > so I know that if I try the original ones from upstream then they > > should work as intended) > > > > Note that the error message doesn't say it can't find Judy-devel, it > > says that it (and Judy) is/are excluded. I don't know why that is. > > > The message means that the Judy-devel package exists in a repository, > but is not available for an installation, because a module it belongs > to is not active (i.e. not enabled nor default). The correct > procedure is enable the module it belongs to. > > "dnf module provides Judy-devel" command returns mariadb-devel:10.3 > module. After enabling that module you get another error message that > Judy package is excluded. That's because Judy package belongs to > mariadb:10.3 module. You also need to enable that module. Then it > works. It also works in mock: > > $ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > --config-opts module_enable=mariadb install Judy-devel [...] > INFO: installing package(s): Judy-devel > No matches found for the following disable plugin patterns: local, > spacewalk CentOS-8 - Base >539 kB/s | 2.2 MB > 00:04 CentOS-8 - AppStream >1.3 MB/s | 7.0 MB > 00:05 CentOS-8 - PowerTools >442 kB/s | 2.0 MB > 00:04 CentOS-8 - Extras >5.7 kB/s | 5.9 kB > 00:01 epel >5.2 kB/s | 4.7 kB > 00:00
[EPEL-devel] Re: Modules again
On Tue, 19 May 2020 09:21:46 -0700 Kevin Fenzi wrote: > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen wrote: > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > wrote: > > > On Tue, 19 May 2020 09:07:30 -0400 > > > Stephen John Smoogen wrote: > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > wrote: > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > > which has the PowerTools repo defined and not disabled. > > > > > > (I generally use my own configs and don't touch the original > > > ones, so I know that if I try the original ones from upstream > > > then they should work as intended) > > > > > > Note that the error message doesn't say it can't find Judy-devel, > > > it says that it (and Judy) is/are excluded. I don't know why that > > > is. > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > problems, the system is trying to pull in mariadb which filters it > > out and mariadb-devel which has it in. So when it sees the filters > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > it might break my system do it anyway!' flag but I don't see one > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > one of the reasons for grobisplitter being used. > > You should be able to set: > > module_hotfixes = True > > in your dnf/yum/mock config. > > From the dnf man page: > > "Set this to True to disable module RPM filtering and make all RPMs > from the repository available. The default is False. This allows > user to create a repository with cherry-picked hotfixes that are > included in a package set on a modular system." Ah, setting that option for the PowerTools repo allows the build to work. Now if only there was a way to do that from the command line so I didn't have to touch the mock config. Thanks! Paul. ___ 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: Modules again
On Tue, 19 May 2020 09:07:30 -0400 Stephen John Smoogen wrote: > On Tue, 19 May 2020 at 06:05, Paul Howarth wrote: > > > On Mon, 18 May 2020 22:29:54 -0600 > > Orion Poplawski wrote: > > > > > On 5/17/20 6:34 AM, Paul Howarth wrote: > > > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > > > > > A koji scratch build somehow works: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > > > > > But a local build does not: > > > > > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > > > ... > > > > Error: > > > > Problem: conflicting requests > > > >- package > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded > > > >- package > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is > > > > excluded > > > > > > > > Adding a repo with a local build of Judy doesn't help; that gets > > > > excluded too. > > > > > > > > Any clues? > > > > > > > > Paul. > > > > > > Judy-devel appears to be part of the mariadb-devel module. > > > Locally I can do: > > > > > > dnf module enable mariadb-devel > > > dnf install Judy-devel > > > > > > This was discovered with: > > > > > > dnf module provides Judy-devel > > > > > > on RHEL 8.2, though that does not appear to work on CentOS 8.1. > > > > > > For mock, this seems to work: > > > > > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > > > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm > > > > I tried that and it didn't make any difference for me (building on > > F-31). Maybe I need to wait for CentOS 8.2? > > > > > Hmm do you have the Powertools enabled in that Mock? I see Judy-devel > in the CentOS-8.1 tree in Powertools. Yes, I'm using vanilla configs straight from mock-core-configs for this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, which has the PowerTools repo defined and not disabled. (I generally use my own configs and don't touch the original ones, so I know that if I try the original ones from upstream then they should work as intended) Note that the error message doesn't say it can't find Judy-devel, it says that it (and Judy) is/are excluded. I don't know why that is. Paul. ___ 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: Modules again
On Mon, 18 May 2020 22:29:54 -0600 Orion Poplawski wrote: > On 5/17/20 6:34 AM, Paul Howarth wrote: > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > A koji scratch build somehow works: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > But a local build does not: > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > ... > > Error: > > Problem: conflicting requests > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is > > excluded > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 > > is excluded > > > > Adding a repo with a local build of Judy doesn't help; that gets > > excluded too. > > > > Any clues? > > > > Paul. > > Judy-devel appears to be part of the mariadb-devel module. Locally I > can do: > > dnf module enable mariadb-devel > dnf install Judy-devel > > This was discovered with: > > dnf module provides Judy-devel > > on RHEL 8.2, though that does not appear to work on CentOS 8.1. > > For mock, this seems to work: > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm I tried that and it didn't make any difference for me (building on F-31). Maybe I need to wait for CentOS 8.2? > koji does some magic to essentially auto-enable some modules that I > don't believe mock has. It writes its own mock configs, that I know. After that, I'm in the dark... Thanks for trying. Paul. ___ 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] Modules again
I'm trying to do a local build of gtkwave for EPEL-8. A koji scratch build somehow works: http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 But a local build does not: $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm ... Error: Problem: conflicting requests - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is excluded Adding a repo with a local build of Judy doesn't help; that gets excluded too. Any clues? Paul. ___ 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: Handling packages retired in epel but not yet available in CentOS?
On Thu, 14 May 2020 12:31:40 -0700 Michel Alexandre Salim wrote: > We're working on validating CentOS 8 for some desktop use cases at > work, and noticed that after working fine on a machine that's > installed several months ago, it's now failing on a freshly-installed > machine. > > Turns out that we need libzstd, which on the previous machine was > sourced from the EPEL repo, but the epel8 package got retired 3 > months ago because the package is now in RHEL's BaseOS: > > https://src.fedoraproject.org/rpms/zstd/history/dead.package?identifier=epel8 > > The package is only in BaseOS in 8.2 though, and CentOS 8.2 is not > out -- the only repo that has it now is 8-stream: > > https://mirrors.edge.kernel.org/centos/8-stream/BaseOS/x86_64/os/Packages/ > > 8.1.1911 does not have the package: > https://mirrors.edge.kernel.org/centos/8.1.1911/BaseOS/x86_64/os/Packages/ > > Also, the version in BaseOS (if 8-stream is up to date) is 1.4.2, > which is older than the last version in EPEL (1.4.4). > > Is anyone else in the same situation, and how do you work around it? > Since EPEL is a sort of "rolling release" does it make sense to just > track 8-stream if you're using it, or are people resorting to hosting > these key packages in internal repos? That's what I'm doing. I got the sources from CentOS git (https://git.centos.org/rpms/zstd/tree/c8), built it myself and hosted it in a temporary local repo until CentOS 8.2 is out. Paul. ___ 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: Input Requested: revising policy for stalled EPEL requests
On Fri, 10 Apr 2020 15:17:25 -0700 Troy Dawson wrote: > On Fri, Apr 3, 2020 at 3:21 PM Troy Dawson wrote: > > > > EPEL Issue #101 [1] has pointed out that our current policy for > > stalled EPEL requests is fairly in-efficient and can cause some long > > delays. > > > > What do people think the process should be? > > > > Here is an example: > > * A packager opens a bugzilla requesting a package be added to EPEL. > > They also express that they are willing to help maintain / > > co-maintain that package in EPEL. > > * A period of time goes by with no response > > * They re-say that they are willing to maintain / co-maintain the > > package in EPEL > > * Another period of time goes by with no response > > * They file a rel-eng ticket, that points to the bugzilla, > > requesting appropriate privileges to be able to branch and build > > that package in EPELX > > * That happens. > > * They then request branch, and build the package in EPELX following > > normal ways. > > > > This is just an example, but it's what I picture in my head. > > Troy > > > > [1] - https://pagure.io/epel/issue/101 > > This is the proposed policy. If people could look through it for any > problems, it would be appreciated. > > **Stalled EPEL Requests** > There are times that an EPEL / Fedora package maintainer isn't > responding to an EPEL package request. If a different packager would > like to build and maintain that package in EPEL, these are the steps > they take. > > * A packager opens a bugzilla requesting a package be added to EPEL. > They also express that they are willing to help maintain / co-maintain > that package in EPEL-X. > > * A week goes by with no response > > * They re-say that they are willing to maintain / co-maintain the > package in EPEL > ** This is just incase the initial message was missed. > > * A week goes by with no response > > * They file a rel-eng ticket, that points to the bugzilla, requesting > appropriate privileges to be able to branch and build that package in > EPEL-X > ** Currently that privilege is "admin" > ** This part of the policy will adjust as various features get > implemented in pagure and dist-git > > * The privileges are given > * They then request a branch, and build the package in EPEL-X > following normal steps. I think there's also a good case for the requester to be made the bugzilla contact for EPEL for that package, though it would be complicated if there was an existing EPEL branch, which would presumably have been made (and been maintained) by someone else. Paul. ___ 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: epel8 build failing
On Thu, 21 Nov 2019 21:56:46 -0700 Orion Poplawski wrote: > DEBUG util.py:596: No available modular metadata for modular package > 'python2-rpm-macros-3-38.module+el8.1.0+3111+de3f2d8e.noarch', it > cannot be installed on the system > DEBUG util.py:596: Error: No available modular metadata for modular > package > > https://koji.fedoraproject.org/koji/taskinfo?taskID=39186949 https://pagure.io/releng/issue/9048 Paul. ___ 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: Recent epel 8 branchs - no tag of package in epel
On Thu, 14 Nov 2019 15:08:32 +0100 Steve Traylen wrote: > Hi, > > > Last couple of days the epel8 branch requests have been processed > okay. Thanks > > However when you then try and build something it results in > > BuildError: package X not in list for tag epel8-playground-pending > > > Example: > > > https://pagure.io/releng/fedora-scm-requests/issue/19622 > https://pagure.io/releng/fedora-scm-requests/issue/19623 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=38994106 > > has occurred for multiple recently branched packages. I think earlier > in the week all was good. It seems to be fixed now. So far so good anyway. Paul. ___ 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: Recent epel 8 branchs - no tag of package in epel
On Thu, 14 Nov 2019 15:08:32 +0100 Steve Traylen wrote: > Last couple of days the epel8 branch requests have been processed > okay. Thanks > > However when you then try and build something it results in > > BuildError: package X not in list for tag epel8-playground-pending > > > Example: > > > https://pagure.io/releng/fedora-scm-requests/issue/19622 > https://pagure.io/releng/fedora-scm-requests/issue/19623 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=38994106 > > has occurred for multiple recently branched packages. I think earlier > in the week all was good. https://pagure.io/fedora-infrastructure/issue/8383 https://pagure.io/releng/issue/9017 Wasn't sure where to report it... Paul. ___ 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: please help with epel8 branches
On Tue, 10 Sep 2019 20:59:33 -0600 Orion Poplawski wrote: > The epel8 branches were not properly created for hypre and > superlu_dist. They were apparently made in the PDC, but they don't > exist in pagure. What to do now? Thanks. This is not the first time this has happened. Fortunately, you may be able to fix it yourself: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/BXBDTCTLY5KD3EBYMETGMHEKSKWW3JHA/ Paul. ___ 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] Code Ready Builder
The EL-8 non-default repo Code Ready Builder is primarily targeted at developers, but it looks to me like it's going to be a required repo for a lot of EPEL-8 users, particularly those using interpreted languages. As an example, today I built perl-Expect for EPEL-8 (https://bugzilla.redhat.com/show_bug.cgi?id=1744512). This has a dependency on perl-IO-Tty, which is in Code Ready Builder. The dependency isn't just a build-time dependency though, it's a run-time one too. So it seems to me that the Code Ready Builder repo will be required for lots of EPEL-8 users, just like the optional repo used to be for earlier EL versions. Paul. ___ 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: Announcing EPEL-8.0 Release
Hi, On Wed, 14 Aug 2019 10:50:24 -0400 Stephen John Smoogen wrote: > ## Known Issues: > 1. EPEL-8.0 does not come with modules. Packages built for perl, > python and other modules are only built against “default” modules. For > example installing a perl library from EPEL will work with the > perl-5.26 but not with the perl-5.24 module. Will this present a problem going forward when modules are available in EPEL-8 and it's possible to build for both perl-5.24 and perl-5.26? i.e. will the presence of non-modular perl packages built against 5.26 cause any issues for people wanting to use the perl-5.24 module? Maybe if the perl modules become buildable at a point release, all the perl packages could be removed from the main EPEL-8 repo at that time and moved into modules? Apologies if this is a stupid question but modularity is still something of an unknown to me. Paul. ___ 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 8 Beta/Alpha?
On Wed, 28 Nov 2018 07:01:04 -0600 Richard Shaw wrote: > On Wed, Nov 28, 2018 at 5:29 AM Paul Howarth > wrote: > > > On Wed, 28 Nov 2018 10:53:58 +0530 > > > > I seem to remember that for EL-7 we generally just branched the f19 > > packages for epel7, rebuilt and that was pretty much it. > > > > I thought it was more of an "opt-in" situation, that packages that > had a EL -1 branch didn't automatically get an EL new branch? > > I would definitely like the opportunity to do some major version > upgrades of some of the packages I maintain. It was mostly opt-in as I recall it, but some packages got EPEL branches for the first time as they were needed as dependencies. Anyone packaging for EPEL-8 should of course be free to choose whichever version of their package is best suited to it; I think f19 was the latest at the time of the EL7 beta release when a lot of stuff got built. Paul. ___ 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://getfedora.org/code-of-conduct.html 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 8 Beta/Alpha?
On Wed, 28 Nov 2018 10:53:58 +0530 Thomas Stephen Lee wrote: > I downloaded and installed > > https://www.redhat.com/en/blog/powering-its-future-while-preserving-present-introducing-red-hat-enterprise-linux-8-beta > > But many packages I use regularly are from EPEL. > > When can we expect EPEL 8 Beta/Alpha? I seem to remember that for EL-7 we generally just branched the f19 packages for epel7, rebuilt and that was pretty much it. That's not going to work for EL-8, which looks like it's going to need significant investments in modules. For instance, there are a large number of perl module packages in EPEL-7, which would need rebuilding for both perl 5.24 and perl 5.26 as both versions are available as modules in EL-8 beta. Or do we just support the default perl stack? Does everything go in one perl module or is there a hierarchy? Similar could apply for libraries and the applications that require them - how is the module hierarchy going to be defined? Separate libraries and application modules, or libraries bundled with applications? Or take it on a case by case basis? I'm very much new to modularity myself and haven't got my head round what I think would be the best approach yet. Paul. ___ 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://getfedora.org/code-of-conduct.html 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: Circular build dependency with perl-namespace-autoclean and perl-MooseX-Role-WithOverloading
On 2017-09-29 03:45, Digimer wrote:
Hi all,
Continuing down by build dependency hole, I ran into another circular
dependency. I checked in perl-namespace-autoclean.spec for the
bootstrap
option, but it didn't seem to exist. I added it, and it allowed me to
build -> install perl-namespace-autoclean, then build -> install
perl-MooseX-Role-WithOverloading, then rebuild perl-namespace-autoclean
normally.
--- perl-namespace-autoclean.spec 2014-08-14 22:16:54.0 +
+++ perl-namespace-autoclean.spec.new 2017-09-29 02:42:34.666511773
+
@@ -41,7 +41,9 @@
%if 0%{?fedora} || 0%{?rhel} > 7
BuildRequires: perl(MooseX::MarkAsMethods)
%endif
+%if !0%{?perl_bootstrap}
BuildRequires: perl(MooseX::Role::WithOverloading) >= 0.09
+%endif
BuildRequires: perl(Mouse)
BuildRequires: perl(Sub::Name)
# Runtime
Was this the right approach? I worry not because obviously you guys
compiled them before.
perl-namespace-autoclean was updated in EPEL from version 0.13 to
version 0.19. Version 0.13 did not have the build dependency on
perl(MooseX::Role::WithOverloading) and thus was able to build
successfully. By the time the upgrade to 0.19 happened,
perl-MooseX-Role-WithOverloading had been built (pulling in the existing
perl-namespace-autoclean 0.13) and so there was no problem doing that
version 0.19 build.
If you look at the master branch of perl-namespace-autoclean, you'll see
that there's now a bootstrapping conditional around the
perl(MooseX::Role::WithOverloading) build requirement.
What you did is fine.
Paul.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Trouble rebuilding perl-Moose
On 2017-09-28 08:42, Digimer wrote: Hi all, This is my first post, apologies if I am off-topic; I'm trying to build perl-Moose, which depends on perl-Data-Visitor, but perl-Data-Visitor depends on perl-Moose; [digimer@el7-builder-test1 SPECS]$ rpmbuild -ba perl-Moose.spec error: Failed build dependencies: perl(Data::Visitor) is needed by perl-Moose-2.1005-1.el7.centos.x86_64 [digimer@el7-builder-test1 SPECS]$ rpmbuild -ba perl-Data-Visitor.spec error: Failed build dependencies: perl(Moose) >= 0.89 is needed by perl-Data-Visitor-0.30-1.el7.centos.noarch I am wondering how EPEL repos solved this problem... I grabbed the source for both from EPEL. Now, I know I could install perl-Data-Visitor from EPEL, then build perl-Moose, install that, then rebuild perl-Data-Visitor but I am trying to learn more about package management, which is why I am asking here to find out what is the proper way to solve this. A bootstrapping process is used to resolve this issue. First, the perl-Moose package is built with the %perl_bootstrap rpm macro set to 1. This could be set in the build system, or by editing the perl-Moose spec file to set it (which is what's done in EPEL). This allows perl-Moose to be built without perl-Data-Visitor or any other module that would result in circular build dependencies. Once perl-Moose has been built, the %perl_bootstrap rpm macro can be removed, either from the build system or the spec file as necessary. It's then possible to build perl-Data-Visitor etc. Finally, perl-Moose is rebuilt without %perl_bootstrap, which improves test coverage by pulling in all of the build requirements that were omitted for the bootstrap build. You can see the bootstrapping process by looking at the commit history for the epel7 branch: https://src.fedoraproject.org/rpms/perl-Moose/commits/epel7 Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: nodejs broken
On 2017-08-23 18:27, Stephen Gallagher wrote: I think the only sane approach here is going to be to just drop all of the 7.3-specific stuff and just tell people that they're unfortunately out of luck on CentOS until 7.4 is out for that platform. Not entirely out of luck. CentOS 7 users could now enable the cr repository and pick up OpenSSL 1.0.2kk from there. Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Current state of dual repository packages.
On 2017-08-11 19:00, Stephen John Smoogen wrote: I have opened 2 tickets in RELENG to have these packages removed/blocked for EPEL. Packages which are newer in EPEL than RHEL-7.4 https://pagure.io/releng/issue/6948 Packages which are older in EPEL than RHEL-7.4 but exist in aarch64, x86_64, ppc64, and ppc64le https://pagure.io/releng/issue/6950 The remaining packages which are not in all architectures BUT are very old (and may break other things). These need some sort of update/rebuild I expect. I took a look at the three I am maintainer of: perl-Crypt-PasswdMD5 This package is unchanged from the EPEL package, just rebuilt (apart from the EPEL package having a "0." release prefix to indicate that it's one of the limited arch packages). I don't really think anything needs to be done with this. python-crypto This is basically a clone of the existing EPEL package, with conditionals added around the python3 package so it doesn't get built for RHEL, which doesn't have python3.x. Updating this to match the RHEL package would result in dropping the python3 support, so I think this should be left alone too. python-paramiko This one has had a version bump to a major new version that uses a different crypto backend (python-cryptography rather than python-crypto). This one should be cloned into the epel7 branch, a "0." prepended to Release: and the python3 package enabled I think. Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Intent to retire perl-MetaCPAN-API from EPEL (7)
The package perl-MetaCPAN-API, which has been deprecated upstream for some time now, was recently updated by upstream to support the new v1 API provided by MetaCPAN. The original v0 API, the only one supported by the existing EPEL perl-MetaCPAN-API package, no longer works with metacpan.org, so the EPEL package is non-functional. At this point I could either upgrade or retire the package. Upgrading to the current upstream version would entail branching and building perl-Moo, perl-Type-Tiny and perl-strictures for EPEL. Whilst this is do-able, perl-Moo is the base of an object ecosystem and I'd rather not be maintaining that in EPEL just because it's needed as a dependency of a deprecated package. It deserves to be maintained by someone that actually cares about it. So, given that the package is deprecated and I don't think there are any dependent packages in EPEL, I'm intending to retire the EPEL branch (there's only a branch for EPEL-7) of perl-MetaCPAN-API. If anyone wants to take it and upgrade it, I'll be happy to hand it over to them. Regards, Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Perl packaging problem
On 2017-02-13 04:51, Sérgio Basto wrote: Hi, perl-Git-Wrapper.spec doesn't build in EPEL7 because : BuildRequires: perl(:VERSION) >= 5.6 Ends in: DEBUG util.py:435: No matching package to install: 'perl(:VERSION) >= 5.6' perl -v : This is perl 5, version 16, subversion 3 (v5.16.3) from: https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl If you need to limit your package to a specific Perl version, use perl(:VERSION) dependency with desired version constraint (e.g. perl(:VERSION) >= 5.22). But Perl 5.6.0 is a version from year 2000, so it is safe comment this "BuildRequires", but anyone know a better solution ? The perl(:VERSION) provide only works in Fedora at the moment so you can't use it in EPEL. Given that even EPEL-5 has perl 5.8.8 I wouldn't worry about the version requirement, but you should retain a build dependency on "perl" itself (not necessarily versioned) as it'll be needed for the package build process. Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Requirements for SRPM names
On 14/09/16 03:51, Dennis Gilmore wrote: So, with the limited arch packages this means that _ALL_ things building in koji will use the epel package. The reason for the prepended 0 is so that users don't install the epel package and instead get the newer rhel version. The limited arch guideline also says you should try and keep the package as close as possible to the rhel version. For el7, and even in some of the big (java*) use cases in el6 the delta in packages between the arches is getting a lot less, and I believe this will be more so as we move forward in el7. I honestly am not sure there is any limited arch packages in epel7 I think po4a may be one: https://bugzilla.redhat.com/show_bug.cgi?id=1134624 Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Necessity of some old RPM constructs in EL5
On 22/01/16 03:11, Jason L Tibbitts III wrote: I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though. %defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can someone verify that it really is not required? Why do people keep putting it in if so? The need for this went away with rpm 4.4, so EL-4 needed it and EL-5 does not. It's probably still there because people can't remember whether it was EL-5 or EL-6 that removed the need for it, and left it there to be on the safe side. Cleaning %buildroot in %install:: Why is is so essential that the buildroot be cleaned as the first line of %install? I think I can make this happen magically but I'm not sure why it's needed at all. %clean What actually goes wrong if %clean isn't there? If it's just some cruft that might be left over after a successful build, then is it really an issue if it's not present? Might these affect people doing short-circuit builds? That's never been a part of my workflow so I've not come across any issues with it. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)
On 21/01/16 00:49, Jason L Tibbitts III wrote: ... Failures in %check: 12 ccache-2.4-21.el5.src.rpm (adev) heimdal-1.6.0-0.9.20140621gita5adc06.el5.src.rpm (ktdreyer) libresample-0.1.3-7.el5.src.rpm (jcollie) perl-Calendar-Simple-1.17-2.el5.src.rpm (laxathom) perl-Email-Abstract-2.132-4.el5.2.src.rpm (spot) This is failing due to a missing dependency perl(User::Identity) in perl-Mail-Box. perl-Gearman-Client-Async-0.94-3.el5.src.rpm (psabata) perl-PDL-2.4.3-5.el5.src.rpm (mmaslano, rnorwood, jplesnik) perl-Perl-Critic-1.05-1.el5.src.rpm (rmyers, pghmcfc) I have patched this (1 fix for code, 1 for test suite) and pushed an update. It had been broken by changes in the List::MoreUtils module. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Mass rebuild of EPEL6 (2016-01-19)
On 20/01/16 04:16, Jason L Tibbitts III wrote: ... Test suite (%check) failures: libgee libserf heimdal nodejs-callsite nodejs-dateformat perl-CGI-Untaint perl-CGI-Untaint-email perl-Class-MOP I have fixed perl-Class-MOP's test suite and submitted an update for it. The issue was caused by an earlier update to perl-Package-Stash, which resulted in an error message change that wasn't anticipated by perl-Class-MOP's test suite. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] Koji build errors (all releases - el5/6/7)
On 15/05/15 10:10, Simone Caronni wrote: This seems the real issue (clicking under show result): BuildError: mismatch when analyzing bacula-logwatch-7.0.5-7.fc21.noarch.rpm, rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm removed REQUIRES bacula-director(armv7hl-32) = 7.0.5-7.fc21 added REQUIRES bacula-director(x86-64) = 7.0.5-7.fc21 It prints errors always on the same subpackage after all branches/arch built succesfully. Am I doing anything wrong? This is the first time I've seen this message. Looks to me like that sub-package has an arch-specific dependency but it's a noarch sub-package. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Package Update
On 13/04/15 09:20, A.H.M Tasbir Farid wrote: Dear All I have configured EPEL local repository in my network. Other clients get packages from central repo. I need a package named monit with version 5.2 to connect m/monit server. EPEL repo have the older version 5.1. I can manually download the 5.2 and it works fine. How can I update this package in my central EPEL repo so that client systems could get the latest version? File a bug requesting a version update: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=el6&component=monit Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] broken PPC64 libxml2-devel?
On 01/04/15 16:26, Ken Dreyer wrote: On my PPC64 build of Ceph today [1], I'm seeing this really odd error regarding libxml2-devel: from root.log: ... DEBUG util.py:388: Error: Package: libxml2-devel-2.9.1-5.el7_1.2.ppc (build) DEBUG util.py:388: Requires: libxml2.so.2 DEBUG util.py:388: You could try using --skip-broken to work around the problem DEBUG util.py:388: You could try running: rpm -Va --nofiles --nodigest Is this a problem in EPEL, or in RHEL? libxml2 is an RHEL package, not an EPEL one. EPEL has libxml++ but not libxml2. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] EPEL packages, CentOS packages
On 31/03/15 12:17, Anssi Johansson wrote:
As of now, the following packages are in EPEL, but the same package also
exists in CentOS.
--- CentOS5 vs EPEL5
blktrace
c-ares
c-ares-devel
cmake
ctdb
ctdb-devel
dstat
ebtables
fribidi
fribidi-devel
iotop
ldb-tools
libassuan-devel
libldb
libldb-devel
libtalloc
libtalloc-devel
libtdb
libtdb-devel
libtevent
libtevent-devel
log4cpp
log4cpp-devel
nedit
perl-Config-General
perl-NetAddr-IP
python-ctypes
python-ethtool
python-kerberos
python-pycurl
python-suds
sblim-cim-client
sblim-cim-client-javadoc
sblim-cim-client-manual
sblim-sfcc
sblim-sfcc-devel
scl-utils
scl-utils-build
tdb-tools
tunctl
tzdata-java
--- CentO6S vs EPEL6
a2ps
emacs-a2ps
emacs-a2ps-el
febootstrap
freerdp
freerdp-devel
freerdp-libs
freerdp-plugins
google-crosextra-caladea-fonts
google-crosextra-carlito-fonts
ht2html
html2ps
json-c
json-c-devel
json-c-doc
libmicrohttpd
libmicrohttpd-devel
libmicrohttpd-doc
lzop
perl-B-Keywords
perl-Class-Accessor
perl-Class-Data-Inheritable
perl-Class-MethodMaker
perl-Class-Trigger
perl-Config-Simple
perl-Crypt-PasswdMD5
perl-DateTime-Format-DateParse
perl-Devel-Cycle
perl-Exception-Class
perl-File-pushd
perl-Font-AFM
perl-HTML-Format
perl-IO-Tty
perl-IPC-Run
perl-Locale-Maketext-Gettext
perl-Locale-PO
perl-MIME-Lite
perl-MIME-Types
perl-Module-Find
perl-Net-SMTP-SSL
perl-PadWalker
perl-Parse-RecDescent
perl-Perl-Critic
perl-Pod-Spell
perl-String-Format
perl-Syntax-Highlight-Engine-Kate
perl-Term-ProgressBar
perl-Test-Memory-Cycle
perl-Test-Perl-Critic
perl-Test-Spelling
perl-UNIVERSAL-can
perl-UNIVERSAL-isa
perl-XML-TokeParser
perl-XML-Writer
pexpect
PyPAM
python-krbV
python-suds
python-tw-forms
python-urwid
scl-utils
scl-utils-build
scons
snappy
snappy-devel
tagsoup
tagsoup-javadoc
wordnet
wordnet-devel
xerces-c
xerces-c-devel
xerces-c-doc
xhtml2ps
--- CentOS7 vs EPEL7
advancecomp
ceph-common
fontawesome-fonts
fontawesome-fonts-web
golang-github-syndtr-gocapability-devel
itstool
libgpod
libgpod-devel
libgpod-doc
libnetfilter_queue
libnetfilter_queue-devel
libntlm
libntlm-devel
librados2
librados2-devel
librbd1
librbd1-devel
libsrtp
libsrtp-devel
libvncserver
libvncserver-devel
perl-Crypt-PasswdMD5
perl-LWP-Protocol-https
perl-Mozilla-CA
po4a
python-gpod
python-mutagen
python-qrcode
python-qrcode-core
python-rados
python-rbd
rubygem-minitest
scap-security-guide
t1utils
thunderbird
xmlsec1
xmlsec1-devel
xmlsec1-gcrypt
xmlsec1-gcrypt-devel
xmlsec1-gnutls
xmlsec1-gnutls-devel
xmlsec1-nss
xmlsec1-nss-devel
xmlsec1-openssl
xmlsec1-openssl-devel
[code]
for ver in c5 c6 c7
do
repoquery -a --repoid=$ver-base --repoid=$ver-updates
--repoid=$ver-cr --qf '%{name}' | sort -u > /tmp/centos-$ver.txt
repoquery -a --repoid=$ver-epel --repoid=$ver-epel-testing --qf
'%{name}' | sort -u > /tmp/epel-$ver.txt
echo CentOS vs EPEL, $ver
while read pkgname; do grep -e "^$pkgname$" /tmp/epel-$ver.txt ;
done < /tmp/centos-$ver.txt
done
[/code]
If you think this list needs to be acted upon, feel free.
Some of these (certainly many of the perl modules) are in EPEL as clones
of RHEL packages because RHEL does not provide them for all
architectures. Removing them would break dependencies for RHEL users on
the affected architectures (mainly ppc).
Paul.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Fwd: [Fedora-packaging] %license for EPEL6
On Tue, 17 Mar 2015 11:34:10 -0600
Stephen John Smoogen wrote:
> This was on the packaging list but effects EPEL. Any suggestions?
>
> -- Forwarded message --
> From: Thomas Moschny
> Date: 17 March 2015 at 10:59
> Subject: [Fedora-packaging] %license for EPEL6
> To: Fedora Packaging list
>
>
> I have a package that can be build on all Fedora branches and on EPEL
> 6 and 7 with the same spec file. It uses
>
> %{!?_pkgdocdir: %global _pkgdocdir %{_docdir}/%{name}-%{version}}
>
> and copies all docs to this %_pkgdocdir. This works fine.
>
> Now how should I handle licenses? On EPEL6, %license is not defined,
> neither is %_licensedir.
> One possibility is to use
>
> %{!?_licensedir:%global license %%doc}
>
> but that would violate the (fresh) packaging guideline mandating usage
> of either %_pkgdocdir or %doc, but not both in the same specfile.
> Any other suggestions?
I have a similar issue in libpng10:
http://pkgs.fedoraproject.org/cgit/libpng10.git/tree/libpng10.spec
Basically, I copy the license file into %_pkgdocdir like for any other
documentation on systems where %_licensedir isn't defined.
Paul.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Is this a bug? proftpd doesn't include mod_sftp
On 15/03/15 16:25, David White wrote: The proftpd package in the EPEL CentOS 7 repo doesn't seem to include mod_sft. |[root@blah /]#! proftpd - l Compiled-in modules: mod_core.c mod_xfer.c mod_rlimit.c mod_auth_unix.c mod_auth_file.c mod_auth.c mod_ls.c mod_log.c mod_site.c mod_delay.c mod_facts.c mod_dso.c mod_ident.c mod_readme.c mod_auth_pam.c mod_tls.c mod_memcache.c mod_cap.c mod_ctrls.c mod_lang.c| Is this because mod_sftp is a contributed module, or is there another reason why it was intentionally left out? It's not left out, it's a loadable module that's only loaded on demand. To use it, you'll need to uncomment the line: # LoadModule mod_sftp.c in the shipped proftpd.conf file. If you're using your own proftpd.conf file, you'll need to explicitly load the module. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] perl-Net-CIDR missing from Centos 7 EPEL; unable to install munin-node
On 17/11/14 15:44, Axel S wrote: Hi all, It seems like perl-Net-CIDR is not availabe in the Centos 7 EPEL? Because of this I am not able to install munin-node, whick depends on perl-Net-CIDR. (also tried with --skip-broken). I don't know of perl-Net-CIDR has been available before, but I have successfully installed munin-node on Centos 7 previously... Already on it: https://bugzilla.redhat.com/show_bug.cgi?id=1163610 https://admin.fedoraproject.org/updates/perl-Net-CIDR-0.17-6.el7 Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] epel install nginx error
On 07/11/14 09:36, Elías Chistyakov wrote: Hi All, I get an error when installing nginx on CentOS 6.4. My actions: rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum install nginx Error message: GeoIP-1.4.8-1.el6.x86_64: failure: GeoIP-1.4.8-1.el6.x86_64.rpm from epel: [Errno 256] No more mirrors to try. How to do fix this? Looks like you're accessing a very out of date mirror. Current version of GeoIP in EPEL 6 is 1.5.1, and has been for a few months now. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 5 orphaned packages status
On 19/08/14 07:06, Till Maas wrote: Hi, there are a lot of orphaned packages in EPEL 5, that should IMHO either be properly maintained or retired, here is a rough overview: ... I took perl-DateTime-Format-Mail Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 branch requests
On 11/03/14 14:59, Dave Johansen wrote: On Sun, Feb 23, 2014 at 10:22 AM, Kevin Fenzi mailto:ke...@scrye.com>> wrote: On Sun, 23 Feb 2014 18:10:10 +0100 Dominik 'Rathann' Mierzejewski mailto:domi...@greysector.net>> wrote: > Hello everyone, > are the EPEL7 branch requests on > https://fedoraproject.org/wiki/EPEL/epel7/Requests still being > processed or are we back to the standard branch requests in the > original review bugs? Yes they are. I'll look at processing it later today if no one beats me to it. I added the packages that I maintain to the list and they've been added, but do I have to kick off the builds on koji? Or is that done automatically? You have to do the builds yourself. Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 status
On 14/01/14 14:27, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 14 Jan 2014 14:18:38 + Paul Howarth escribió: On 10/01/14 23:52, Dennis Gilmore wrote: Hi All, Se we have composes working automatically now, the job had been failing. I'm trying to get epel 7 to the point where the packaging tools are available on epel7. hopefully that will be by the end of today. In order to submit builds for epel7 you need to have fedpkg-1.15-1 installed, versions prior will fail due to not understanding the epel7 branch. https://fedoraproject.org/wiki/EPEL/epel7 lists all the packages in RHEL 7 Beta. Please put branching request in https://fedoraproject.org/wiki/EPEL/epel7/Requests if you think of a better way to file requests please speak up. We will do some checking that the package is not in RHEL before branching but please check the list if you are not sure. I'm getting along nicely with most of my packages, but I'm having trouble pushing a single fast-forward commit for one of my packages: $ git status # On branch epel7 # Your branch is ahead of 'origin/epel7' by 1 commit. # (use "git push" to publish your local commits) # nothing to commit, working directory clean $ fedpkg push Total 0 (delta 0), reused 0 (delta 0) remote: W refs/heads/epel7 perl-Compress-Raw-Lzma pghmcfc DENIED by refs/heads/epel[0-9] remote: error: hook declined to update refs/heads/epel7 To ssh://pghm...@pkgs.fedoraproject.org/perl-Compress-Raw-Lzma ! [remote rejected] epel7 -> epel7 (hook declined) error: failed to push some refs to 'ssh://pghm...@pkgs.fedoraproject.org/perl-Compress-Raw-Lzma' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Any ideas? The branch is done in git but I didn't get the email about it being added to pkgdb, and a pkgdb query doesn't show the epel7 branch. Something gone wrong during branching? Im guessing you put EL-6 as the acl source in your request, and the package currently does not exist in EPEL so you needed to use devel as the source to copy the acls from. I thought it was clear what you needed to do, but apparently not so please help to make the wording better so that everyone gets it. you will need to put in a new request with the correct acl source Whoops. I did see that and understood it too. Virtually all of my packages go all the way back to EL-5 and there are very few without an EL-6 branch so I forgot to check in this case and just put EL-6 out of habit. Sorry about that, branch re-requested. Regards, Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 status
On 10/01/14 23:52, Dennis Gilmore wrote: Hi All, Se we have composes working automatically now, the job had been failing. I'm trying to get epel 7 to the point where the packaging tools are available on epel7. hopefully that will be by the end of today. In order to submit builds for epel7 you need to have fedpkg-1.15-1 installed, versions prior will fail due to not understanding the epel7 branch. https://fedoraproject.org/wiki/EPEL/epel7 lists all the packages in RHEL 7 Beta. Please put branching request in https://fedoraproject.org/wiki/EPEL/epel7/Requests if you think of a better way to file requests please speak up. We will do some checking that the package is not in RHEL before branching but please check the list if you are not sure. I'm getting along nicely with most of my packages, but I'm having trouble pushing a single fast-forward commit for one of my packages: $ git status # On branch epel7 # Your branch is ahead of 'origin/epel7' by 1 commit. # (use "git push" to publish your local commits) # nothing to commit, working directory clean $ fedpkg push Total 0 (delta 0), reused 0 (delta 0) remote: W refs/heads/epel7 perl-Compress-Raw-Lzma pghmcfc DENIED by refs/heads/epel[0-9] remote: error: hook declined to update refs/heads/epel7 To ssh://pghm...@pkgs.fedoraproject.org/perl-Compress-Raw-Lzma ! [remote rejected] epel7 -> epel7 (hook declined) error: failed to push some refs to 'ssh://pghm...@pkgs.fedoraproject.org/perl-Compress-Raw-Lzma' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Any ideas? The branch is done in git but I didn't get the email about it being added to pkgdb, and a pkgdb query doesn't show the epel7 branch. Something gone wrong during branching? Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
