[EPEL-devel] Re: How can I add a component for fedora to request a packges?

2022-10-21 Thread Carl George
On Fri, Oct 21, 2022 at 5:26 PM Betty Liu  wrote:
>
> Hi, I want to request a package in EPEL8 and I follow the steps in the 
> documentation
> If  isn’t found in Component under "Fedora EPEL" or "Fedora" 
> Products, it should be added to Fedora first
>
> The package name is webkit2gtk-4.0 and I saw it in Fedora, but not in the 
> RedHat Bugzilla. Can anyone teach me how to add the component to fedora?
> ___
> 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

The component in bugzilla corresponds to the source package name, not
the binary package name.  Often times these are the same, but you've
run into one of the instances where they are not.  One way to check
for this is to use the dnf repoquery command, in this case on Fedora
since that's where the package is present and query-able.

[root@f37-container:~]# dnf repoquery --quiet --info webkit2gtk4.0 |
grep --max-count 1 Source
Source   : webkitgtk-2.38.0-3.fc37.src.rpm

Alternatively, you can search for the package name in the Fedora
Packages web app.

https://packages.fedoraproject.org/search?query=webkit2gtk4.0

This returns one result, which shows webkit2gtk4.0 as a "subpackage"
of webkitgtk.  That's another way to describe the source/binary
relationship.

https://packages.fedoraproject.org/pkgs/webkitgtk/webkit2gtk4.0/

Whichever way you discover the source name, use that as the component
for your bugzilla request.

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=webkitgtk

-- 
Carl George
___
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 repo error for distribution-gpg-keys?

2022-10-21 Thread Todd Zullinger
manuel wolfshant wrote:
> On 10/22/22 00:22, Troy Dawson wrote:
>> 
>> distribution-gpg-keys-1.78-1.el7 is currently in testing.
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0
>> 
>> You can get things moving my using the epel-testing repo
>>   yum --enablerepo=epel-testing update mock-core-configs
> 
> s/distribution-gpg-keys/distribution-gpg-keys :)

I presume s/mock-core-configs/distribution-gpg-keys/ is what
you meant? ;)

But since the OP was trying to install mock-core-configs and
hitting the issue, installing that package with the
epel-testing repo enabled would seem to be the quicker way
to the end goal.

Thanks to the karma you each left, the update is on the way
to the stable repo now.  (I added another, but only because
I had done the testing before I noticed that it only needed
2 positive karma points.)

-- 
Todd


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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] How can I add a component for fedora to request a packges?

2022-10-21 Thread Betty Liu
Hi, I want to request a package in EPEL8 and I follow the steps in the 
documentation
If  isn’t found in Component under "Fedora EPEL" or "Fedora" Products, 
it should be added to Fedora first

The package name is webkit2gtk-4.0 and I saw it in Fedora, but not in the 
RedHat Bugzilla. Can anyone teach me how to add the component to fedora?
___
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 repo error for distribution-gpg-keys?

2022-10-21 Thread manuel wolfshant

On 10/22/22 00:22, Troy Dawson wrote:
On Wed, Oct 19, 2022 at 2:44 AM Nick Howitt via epel-devel 
 wrote:


On a server I don't use very often, I am trying to update
mock-core-configs with yum and I am seeing:


Resolving Dependencies
--> Running transaction check
---> Package mock-core-configs.noarch 0:36.9-1.el7 will be updated
---> Package mock-core-configs.noarch 0:36.13-1.el7 will be an update
--> Processing Dependency: distribution-gpg-keys >= 1.77 for
package: mock-core-configs-36.13-1.el7.noarch
--> Finished Dependency Resolution
Error: Package: mock-core-configs-36.13-1.el7.noarch
(epel-unverified)
   Requires: distribution-gpg-keys >= 1.77
   Installed: distribution-gpg-keys-1.75-1.el7.noarch
(@epel-unverified)
   distribution-gpg-keys = 1.75-1.el7
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


On another server I regularly use and update I have
distribution-gpg-keys-1.77-1.el7.noarch which I updated to a while
back, so it appears that the updated package has been removed?
Obviously this then breaks updating mock-core-configs. If
distribution-gpg-keys-1.77-1.el7.noarch was a bad release, perhaps
1.75 should be bumped to a later version so it gets installed over
1.77 rather than just removing the package?


Hi Nick,
Looking at the koji history, 1.77 never was untagged, but 1.75 was 
tagged in on Oct. 10th.  Koji and the repo's only show what was the 
last tagged in.

I'm not sure why 1.75 was tagged in.

distribution-gpg-keys-1.78-1.el7 is currently in testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0

You can get things moving my using the epel-testing repo
  yum --enablerepo=epel-testing update mock-core-configs


s/distribution-gpg-keys/distribution-gpg-keys :)


If it works for you (it works for me) give the update some karma so it 
will go out quicker.




wfm too

___
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 repo error for distribution-gpg-keys?

2022-10-21 Thread Troy Dawson
On Wed, Oct 19, 2022 at 2:44 AM Nick Howitt via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> On a server I don't use very often, I am trying to update
> mock-core-configs with yum and I am seeing:
>
> Resolving Dependencies
> --> Running transaction check
> ---> Package mock-core-configs.noarch 0:36.9-1.el7 will be updated
> ---> Package mock-core-configs.noarch 0:36.13-1.el7 will be an update
> --> Processing Dependency: distribution-gpg-keys >= 1.77 for package:
> mock-core-configs-36.13-1.el7.noarch
> --> Finished Dependency Resolution
> Error: Package: mock-core-configs-36.13-1.el7.noarch (epel-unverified)
>Requires: distribution-gpg-keys >= 1.77
>Installed: distribution-gpg-keys-1.75-1.el7.noarch
> (@epel-unverified)
>distribution-gpg-keys = 1.75-1.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
>
>
> On another server I regularly use and update I have
> distribution-gpg-keys-1.77-1.el7.noarch which I updated to a while back, so
> it appears that the updated package has been removed? Obviously this then
> breaks updating mock-core-configs. If
> distribution-gpg-keys-1.77-1.el7.noarch was a bad release, perhaps 1.75
> should be bumped to a later version so it gets installed over 1.77 rather
> than just removing the package?
>

Hi Nick,
Looking at the koji history, 1.77 never was untagged, but 1.75 was tagged
in on Oct. 10th.  Koji and the repo's only show what was the last tagged in.
I'm not sure why 1.75 was tagged in.

distribution-gpg-keys-1.78-1.el7 is currently in testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0

You can get things moving my using the epel-testing repo
  yum --enablerepo=epel-testing update mock-core-configs
If it works for you (it works for me) give the update some karma so it will
go out quicker.

Troy
___
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: Modularity transition plan

2022-10-21 Thread Troy Dawson
On Fri, Oct 21, 2022 at 9:59 AM Leon Fauster via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Am 21.10.22 um 17:11 schrieb Troy Dawson:
> ...
> > == Transition Steps
> > === 1 - Verify that you are using an EPEL 8 Module
> > dnf list installed | grep epel-modular
> > If nothing shows up, great, you are done.
>
> just wanted to add:
>
> dnf list installed | grep epel-testing-modular
>

Thanks Leon, I forgot that.
I guess to have it all in one

  dnf list installed | grep -e epel-modular -e epel-testing-modular
___
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: Modularity transition plan

2022-10-21 Thread Leon Fauster via epel-devel

Am 21.10.22 um 17:11 schrieb Troy Dawson:
...

== Transition Steps
=== 1 - Verify that you are using an EPEL 8 Module
dnf list installed | grep epel-modular
If nothing shows up, great, you are done.


just wanted to add:

dnf list installed | grep epel-testing-modular

--
Leon

___
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] Modularity transition plan

2022-10-21 Thread Troy Dawson
We have been asked for a transition plan, for people using epel 8 modules.
Although we have talked about a transition plan, I realized we didn't write
anything outside of chats and talking to one another.  I believe this is
what we said, but if others can verify and/or correct me, that would be
great.

= EPEL 8 Modularity transition plan
There are users that use EPEL 8 Modules.  This is a transition plan to help
users through this process.

== Transition Steps
=== 1 - Verify that you are using an EPEL 8 Module
  dnf list installed | grep epel-modular
If nothing shows up, great, you are done.

=== 2 - Determine if there are alternatives
Several of the EPEL 8 modules are in RHEL's modules, or are non-modular
packages in epel.  In the list below, look for the modules with [a].  That
means there is an alternative to the epel module.  If your module version
has an [s], then the alternative is the same version.  If your module
version has a [d], then the alternative has a different version.
If you have an alternative, safely switch to the alternative packages.[1]
If you were able to move off of all your epel 8 modules, great, you are
done.

=== 3 - Request non-modular package for EPEL 8
If there were no alternative packages to move to, then request the package
be put in non-modular epel8.  Once it is in non-modular EPEL 8, got back to
step 2.
https://docs.fedoraproject.org/en-US/epel/epel-package-request/

=== 4 - Last Resort
If you have been unable to transition off the EPEL 8 Modules, then the
final option is to just keep using them.  Because the mirrors will be
pointing to the archives, there is nothing you need to change in your
epel-modularity configuration file.  It will just continue to work.  But
keep a backup somewhere because eventually, the epel-modularity
configuration will be completely removed from epel-release.
This is not recommended.  The modules will not receive any further security
or bug fixes.

== EPEL 8 Modules
Legend:
[a] - There is an alternative
[n] - There is no alternative
[s] - There is an alternative with the same version
[d] - There is an alternative with a different version
[x] - This module didn't install, or had some problems with it.

=== 389-directory-server [n]
=== avocado [a]
  * latest [d]
  * 8.2 [s]
=== avocado-vt [n]
=== cobbler [n]
=== cri-o [n]
=== dwm [n][x]
  Does not install on RHEL 8
=== ghc [a]
  * 8.2 [s]
  * 8.4 [d]
=== libuv [a]
=== nextcloud [n][x]
  None of the modules install on RHEL 8
=== nginx [a][d]
=== nodejs [a]
  * 13 [d]
  * 16-epel [s]
=== postgresql [a][d]
=== swig [a][x][s]
  The EPEL version conflicts with RHEL's, should have been removed earlier.
=== zabbix [a]
  * 5.0 [d]
  * 6.0 [s]


Does this sound correct to everyone?

Troy

[1] - Detailed instructions for moving to alternative packages are out of
the scope of this document.
___
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] Fedora EPEL 7 updates-testing report

2022-10-21 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-473e5052db   
ckeditor-4.20.0-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-576e858e93   
php-Smarty-3.1.47-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-22e6871166   
drupal7-7.92-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-42745d5b54   
wordpress-5.1.15-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-204b242845   
jhead-3.06.0.1-5.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c6dc44e789   
exim-4.96-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

uberftp-2.9.1-1.el7

Details about builds:



 uberftp-2.9.1-1.el7 (FEDORA-EPEL-2022-4e493690bb)
 GridFTP-enabled ftp client

Update Information:

Version 2.9.1  * The fix for recursive listings was incomplete and created a
regression preventing recursive file transfer operations to succeed. This is
fixed now. *  If the environment variable UBERFTP_CAT_CORRECT is present, this
version omits the odd newline that is printed out by the cat functionality of
previous versions of UberFTP. If not, the old behaviour is used for
compatibility reasons.

ChangeLog:

* Thu Oct 20 2022 Steve Traylen  - 2.9.1-1
- Upstream to 2.9.1


___
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