[EPEL-devel] Re: EPEL9 updates obsoleted

[Sérgio Basto]

Following Fabio Valentini tip ,

One thing you *could* try is do a new side-tag and move the builds to
there .

and example of move build : 

koji move-build epel8-testing-candidate epel8-build-side-52356
ImageMagick-6.9.12.44-1.el8


On Tue, 2024-04-09 at 11:46 +0200, Antonio T. sagitter wrote:
> Yes, but i can't because the side-tag is already used.
> 
> On 08/04/24 09:52, Sandro wrote:
> > On 07-04-2024 19:04, Antonio T. sagitter wrote:
> > > Can this update be re-activated or i have to rebuild everything?
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab
> > 
> > Have you tried re-submitting the side tag to Bodhi?
> > -- 
> > ___
> > 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
> 
> -- 
> ---
> Antonio Trande
> Fedora Project
> https://fedoraproject.org/wiki/User:Sagitter
> mailto: sagit...@fedoraproject.org
> GPG key: 0x40FDA7B70789A9CD
> GPG keys server: https://keys.openpgp.org/

-- 
Sérgio M. B.
--
___
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: Packages to be untagged from epel-next

[Sérgio Basto]

On Sat, 2023-11-18 at 09:35 +0200, Tuomo Soini wrote:
> On Fri, 17 Nov 2023 21:31:37 +
> Sérgio Basto  wrote:
> 
> > Hi, 
> > Is not an negative feedback, is a side note but I realize some time
> > ago that version with next is bigger than version without next [1]
> > therefore we should find a way that the el8 version be greater than
> > the el8.next version.
> > 
> > 
> > [1] 
> > 
> > rpmdev-vercmp 1.el8.next 1.el8
> > 
> > 1.el8.next > 1.el8
> > 
> 
> I already suggested adding requirement to do a release bump when
> building from epel-next to epel.
> 
> https://pagure.io/epel/pull-request/259
> 
> I find it important that new, compatible with new rhel build has
> bigger
> version-release than epel-next build.
> 

I just tested 

rpmdev-vercmp 1.el8.next 1.el8
1.el8.next > 1.el8

rpmdev-vercmp 1.el8.next 1.el8.1
1.el8.next < 1.el8.1


so rpmdev-bumpspec --rightmost is enough 


> -- 
> Tuomo Soini 
> Foobar Linux services
> +358 40 5240030
> Foobar Oy <https://foobar.fi/>
> --
> ___
> 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

-- 
Sérgio M. B.
--
___
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: Packages to be untagged from epel-next

[Sérgio Basto]

Hi, 
Is not an negative feedback, is a side note but I realize some time
ago that version with next is bigger than version without next [1]
therefore we should find a way that the el8 version be greater than the
el8.next version.


[1] 

rpmdev-vercmp 1.el8.next 1.el8

1.el8.next > 1.el8



On Fri, 2023-11-17 at 09:24 -0800, Troy Dawson wrote:
> I haven't heard any negative feedback from these.
> I will untag these today.
> 
> On Wed, Nov 15, 2023 at 12:55 PM Troy Dawson 
> wrote:
> > The following packages have the same version in epel-next as in
> > epel.
> > I plan on untagging them from epel-next unless people tell me
> > otherwise.
> > 
> > epel8-next:
> > boinc-client-7.20.2-1.el8.next
> > darktable-3.8.1-2.el8.next
> > kimageannotator-0.6.1-1.el8.next
> > ksnip-1.10.1-1.el8.next
> > python3.11-dns-epel-2.2.1-2.el8.next
> > python3.11-jmespath-epel-1.0.1-1.el8.next
> > 
> > epel9-next:
> > cargo2rpm-0.1.13-1.el9.next
> > keepassxc-2.7.6-1.el9.next
> > python3.11-dns-epel-2.2.1-2.el9.next
> > python3.11-jmespath-epel-1.0.1-1.el9.next
> > python3.11-netaddr-epel-0.8.0-1.el9.next
> > python3.11-ntlm-auth-epel-1.5.0-1.el9.next
> > rust-addr2line-0.19.0-1.el9.next
> > rust-aho-corasick-1.1.2-1.el9.next
> > rust-ansiterm-0.12.2-1.el9.next
> > rust-arbitrary-1.3.0-1.el9.next
> > rust-automod-1.0.13-1.el9.next
> > rust-backtrace-0.3.67-2.el9.next
> > rust-bitflags-2.4.1-1.el9.next
> > rust-bstr0.2-0.2.17-1.el9.next
> > rust-bstr-1.7.0-1.el9.next
> > rust-bumpalo-3.14.0-1.el9.next
> > rust-bytesize-1.3.0-1.el9.next
> > rust-byte-unit-4.0.19-1.el9.next
> > rust-cargo-0.64.0-3.el9.next
> > rust-clap3-3.2.25-1.el9.next
> > rust-clap_complete3-3.2.5-1.el9.next
> > rust-clap_derive3-3.2.25-1.el9.next
> > rust-crossbeam-epoch-0.9.15-2.el9.next
> > rust-csv-1.3.0-1.el9.next
> > rust-csv-core-0.1.11-1.el9.next
> > rust-ctor-0.2.5-1.el9.next
> > rust-deranged-0.3.8-1.el9.next
> > rust-directories4-4.0.1-1.el9.next
> > rust-directories-5.0.1-1.el9.next
> > rust-env_logger-0.10.0-1.el9.next
> > rust-env_logger0.9-0.9.3-1.el9.next
> > rust-grep-cli-0.1.7-1.el9.next
> > rust-grep-printer-0.1.7-1.el9.next
> > rust-grep-regex-0.1.11-1.el9.next
> > rust-grep-searcher-0.1.11-1.el9.next
> > rust-half1-1.8.2-1.el9.next
> > rust-hashbrown-0.14.2-1.el9.next
> > rust-ignore-0.4.20-1.el9.next
> > rust-indexmap-2.0.2-1.el9.next
> > rust-is_executable-1.0.1-1.el9.next
> > rust-jobserver-0.1.27-1.el9.next
> > rust-lexopt-0.3.0-1.el9.next
> > rust-libc-0.2.149-1.el9.next
> > rust-libm-0.2.8-1.el9.next
> > rust-lock_api-0.4.11-1.el9.next
> > rust-memchr-2.6.4-1.el9.next
> > rust-miniz_oxide0.5-0.5.4-1.el9.next
> > rust-miniz_oxide-0.7.1-3.el9.next
> > rust-num_enum-0.5.11-1.el9.next
> > rust-num_enum_derive-0.5.11-1.el9.next
> > rust-num-traits-0.2.17-1.el9.next
> > rust-object-0.30.3-1.el9.next
> > rust-os_pipe0.9-0.9.2-3.el9.next
> > rust-os_str_bytes-6.6.1-1.el9.next
> > rust-packaging-25.2-1.el9.next
> > rust-parking_lot_core-0.9.9-1.el9.next
> > rust-predicates-core-1.0.6-1.el9.next
> > rust-print_bytes-1.2.0-1.el9.next
> > rust-proc-macro2-1.0.69-1.el9.next
> > rust-rayon-1.8.0-1.el9.next
> > rust-rayon-core-1.12.0-1.el9.next
> > rust-regex-1.10.2-1.el9.next
> > rust-regex-automata-0.4.3-1.el9.next
> > rust-regex-syntax0.7-0.7.5-1.el9.next
> > rust-regex-syntax-0.8.2-1.el9.next
> > rust-relative-path-1.9.0-1.el9.next
> > rust-roff0.1-0.1.0-1.el9.next
> > rust-roff-0.2.1-1.el9.next
> > rust-rpassword5-5.0.1-1.el9.next
> > rust-rpassword-7.2.0-1.el9.next
> > rust-rstest-0.18.2-1.el9.next
> > rust-rstest_macros-0.18.2-1.el9.next
> > rust-rstest_reuse-0.6.0-1.el9.next
> > rust-rtoolbox-0.0.1-1.el9.next
> > rust-rust_decimal-1.32.0-1.el9.next
> > rust-serde-1.0.189-1.el9.next
> > rust-serde_derive-1.0.189-1.el9.next
> > rust-serde_json-1.0.107-1.el9.next
> > rust-shared_child-1.0.0-3.el9.next
> > rust-smallvec-1.11.1-1.el9.next
> > rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
> > rust-strip-ansi-escapes-0.2.0-1.el9.next
> > rust-syn-2.0.38-1.el9.next
> > rust-system-deps-6.1.2-1.el9.next
> > rust-tempfile-3.8.0-1.el9.next
> > rust-termcolor-1.3.0-1.el9.next
> > rust-terminal_size0.2-0.2.6-1.el9.next
> > rust-terminal_size-0.3.0-1.el9.next
> > rust-textwrap0.15-0.15.2-1.el9.next
> > rust-textwrap-0.16.0-1.el9.next
> > rust-thread-id-4.2.1-1.el9.next
> > rust-timeago-0.4.2-1.el9.next
> > rust-time-core-0.1.1-1.el9.next
> > rust-toml0.5-0.5.11-1.el9.next
> > rust-toml0.7-0.7.8-1.el9.next
> > rust-toml-0.8.2-1.el9.next
> > rust-toml_edit0.19-0.19.15-1.el9.next
> > rust-toml_edit-0.20.2-1.el9.next
> > rust-ucd-parse-0.1.10-1.el9.next
> > rust-winnow0.4-0.4.11-1.el9.next
> > rust-winnow-0.5.16-1.el9.next
> > rust-xml-rs-0.8.19-1.el9.next
> > 
> > 
> > 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/

[EPEL-devel] Re: kdenlive is ready for epel9

[Sérgio Basto]

On Mon, 2023-05-15 at 08:54 -0700, Troy Dawson wrote:
> Hi Sérgio,
> Thank you for the update and reminder.
> I've put kdenlive on my KDE list of packages that I check and update.
> It will automatically get updated in step with the other KDE packages
> in epel.
> 
> That means that for epel9, it will be the F37 version of kdenlive -
> 22.12.3.
> For epel9-next it will be the F38 version of kdenlive - 23.04.0 (or
> possibly 23.04.1)
> 
> Then it will continue to get updates along with the other KDE
> packages in epel9 / epel9-next


LGTM, thank you 



> Troy
> 
> On Mon, May 15, 2023 at 5:02 AM Sérgio Basto 
> wrote:
> > Hi Troy,
> > 
> > Yesterday , after telling Neal that we already can build kdenlive
> > on
> > EPEL 9, since rttr package was pushed to stable repo.
> > 
> > Neal wrote to you (in KDE channel) :
> > "I was reminded by sergiomb that kdenlive should be upgraded along
> > with
> > other KDE apps when you're doing the Plasma upgrade for EPEL 9
> > 
> > since kdenlive was added to Fedora and EPEL only a few months ago,
> > it
> > might not be in on your register to track that too, hence the
> > reminder"
> > 
> > 
> > With --enablerepo=epel-next-testing and --enablerepo=epel-testing
> > kdenlive builds on epel-next-9 with rawhide sources without any
> > modification.
> > 
> > In resume what to you prefer or think ? you add kdenlive to kde
> > track
> > or we build it as an epel package ? 
> > 
> > Thank you.
> > 
> > Best regards,

-- 
Sérgio M. B.
___
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] kdenlive is ready for epel9

[Sérgio Basto]

Hi Troy,

Yesterday , after telling Neal that we already can build kdenlive on
EPEL 9, since rttr package was pushed to stable repo.

Neal wrote to you (in KDE channel) :
"I was reminded by sergiomb that kdenlive should be upgraded along with
other KDE apps when you're doing the Plasma upgrade for EPEL 9

since kdenlive was added to Fedora and EPEL only a few months ago, it
might not be in on your register to track that too, hence the reminder"


With --enablerepo=epel-next-testing and --enablerepo=epel-testing
kdenlive builds on epel-next-9 with rawhide sources without any
modification.

In resume what to you prefer or think ? you add kdenlive to kde track
or we build it as an epel package ? 

Thank you.

Best regards,
-- 
Sérgio M. B.
___
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: python3-qt5-webkit for EPEL 8

[Sérgio Basto]

On Sun, 2023-01-29 at 10:26 -0700, Orion Poplawski wrote:
> The python-qt5 package in RHEL 8 does not ship the webkit package. 
> I'm 
> assuming that this is unlikely to be changed since qt5-qtwebkit isn't
> in 
> RHEL but is in EPEL.
> 
> I think I'm close to producing a python-qt5-epel package here [1]
> that 
> produces python3-qt5-webkit and would love to hear from people more 
> familiar with the package if this seems like it's
> reasonable/workable.
> 
Hi,

I got a similar problem with smtube , all distros are starting dropping
qt5-webkit and the natural replacement is qtwebengine .


https://github.com/smplayer-dev/smtube/issues/7
https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval 

> I think we're depending on the fact that the RHEL python3-qt5-devel 
> package does ship the WebKit sip files and that these would match up 
> with what this package ships.
> 
> It also just seems like webengine isn't in there, or I'm missing
> what's 
> needed to build it.  I also don't need it for my purposes.
> 



> [1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
> 
> 
> ___
> 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

-- 
Sérgio M. B.
___
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] gcc bug on RHEL9 , How we reach RHEL team ?

[Sérgio Basto]

Hi,
Sorry, now subject is correct, the gcc have one patch for the error
above, that is seen on rhel 9 

https://bugzilla.redhat.com/show_bug.cgi?id=1996330#c14


-- 
Sérgio M. B.
___
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

-- 
Sérgio M. B.
___
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] gcc ee this bug on RHEL9 , How we reach RHEL team ?

[Sérgio Basto]

https://bugzilla.redhat.com/show_bug.cgi?id=1996330#c14
-- 
Sérgio M. B.
___
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: Are there any plans to rebuild ClamAV in EPEL7 following CVE-2022-37434?

[Sérgio Basto]

On Tue, 2022-11-01 at 10:50 +, Nick Howitt via epel-devel wrote:
>  Yesterday, ClamAV announced CVE-2022-37434 as critical
> (https://blog.clamav.net/2022/10/new-packages-for-clamav-01037-01044.
> html). Redhat only seem to classify the issue as Moderate in EL7 -
> https://access.redhat.com/security/cve/cve-2022-37434. It looks like
> that, unless Redhat classify it as Critical, zlib and zlib-devel
> won't get updated so ClamAV can't be rebuilt against the updated
> zlib-devel. What is the EPEL take on the issue?


we build clamav from the sources , no bundles evolved , we use system
zlib and libxml2 




-- 
Sérgio M. B.
___
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: python-attrs on epel very outdated

[Sérgio Basto]

On Tue, 2022-07-05 at 13:00 +0200, Miro Hrončok wrote:
> On 05. 07. 22 12:43, Stephen Smoogen wrote:
> > You will need to work with the upstream RHEL team to see if they
> > can update 
> > python-attrs
> 
> The rule of thumb is that we don't. If you need a certain feature
> from the 
> newer version, you can try requesting a backport, explaining your use
> case. We 
> generally try to help fellow EPEL packagers even when they are not
> RHEL 
> customers (when the backport is doable with reasonable effort).
> 
> However, if you just want a newer version because you like new
> things, maybe 
> try Fedora Linux instead of EL+EPEL.


https://github.com/shlomif/PySolFC/issues/159 , I realized  pysolfc-
2.8.0 (Mar 05, 2020) already doesn't work on epel 7 and epel 8 ...




> -- 
> Miro Hrončok

-- 
Sérgio M. B.
___
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] python-attrs on epel very outdated

[Sérgio Basto]

Hi,

looking to 
https://koji.fedoraproject.org/koji/packageinfo?packageID=22940
and
https://www.attrs.org/en/stable/changelog.html 
and
https://git.centos.org/rpms/python-attrs

18.1.0 was release on 2018-05-03 , but centos 8 have 17.04

in 2019-02-25 we have the first update of python-attrs to 18.x 

Remember python-attrs don't have many deps , what  I can do to have it
updated at least to 18.x version released at 2018 / 2019 ? 



python-pystalk (maintained by: orphan)
python-pystalk-0.5.1-2.el7.src requires python2-attrs = 17.4.0-4.el7,
python36-attrs = 17.4.0-4.el7
python2-pystalk-0.5.1-2.el7.noarch requires python2-attrs = 17.4.0-
4.el7
python36-pystalk-0.5.1-2.el7.noarch requires python36-attrs = 17.4.0-
4.el7

python-service-identity (maintained by: carlwgeorge, eclipseo,
ignatenkobrain, python-sig, ralph)
python-service-identity-18.1.0-1.el7.src requires python36-attrs =
17.4.0-4.el7
python3-service-identity-18.1.0-1.el7.noarch requires python36-attrs =
17.4.0-4.el7

Affected (co)maintainers
carlwgeorge: python-attrs
churchyard: python-attrs
eclipseo: python-attrs
ignatenkobrain: python-attrs
lbalhar: python-attrs
python-sig: python-attrs
ralph: python-attrs

Depending packages (epel7) (2): python-pystalk python-service-identity


FTBFS (epel7) (1): python-attrs


FTBFS (epel7) (depended on) (1): python-attrs


FTBFS (epel7) (not depended on) (0):

-- 
Sérgio M. B.
___
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: Thoughts: epel-release auto-enable crb repo

[Sérgio Basto]

On Mon, 2022-06-13 at 07:41 -0400, Josh Boyer wrote:
> On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto 
> wrote:
> > 
> > On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
> > > Let me start with examples that I get *regularly*: Pagure fails
> > > to
> > > install from EPEL on RHEL/CentOS/Alma/etc. because python3-
> > > markdown
> > > is
> > > not available. KDE Plasma fails to install because of a mass of
> > > missing dependencies.
> > 
> > if epel use  crb to build some package, crb should be enabled when
> > we
> > install epel repo, yes , that is my opinion
> 
> If the dependency is only needed at build time, which is what CRB
> content is intended for, then there is no reason to default to having
> CRB enabled because nothing will be installed from CRB anyway.  The
> issue that people are running into is that EPEL packages have
> developed *runtime* dependencies on CRB content.  For a subset of
> users, that is probably fine.  However, if a package needs something
> at runtime it would be better to first inquire about putting that
> dependency in BaseOS or AppStream rather than just blindly using it
> from CRB.


at least [1] we should be add to BaseOS or AppStream 

[1] 
aspell.x86_64 12:0.60.8-8.el9 @crb
poppler-qt5.x86_64 21.01.0-12.el9 @crb
python3-markdown 

I got the results running `dnf --disablerepo=crb list extras`

> josh
> ___
> 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

-- 
Sérgio M. B.
___
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: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)

[Sérgio Basto]

On Mon, 2022-06-13 at 09:34 +0200, Petr Pisar wrote:
> V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a):
> > On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2095649
> > 
> > Hi, 
> > for some reason the build on epel 8 to update ImageMagick-6.9.12
> > from
> > 48 to 50 (
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) 
> > used  perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I
> > guess
> > modules repo
> 
> Interesting. I'm courious how it could happen. DNF rejects installing
> modular
> packages if they are not listed in a defintion of a module stream. So
> either
> somebody enabled perl:5.32 stream explicitly (improbable), or mock
> repositories in Koji are configured with module_hotfixes=true which
> is alarming.

"Koji are configured with module_hotfixes=true" , but usually  don't
push  perl:5.32 stream , why this time it was pushed ? how I can avoid
it ? 

Thank you 

> Koji configuration confirm the other theory:
> 
> $ koji mock-config -a x86_64 --target epel8-candidate | grep
> module_hotfixes
> config_opts['yum.conf'] =
> '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.
> log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumey
> es=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
> repos\n\n[build]\nname=build\nbaseurl=
> https://kojipkgs.fedoraproject.org/repos/epel8-
> build/4655904/x86_64\nmodule_hotfixes=1\n'
> 
> I recommend Koji maintainers to add and use RHEL repositories next to
> epel8-build with EPEL8 packages:
> 
> [build]
> name=build
> baseurl=
> https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64
> 
> [rhel-AppStream]
> name=rhel-AppStream
> baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM
> 
> -- Petr
> 
> ___
> 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

-- 
Sérgio M. B.
___
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: Thoughts: epel-release auto-enable crb repo

[Sérgio Basto]

On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
> Let me start with examples that I get *regularly*: Pagure fails to
> install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown
> is
> not available. KDE Plasma fails to install because of a mass of
> missing dependencies.

if epel use  crb to build some package, crb should be enabled when we
install epel repo, yes , that is my opinion 
-- 
Sérgio M. B.
___
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] [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)

[Sérgio Basto]

On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=2095649

Hi, 
for some reason the build on epel 8 to update ImageMagick-6.9.12 from
48 to 50 (
https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) 
used  perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I guess
modules repo ... this is an error , which I want fix quick as possible.

I built it again and now use the correct perl 4:5.26.3-421.el8, so I
though ask you please give positive karma urgently on
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0c9f27acb3 

Thank you 
-- 
Sérgio M. B.
___
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: Fwd: ImageMagick in EPEL 8

[Sérgio Basto]

ImageMagick now provides libMagickWand-6.Q16.so.7()(64bit)  and not provides 
anymore  libMagickWand-6.Q16.so.6()(64bit) , that is called soname bump So I'm 
sorry , ImageMagick-6.9.10 -97 was release more than 2 years ago
(2020-02-29 09:40) while ImageMagick-6.9.12 still supported by
ImageMagick and have all security the fixes . 
you just need rebuild yours packages against the new ImageMagick or
just not update ImageMagick with , dnf update --exclude="ImageMagick*"
or add the line exclude="ImageMagick*" in the /etc/yum.repos.d

Sometimes we need that things change but is nothing todo with libc and
is not us which decide when dynamic libraries change his API . 




On Fri, 2022-05-27 at 12:17 -0700, Patrick J. LoPresti wrote:
> Can you explain the rationale for bumping the soname? That is
> supposed to represent a non-backwards-compatile change; i.e. rare to
> never (cf. libc.so.6 soon to enter its third decade). This just
> sounds like a security fix (?)
> 
> It kind of sucks when RHEL7 and RHEL8 cannot run the same binaries.
> 
>  - Pat
> 
> 
> On Fri, May 27, 2022 at 12:07 PM Sérgio Basto 
> wrote:
> > yes, now its provide libMagickWand-6.Q16.so.7()(64bit) [2] , you
> > need
> > rebuild your packages 
> > 
> > ImageMagick soname bump was approved [0] in EPEL Steering Committee
> > meeting. and I'm continuing with the process for incompatible
> > upgrades
> > from step 4 forward [1]. and 81 security bugs will be fixed
> > 
> > [0]
> > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > [1]
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > 
> > [2]
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158
> > 
> > 
> > On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
> > > Shared message to address an issue below.
> > > 
> > >  
> > >   Forwarded Message     Subject:  ImageMagick in
> > EPEL
> > > 8  Date:  Wed, 25 May 2022 15:20:54 -0700  From:  Patrick J.
> > LoPresti
> > >   To:  l...@fedoraproject.org 
> > >  
> > > Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major
> > > version number 7, as in "libMagickWand-6.Q16.so.7".
> > > 
> > > I have a number of binaries compiled for RHEL7 against
> > ImageMagick,
> > > where the major number was 6, as in "libMagickWand-6.Q16.so.6".
> > These
> > > binaries do not run on RHEL8 because of this major version
> > mismatch.
> > > 
> > > Has the .so really changed in a backwards-incompatible way? (When
> > I
> > > symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled
> > > applications appear to run.) If not, can I request that the
> > version
> > > in EPEL change to use .so.6?
> > > 
> > > Thanks!
> > > 
> > >  - Pat
> > > 
> > >  
> > > ___
> > > devel mailing list -- de...@lists.fedoraproject.org
> > > To unsubscribe send an email to
> > 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/de...@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> > 


-- 
Sérgio M. B.
___
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: Fwd: ImageMagick in EPEL 8

[Sérgio Basto]

yes, now its provide libMagickWand-6.Q16.so.7()(64bit) [2] , you need
rebuild your packages 

ImageMagick soname bump was approved [0] in EPEL Steering Committee
meeting. and I'm continuing with the process for incompatible upgrades
from step 4 forward [1]. and 81 security bugs will be fixed

[0]
https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
[1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades

[2]
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158


On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
> Shared message to address an issue below.
> 
>  
>   Forwarded Message Subject:  ImageMagick in EPEL
> 8  Date:  Wed, 25 May 2022 15:20:54 -0700  From:  Patrick J. LoPresti
>   To:  l...@fedoraproject.org 
>  
> Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major
> version number 7, as in "libMagickWand-6.Q16.so.7".
> 
> I have a number of binaries compiled for RHEL7 against ImageMagick,
> where the major number was 6, as in "libMagickWand-6.Q16.so.6". These
> binaries do not run on RHEL8 because of this major version mismatch.
> 
> Has the .so really changed in a backwards-incompatible way? (When I
> symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled
> applications appear to run.) If not, can I request that the version
> in EPEL change to use .so.6?
> 
> Thanks!
> 
>  - Pat
> 
>  
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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: ImageMagick to 6.9.12.48

[Sérgio Basto]

rebuilt it asap 

ImageMagick soname bump was approved [0] in EPEL Steering Committee
meeting. and I'm continuing with the process for incompatible upgrades
from step 4 forward [1]. and 81 security bugs will be fixed

[0]
https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
[1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


On Fri, 2022-05-20 at 14:30 +, Marcel Evenson wrote:
> Just a note that this ImageMagick update broke yum on all a tonne of
> servers that have EPEL enabled :
> 
> Problem:
> https://talk.plesk.com/threads/problem-package-plesk-php74-imagick-3-7-0-0redhat-8-220415-1034-x86_64-requires-libmagickcore-6-q16-so-6-64bit-but-none-of-the-providers-can-be-i.364972/
> 
> [root@busy-gates ~]# yum update
> Last metadata expiration check: 0:07:35 ago on Fri 20 May 2022
> 06:49:26 AM MDT.
> Error: 
>  Problem: package plesk-php73-imagick-3.6.0-
> 1centos.8.28.1928.x86_64 requires libMagickCore-
> 6.Q16.so.6()(64bit), but none of the providers can be installed
>   - package plesk-php73-imagick-3.6.0-1centos.8.28.1928.x86_64
> requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers
> can be installed
>   - cannot install both ImageMagick-libs-6.9.12.48-2.el8.x86_64 and
> ImageMagick-libs-6.9.10.86-1.el8.x86_64
>   - cannot install both ImageMagick-libs-6.9.10.86-1.el8.x86_64 and
> ImageMagick-libs-6.9.12.48-2.el8.x86_64
>   - cannot install the best update candidate for package plesk-php73-
> imagick-3.6.0-1centos.8.28.1928.x86_64
>   - cannot install the best update candidate for package ImageMagick-
> libs-6.9.10.86-1.el8.x86_64
> (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages or '--
> nobest' to use not only best candidate packages)
> 
> Does EPEL normally do major package updates like this mid cycle? I
> thought that EPEL packages only got major upgrades when switching
> from doing a dist OS upgrade?
> 
> -- 
> Best regards,
> Marcel Evenson
> Danami - Software for the Cloud
> www.danami.com
> 

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Sun, 2022-05-08 at 16:16 +0100, Sérgio Basto wrote:
> On Fri, 2022-04-29 at 14:52 +0100, Sérgio Basto wrote:
> > A qui, 28-04-2022 às 15:18 +0100, Sérgio Basto escreveu:
> > > On Thu, 2022-04-28 at 07:09 -0700, Troy Dawson wrote:
> > > > 
> > > > 
> > > > On Thu, Apr 28, 2022 at 2:57 AM Sérgio Basto
> > > >  wrote:
> > > > > A qui, 28-04-2022 às 10:48 +0100, Sérgio Basto escreveu:
> > > > > > A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto
> > > > > > >  wrote:
> > > > > > > > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > > > > > > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > > > > > > > This was approved [0] in today's EPEL Steering
> > > > > > > > Committee meeting.
> > > > > > > > > > > Please continue with the process for incompatible
> > > > > > > > upgrades from
> > > > > > > > > > > step 4
> > > > > > > > > > > forward [1].
> > > > > > > > > > > 
> > > > > > > > > > > [0]
> > > > > > > > > > >
> > > > > > > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Carl George
> > > > > > > > > > 
> > > > > > > > > > Based on repoquery it looks like only three
> > > > > > > > packages need to be
> > > > > > > > > > rebuilt for this.
> > > > > > > > > > 
> > > > > > > > > > converseen
> > > > > > > > > > digikam
> > > > > > > > > > dvdauthor
> > > > > > > > > 
> > > > > > > > > Correct the other packages "just" use Imageagick
> > > > > > > > tools , I need to
> > > > > > > > > check
> > > > > > > > > also packages that use perl(ImageMagick)
> > > > > > > > > 
> > > > > > > > > I'm going start now ! 
> > > > > > > > 
> > > > > > > > digikam is updated in epel8-next , I'm doing a side-tag
> > > > > > > > in epel8 .
> > > > > > > > 
> > > > > > > > This case brings one question , the packages of epel8-
> > > > > > > > next will be
> > > > > > > > branch to epel8 ? 
> > > > > > > > The way I see it is rhel 8.5 + epel 8 and centos stream
> > > > > > > > 8 + epel 8 next
> > > > > > > > , rhel 8.6 is branched from centos stream 8 and epel 8
> > > > > > > > should also be
> > > > > > > > branched from epel 8 next . This implies that packages
> > > > > > > > on epel 8 must
> > > > > > > > have lower versions than epel 8 next  .
> > > > > > > > 
> > > > > > > > 
> > > > > > > > what I should do with digikam ? 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The version in digikam epel8 and epel8-next are
> > > > > > > different.  The reason is because of a package update
> > > > > > > (opencr) that is currently in CentOS Stream 8 that won't
> > > > > > > make it into RHEL 8 until RHEL 8.6.
> > > > > > > For the epel8 version, just do a bump and build like you
> > > > > > > have the other packages on your list, keeping it's
> > > > > > > version the same.
> > > > > > > I can do the epel8-next rebuild after you are done.  And
> > > >

[EPEL-devel] Re: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Fri, 2022-04-29 at 14:52 +0100, Sérgio Basto wrote:
> A qui, 28-04-2022 às 15:18 +0100, Sérgio Basto escreveu:
> > On Thu, 2022-04-28 at 07:09 -0700, Troy Dawson wrote:
> > > 
> > > 
> > > On Thu, Apr 28, 2022 at 2:57 AM Sérgio Basto 
> > > wrote:
> > > > A qui, 28-04-2022 às 10:48 +0100, Sérgio Basto escreveu:
> > > > > A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> > > > > > 
> > > > > > 
> > > > > > On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto
> > > > > >  wrote:
> > > > > > > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > > > > > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > > > > > > This was approved [0] in today's EPEL Steering
> > > > > > > Committee meeting.
> > > > > > > > > > Please continue with the process for incompatible
> > > > > > > upgrades from
> > > > > > > > > > step 4
> > > > > > > > > > forward [1].
> > > > > > > > > > 
> > > > > > > > > > [0]
> > > > > > > > > >
> > > > > > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > > > > > > [1]
> > > > > > > > > >
> > > > > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Carl George
> > > > > > > > > 
> > > > > > > > > Based on repoquery it looks like only three packages
> > > > > > > need to be
> > > > > > > > > rebuilt for this.
> > > > > > > > > 
> > > > > > > > > converseen
> > > > > > > > > digikam
> > > > > > > > > dvdauthor
> > > > > > > > 
> > > > > > > > Correct the other packages "just" use Imageagick tools
> > > > > > > , I need to
> > > > > > > > check
> > > > > > > > also packages that use perl(ImageMagick)
> > > > > > > > 
> > > > > > > > I'm going start now ! 
> > > > > > > 
> > > > > > > digikam is updated in epel8-next , I'm doing a side-tag
> > > > > > > in epel8 .
> > > > > > > 
> > > > > > > This case brings one question , the packages of epel8-
> > > > > > > next will be
> > > > > > > branch to epel8 ? 
> > > > > > > The way I see it is rhel 8.5 + epel 8 and centos stream 8
> > > > > > > + epel 8 next
> > > > > > > , rhel 8.6 is branched from centos stream 8 and epel 8
> > > > > > > should also be
> > > > > > > branched from epel 8 next . This implies that packages on
> > > > > > > epel 8 must
> > > > > > > have lower versions than epel 8 next  .
> > > > > > > 
> > > > > > > 
> > > > > > > what I should do with digikam ? 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > The version in digikam epel8 and epel8-next are different. 
> > > > > > The reason is because of a package update (opencr) that is
> > > > > > currently in CentOS Stream 8 that won't make it into RHEL 8
> > > > > > until RHEL 8.6.
> > > > > > For the epel8 version, just do a bump and build like you
> > > > > > have the other packages on your list, keeping it's version
> > > > > > the same.
> > > > > > I can do the epel8-next rebuild after you are done.  And
> > > > > > when RHEL 8.6 is released, I'll be bringing the higher
> > > > > > version that is in epel8-next, over to epel8.
> > > > > 
> > > > > Notification time stamped 2022-04-28 00:48:53 UTC
> > > > > 
> > > > > sergiomb's digikam-6.4.0-5.el8 failed to build
> > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=195710

[EPEL-devel] Re: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Sérgio Basto]

A qua, 04-05-2022 às 15:38 -0400, Stephen John Smoogen escreveu:
> 
> 
> On Wed, 4 May 2022 at 15:31, Sérgio Basto  wrote:
> > On Wed, 2022-05-04 at 20:25 +0100, Sérgio Basto wrote:
> > > dnf --enablerepo=epel-next-testing --whatprovides "libpoppler-
> > > qt5.so*"
> > > nothing  ?!?
> > 
> > 
> > I missed repoquery word .
> > 
> > dnf --enablerepo=epel-next-testing repoquery --whatprovides
> > "libpoppler-qt5.so*"
> > nothing  ?!?
> > 
> > 
> > btw in Fedora 35 
> > 
> > dnf repoquery --whatprovides "libpoppler-qt5.so*"
> > poppler-qt5-0:21.08.0-1.fc35.i686
> > poppler-qt5-0:21.08.0-1.fc35.x86_64 
> > 
> > 
> 
> 
> Looked to see what package owns that in F34.
> $ rpm --nosignature --qf='%{SOURCERPM}\n' -qp poppler-qt5-21.01.0-
> 6.fc34.x86_64.rpm 
> poppler-21.01.0-6.fc34.src.rpm
> 
> I found that package in CRB poppler-qt5-21.01.0-12.el9.x86_64.rpm
> /usr/lib64/libpoppler-qt5.so.1
> /usr/lib64/libpoppler-qt5.so.1.27.0


Thank you , after enable CRB repo it starts to update.

I haven't find more issues .


Best regards,
-- 
Sérgio M. B.
___
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: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Sérgio Basto]

On Wed, 2022-05-04 at 20:25 +0100, Sérgio Basto wrote:
> dnf --enablerepo=epel-next-testing --whatprovides "libpoppler-
> qt5.so*"
> nothing  ?!?

I missed repoquery word .

dnf --enablerepo=epel-next-testing repoquery --whatprovides
"libpoppler-qt5.so*"
nothing  ?!?


btw in Fedora 35 

dnf repoquery --whatprovides "libpoppler-qt5.so*"
poppler-qt5-0:21.08.0-1.fc35.i686
poppler-qt5-0:21.08.0-1.fc35.x86_64 
-- 
Sérgio M. B.
___
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: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Sérgio Basto]

On Wed, 2022-05-04 at 08:01 -0700, Troy Dawson wrote:
> 
> On Wed, Apr 27, 2022 at 9:31 AM Troy Dawson 
> wrote:
> > During the past week qt5 was updated on CentOS Stream 8 and 9 to
> > version 5.15.3.  This caused updates to break for KDE users running
> > CentOS Stream 8 and 9.  The epel 8 and 9 packages affected are
> > being rebuilt at this time.  We expect everything rebuilt and
> > through testing next week.
> > 
> > Question: Does this affect my RHEL/Alma/Rocky 8/9 install?
> > Answer: Not at this time.  This qt5 update isn't going to be
> > released until RHEL 8.7 and 9.1.
> > 
> > Question: What is being rebuilt?
> > Answer:
> > epel8 - We believe about 30 packages.  That includes all of the qt5
> > packages in epel8, as well as several plasma and kf5 packages that
> > have tight version dependencies on qt5.
> > 
> > epel9 - The entire KDE Plasma Desktop stack. (about 380 packages). 
> > There recently has been an update to wayland-protocols in Stream
> > 9.  It didn't break anything, but it had been an update that was
> > needed to update to the latest kf5 and plasma releases.  Since we
> > knew that the qt5 update was coming, we held off rebuilding
> > everything until qt5 came out.  Now that it is out, we are updating
> > everything.

dnf --enablerepo=epel-next-testing install baloo-widgets dolphin
gwenview gwenview-libs k3b kde-print-manager kf5-baloo kf5-baloo-file
kf5-baloo-libs kf5-kfilemetadata kfind okular okular-part pipewire-
pulseaudio plasma-browser-integration plasma-desktop plasma-workspace
plasma-workspace-wayland plasma-workspace-x11 --allowerasing  

nothing provides libpoppler-qt5.so.1()(64bit) needed by kf5-
kfilemetadata-5.93.0-1.el9.next.x86_64

dnf --enablerepo=epel-next-testing --whatprovides "libpoppler-qt5.so*"
nothing  ?!?

> > Troy Dawson
> > 
> 
> 
> Latest update on this.
> 
> EPEL9 - Everything is in epel-next-testing.  To do your update do
>   dnf --enablerepo=epel-next-testing update
> 
> Reminder, this is a complete KDE Plasma Desktop update to plasma
> 5.24.4, kf5 5.93, qt5 5.15.3
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-a6c0f04770
> 
> EPEL8 - Some packages are rebuilt and available, but qt5-qtwebengine,
> and everything that depends on it, has not been rebuilt.
> This is due to a complex module bug in CentOS Stream 8 affecting the
> epel8-next buildroot.  It may, or may not, get fixed this week.
> 
> Thank you all for your patience.
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

A qui, 28-04-2022 às 15:18 +0100, Sérgio Basto escreveu:
> On Thu, 2022-04-28 at 07:09 -0700, Troy Dawson wrote:
> > 
> > 
> > On Thu, Apr 28, 2022 at 2:57 AM Sérgio Basto 
> > wrote:
> > > A qui, 28-04-2022 às 10:48 +0100, Sérgio Basto escreveu:
> > > > A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> > > > > 
> > > > > 
> > > > > On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto
> > > > >  wrote:
> > > > > > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > > > > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > > > > > This was approved [0] in today's EPEL Steering
> > > > > > Committee meeting.
> > > > > > > > > Please continue with the process for incompatible
> > > > > > upgrades from
> > > > > > > > > step 4
> > > > > > > > > forward [1].
> > > > > > > > > 
> > > > > > > > > [0]
> > > > > > > > >
> > > > > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > > > > > [1]
> > > > > > > > >
> > > > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Carl George
> > > > > > > > 
> > > > > > > > Based on repoquery it looks like only three packages
> > > > > > need to be
> > > > > > > > rebuilt for this.
> > > > > > > > 
> > > > > > > > converseen
> > > > > > > > digikam
> > > > > > > > dvdauthor
> > > > > > > 
> > > > > > > Correct the other packages "just" use Imageagick tools ,
> > > > > > I need to
> > > > > > > check
> > > > > > > also packages that use perl(ImageMagick)
> > > > > > > 
> > > > > > > I'm going start now ! 
> > > > > > 
> > > > > > digikam is updated in epel8-next , I'm doing a side-tag in
> > > > > > epel8 .
> > > > > > 
> > > > > > This case brings one question , the packages of epel8-next
> > > > > > will be
> > > > > > branch to epel8 ? 
> > > > > > The way I see it is rhel 8.5 + epel 8 and centos stream 8 +
> > > > > > epel 8 next
> > > > > > , rhel 8.6 is branched from centos stream 8 and epel 8
> > > > > > should also be
> > > > > > branched from epel 8 next . This implies that packages on
> > > > > > epel 8 must
> > > > > > have lower versions than epel 8 next  .
> > > > > > 
> > > > > > 
> > > > > > what I should do with digikam ? 
> > > > > > 
> > > > > 
> > > > > 
> > > > > The version in digikam epel8 and epel8-next are different. 
> > > > > The reason is because of a package update (opencr) that is
> > > > > currently in CentOS Stream 8 that won't make it into RHEL 8
> > > > > until RHEL 8.6.
> > > > > For the epel8 version, just do a bump and build like you have
> > > > > the other packages on your list, keeping it's version the
> > > > > same.
> > > > > I can do the epel8-next rebuild after you are done.  And when
> > > > > RHEL 8.6 is released, I'll be bringing the higher version
> > > > > that is in epel8-next, over to epel8.
> > > > 
> > > > Notification time stamped 2022-04-28 00:48:53 UTC
> > > > 
> > > > sergiomb's digikam-6.4.0-5.el8 failed to build
> > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=1957109
> > > > 
> > > > :( 
> > > 
> > > 
> > > BTW if someone want to fix it, please built it in the side-tag
> > > epel8-build-side-52356
> > > 
> > > fedpkg build --target=epel8-build-side-52356
> > > 
> > 
> > 
> > Ugg ... why must digikam be this way.  :(
> > *Sigh* I know why.  It's the nature of the "let's pull it all
> > together" program.
> > Looking into this.
> 
> I will try the fix suggest  here 
> https://forum.qt.io/topic/122702/error-aggregate-qpainterpath-path-has-incomplete-type-and-cannot-be-defined/3
> ( include  may be missing. Just add it. ) 

The fix worked .

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158 has
been submitted .

The side-tag  changed because the previous has disappeared , I think it
was deleted because had more than 30 days ... 

New side-tag is:  epel8-build-side-53268 

Thank you and best regards
-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Thu, 2022-04-28 at 07:09 -0700, Troy Dawson wrote:
> 
> 
> On Thu, Apr 28, 2022 at 2:57 AM Sérgio Basto 
> wrote:
> > A qui, 28-04-2022 às 10:48 +0100, Sérgio Basto escreveu:
> > > A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> > > > 
> > > > 
> > > > On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto
> > > >  wrote:
> > > > > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > > > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > > > > This was approved [0] in today's EPEL Steering
> > > > > Committee meeting.
> > > > > > > > Please continue with the process for incompatible
> > > > > upgrades from
> > > > > > > > step 4
> > > > > > > > forward [1].
> > > > > > > > 
> > > > > > > > [0]
> > > > > > > >
> > > > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > > > > [1]
> > > > > > > >
> > > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Carl George
> > > > > > > 
> > > > > > > Based on repoquery it looks like only three packages need
> > > > > to be
> > > > > > > rebuilt for this.
> > > > > > > 
> > > > > > > converseen
> > > > > > > digikam
> > > > > > > dvdauthor
> > > > > > 
> > > > > > Correct the other packages "just" use Imageagick tools , I
> > > > > need to
> > > > > > check
> > > > > > also packages that use perl(ImageMagick)
> > > > > > 
> > > > > > I'm going start now ! 
> > > > > 
> > > > > digikam is updated in epel8-next , I'm doing a side-tag in
> > > > > epel8 .
> > > > > 
> > > > > This case brings one question , the packages of epel8-next
> > > > > will be
> > > > > branch to epel8 ? 
> > > > > The way I see it is rhel 8.5 + epel 8 and centos stream 8 +
> > > > > epel 8 next
> > > > > , rhel 8.6 is branched from centos stream 8 and epel 8 should
> > > > > also be
> > > > > branched from epel 8 next . This implies that packages on
> > > > > epel 8 must
> > > > > have lower versions than epel 8 next  .
> > > > > 
> > > > > 
> > > > > what I should do with digikam ? 
> > > > > 
> > > > 
> > > > 
> > > > The version in digikam epel8 and epel8-next are different.  The
> > > > reason is because of a package update (opencr) that is
> > > > currently in CentOS Stream 8 that won't make it into RHEL 8
> > > > until RHEL 8.6.
> > > > For the epel8 version, just do a bump and build like you have
> > > > the other packages on your list, keeping it's version the same.
> > > > I can do the epel8-next rebuild after you are done.  And when
> > > > RHEL 8.6 is released, I'll be bringing the higher version that
> > > > is in epel8-next, over to epel8.
> > > 
> > > Notification time stamped 2022-04-28 00:48:53 UTC
> > > 
> > > sergiomb's digikam-6.4.0-5.el8 failed to build
> > > http://koji.fedoraproject.org/koji/buildinfo?buildID=1957109
> > > 
> > > :( 
> > 
> > 
> > BTW if someone want to fix it, please built it in the side-tag
> > epel8-build-side-52356
> > 
> > fedpkg build --target=epel8-build-side-52356
> > 
> 
> 
> Ugg ... why must digikam be this way.  :(
> *Sigh* I know why.  It's the nature of the "let's pull it all
> together" program.
> Looking into this.

I will try the fix suggest  here 
https://forum.qt.io/topic/122702/error-aggregate-qpainterpath-path-has-incomplete-type-and-cannot-be-defined/3
( include  may be missing. Just add it. ) 


> ___
> 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

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

A qui, 28-04-2022 às 10:48 +0100, Sérgio Basto escreveu:
> A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> > 
> > 
> > On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto 
> > wrote:
> > > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > > This was approved [0] in today's EPEL Steering Committee
> > > meeting.
> > > > > > Please continue with the process for incompatible upgrades
> > > from
> > > > > > step 4
> > > > > > forward [1].
> > > > > > 
> > > > > > [0]
> > > > > >
> > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > > [1]
> > > > > >
> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > > 
> > > > > > --
> > > > > > Carl George
> > > > > 
> > > > > Based on repoquery it looks like only three packages need to
> > > be
> > > > > rebuilt for this.
> > > > > 
> > > > > converseen
> > > > > digikam
> > > > > dvdauthor
> > > > 
> > > > Correct the other packages "just" use Imageagick tools , I need
> > > to
> > > > check
> > > > also packages that use perl(ImageMagick)
> > > > 
> > > > I'm going start now ! 
> > > 
> > > digikam is updated in epel8-next , I'm doing a side-tag in epel8
> > > .
> > > 
> > > This case brings one question , the packages of epel8-next will
> > > be
> > > branch to epel8 ? 
> > > The way I see it is rhel 8.5 + epel 8 and centos stream 8 + epel
> > > 8 next
> > > , rhel 8.6 is branched from centos stream 8 and epel 8 should
> > > also be
> > > branched from epel 8 next . This implies that packages on epel 8
> > > must
> > > have lower versions than epel 8 next  .
> > > 
> > > 
> > > what I should do with digikam ? 
> > > 
> > 
> > 
> > The version in digikam epel8 and epel8-next are different.  The
> > reason is because of a package update (opencr) that is currently in
> > CentOS Stream 8 that won't make it into RHEL 8 until RHEL 8.6.
> > For the epel8 version, just do a bump and build like you have the
> > other packages on your list, keeping it's version the same.
> > I can do the epel8-next rebuild after you are done.  And when RHEL
> > 8.6 is released, I'll be bringing the higher version that is in
> > epel8-next, over to epel8.
> 
> Notification time stamped 2022-04-28 00:48:53 UTC
> 
> sergiomb's digikam-6.4.0-5.el8 failed to build
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=1957109
> 
> :( 

BTW if someone want to fix it, please built it in the side-tag epel8-
build-side-52356

fedpkg build --target=epel8-build-side-52356


> > 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 on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> ___
> 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.fedor
> aproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

A qua, 27-04-2022 às 16:58 -0700, Troy Dawson escreveu:
> 
> 
> On Wed, Apr 27, 2022 at 4:38 PM Sérgio Basto 
> wrote:
> > On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> > > On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > > > This was approved [0] in today's EPEL Steering Committee
> > meeting.
> > > > > Please continue with the process for incompatible upgrades
> > from
> > > > > step 4
> > > > > forward [1].
> > > > > 
> > > > > [0]
> > > > >
> > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > > > [1]
> > > > >
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > > > 
> > > > > --
> > > > > Carl George
> > > > 
> > > > Based on repoquery it looks like only three packages need to be
> > > > rebuilt for this.
> > > > 
> > > > converseen
> > > > digikam
> > > > dvdauthor
> > > 
> > > Correct the other packages "just" use Imageagick tools , I need
> > to
> > > check
> > > also packages that use perl(ImageMagick)
> > > 
> > > I'm going start now ! 
> > 
> > digikam is updated in epel8-next , I'm doing a side-tag in epel8 .
> > 
> > This case brings one question , the packages of epel8-next will be
> > branch to epel8 ? 
> > The way I see it is rhel 8.5 + epel 8 and centos stream 8 + epel 8
> > next
> > , rhel 8.6 is branched from centos stream 8 and epel 8 should also
> > be
> > branched from epel 8 next . This implies that packages on epel 8
> > must
> > have lower versions than epel 8 next  .
> > 
> > 
> > what I should do with digikam ? 
> > 
> 
> 
> The version in digikam epel8 and epel8-next are different.  The
> reason is because of a package update (opencr) that is currently in
> CentOS Stream 8 that won't make it into RHEL 8 until RHEL 8.6.
> For the epel8 version, just do a bump and build like you have the
> other packages on your list, keeping it's version the same.
> I can do the epel8-next rebuild after you are done.  And when RHEL
> 8.6 is released, I'll be bringing the higher version that is in
> epel8-next, over to epel8.

Notification time stamped 2022-04-28 00:48:53 UTC

sergiomb's digikam-6.4.0-5.el8 failed to build
 http://koji.fedoraproject.org/koji/buildinfo?buildID=1957109

:( 

> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Wed, 2022-04-27 at 23:44 +0100, Sérgio Basto wrote:
> On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > > This was approved [0] in today's EPEL Steering Committee meeting.
> > > Please continue with the process for incompatible upgrades from
> > > step 4
> > > forward [1].
> > > 
> > > [0]
> > > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > > [1]
> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > > 
> > > --
> > > Carl George
> > 
> > Based on repoquery it looks like only three packages need to be
> > rebuilt for this.
> > 
> > converseen
> > digikam
> > dvdauthor
> 
> Correct the other packages "just" use Imageagick tools , I need to
> check
> also packages that use perl(ImageMagick)
> 
> I'm going start now ! 

digikam is updated in epel8-next , I'm doing a side-tag in epel8 .

This case brings one question , the packages of epel8-next will be
branch to epel8 ? 
The way I see it is rhel 8.5 + epel 8 and centos stream 8 + epel 8 next
, rhel 8.6 is branched from centos stream 8 and epel 8 should also be
branched from epel 8 next . This implies that packages on epel 8 must
have lower versions than epel 8 next  .


what I should do with digikam ? 





-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Wed, 2022-04-13 at 17:54 -0500, Carl George wrote:
> > This was approved [0] in today's EPEL Steering Committee meeting.
> > Please continue with the process for incompatible upgrades from
> > step 4
> > forward [1].
> > 
> > [0]
> > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > [1]
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > 
> > --
> > Carl George
> 
> Based on repoquery it looks like only three packages need to be
> rebuilt for this.
> 
> converseen
> digikam
> dvdauthor

Correct the other package "just" use Imageagick tools , I need to check
also packages that use perl(ImageMagick)

I'm going start now ! 

Thank you 

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Thu, 2022-04-21 at 12:35 -0700, Troy Dawson wrote:
> Hi  Sérgio,
> We aren't sure if you saw this or not, but you have permission to
> move ahead with the re-builds.
> Let us know if you need help with anything.

Hi, thank you , I'm aware, I will try do it this weekend . 

I have a issue in email client ( evolution ) which me prevents me to
select text, in my remote desktop,  which limits me to write emails
properly ...

Best regards, 

> On Wed, Apr 13, 2022 at 3:06 PM Carl George  wrote:
> > On Fri, Apr 8, 2022 at 5:17 PM Troy Dawson 
> > wrote:
> > >
> > >
> > >
> > > On Fri, Apr 8, 2022 at 3:00 PM Sérgio Basto 
> > wrote:
> > >>
> > >> On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote:
> > >>
> > >>
> > >>
> > >> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto 
> > wrote:
> > >>
> > >> On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote:
> > >> > > This update changes a library soname, which makes it an
> > >> > > incompatible
> > >> > > upgrade.  It must follow the EPEL incompatible upgrades
> > policy [0].
> > >> > > This email can count as step 1 once you reply with the
> > specific
> > >> > > CVEs
> > >> > > this will address.  Then it must be open for discussion on
> > list for
> > >> > > one week (step 2) before being added as an agenda item at
> > next
> > >> > > week's
> > >> > > EPEL Steering Committee meeting [1] (step 3).
> > >> > >
> > >> > > [0]
> > >> > >
> >
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > >> > > [1] https://calendar.fedoraproject.org/epel/#m9854
> > >> >
> > >> > OK , thank you
> > >>
> > >>
> > >> Hi,
> > >> have we any new ?
> > >>
> > >> I'd like move on before rhel 8.6 be available .
> > >>
> > >>
> > >> Thank you
> > >>
> > >>
> > >> Hi Sérgio,
> > >> Could you list the CVE's that this update addresses.
> > >> If that list is fairly long, at least the important ones
> > >>
> > >>
> > >>
> > >> we got 82 reported on bugzilla
> > >>
> >
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=ImageMagick_id=12543908=Fedora%20EPEL_format=advanced
> > >
> > >
> > >  Youch!
> > > Next time, lead with that. :)
> > > I joke, but that's really what we were waiting for.
> > > It's a Friday afternoon, and I'm pretty certain we won't get
> > enough of the committee reading this to give a full vote until next
> > week.
> > > But, as for me, I give it a +1.
> > > 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 on the list, report it:
> > https://pagure.io/fedora-infrastructure
> > 
> > This was approved [0] in today's EPEL Steering Committee meeting.
> > Please continue with the process for incompatible upgrades from
> > step 4
> > forward [1].
> > 
> > [0]
> >
> https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > [1]
> >
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > 

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote:
> 
> 
> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto 
> wrote:
> > On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote:
> > > > This update changes a library soname, which makes it an
> > > > incompatible
> > > > upgrade.  It must follow the EPEL incompatible upgrades policy
> > [0].
> > > > This email can count as step 1 once you reply with the specific
> > > > CVEs
> > > > this will address.  Then it must be open for discussion on list
> > for
> > > > one week (step 2) before being added as an agenda item at next
> > > > week's
> > > > EPEL Steering Committee meeting [1] (step 3).
> > > > 
> > > > [0]
> > > >
> >
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > > > [1] https://calendar.fedoraproject.org/epel/#m9854
> > > 
> > > OK , thank you 
> > 
> > 
> > Hi, 
> > have we any new ?
> > 
> > I'd like move on before rhel 8.6 be available .
> > 
> > 
> > Thank you  
> > 
> 
> 
> Hi Sérgio,
> Could you list the CVE's that this update addresses.
> If that list is fairly long, at least the important ones


we got 82 reported on bugzilla 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=ImageMagick_id=12543908=Fedora%20EPEL_format=advanced







> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.


Bug List.ods
Description: application/vnd.oasis.opendocument.spreadsheet
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote:
> > This update changes a library soname, which makes it an
> > incompatible
> > upgrade.  It must follow the EPEL incompatible upgrades policy [0].
> > This email can count as step 1 once you reply with the specific
> > CVEs
> > this will address.  Then it must be open for discussion on list for
> > one week (step 2) before being added as an agenda item at next
> > week's
> > EPEL Steering Committee meeting [1] (step 3).
> > 
> > [0]
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > [1] https://calendar.fedoraproject.org/epel/#m9854
> 
> OK , thank you 


Hi, 
have we any new ?

I'd like move on before rhel 8.6 be available .


Thank you  



-- 
Sérgio M. B.
___
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: tinyproxy for EPEL 8, please

[Sérgio Basto]

the maintainers seems unresponsive , the package also isn't updated in
Fedora.
I don't know what is the best to do ... 

https://src.fedoraproject.org/rpms/tinyproxy/pull-request/1

On Thu, 2022-03-31 at 19:20 +, Dan White via epel-devel wrote:
> Following
> https://docs.fedoraproject.org/en-US/epel/epel-package-request/#end_users
> 
> Are there are any packagers who would like to package and maintain
> tinyproxy on EPEL-8 ?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1885155
> ___
> 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

-- 
Sérgio M. B.
___
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: [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

On Wed, 2022-03-30 at 21:54 -0500, Carl George wrote:
> On Tue, Mar 29, 2022 at 6:23 PM Sérgio Basto 
> wrote:
> > 
> > Hi,
> > 
> > ImageMagick 6.9.12.x have a bunch security fixes since 6.9.10.x .
> > I'd like update ImageMagick (IM) on epel8 with soname bump .
> > ImageMagick-6.9.10 last version, have almost 2 years and keep it
> > and
> > just pull security patches, it would have a lot more work in my
> > opinion.
> > 
> > so in  epel8-build-side-52356 repo (sidetag) we got now
> > ImageMagick-6.9.12.44-1.el8
> > 
> > I will rebuild these 24 packages [1] calculated
> > with find_unblocked_orphans.py from
> > https://pagure.io/releng/blob/main/f/scripts [2]
> > 
> > 
> > Best regards,
> > 
> > 
> > [1]
> > Depending packages (epel8) (24): conky-manager converseen darktable
> > digikam dvdauthor ettercap gnokii keepass latex2rtf lyx mediainfo
> > openbabel perl-GD-SecurityImage perl-PAR-Packer playonlinux
> > purple-discord putty stb stellarium tango-icon-theme w3m
> > xemacs-packages-extra xfig xforms
> > 
> > [2]
> > ./find_unblocked_orphans.py --release epel8 --skip-orphans --
> > max_deps 0
> > ImageMagick
> > 
> > conky-manager (maintained by: orphan)
> > conky-manager-2.3.4-11.el8.x86_64 requires ImageMagick = 6.9.10.86-
> > 1.el8
> > 
> > converseen (maintained by: marionline)
> > converseen-0.9.8.1-1.el8.src requires ImageMagick-c++-devel =
> > 6.9.10.86-1.el8, ImageMagick-devel = 6.9.10.86-1.el8
> > converseen-0.9.8.1-1.el8.x86_64 requires libMagick++-
> > 6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)
> > 
> > darktable (maintained by: asn, germano, kalev, madko)
> > darktable-tools-noise-3.8.0-5.el8.x86_64 requires ImageMagick =
> > 6.9.10.86-1.el8
> > 
> > digikam (maintained by: dvratil, kde-sig, kwizart, nucleo, rdieter,
> > than, tuxbrewr, vjancik)
> > digikam-6.4.0-4.el8.src requires ImageMagick-c++-devel = 6.9.10.86-
> > 1.el8, ImageMagick-devel = 6.9.10.86-1.el8
> > digikam-6.4.0-4.el8.x86_64 requires libMagick++-
> > 6.Q16.so.8()(64bit),
> > libMagickCore-6.Q16.so.6()(64bit)
> > digikam-libs-6.4.0-4.el8.x86_64 requires libMagick++-
> > 6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)
> > 
> > dvdauthor (maintained by: hobbes1069, sergiomb)
> > dvdauthor-0.7.2-14.el8.src requires ImageMagick-devel = 6.9.10.86-
> > 1.el8
> > dvdauthor-0.7.2-14.el8.x86_64 requires libMagickCore-
> > 6.Q16.so.6()(64bit)
> > 
> > ettercap (maintained by: limb)
> > ettercap-0.8.3.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > gnokii (maintained by: limb, robert, snirkel)
> > gnokii-0.6.31-29.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > keepass (maintained by: mavit, tpokorra)
> > keepass-2.45-1.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > latex2rtf (maintained by: cicku, yselkowitz)
> > latex2rtf-2.3.18-4.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > latex2rtf-2.3.18-4.el8.x86_64 requires ImageMagick = 6.9.10.86-
> > 1.el8
> > 
> > lyx (maintained by: jamatos, rdieter)
> > lyx-2.3.6-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8
> > 
> > mediainfo (maintained by: ivanromanov, vascom)
> > mediainfo-21.09-1.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > openbabel (maintained by: alexpl, jussilehtola, rathann, sagitter,
> > scitech_sig)
> > openbabel-3.1.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > perl-GD-SecurityImage (maintained by: eseyman)
> > perl-GD-SecurityImage-1.75-4.el8.noarch requires
> > perl(Image::Magick)
> > perl-GD-SecurityImage-1.75-4.el8.src requires perl(Image::Magick)
> > 
> > perl-PAR-Packer (maintained by: jplesnik, ppisar)
> > perl-PAR-Packer-1.052-2.el8.src requires ImageMagick = 6.9.10.86-
> > 1.el8
> > 
> > playonlinux (maintained by: robert)
> > playonlinux-4.4-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8
> > 
> > purple-discord (maintained by: xvitaly)
> > purple-discord-0-33.20210928gitb7ac723.el8.src requires ImageMagick
> > =
> > 6.9.10.86-1.el8
> > 
> > putty (maintained by: jskarvad, olysonek, zaniyah)
> > putty-0.76-1.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > stb (maintained by: churchyard, music)
> > stb-0-0.7.20211022gitaf1a5bc.el8.src requires /usr/bin/convert
> > 
> > stellarium (maintained by: limb, s4504kr)
> > stellarium-0.20.1-1.el8.src requires ImageMagick = 6.9.10.86-1.el8
> > 
> > t

[EPEL-devel] [HEADS UP] ImageMagick side-tag for epel8

[Sérgio Basto]

Hi, 

ImageMagick 6.9.12.x have a bunch security fixes since 6.9.10.x .
I'd like update ImageMagick (IM) on epel8 with soname bump .
ImageMagick-6.9.10 last version, have almost 2 years and keep it and
just pull security patches, it would have a lot more work in my
opinion.

so in  epel8-build-side-52356 repo (sidetag) we got now 
ImageMagick-6.9.12.44-1.el8 

I will rebuild these 24 packages [1] calculated
with find_unblocked_orphans.py from
https://pagure.io/releng/blob/main/f/scripts [2] 


Best regards, 


[1] 
Depending packages (epel8) (24): conky-manager converseen darktable
digikam dvdauthor ettercap gnokii keepass latex2rtf lyx mediainfo
openbabel perl-GD-SecurityImage perl-PAR-Packer playonlinux
purple-discord putty stb stellarium tango-icon-theme w3m
xemacs-packages-extra xfig xforms 

[2]
./find_unblocked_orphans.py --release epel8 --skip-orphans --max_deps 0
ImageMagick

conky-manager (maintained by: orphan)
conky-manager-2.3.4-11.el8.x86_64 requires ImageMagick = 6.9.10.86-
1.el8

converseen (maintained by: marionline)
converseen-0.9.8.1-1.el8.src requires ImageMagick-c++-devel =
6.9.10.86-1.el8, ImageMagick-devel = 6.9.10.86-1.el8
converseen-0.9.8.1-1.el8.x86_64 requires libMagick++-
6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)

darktable (maintained by: asn, germano, kalev, madko)
darktable-tools-noise-3.8.0-5.el8.x86_64 requires ImageMagick =
6.9.10.86-1.el8

digikam (maintained by: dvratil, kde-sig, kwizart, nucleo, rdieter,
than, tuxbrewr, vjancik)
digikam-6.4.0-4.el8.src requires ImageMagick-c++-devel = 6.9.10.86-
1.el8, ImageMagick-devel = 6.9.10.86-1.el8
digikam-6.4.0-4.el8.x86_64 requires libMagick++-6.Q16.so.8()(64bit),
libMagickCore-6.Q16.so.6()(64bit)
digikam-libs-6.4.0-4.el8.x86_64 requires libMagick++-
6.Q16.so.8()(64bit), libMagickCore-6.Q16.so.6()(64bit)

dvdauthor (maintained by: hobbes1069, sergiomb)
dvdauthor-0.7.2-14.el8.src requires ImageMagick-devel = 6.9.10.86-1.el8
dvdauthor-0.7.2-14.el8.x86_64 requires libMagickCore-
6.Q16.so.6()(64bit)

ettercap (maintained by: limb)
ettercap-0.8.3.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8

gnokii (maintained by: limb, robert, snirkel)
gnokii-0.6.31-29.el8.src requires ImageMagick = 6.9.10.86-1.el8

keepass (maintained by: mavit, tpokorra)
keepass-2.45-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

latex2rtf (maintained by: cicku, yselkowitz)
latex2rtf-2.3.18-4.el8.src requires ImageMagick = 6.9.10.86-1.el8
latex2rtf-2.3.18-4.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

lyx (maintained by: jamatos, rdieter)
lyx-2.3.6-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

mediainfo (maintained by: ivanromanov, vascom)
mediainfo-21.09-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

openbabel (maintained by: alexpl, jussilehtola, rathann, sagitter,
scitech_sig)
openbabel-3.1.1-4.el8.src requires ImageMagick = 6.9.10.86-1.el8

perl-GD-SecurityImage (maintained by: eseyman)
perl-GD-SecurityImage-1.75-4.el8.noarch requires perl(Image::Magick)
perl-GD-SecurityImage-1.75-4.el8.src requires perl(Image::Magick)

perl-PAR-Packer (maintained by: jplesnik, ppisar)
perl-PAR-Packer-1.052-2.el8.src requires ImageMagick = 6.9.10.86-1.el8

playonlinux (maintained by: robert)
playonlinux-4.4-2.el8.x86_64 requires ImageMagick = 6.9.10.86-1.el8

purple-discord (maintained by: xvitaly)
purple-discord-0-33.20210928gitb7ac723.el8.src requires ImageMagick =
6.9.10.86-1.el8

putty (maintained by: jskarvad, olysonek, zaniyah)
putty-0.76-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

stb (maintained by: churchyard, music)
stb-0-0.7.20211022gitaf1a5bc.el8.src requires /usr/bin/convert

stellarium (maintained by: limb, s4504kr)
stellarium-0.20.1-1.el8.src requires ImageMagick = 6.9.10.86-1.el8

tango-icon-theme (maintained by: cottsay, mavit)
tango-icon-theme-0.8.90-24.el8.src requires ImageMagick-devel =
6.9.10.86-1.el8

w3m (maintained by: pnemade, robert)
w3m-img-0.5.3-50.git20210102.el8.x86_64 requires ImageMagick =
6.9.10.86-1.el8

xemacs-packages-extra (maintained by: jjames, stevetraylen)
xemacs-packages-extra-20191207-1.el8.src requires ImageMagick =
6.9.10.86-1.el8

xfig (maintained by: jwrdegoede, stevetraylen)
xfig-3.2.7b-3.el8.src requires ImageMagick = 6.9.10.86-1.el8

xforms (maintained by: rdieter, robert)
xforms-1.2.4-14.el8.src requires ImageMagick = 6.9.10.86-1.el8

-- 
Sérgio M. B.
___
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: Builds for EPEL9

[Sérgio Basto]

On Mon, 2021-12-13 at 22:30 +1100, Frank Crawford wrote:
> On Mon, 2021-12-13 at 06:18 -0500, Neal Gompa wrote:
> > On Mon, Dec 13, 2021 at 6:13 AM Troy Dawson 
> > wrote:
> > > 
> > > 
> > > 
> > > On Sat, Dec 11, 2021 at 1:58 AM Frank Crawford
> > >  wrote:
> > > > 
> > > > Folks,
> > > > 
> > > > I'm looking at building a package that currently exists in EPEL8
> > > > for
> > > > EPEL9.  I have a new branch epel9 branch for my package, but when
> > > > I try
> > > > to do a mock build or scratch build it fails with the error:
> > > > 
> > > > Error: Error downloading packages:
> > > >   Status code: 404 for
> > > > https://infrastructure.fedoraproject.org/repo/centos/centos-9-
> > > > stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesy
> > > > stem-11-13.el9.noarch.rpm
> > > > (IP: 38.145.60.16)
> > > > 
> > > > Am I doing anything wrong here, is it just that we can't
> > > > currently
> > > > build for EPEL9?
> > > 
> > > 
> > > You certainly can build for epel9.
> > > But you haven't said what command(s) you are doing that gives that
> > > output.
> > > Let us know what you are doing, and that will make it possible for
> > > us to help.
> > > 
> > 
> > I have the same problem using fedpkg-1.41-2.fc35.
> > 
> > Using "fedpkg --release epel9 mockbuild" fails with that error
> > consistently. I tried to test builds of a couple of packages locally
> > before doing branch requests and I couldn't.
> 
> Yeah sorry about that, I tried two different things, in the EPEL9
> branch of my code:
> 
> fedpkg mockbuild

with --verbose output 

fedpkg -v mockbuild
(...)
Mock config /etc/mock/epel-9-x86_64.cfg was not found. Going to request
koji to create new one.
New mock config directory: /tmp/epel-9-x86_64.lwxt33udmockconfig
(...)

and basesystem is installed , have you any /etc/mock/epel-9-x86_64.cfg
? 



> and also
> 
> fedpkg scratch-build
> 
> Both cases came out with pretty much the same error, i.e. couldn't get
> basesystem.
> 
> Regards
> Frank
> ___
> 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

-- 
Sérgio M. B.
___
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: why ccache is not available on epel7 ?

[Sérgio Basto]

On Fri, 2021-10-08 at 10:13 -0400, Stephen John Smoogen wrote:
> On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
> > 
> > Hi,
> > 
> > I see ccache for epel 7 here 
> > https://src.fedoraproject.org/rpms/ccache
> > , but is not available in repos ... why ?
> > 
> 
> 
> https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
> https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm
> 
> So it is in the repos. I also was able to install it on a fresh
> CentOS-7 system. Not sure why it is not showing up for you.
> > 

Sorry , I was using  mock -r centos-7-x86_64

is centos-7 that don't have ccache ! epel-7 have it 

Thank you.

> > Thank you,
> > --
> > Sérgio M. B.
> > ___
> > 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
> 
> 
> 
> --
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in
> sci.astro.orion. I have seen SPAM filters overload because of
> Godwin's
> Law. All those moments will be lost in time... like posts on a BBS...
> time to shutdown -h now.
> ___
> 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

-- 
Sérgio M. B.
___
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] why ccache is not available on epel7 ?

[Sérgio Basto]

Hi, 

I see ccache for epel 7 here https://src.fedoraproject.org/rpms/ccache
, but is not available in repos ... why ? 


Thank you,
-- 
Sérgio M. B.
___
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: Get BR: %{py3_dist } working on EPEL7

[Sérgio Basto]

On Wed, 2021-10-06 at 20:43 -0600, Orion Poplawski wrote:
> Would it be possible to get BuildRequires: %{py3_dist NAME} working
> on 
> EPEL7?  At first I thought it was sufficient for epel-rpm-macros to 
> require python3-rpm-macros, but now I think we may need to override
> the 
> definition of py3_dist.  In fedora it uses %python3_pkgversion, in
> RHEL7 
> it uses %python3_version, and in RHEL8 "python3dist".
> 
> But %python3_version requires python to evaluate.
> 
> Presumably we're using %python3_version to allow for multiple python 
> versions, but I think we've given up on that in single spec files.
> 
> Thoughts?
> 

I think it is related with 
https://bugzilla.redhat.com/show_bug.cgi?id=1812665

maybe we should open a new bug ...


-- 
Sérgio M. B.
___
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: Getting %ldconfig_scriptlets in CentOS 7

[Sérgio Basto]

On Sun, 2021-09-19 at 20:08 +0100, Mikhail Ramendik wrote:
> On Fri, 17 Sept 2021 at 23:12, Troy Dawson  wrote:
>  
> > He needs epel-rpm-macros which provides
> > /usr/lib/rpm/macros.d/macros.epel-rpm-macros that has the
> > %ldconfig_scriptlets defined.
> > 
> 
> 
> Thanks a lot!! This resolves the issue.
> 
> May I ask you to add this information
> to  https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
>  ? I tried, but I am having problems with the Fedora Project website;
> it gives an Error 500 when I try to complete the FPCA. 
> 


IMO , we should add one page on docs (
https://docs.fedoraproject.org/en-US/packaging-guidelines/ )

with what a mention in previous link on this thread ( a page with what
is not necessary anymore) 

I had found a nice wiki page in my bookmarks that have information that
also should be add
https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets=468484#mimeinfo

https://docs.fedoraproject.org/en-US/packaging-guidelines/ supersede
wiki pages 


we already have
https://docs.fedoraproject.org/en-US/epel/epel-packaging/


-- 
Sérgio M. B.
___
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: Getting %ldconfig_scriptlets in CentOS 7

[Sérgio Basto]

On Fri, 2021-09-17 at 12:35 +0100, Mikhail Ramendik wrote:
> Hello,
> 
> A friend of mine is rebuilding an EPEL package (namely llvm9.0) from
> source for CentOS 7 on aarch64. The aarch64 build is not in the EPEL
> repo, probably because RHEL7 for aarch64 is out of support.
> 
> WIth an unmodified .spec file, he gets a message that
> the  %ldconfig_scriptlets macro is unknown, or else he gets it built
> but not linked and so not running. He had to add "%post -p
> /sbin/ldconfig" and rebuild.
> 
> I did find the wiki page about this macro
> at https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
> but I could not work out which package should pull this feature into
> CentOS 7.
> 
> So how can he get his aarch64 CentOS 7 to support this macro, to
> enable rebuilds without modifying the .spec file?
> 
> (Ideally he wants to be able to rebuild for Russian RHEL7 derivatives
> too).



https://lists.fedorahosted.org/archives/list/packag...@lists.fedoraproject.org/thread/XJGRYU5G3YIRXDAOWF5GTY4NOOKFHTXR/


> ___
> 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

-- 
Sérgio M. B.
___
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] is possible rollback Epoch bump on epel ?

[Sérgio Basto]

Hi, 
In practice, after bug [1] I decided rollback update on epel 7 with one
epoch bump [2]. Now after one year and half and after testing, we know
if we removing one line it works, so I want rollback the rollback and
update debmirror on epel7 to support Ubuntu 20.04 ... 

the question is, can I remove Epoch tag ? or should I put Epoch in
every branch, i.e epel 8 ? 

Thank you . 


[1] 
https://bugzilla.redhat.com/show_bug.cgi?id=1801338


[2] 
https://src.fedoraproject.org/rpms/debmirror/commits/epel7
-- 
Sérgio M. B.
___
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] and about missing binary packages Re: proposed recommendation - missing devel packages

[Sérgio Basto]

Hi,

Sorry, this may be a little Off-topic but we notice that lame package
from RHEL 8 (1) is not shipping lame package with binaries and in this
case lame-devel is provided along with lame-libs , can we apply the
same rules ? is completely a different situation ? 


(1)
https://git.centos.org/rpms/lame/blob/c8/f/SPECS/lame.spec


On Thu, 2021-07-01 at 15:05 -0700, Troy Dawson wrote:
> I believe this is a recommendation, versus a policy.
> I wanted to get people's thoughts on it, and if ya'll like it, put it
> in the documentation.
> 
> In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> packages that are built from RHEL spec files.  This will also be true
> of RHEL 9, and possibly future RHEL releases.  These missing packages
> are usually -devel packages and may impact an EPEL package build.
> If your EPEL package is impacted by a missing -devel package, do the
> following.
> 
> 1 - Request the package be added to RHEL 8 and 9 CRB repository.  
> -- To initiate this process, please file a bug in
> https://bugzilla.redhat.com and request it be added to RHEL 8 and 9.
> Report the bug against the "CentOS Stream" version of the "Red Hat
> Enterprise Linux 8" and/or "Red Hat Enterprise Linux 9" product. 
> -- Be sure to say that it is impacting an EPEL build, and which package
> it is impacting.
> 
> 2 - Create an epel package that only has the missing packages.
> -- Be prepared to maintain this package as long as it is needed.
> -- It is recommended that you name it -epel
> -- It is recommended that you add the epel-packaging-sig group as a co-
> maintainer
> -- It qualifies for an exception to the review process[1] so you can
> request the repo with
> --- fedpkg request-repo --exception -epel
> -- If you need help building this, ask for help.  We have some
> examples.
> 
> 3 - When/If the missing package(s) are added to RHEL CRB, retire your -
> epel package.
> 
> ---
> Sorry, this is a little rushed.  I wanted to get something out sooner,
> rather than later.
> 
> Troy
> 
> [1] -
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
>   - Third bullet point

-- 
Sérgio M. B.
___
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: anyone knows why perl in epel8 give me a lot of "security" errors ?

[Sérgio Basto]

On Wed, 2021-05-26 at 13:00 +0200, Petr Pisar wrote:
> V Wed, May 26, 2021 at 10:30:54AM +0100, Sérgio Basto napsal(a):
> > fedpkg clone debhelper
> > cd debhelper
> > fedpkg srpm && mock -r epel-8-x86_64  --no-clean --rebuild
> > debhelper-
> > 13.3.4-1.fc35.src.rpm 
> > 
> > I can build the package in _all_ others branches but
> 
> In epel7 too?
> 
> > in epel8 ends with
> > "Initialization of state variables in list context currently
> > forbidden
> > at /builddir/build/BUILD/debhelper-
> > 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near");" "
> > 
> perl has a "splain" tool which explains the compiler errors and
> warnings:
> 
> $ splain
> /usr/bin/splain: Reading from STDIN
> Initialization of state variables in list context currently forbidden
> at /home/test/fedora/debhelper/debhelper-
> 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");"
> Initialization of state variables in list context currently forbidden
> at
>     /home/test/fedora/debhelper/debhelper-
> 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");" (#1)
>     (F) state only permits initializing a single scalar variable, in
> scalar
>     context.  So state $a = 42 is allowed, but not state ($a) = 42. 
> To apply
>     state semantics to a hash or array, store a hash or array
> reference in a
>     scalar variable.
> 
> What do we have at the line 2021?:
> 
>     state %rrr = map { $_ => 1 } split(' ', $rrr_env);
> 
> That's it. perl 5.26.3 does not support "state" declaration for
> hashes (%err).
> Here is a one-line reproducer:
> 
> $ perl -e 'use v5.24; sub foo {state %rrr = map { $_ => 1 } split(q{
> }, q{});}'
> Initialization of state variables in list context currently forbidden
> at -e line 1, near ");"
> Execution of -e aborted due to compilation errors.
> 
> Which can be reduced to:
> 
> $ perl -e 'use v5.24; state %rrr = ();'
> Initialization of state variables in list context currently forbidden
> at -e line 1, near ");"
> Execution of -e aborted due to compilation errors.
> 
> Please note that the "use v5.24;" statement is taken from debhelper
> code.
> It's obviously an upstream bug. The code is not valid syntax for perl
> 5.24.
> 
> The state support for non-scalar types was implemented in Perl 5.28.0
> (see
> "perldoc perl5280delta" command output):
> 

ok

>   Initialisation of aggregate state variables
>     A persistent lexical array or hash variable can now be
> initialized, by
>     an expression such as "state @a = qw(x y z)". Initialization of a
> list
>     of persistent lexical variables is still not possible.
> 
> You should reach out depbhelp upstream to correct the "use v5.24;"
> into "use
> v5.28;". Or you can ask them to refactor the code to support perl
> 5.26.

yes , I will 

> If you insist on using that debhelper version on RHEL-8, you can try
> switching
> to perl:5.30 module stream which delivers Perl 5.30.1. But you will
> have to
> rebuild most of the dephelper dependencies for the new perl yourself.
> (Because
> EPEL support for modules is, ehm, mostly undefined and unhelpful.)
> 

Many thanks Petr , I will try forward this bug to debhelper developer
team . And I will wait for the fixes or reply before do something in
epel 8  . 


-- 
Sérgio M. B.
___
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: anyone knows why perl in epel8 give me a lot of "security" errors ?

[Sérgio Basto]

On Wed, 2021-05-26 at 13:00 +0200, Petr Pisar wrote:
> V Wed, May 26, 2021 at 10:30:54AM +0100, Sérgio Basto napsal(a):
> > fedpkg clone debhelper
> > cd debhelper
> > fedpkg srpm && mock -r epel-8-x86_64  --no-clean --rebuild debhelper-
> > 13.3.4-1.fc35.src.rpm 
> > 
> > I can build the package in _all_ others branches but
> 
> In epel7 too?

Doesn't build at all in epel 7 (1) 

From debhelper (13.1) changelog: "Dh_Lib.pm: Require perl v5.24
(available in Debian oldstable) to enable more modern features. "

(1)
Perl v5.24.0 required--this is only v5.16.3, stopped at
/builddir/build/BUILD/debhelper-13.3.4/lib/Debian/Debhelper/Dh_Lib.pm
line 9.

> > in epel8 ends with
> > "Initialization of state variables in list context currently
> > forbidden
> > at /builddir/build/BUILD/debhelper-
> > 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near");" "
> > 
> perl has a "splain" tool which explains the compiler errors and
> warnings:
> 
> $ splain
> /usr/bin/splain: Reading from STDIN
> Initialization of state variables in list context currently forbidden
> at /home/test/fedora/debhelper/debhelper-
> 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");"
> Initialization of state variables in list context currently forbidden
> at
>     /home/test/fedora/debhelper/debhelper-
> 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");" (#1)
>     (F) state only permits initializing a single scalar variable, in
> scalar
>     context.  So state $a = 42 is allowed, but not state ($a) = 42.  To
> apply
>     state semantics to a hash or array, store a hash or array reference
> in a
>     scalar variable.
> 
> What do we have at the line 2021?:
> 
>     state %rrr = map { $_ => 1 } split(' ', $rrr_env);
> 
> That's it. perl 5.26.3 does not support "state" declaration for hashes
> (%err).
> Here is a one-line reproducer:
> 
> $ perl -e 'use v5.24; sub foo {state %rrr = map { $_ => 1 } split(q{ },
> q{});}'
> Initialization of state variables in list context currently forbidden
> at -e line 1, near ");"
> Execution of -e aborted due to compilation errors.
> 
> Which can be reduced to:
> 
> $ perl -e 'use v5.24; state %rrr = ();'
> Initialization of state variables in list context currently forbidden
> at -e line 1, near ");"
> Execution of -e aborted due to compilation errors.
> 
> Please note that the "use v5.24;" statement is taken from debhelper
> code.
> It's obviously an upstream bug. The code is not valid syntax for perl
> 5.24.
> 
> The state support for non-scalar types was implemented in Perl 5.28.0
> (see
> "perldoc perl5280delta" command output):
> 
>   Initialisation of aggregate state variables
>     A persistent lexical array or hash variable can now be initialized,
> by
>     an expression such as "state @a = qw(x y z)". Initialization of a
> list
>     of persistent lexical variables is still not possible.
> 
> You should reach out depbhelp upstream to correct the "use v5.24;" into
> "use
> v5.28;". Or you can ask them to refactor the code to support perl 5.26.
> 
> If you insist on using that debhelper version on RHEL-8, you can try
> switching
> to perl:5.30 module stream which delivers Perl 5.30.1. But you will
> have to
> rebuild most of the dephelper dependencies for the new perl yourself.
> (Because
> EPEL support for modules is, ehm, mostly undefined and unhelpful.)
> 
> -- Petr
> 
> ___
> 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

-- 
Sérgio M. B.
___
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] anyone knows why perl in epel8 give me a lot of "security" errors ?

[Sérgio Basto]

Hi,

fedpkg clone debhelper
cd debhelper
fedpkg srpm && mock -r epel-8-x86_64  --no-clean --rebuild debhelper-
13.3.4-1.fc35.src.rpm 

I can build the package in _all_ others branches but in epel8 ends with
"Initialization of state variables in list context currently forbidden
at /builddir/build/BUILD/debhelper-
13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near");" "

If I try build version 13 (.0), I can. But 13.1 I can't because it have
some "modern" Perl syntax and builds also ends with others strange
messages like 
https://stackoverflow.com/questions/13517270/error-bareword-params-not-allowed-while-strict-subs

Any clue ? 

Thank you
-- 
Sérgio M. B.
___
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: intent to retire roundcubemail in epel7

[Sérgio Basto]

On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote:
> On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
> > On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen <
> > smo...@gmail.com>
> > wrote:
> 
> ...snip...
> 
> Here's a scratch build of 1.4.11, but I bet it won't work as many of
> the
> php-pear packages are too old. ;( 
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
> 

why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/
?



> > > I am wondering if we need a different way to announce reasons for
> > > this:
> > > 
> > > [ ] I no longer use RHEL-7 so can not test
> > > [ ] I found that there are too many package updates needed that I
> > > do not
> > > have time for.
> > > [ ] The following RHEL packages are too old for this package to be
> > > updated
> > > [ ] The upstream is dead and I can not fix
> > > ...
> > 
> > Or maybe instead of saying it's retiring, do Fedora's Orphaning
> > format.
> > Announce they are orphaning the package, and if a package is orphaned
> > for a
> > certain amount of time, and has all the orphan annoucements, it get's
> > removed.
> > But I do like your checkbox way for announcing the reasons for
> > retiring/orphaning.
> 
> Well, thats what goes in the dead.package file when the package is
> retired. :) 
> 
> I was just wanting to stop shipping a known vulnerable package and get
> it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't
> actually going to work, but happy for someone to prove me wrong. I
> don't
> really have the time to investigate further myself.
> 
> So, I will orphan it now, if no one takes it in a while, I will retire
> it then?
> 
> kevin
> ___
> 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

-- 
Sérgio M. B.
___
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: dpkg Requires po4a >= 0.59 on epel 8 but version available is po4a-0.52-4.el8

[Sérgio Basto]

On Tue, 2021-05-11 at 21:54 -0500, Carl George wrote:
> PowerTools is the CentOS equivalent of the RHEL CRB repository.  EPEL
> doesn't have any control over it.  You'll have to convince the RHEL
> maintainer to rebase that package.
> 
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red Hat Enterprise
> Linux 8=po4a=CentOS Stream


https://bugzilla.redhat.com/show_bug.cgi?id=1959750

Thanks

> On Tue, May 11, 2021 at 6:13 PM Sérgio Basto  wrote:
> > 
> > Hi,
> > Since this commit [1] I need po4a >= 0.59 to build dpkg , but [2],
> > po4a is in powertools repo [3]  , can we do something to update it ?
> > 
> > Thank you.
> > 
> > 
> > [1]
> > https://github.com/guillemj/dpkg/commit/a74a91310260efe55cc986506fe208ae2776a45a
> > 
> > [2]
> > https://git.centos.org/rpms/po4a/
> > import po4a-0.52-4.el8  CentOS Sources committed 2 years ago
> > 
> > [3]
> > dnf repoquery po4a --qf "%{repoid} %{sourcerpm}" --quiet
> > powertools po4a-0.52-4.el8.src.rpm
> > 
> > --
> > Sérgio M. B.
> > ___
> > 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
> 
> 
> 
> -- 
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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] dpkg Requires po4a >= 0.59 on epel 8 but version available is po4a-0.52-4.el8

[Sérgio Basto]

Hi,
Since this commit [1] I need po4a >= 0.59 to build dpkg , but [2], 
po4a is in powertools repo [3]  , can we do something to update it ?  

Thank you.


[1]
https://github.com/guillemj/dpkg/commit/a74a91310260efe55cc986506fe208ae2776a45a

[2]
https://git.centos.org/rpms/po4a/
import po4a-0.52-4.el8  CentOS Sources committed 2 years ago 

[3]
dnf repoquery po4a --qf "%{repoid} %{sourcerpm}" --quiet
powertools po4a-0.52-4.el8.src.rpm

-- 
Sérgio M. B.
___
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] Fedpkg wrote "Create package.cfg to specify build targets to build. "

[Sérgio Basto]

Hi ,
Fedpkg wrote "Create package.cfg to specify build targets to build. "
 , where I can read more about this subject , should I add package.cfg
to the package ? can package.cfg be in master branch and in Fedora
branches ? etc .


Thank you.


-- 
Sérgio M. B.
___
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: apt-cacher-ng not working on CentOS 7

[Sérgio Basto]

On Thu, 2020-06-25 at 09:15 -0400, Scott Talbert wrote:
> On Thu, 25 Jun 2020, Nicolas Kovacs wrote:
> 
> > Hi,
> > 
> > I've been using the nifty apt-cacher-ng package cache successfully
> > on Debian.
> > 
> > Now I'd like to run it on our local server running CentOS 7. I
> > installed the
> > package from EPEL, but the service fails to start.
> > 
> > On Debian, running apt-cacher-ng is a matter of installing it,
> > firing it up and
> > then pointing clients to the proxy.
> > 
> > Any idea why the service is failing on CentOS ?
> 
> Unfortunately, it appears there is currently no maintainer for the
> package 
> in Fedora.
> 
> It sounds like this problem has been known for a while:
> https://bugzilla.redhat.com/show_bug.cgi?id=1734712

also [1] could help it says that you need create a directory 

also the package is orphan and was retired on F33 , I may take it ,if
have an easy fix ... 

https://bugzilla.redhat.com/show_bug.cgi?id=1738884

> Scott
> ___
> 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
-- 
Sérgio M. B.
___
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] Please clarify if EPEL8 need the scriptlets of Icon Cache, mimeinfo and Desktop databases

[Sérgio Basto]

Hi, 

Guideline page needing clarification: 
https://fedoraproject.org/wiki/EPEL:Packaging

Explanation

in this wiki page is not clear that on EPEL8 we don't need anymore the
scriptlets of Icon Cache, mimeinfo and Desktop databases

Thank you
-- 
Sérgio M. B.
___
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: Updated KDE available in EPEL 8

[Sérgio Basto]

On Tue, 2020-06-16 at 07:36 -0700, Troy Dawson wrote:
> On Mon, Jun 15, 2020 at 8:21 PM Sérgio Basto 
> wrote:
> > On Mon, 2020-06-15 at 10:04 -0700, Troy Dawson wrote:
> > > RHEL 8.2 and CentOS 8.2 have an updated qt5.  This updated qt5
> > > allowed
> > > us to update the KDE Plasma Desktop in EPEL8.  We are not at the
> > > following versions.
> > > 
> > > qt5 - 5.12
> > > plasma - 5.18 [1]
> > > kf5 - 5.68 / 19.12
> > > apps - 5.18 / 19.12
> > > 
> > > Installation Instructions:
> > > ### First: install epel-release
> > > rpm -Uvh
> > > https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> > > 
> > > ### Second: Enable codeready-builder or PowerTools
> > >   subscription-manager repos --enable codeready-builder-for-rhel-
> > > 8-
> > > x86_64-rpms
> > >  If CentOS 8 do
> > >   dnf config-manager --enable PowerTools
> > >    If CentOS Stream do
> > > dnf config-manager --enable Stream-PowerTools
> > > 
> > > ### Third: install KDE
> > > dnf group install "KDE Plasma Workspaces"
> > >   or
> > > dnf group install kde-desktop
> > > (Optional) dnf group install kde-media
> > > (Optional) dnf group install kde-apps
> > > (Optional) dnf install okular
> > > 
> > > ### (Optional) Fourth: Set sddm as desktop manager
> > > ### Required if you started from a minimal install
> > > systemctl set-default graphical.target [if in multi-user.target]
> > > dnf install sddm\*
> > > systemctl enable sddm -f
> > > reboot
> > > 
> > > ### (Optional) If you installed in GNOME
> > > systemctl reload gdm
> > > 
> > > 
> > > Known Issues:
> > > Several (about 50%) settings do not work in System Settings.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1838801
> > > Help resolving this bug would be appreciated.
> > > It is irritating, but not critical.
> > 
> > Hi,
> > I'm testing Centos 8.2 in a VM with
> > VirtualBox-guest-additions-6.1.10-3.el8.x86_64,  seems to me that
> > undefined symbol:
> > _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_
> > don't
> > let me start KDE [1] .
> > 
> > Any guess ?
> > 
> > Thank you
> > 
> > [1]
> > Jun 15 23:20:08 localhost sddm-greeter[1663]:
> > file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:26:1:
> > plugin
> > cannot be loaded for module "org.kde.plasma.core": Cannot load
> > library
> > /usr/lib64/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so:
> > (/lib64/libKF5XmlGui.so.5: undefined symbol:
> > _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_)
> > #012 import org.kde.plasma.core 2.0 as PlasmaCore #012
> > 
> 
> Is this a fresh install of CentOS 8.2 or an update of something
> older?
> How did you install kde?
> If it's a fresh install, did you do an update after the install?
> 
> Although the only virtual machines I've tried it on is KVM based
> ones,
> I don't *think*  this is a VirtualBox vs KVM issue.
> It seems to be a too-old or too-new library issue.
> 
> My guess:
> You updated from CentOS 8.1 to 8.2. 

I installed Centos 8 with CentOS-8.1.1911-x86_64-boot.iso. 
Today after doing dnf distro-sync which installed 18 Packages and
upgraded 683 Packages, it starts to work correctly .

Thank you


> You have rpm-fusion installed, and
> there is some package in rpm-fusion that hasn't been rebuilt yet.
> Whatever those packages are, are preventing a complete update to
> CentOS 8.2, and whatever isn't updated is affecting kf5-plasma from
> starting.
> It's a total guess, and I'm not meaning to pick on the rpm-fusion
> people, but since CentOS 8.2 just came out, it's possible they don't
> have everything finished yet.
> 
> Hope this helps.
> 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
-- 
Sérgio M. B.
___
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: Updated KDE available in EPEL 8

[Sérgio Basto]

On Mon, 2020-06-15 at 10:04 -0700, Troy Dawson wrote:
> RHEL 8.2 and CentOS 8.2 have an updated qt5.  This updated qt5
> allowed
> us to update the KDE Plasma Desktop in EPEL8.  We are not at the
> following versions.
> 
> qt5 - 5.12
> plasma - 5.18 [1]
> kf5 - 5.68 / 19.12
> apps - 5.18 / 19.12
> 
> Installation Instructions:
> ### First: install epel-release
> rpm -Uvh 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> 
> ### Second: Enable codeready-builder or PowerTools
>   subscription-manager repos --enable codeready-builder-for-rhel-8-
> x86_64-rpms
>  If CentOS 8 do
>   dnf config-manager --enable PowerTools
>    If CentOS Stream do
> dnf config-manager --enable Stream-PowerTools
> 
> ### Third: install KDE
> dnf group install "KDE Plasma Workspaces"
>   or
> dnf group install kde-desktop
> (Optional) dnf group install kde-media
> (Optional) dnf group install kde-apps
> (Optional) dnf install okular
> 
> ### (Optional) Fourth: Set sddm as desktop manager
> ### Required if you started from a minimal install
> systemctl set-default graphical.target [if in multi-user.target]
> dnf install sddm\*
> systemctl enable sddm -f
> reboot
> 
> ### (Optional) If you installed in GNOME
> systemctl reload gdm
> 
> 
> Known Issues:
> Several (about 50%) settings do not work in System Settings.
> https://bugzilla.redhat.com/show_bug.cgi?id=1838801
> Help resolving this bug would be appreciated.
> It is irritating, but not critical.

Hi,
I'm testing Centos 8.2 in a VM with 
VirtualBox-guest-additions-6.1.10-3.el8.x86_64,  seems to me that
undefined symbol:
_ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_ don't
let me start KDE [1] .

Any guess ? 

Thank you 

[1] 
Jun 15 23:20:08 localhost sddm-greeter[1663]:
file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:26:1: plugin
cannot be loaded for module "org.kde.plasma.core": Cannot load library
/usr/lib64/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so:
(/lib64/libKF5XmlGui.so.5: undefined symbol:
_ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_)
#012 import org.kde.plasma.core 2.0 as PlasmaCore #012   








> Many thanks to all who helped with this.
> Troy Dawson
> 
> [1] plasma-nm is currently at 5.15.  This has been verified to work.
> We will hopefully be able to update it to 5.18 within a month.
> ___
> 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
-- 
Sérgio M. B.
___
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: unable to submit updates to stable: 504 Gateway Time-out

[Sérgio Basto]

On Wed, 2020-06-03 at 20:49 -0700, Kevin Fenzi wrote:
> On Wed, Jun 03, 2020 at 07:13:06AM -0700, Troy Dawson wrote:
> > On Tue, Jun 2, 2020 at 8:14 AM Felix Schwarz <
> > fschw...@fedoraproject.org> wrote:
> > > 
> > > Am 01.06.20 um 17:25 schrieb Troy Dawson:
> > > > I was having a similar problem last week, I opened a
> > > > fed-infrastructure ticket and they extended the time out
> > > > time.  But it
> > > > looks like things have gotten so bad that even that extended
> > > > time
> > > > isn't good enough.
> > > > I have re-opened the ticket.

Please what ticket ? I'm seeing also some update that became pending ,
just pending , I opened a ticket as well [1] 

https://bodhi.fedoraproject.org/updates/?status=pending

[1] 
https://pagure.io/releng/issue/9492 


> > > Thank you - I was able to submit my updates to stable this
> > > morning :-)
> > > 
> > Something happened, though my ticket wasn't updated.  I was able to
> > see my update again ... once.
> > But my smaller updates and overrides are working now.
> > I'm glad it's working for you now.
> > Troy
> 
> To clarify we knew it was having problems and tried a bunch of things
> to
> get it working, and it seems that it is now? But the actual root
> cause
> of the slowdown is still unknown. ;( 


From https://bodhi.fedoraproject.org/updates/?status=pending I found
this update [1] which are just pending and if we click on it, always
gives "504 Gateway Time-out"

HTH

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d7c1181e05

-- 
Sérgio M. B.
___
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: Question

[Sérgio Basto]

On Sun, 2020-02-09 at 06:19 -0500, Pete Geenhuizen wrote:
> Is this the right list to ask about the status of ClamAV 0.102.1 and
> when it will be released?
> If this is not the right list please tell which list I to  which I
> should direct this question.
> Thanks


I'm trying to update it, but my two mates don't agree with the move
from freshclam to systemd [1]

will I try start shipping clamav 0.102.1 , today . 

[1] 
https://bugzilla.redhat.com/show_bug.cgi?id=1800226

> Pete
>  -- 
> Unencumbered by the thought process.  
>  -- Click and Clack the Tappet brothers 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean.
> ___
> 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
> 
> 
-- 
Sérgio M. B.
___
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

[Sérgio Basto]

On Fri, 2019-11-15 at 22:31 +, Sérgio Basto wrote:
> On Thu, 2019-11-14 at 18:33 +, Paul Howarth wrote:
> > 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.
> 
> I got the same error in these 2 cases [1] , I requested the branches
> today 
> 
> [1]
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39019804
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39019796

Seems we need to wait an amount of time to koji get synced with
request, but how long we have to wait ? 

Today I got one error in epel8 [1] and one in epel8-playground [2]

[1]
BuildError: package pbuilder not in list for tag epel8-testing-
candidate 

[2]
BuildError: package pbuilder not in list for tag epel8-playground-
pending

-- 
Sérgio M. B.
___
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

[Sérgio Basto]

On Thu, 2019-11-14 at 18:33 +, Paul Howarth wrote:
> 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.

I got the same error in these 2 cases [1] , I requested the branches
today 

[1]
https://koji.fedoraproject.org/koji/taskinfo?taskID=39019804
https://koji.fedoraproject.org/koji/taskinfo?taskID=39019796

-- 
Sérgio M. B.
___
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: Outstanding package requests for EPEL-8

[Sérgio Basto]

I wonder if we can request the branch and be added as co-maintainer ? 


On Wed, 2019-10-23 at 13:38 -0400, Stephen John Smoogen wrote:
> So this came up in the last EPEL meeting:
> bugzilla query -s NEW -t 'epel8'  --outputformat "%{id}:
> %{component}:
> %{summary}" | sort | less
> 
> 
> Most of these are package requests but some are other types.
> 
> 1739162: libxml++: libxml++ for EPEL8
> 1739163: libffado: libffado for EPEL8
> 1741523: mod_auth_cas: mod_auth_cas for EPEL8
> 1741654: dash: RFE: dash for EPEL8
> 1744341: jq: RFE: jq for EPEL8
> 1744343: nagios-plugins-openmanage: RFE: nagios-plugins-openmanage
> for EPEL8
> 1744699: perl-Apache-LogFormat-Compiler: [RFE] EPEL8 branch of
> perl-Apache-LogFormat-Compiler
> 1744700: perl-Authen-Passphrase: [RFE] EPEL8 branch perl-Authen-
> Passphrase
> 1744704: perl-Authen-Simple-Passwd: [RFE] EPEL8 branch of
> perl-Authen-Simple-Passwd
> 1744705: perl-Authen-Passphrase: [RFE] EPEL8 branch of perl-Authen-
> Simple
> 1744712: perl-IO-Handle-Util: [RFE] EPEL8 branch for perl-IO-Handle-
> Util
> 1744782: perl-Crypt-SSLeay: (RFE) EPEL8 branch of perl-Crypt-SSLeay
> 1744785: perl-Proc-Daemon: (RFE) EPEL8 branch of perl-Proc-Daemon
> 1745727: apcupsd: [RFE] apcupsd: epel8 build request
> 1749146: lxqt-session: Build LXQt in EPEL8
> 1749780: genders: please build for epel8
> 1750404: php-phpmailer6: [RFE] EPEL8 branch of php-phpmailer6
> 1753203: weechat: Can you please make a package in EPEL8 with new
> Weechat version?
> 1753397: scons: Build for EPEL8
> 1753401: perl-Class-Accessor-Lite: [RFE] EPEL8 branch of
> perl-Class-Accessor-Lite
> 1754155: quazip: Create EPEL8 branc
> 1755034: python-passlib: [RFE] EPEL8 branch of python-passlib
> 1755264: dnf-plugins-extras: Please release the snapper plug-in for
> epel8 also.
> 1755345: python-mysql: Request to build python3-mysql for EPEL8
> 1755761: clementine: [RFE] : clementine : epel8 build request
> 1755789: pidgin-otr: [RFE] : pidgin-otr epel8 build request
> 1755791: powerline: [RFE] : powerline : epel8 build request
> 1755793: autossh: [RFE] : autossh epel8 build request
> 1755809: cross-binutils: [RFE] EPEL8 branch of cross-binutils
> 1755816: simple-scan: [RFE] : simple-scan : epel8 build request
> 1755945: bats: [RFE] bats: epel8 build request
> 1755960: liblastfm: Please provide EPEL8 package
> 1755963: libmygpo-qt: Please provide EPEL8 package
> 1755964: libprojectM: Please provide EPEL8 package
> 1755965: qca: Please provide EPEL8 package
> 1755966: udisks: Please provide EPEL8 package
> 1755968: sha2: Please provide EPEL8 package
> 1755975: phonon: Please provide EPEL8 package
> 1756036: perl-XML-TreePP: [RFE] perl-XML-TreePP build for epel8
> 1756170: libcec: [RFE] libcec build for epel8
> 1756171: perl-Net-UPnP: [RFE] perl-Net-UPnP build for epel8
> 1756941: kid3: [RFE] : kid3 : epel8 build request
> 1756942: pylast: [RFE] : pylast : epel8 build request
> 1756976: gtk-murrine-engine: [RFE] : gtk-murrine-engine : epel8 build
> request
> 1757000: xmlstarlet: xmlstarlet missing in EPEL8
> 1757002: docbook2X: docbook-utils-pdf missing in RHEL8/CentOS-8: need
> it in EPEL8
> 1757009: perl-Qt: perl-Qt 4.14.3 missing for EPEL8
> 1757016: ntfsprogs: ntfsprogs is missing for EPEL8
> 1757645: python-urlgrabber: [RFE] python3-urlgrabber build for epel8
> 1757682: thunderbird-enigmail: [RFE] : thunderbird-enigmail : epel8
> build request
> 1757868: uboot-tools: Package uboot-tools is not available in EPEL8
> 1758005: xlockmore: build xlockmore for epel8
> 1758271: ipython: Branch request: python3-ipython for epel8
> 1758311: nova-agent: build nova-agent for epel8
> 1758329: python-requests-cache: [RFE] python-requests-cache for epel8
> 1758340: python-oauth: [RFE] python-oauth build for epel8
> 1758778: fmt: fmt not packaged for epel8
> 1758779: xalan-c: xalan-c not packaged for epel8
> 1758780: spdlog: spdlog not packaged for epel8
> 1758822: python-funcsigs: [RFE] EPEL8 branch of python-funcsigs
> 1759107: python-celery: Branch request: python-celery for epel8
> 1759108: python-markdown2: Branch request: python-markdown2 for epel8
> 1759109: python-aiohttp: Branch request: python-aiohttp for epel8
> 1759112: python-requests-mock: Branch request: python-requests-mock
> for epel8
> 1759114: python-cached_property: Branch request:
> python-cached_property for epel8
> 1759116: python-xmlsec: Branch request: python-xmlsec for epel8
> 1759121: python-zeep: Branch request: python-zeep for epel8
> 1759124: python-XStatic-Patternfly: Branch request:
> python-XStatic-Patternfly for epel8
> 1759129: nodejs-typeahead.js: Branch request: nodejs-typeahead.js for
> epel8
> 1759130: python-flask-openid: Branch request: python-flask-openid for
> epel8
> 1759132: python-flask-wtf: Branch request: python-flask-wtf for epel8
> 1759133: python-flask-sqlalchemy: Branch request:
> python-flask-sqlalchemy for epel8
> 1759136: nodejs-moment: Branch request: nodejs-moment for epel8
> 1759459: phpMyAdmin: Please build phpMyAdmin for 

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Sérgio Basto]

If it helps Copr (and mock) use centos 7 [1]

[1]
https://github.com/rpm-software-management/mock/blob/master/mock-core-configs/etc/mock/epel-7-x86_64.cfg


On Sun, 2019-08-11 at 10:44 +0200, Miro Hrončok wrote:
> See for example:
> 
> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> 2019-08-11 07:50:11
> 
> - nothing provides python(abi) = 3.6 ...
> 
> This is provided in RHEL 7.7.
> 
> (Note that we've unretired the python36 package, so later it resolved
> correctly.)
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
-- 
Sérgio M. B.
___
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: postgis-2.0.7-2.el7 still in epel7-testing

[Sérgio Basto]

On Fri, 2019-04-12 at 09:36 +0200, Danny Smit wrote:
> Hi all,
> 
> I'm looking for a fix in postgis, which seems to be fixed already in
> postgis-2.0.7-2.el7.
> 
> However that package seems to be 'stuck' in the epel7-testing
> repository for a long time:
>   https://koji.fedoraproject.org/koji/buildinfo?buildID=750618
>   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b6c229157e
> 
> Can the package be pushed to stable?

I gave +1 karma and more one and package will be pushed to updates
automatically .

Can someone give one more positive karma ? please 

Thanks

> -- 
> Kind regards,
> Danny
> ___
> 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
-- 
Sérgio M. B.
___
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: cairo issue with RHEL 7.6?

[Sérgio Basto]

On Tue, 2018-10-30 at 20:57 -0600, Orion Poplawski wrote:
> I'm getting this:
> 
> DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
> DEBUG util.py:439: Requires: libEGL.so.1()(64bit)
> DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
> DEBUG util.py:439: Requires: libGL.so.1()(64bit)
> 
> https://apps.fedoraproject.org/koschei/package/logback?collection=epe
> l7
> 
> That appears to be the appropriate latest version of cairo in RHEL
> 7.6. 
> Did it somehow not get properly rebuilt against the latest mesa-
> libGL/EGL?

+1 

perl-Qt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/perl-Qt?collecti
on=epel7

debconf's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/debconf?collecti
on=epel7

smokeqt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/smokeqt?collecti
on=epel7

clamav's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/clamav?collectio
n=epel7

mlt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/mlt?collection=e
pel7


> 
> -- 
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/epel-dev
> e...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
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] [Fwd: [includepkgs=devtoolset*] Re: Cannot find -latomic when building for epel7 aarch64]

[Sérgio Basto]

Hello, 

Moving this subject to epel-devel ML 

Generically where I find devtoolset howto(s) ? and what should be mock-
core-configs ? 

And I'm confused what difference of rh-eclipse46 and devtoolset-4 [1] ?

Thanks 
[1]
https://www.softwarecollections.org/en/scls/rhscl/rh-eclipse46/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/



 Forwarded Message 
From: Sérgio Basto 
Reply-to: Development discussions related to Fedora

To: Development discussions related to Fedora 
Subject: [includepkgs=devtoolset*] Re: Cannot find -latomic when
building for epel7 aarch64
Date: Mon, 22 Oct 2018 16:48:45 +0100

On Sat, 2018-10-20 at 13:03 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > I had checked mock-core-config [1] , which are in use in copr (I
> > guess)
> > and can't enable developer tools .
> > But on koji runs well , can you review this ? please .
> > 
> > I could build azureus [4] on koji [2] which need eclipse-swt , but
> > not
> > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >=
> > 3.5` 
> > Unfortunately I didn't have much time to dig it ... 
> 
> Packages from the SCL repos in mock-core-configs are
> restricted via the following config entry¹:
> 
> includepkgs=devtoolset*
> 
> That limit was not included in the initial koji
> configuration, but my understanding was that was going to be
> corrected.
> 
> The only packages allowed to be used (or more specifically,
> BuildRequired) from the SCL repos in EPEL are devtoolset*.
> (Feel free to follow up on epel-devel on that, as that's
> where the folks who know best are.)
> 
> ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-cor
> e-configs/etc/mock/epel-7-x86_64.cfg#L62


Thank you for the reply 

I improve my spec [1], I'm using devtoolset-4, I could build and run
azureus on el7 but unfortunately, this collection is EOL since Dec
2017; so I don't know if it is a good test, anyway with actual mock-
core-configs we can't install dependencies (rh-java-common-jpackage-
utils and rh-java-common-runtime).
if I add to [sclo-rh] includepkgs=devtoolset*,rh* it works .

In resume [2] fails with: [3]

Thanks 

[1]
https://github.com/sergiomb2/azureus/commits/master

[2]
mock -r epel-7-x86_64 --install devtoolset-4-eclipse-swt

[3]
Problem: cannot install the best candidate for the job
  - nothing provides rh-java-common-runtime needed by devtoolset-4-
eclipse-swt-1:4.5.2-5.4.el7.x86_64


-- 
Sérgio M. B.
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@list
s.fedoraproject.org
-- 
Sérgio M. B.
___
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: debootstrap, dpkg and man-pages-it

[Sérgio Basto]

On Tue, 2018-05-22 at 04:10 +0100, Sérgio Basto wrote:
> Hello,
> 
> On Sat, 2018-04-28 at 07:02 +0100, Andrew C Aitchison wrote:
> > From Fedora EPEL 6 updates-testing report Tuesday, 24 April 2018:
> > 
> > > The following Fedora EPEL 6 Security updates need testing:
> > 
> > ...
> > > The following builds have been pushed to Fedora EPEL 6 updates-
> > > testing
> > > debmirror-2.29-1.el6
> > > debootstrap-1.0.97-1.el6
> > > ocserv-0.12.0-1.el6 php-symfony-psr-http-message-bridge-1.0.2-
> > > 2.el6
> > > php-webmozart-assert-1.3.0-1.el6
> > 
> > When I attempt to update debootstrap with
> > 
> > # yum update
> > /var/cache/yum/x86_64/6.9/epel-testing/packages/debootstrap-1.0.97-
> > 1.el6.noarch.rpm
> > 
> > I get (sumary here, full log below the line):
> > Downloading Packages:
> > Running rpm_check_debug
> > Running Transaction Test
> > 
> > Transaction Check Error:
> >file /usr/share/man/it/man5/dpkg.cfg.5.gz from install of
> > dpkg-1.16.18-2.el6x86_64 conflicts with file from package
> > man-pages-it-2.80-6.el6.noarch
> > 
> > 
> > (Parenthetically, given rpmquiery -i debootstrap
> >Description :
> >debootstrap is used to create a Debian base system from scratch,
> >without requiring the availability of dpkg or apt...
> > It seems odd that we now require dpkg. If I get to choose, could
> > you
> > remove the dependency rather than update the decription :-) ?)
> 
> hum !?!
> 
> https://src.fedoraproject.org/rpms/debootstrap/c/6f76bb966ef3b1067db8
> 6d2dae748f50a0cdc117?branch=master
> 
> but the main problem is in man-pages-it-2.80-6.el6.noarch which
> provide a man page for dpkg 

I have submitted a fix [1]

[1]
https://bodhi.fedoraproject.org/updates/debootstrap-1.0.100-1.el6

Thanks, 
-- 
Sérgio M. B.
___
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/message/35G25PHJXVHEDM4PTQ5RXTPCDDVRUZ2E/

[EPEL-devel] Re: php

[Sérgio Basto]

On Tue, 2018-05-22 at 11:05 -0400, Stephen John Smoogen wrote:
> On 21 May 2018 at 23:18, Sérgio Basto <ser...@serjux.com> wrote:
> > Hi,
> > Latest php 5.4 release was in 2015-Sep-04 ( php-5.4.45.tar.gz )
> > 3 years ago ...
> > We will have el 7 until 2024 , more 6 years, can we update php to
> > 5.6
> > on el 7 ? or PHP apps for epel have to move to remi repo ?
> 
> I am expecting they will need to move to the remi repo because php-
> 5.4
> is shipped in RHEL and we do not over-write those packages. In the
> past RHEL would have shipped a php56 which would have done this, but
> I
> expect that they instead are wanting people to use SCL's for this.
> Which would require us to either ship the SCLs ourselves (as we can't
> assume a person has that repo turned on) or we create a repository
> which requires them so that people aren't broken.

I have to check SCL , but SCL-epel sounds good to me 

> There is another option where someone packages up the php56 rpms in
> some way which could be shipped in EPEL, but I think that is a large
> amount of work and I believe remi has pointed people to use scl's
> instead.

-- 
Sérgio M. B.
___
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/message/FH2MIFSMFG7UJFN6ZBBDSZGFZSERGTRZ/

[EPEL-devel] Re: debootstrap, dpkg and man-pages-it

[Sérgio Basto]

Hello,

On Sat, 2018-04-28 at 07:02 +0100, Andrew C Aitchison wrote:
> From Fedora EPEL 6 updates-testing report Tuesday, 24 April 2018:
> 
> > The following Fedora EPEL 6 Security updates need testing:
> 
> ...
> > The following builds have been pushed to Fedora EPEL 6 updates-
> > testing
> > debmirror-2.29-1.el6
> > debootstrap-1.0.97-1.el6
> > ocserv-0.12.0-1.el6 php-symfony-psr-http-message-bridge-1.0.2-2.el6
> > php-webmozart-assert-1.3.0-1.el6
> 
> When I attempt to update debootstrap with
> 
> # yum update
> /var/cache/yum/x86_64/6.9/epel-testing/packages/debootstrap-1.0.97-
> 1.el6.noarch.rpm
> 
> I get (sumary here, full log below the line):
> Downloading Packages:
> Running rpm_check_debug
> Running Transaction Test
> 
> Transaction Check Error:
>file /usr/share/man/it/man5/dpkg.cfg.5.gz from install of
> dpkg-1.16.18-2.el6x86_64 conflicts with file from package
> man-pages-it-2.80-6.el6.noarch
> 
> 
> (Parenthetically, given rpmquiery -i debootstrap
>Description :
>debootstrap is used to create a Debian base system from scratch,
>without requiring the availability of dpkg or apt...
> It seems odd that we now require dpkg. If I get to choose, could you
> remove the dependency rather than update the decription :-) ?)

hum !?!

https://src.fedoraproject.org/rpms/debootstrap/c/6f76bb966ef3b1067db86d
2dae748f50a0cdc117?branch=master

but the main problem is in man-pages-it-2.80-6.el6.noarch which provide
a man page for dpkg 



-- 
Sérgio M. B.
___
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/message/PMLJLKBCD3JPM5AAGI4IPMLADE4AVVTM/

[EPEL-devel] Re: [fedora-java] Re: Re: mod_jk

[Sérgio Basto]

On Sat, 2018-04-28 at 08:45 +, Bill Chatfield wrote:
> mod_jk is easy to build from source. I just did it
> myself. The instructions are easy to understand, there are only a few
> steps, and it actually compiles without errors. You're not going to
> waste most of a day getting it to build. It takes about 15 minutes at
> the most. It has some significant advantages over mod_proxy in that
> it has better load balancing and fail-over.

But now we have mod_proxy_ajp, with support to load balancing and ajp
things, I'm using it now and it is even more easy to configure . And I
don't need to build any package .
> 
> 
> 
> 
> 
> On Sunday, April 22, 2018, 3:51:00 PM EDT,
> Sérgio Basto <ser...@serjux.com> wrote:
> 
> 
> 
> 
> 
> On Sun, 2018-04-22 at 09:46 -0500, Rex Dieter
> wrote:
> > Sérgio Basto wrote:
> > 
> > > To simplify my concerns, what is easy way to install mod_jk ? on
> > > epel 7and
> > > 6 BTW
> > 
> > I went through similar searching for my @dayjob awhile back, ended
> > up 
> > switching to use apache's mod_proxy
> 
> ah mod_proxy_ajp.so is available on httpd package of el6, el7 and 
> Fedora 
> 
> Thanks for the tips 
> 
> -- 
> Sérgio M. B.
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.
> org
> 
> 
> 
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: mod_jk

[Sérgio Basto]

On Sun, 2018-04-22 at 09:46 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > To simplify my concerns, what is easy way to install mod_jk ? on
> > epel 7and
> > 6 BTW
> 
> I went through similar searching for my @dayjob awhile back, ended
> up 
> switching to use apache's mod_proxy

ah mod_proxy_ajp.so is available on httpd package of el6, el7 and 
Fedora 

Thanks for the tips 

-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: mod_jk rpm

[Sérgio Basto]

On Sun, 2018-04-22 at 11:55 +0200, Reindl Harald wrote:
> Am 22.04.2018 um 02:52 schrieb Sérgio Basto:
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html

OK I see that we also have mod_proxy_ajp [1] .
But what I meant , we don't have any of these in yum/dnf repos, neither
we have any src.rpm updated since 2015, or am I missing something ? 

Thanks 

[1]
https://wiki.apache.org/tomcat/FAQ/Connectors#Q2
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: mod_jk rpm

[Sérgio Basto]

On Sun, 2018-04-22 at 11:55 +0200, Reindl Harald wrote:
> Am 22.04.2018 um 02:52 schrieb Sérgio Basto:
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: mod_jk

[Sérgio Basto]

Sorry just some more notes:
http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/JBCS/SRPMS
/
for example these jbcs-httpd24 , doesn't make sense because el6 haveapache 2.2 

https://access.redhat.com/solutions/3357951

On Sun, 2018-04-22 at 02:23 +0100, Sérgio Basto wrote:
> meanwhile upstream updated to 1.2.43 [1] when last version found in
> rpms is 1.2.41
> 
> 
> [1]
> https://github.com/apache/tomcat-connectors/releases/tag/JK_1_2_43
> 
> 
> On Sun, 2018-04-22 at 01:52 +0100, Sérgio Basto wrote:
> > Hello, 
> > 
> > First my notes: 
> > https://issues.jboss.org/browse/JBCS-119?_sscc=t
> > http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6S
> > er
> > ver/en/JBEAP/SRPMS/
> > https://bugzilla.redhat.com/show_bug.cgi?id=1366581
> > https://developers.redhat.com/products/eap/download/
> > https://bugzilla.redhat.com/show_bug.cgi?id=1369758
> > 
> > 
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> > 
> > To simplify my concerns, what is easy way to install mod_jk ? on
> > epel
> > 7and 6 BTW 
> > 
> > we have JBCS (jboss something ) and we have JBEAP ? what is the
> > difference ? 
> > 
> > Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: mod_jk

[Sérgio Basto]

meanwhile upstream updated to 1.2.43 [1] when last version found in
rpms is 1.2.41


[1]
https://github.com/apache/tomcat-connectors/releases/tag/JK_1_2_43


On Sun, 2018-04-22 at 01:52 +0100, Sérgio Basto wrote:
> Hello, 
> 
> First my notes: 
> https://issues.jboss.org/browse/JBCS-119?_sscc=t
> http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6Ser
> ver/en/JBEAP/SRPMS/
> https://bugzilla.redhat.com/show_bug.cgi?id=1366581
> https://developers.redhat.com/products/eap/download/
> https://bugzilla.redhat.com/show_bug.cgi?id=1369758
> 
> 
> I needed mod_jk for some tomcat applications and it was one
> adventure 
> because last build of mod_jk is about 2015 and jpp project died in
> 2009
> 
> To simplify my concerns, what is easy way to install mod_jk ? on epel
> 7and 6 BTW 
> 
> we have JBCS (jboss something ) and we have JBEAP ? what is the
> difference ? 
> 
> Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] mod_jk

[Sérgio Basto]

Hello, 

First my notes: 
https://issues.jboss.org/browse/JBCS-119?_sscc=t
http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6Server/en/JBEAP/SRPMS/
https://bugzilla.redhat.com/show_bug.cgi?id=1366581
https://developers.redhat.com/products/eap/download/
https://bugzilla.redhat.com/show_bug.cgi?id=1369758


I needed mod_jk for some tomcat applications and it was one adventure 
because last build of mod_jk is about 2015 and jpp project died in 2009

To simplify my concerns, what is easy way to install mod_jk ? on epel 7and 6 
BTW 

we have JBCS (jboss something ) and we have JBEAP ? what is the
difference ? 

Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Sérgio Basto]

On Tue, 2018-03-27 at 13:46 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Tue, 2018-03-27 at 11:53 -0500, Rex Dieter wrote:
> > > Sérgio Basto wrote:
> > > 
> > > > On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> > > > > Sérgio Basto wrote:
> > > > > 
> > > > > > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > > > > > I'd be ok with an epel7-only python3-sip
> > > > > > > 
> > > > > > > Since it is a new package (not a branch of an existing
> > > > > > > one),
> > > > > > > then
> > > > > > > it
> > > > > > > would require a new package review.
> > > > > > > 
> > > > > > > It would be a bit of shame though, having to fork things
> > > > > > > like
> > > > > > > that.
> > > > > > 
> > > > > > I tried this solution (epel7-only python3-sip) but
> > > > > > BUILDSTDERR: Error: This version of PyQt5 requires sip
> > > > > > 4.19.4
> > > > > > or
> > > > > > later.
> > > > > > when el7 have  sip-devel  x86_64 4.14.6-
> > > > > > 4.el7 base
> > > > > > 
> > > > > > if we do package sip-qt5 we must override
> > > > > > /usr/lib64/python2.7/site-
> > > > > > packages/sip.so
> > > > > > it is possible sip-qt5 provides and obsolete sip (4.14.6-
> > > > > > 4.el7)
> > > > > > ?
> > > > > 
> > > > > Not possible (by policy).  It should be able to work without
> > > > > doing
> > > > > that, but
> > > > > it may require patching.
> > > > 
> > > > I don't see how. In python2, how "import sip" will work ?
> > > > "import
> > > > sip-qt5
> > > > as sip" ?
> > > 
> > > I thought the context here was your desire to add *only python3*
> > > sip/python-
> > > qt5 to epel ?
> > 
> > That was if pyhton2-sip was enough , but sip 4.14.6 is not enough
> > for
> > python2-qt5-devel ...
> > 
> > But thinking, we might only build python3-qt5 ?  ok,  let me review
> > this again , seems enough for my openshot and subdownloader 
> 
> Yes, that's really the only viable option here, to do *only* python3-
> sip and 
> python3-qt5

Done, sip : 
https://src.fedoraproject.org/fork/sergiomb/rpms/sip/c/84b5266e6d36d6e20c23bafe4da429fa0b98e0de?branch=master

and python3-qt5:
https://src.fedoraproject.org/fork/sergiomb/rpms/python-qt5/commits/master


As a note python34-sip-devel and sip-devel (pyhton2 version) can't be installed 
at same time [1]
but it is correct, we can only have one macros.sip in the system , is it a 
problem ? 
So can we do branches of sip and python-qt5 for epel-7 using the same packages 
but just build python3 part ? 

Thanks,

[1]
Problem: problem with installed package sip-devel-4.14.6-4.el7.x86_64

  - package sip-devel-4.14.6-4.el7.x86_64 requires sip-macros = 4.14.6-4.el7, 
but none of the providers can be installed
  - package python34-sip-macros-4.19.8-4.el7.centos.noarch obsoletes sip-macros 
< 4.15.5 provided by sip-macros-4.14.6-4.el7.x
86_64
  - package python34-sip-devel-4.19.8-4.el7.centos.x86_64 requires 
python34-sip-macros = 4.19.8-4.el7.centos, but none of the 
providers can be installed


rpm -q sip-macros -l
/etc/rpm/macros.sip

cat /etc/rpm/macros.sip
%_sip_api_major 9
%_sip_api_minor 2
%_sip_api %{_sip_api_major}.%{_sip_api_minor}


rpm -q python34-sip-macros -l
/usr/lib/rpm/macros.d/macros.sip

cat /usr/lib/rpm/macros.d/macros.sip
%_sip_api_major 12
%_sip_api_minor 4
%_sip_api %{_sip_api_major}.%{_sip_api_minor}

-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Sérgio Basto]

On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > I'd be ok with an epel7-only python3-sip
> > > 
> > > Since it is a new package (not a branch of an existing one), then
> > > it
> > > would require a new package review.
> > > 
> > > It would be a bit of shame though, having to fork things like
> > > that.
> > 
> > I tried this solution (epel7-only python3-sip) but
> > BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or
> > later.
> > when el7 have  sip-devel  x86_64 4.14.6-4.el7 base
> > 
> > if we do package sip-qt5 we must override
> > /usr/lib64/python2.7/site-
> > packages/sip.so
> > it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ?
> 
> Not possible (by policy).  It should be able to work without doing
> that, but 
> it may require patching.

I don't see how. In python2, how "import sip" will work ? "import sip-qt5 as 
sip" ? 

Best regards
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Sérgio Basto]

On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> I'd be ok with an epel7-only python3-sip
> 
> Since it is a new package (not a branch of an existing one), then it
> would require a new package review.
> 
> It would be a bit of shame though, having to fork things like that.

I tried this solution (epel7-only python3-sip) but 
BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or later.
when el7 have  sip-devel  x86_64 4.14.6-4.el7 base

if we do package sip-qt5 we must override /usr/lib64/python2.7/site-
packages/sip.so

it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ? 

As a side note for epel-devel we also need python3-sip which is not
provide by el7, since only epel-7 have python3, isn't it ?

 

> On Tue, Mar 6, 2018 at 2:02 PM, Sérgio Basto <ser...@serjux.com>
> wrote:
> > new suggestion for new sip: sip-qt5
> > 
> > On Mon, 2018-03-05 at 16:35 +, Sérgio Basto wrote:
> > > I study this a little , the sip on rhel is sip 4.14 and we need
> > > sip 4.15+ , but should be cool have python3-qt5, even we they
> > > update sip in RHEL won't have pyhton3 bindings since python34 is
> > > in epel .
> > > So can we consider do a package named sip5 (for qt5) just in
> > > epel7 ?
> > > 
> > > On Mon, 2018-03-05 at 10:20 -0600, Rex Dieter wrote:
> > > > Since the requisite version of sip cannot go into epel7, I'm
> > > > not sure if it makes sense to make an epel7 branch for python-
> > > > qt5.  I'm guessing no.
> > > > 
> > > > On Sat, Mar 3, 2018 at 6:37 PM, Sérgio Basto <ser...@serjux.com
> > > > > wrote:
> > > > > Hello,
> > > > > Same email to python-qt5
> > > > > 
> > > > > From [1] I'd like ask, please, request to commit or please
> > > > > branch
> > > > > python-qt5 into epel7 (after build sip ) and build the
> > > > > package from
> > > > > master  .
> > > > > I'd like bring python-qt5 to epel7 , as explain in PR #3 [2]
> > > > > epel 6 for now is not in the plans .
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > [2]
> > > > > https://src.fedoraproject.org/rpms/sip/pull-request/3
> > > > > 
> > > > > I'd like have python-qt5 on epel7 to build openshot and
> > > > > probably other
> > > > > packages , for that I need sip
> > > > > 
> > > > > I tested in copr [1] and build openshot successfully  for
> > > > > epel6 we
> > > > > need phonon-qt5 and phonon-qt5-backend-gstreamer , but epel6
> > > > > doesn't
> > > > > have gstreame1 for backend package ...
> > > > > 
> > > > > 
> > > > > [1]
> > > > > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToP
> > > > > kgdb#How_do_I_request_commit_access_to_a_dist-git_repo.3F
> > > > > 
> > > > > How do I request commit access to a dist-git repo?
> > > > > 
> > > > > Email the packagename-ow...@fedoraproject.org alias asking to
> > > > > be given
> > > > > access, or file a bugzilla bug on the package asking for
> > > > > access.
> > > > > 
> > > > > 
> > > > > --
> > > > > Sérgio M. B.
> > > 
> > > -- 
> > > Sérgio M. B.
> > 
> > -- 
> > Sérgio M. B.
> 
> 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Looking for testers: Clamav 0.99.4 EL-6

[Sérgio Basto]

On Mon, 2018-03-12 at 17:30 -0400, Stephen John Smoogen wrote:
> There is a security update waiting in epel-testing for 0.99.4.
> 
> I have tested it in my setup and it looks to be working but it needs
> more testing
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7e91105260

BTW we also need karma for EL-7 please 

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aacf1b47d6

Thanks, 

> -- 
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: qt5 dependency problem

[Sérgio Basto]

On Sat, 2018-03-03 at 13:20 -0500, Christopher Brown wrote:
> On 02/24/2018 02:15 PM, Sérgio Basto wrote:
> > On Sat, 2018-02-24 at 17:45 +, Christopher Brown wrote:
> > > Hi,
> > > 
> > > In trying to install trojita, I got the following error:
> > > 
> > > $ sudo yum install trojita
> > > Loaded plugins: langpacks
> > > Resolving Dependencies
> > > --> Running transaction check
> > > ---> Package trojita.x86_64 0:0.7-4.el7 will be installed
> > > --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit)
> > > for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit)
> > > for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libQt5WebKit.so.5()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libmimetic.so.0()(64bit) for package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libqt5keychain.so.1()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Running transaction check
> > > ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed
> > > ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed
> > > ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> > > --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit)
> > > for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Positioning.so.5()(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Sensors.so.5()(64bit) for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be
> > > installed
> > > --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for
> > > package: qtkeychain-qt5-0.7.0-1.el7.x86_64
> > > --> Running transaction check
> > > ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> > > --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed
> > > --> Finished Dependency Resolution
> > > Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
> > > Requires: qt5-qtbase(x86-64) = 5.6.2
> > > Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl)
> > > qt5-qtbase(x86-64) = 5.6.1-10.el7
> > > Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
> > > Requires: qt5-qtdeclarative(x86-64) = 5.6.2
> > > Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64
> > > (@sl)
> > > qt5-qtdeclarative(x86-64) = 5.6.1-10.el7
> > >   You could try using --skip-broken to work around the problem
> > >   You could try running: rpm -Va --nofiles --nodigest
> > > $
> > > 
> > > ...Any suggestions?
> > 
> > mock -r epel-7-x86_64-rpmfusion_free --install trojita
> > 
> > works fine here, it  installs  qt5-qtdeclarative-5.6.2-1.el7  and
> >   qt5-qtbase-5.6.2-1.el7 from base repo
> > 
> > 
> > 
> 
> Thanks for the reply. But I already use epel and nux, and when I
> install 
> rpmfusion, I get many dependency errors reported for other packages.
> Is 
> there another yum way (I mean, aside from downloading the individual 
> packages and localinstall'ing them)?

yum distro-sync --disable-repo=nux

> Chris
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: qt5 dependency problem

[Sérgio Basto]

On Sat, 2018-02-24 at 17:45 +, Christopher Brown wrote:
> Hi,
> 
> In trying to install trojita, I got the following error:
> 
> $ sudo yum install trojita
> Loaded plugins: langpacks
> Resolving Dependencies
> --> Running transaction check
> ---> Package trojita.x86_64 0:0.7-4.el7 will be installed
> --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libQt5WebKit.so.5()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libmimetic.so.0()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libqt5keychain.so.1()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Running transaction check
> ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed
> ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed
> ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Positioning.so.5()(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Sensors.so.5()(64bit) for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be installed
> --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for
> package: qtkeychain-qt5-0.7.0-1.el7.x86_64
> --> Running transaction check
> ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed
> --> Finished Dependency Resolution
> Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
>Requires: qt5-qtbase(x86-64) = 5.6.2
>Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl)
>qt5-qtbase(x86-64) = 5.6.1-10.el7
> Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
>Requires: qt5-qtdeclarative(x86-64) = 5.6.2
>Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64 (@sl)
>qt5-qtdeclarative(x86-64) = 5.6.1-10.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> $ 
> 
> ...Any suggestions?


mock -r epel-7-x86_64-rpmfusion_free --install trojita 

works fine here, it  installs  qt5-qtdeclarative-5.6.2-1.el7  and 
 qt5-qtbase-5.6.2-1.el7 from base repo 



> Thanks,
> Chris
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Need to have some packages rebuilt in EPEL

[Sérgio Basto]

On Qua, 2017-04-19 at 15:16 -0600, Kevin Fenzi wrote:
> > 
> > ah , I built po4a to build dpkg on epel7 , but in fact po4a was
> > added
> > to centos 7 some moments before (I don't know if in RHEL7) 
> 
> It is. It's in rhel7-server-optional. Note that CentOS doesn't do any
> of
> the channel stuff, all of base, optional, etc all just are in their
> base
> repo IIRC.
> 
> 
> and that is
> > 
> > why it misses ppc64 arch [1] IIRC. BTW it also misses on ppc64,
> > perl-
> > gettext [2], maybe should be good also coordinate the fix of this
> > package too. 
> 
> Yeah, I started looking at the spec and saw that comment as well.
> 
> > 
> > If you could fix these 2 packages may the best is remove po4a from 
> > epel7 repo , if it is possible ... or bump epoch on RHEL7 ... 
> 
> Well, We can push out a lower version of the package, but people who
> already have the newer one installed will just still have that. It
> would
> fix new installs and the like though.
> 
> We definitely don't want to add an Epoch, because the idea is that we
> keep the EPEL package "older" than the RHEL one so people who install
> get the official one (if available on their arch).


I wrote my second reply before read this message anyway 
feel free to do anything with po4a.

Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Need to have some packages rebuilt in EPEL

[Sérgio Basto]

On Qua, 2017-04-19 at 12:03 -0600, Kevin Fenzi wrote:
> On 04/14/2017 12:05 PM, Stephen John Smoogen wrote:
> > 
> > OK something for people to help with:
> > 
> > There is a po4a package which over-rides the version that is in
> > RHEL-7
> > optional. It needs to be removed from EPEL and packages depending
> > on
> > it need to be rebuilt against the RHEL version with a bump in NEVR
> > get
> > pulled on updates.
> 
> Well, I filed:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1443685
> 
> Unfortunately to match the limited arch guidelines the package needs
> to
> be _older_ than it is now in epel.
> 
> I'm not sure if we can get yum to do the right thing and downgrade
> it,
> but we could try.


ah , I built po4a to build dpkg on epel7 , but in fact po4a was added
to centos 7 some moments before (I don't know if in RHEL7) and that is
why it misses ppc64 arch [1] IIRC. BTW it also misses on ppc64, perl-
gettext [2], maybe should be good also coordinate the fix of this
package too. 
If you could fix these 2 packages may the best is remove po4a from 
epel7 repo , if it is possible ... or bump epoch on RHEL7 ... 

Best regards, 

[1] 
https://src.fedoraproject.org/cgit/rpms/po4a.git/tree/po4a.spec#n79
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1196539

> kevin
> 
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Debian tools on epel7

[Sérgio Basto]

Hi, 
I build for  epel 7 several Debian tools that may allow build deb
packages, now I can build some debs  in epel 7, If someone is
interested in testing let me have some feedback .

po-debconf-1.0.16-8.nmu3.el7    
smokeqt-4.14.3-7.el7    
smokegen-4.14.3-6.el7   
perl-Qt-4.14.3-5.el7    
debconf-1.5.56-6.el7    
debhelper-9.20150628-4.el7  
dpkg-1.17.27-1.el7
perl-File-FcntlLock-0.22-6.el7  
perl-Mail-Box-2.120-2.el7   
perl-User-Identity-0.96-1.el7   
perl-Object-Realize-Later-0.19-6.el7    
perl-Mail-Transport-Dbx-0.07-28.el7 
perl-Geography-Countries-2009041301-17.el7
debmirror-2.16-4.el7
dh-make-1.20140617-2.el7
pbuilder-0.228.3-2.el7  
perl-Git-Wrapper-0.047-3.el7    
perl-Parse-DebControl-2.005-10.el7  
sensible-utils-0.0.9-5.el7  
devscripts-2.16.5-1.el7
dh-autoreconf-13-2.el7  
cdbs-0.4.150-3.el7  
po-debconf-1.0.16-9.nmu3.el7
debian-keyring-2014.3-4.el7 
jetring-0.25-2.el7  
keyrings-filesystem-1-6.el7

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d90518ab91
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a0a16db403
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-73abc671aa
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f883af5b55
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cababed3d2
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c837a68c52
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-43496f6ce3
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2ef0ea428d
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-788760d644

also we got alien 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bdf2b8d718

Cheers,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Perl packaging problem

[Sérgio Basto]

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 ? 

Thanks. 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: new DNF for everyone

[Sérgio Basto]

On Seg, 2016-08-29 at 18:06 +0200, Honza Silhan wrote:
> On Fri, Aug 26, 2016 at 9:39 PM, Orion Poplawski <or...@cora.nwra.com
> > wrote:
> 
> Hi,
> 
> > 
> > On 08/26/2016 12:26 PM, Sérgio Basto wrote:
> > > 
> > > On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > DNF is in EPEL for more than one year, unfortunately there was
> > > > still
> > > > the old
> > > > DNF-0.6.4
> > > > version. Over that time in DNF were implemented a lot of great
> > > > features and
> > > > plenty of bugs
> > > > have been fixed. DNF (especially its libraries) could not be
> > > > updated
> > > > in EPEL
> > > > repository
> > > > because of its policy. Now we have prepared fresh DNF-1.1.9 for
> > > > RHEL
> > > > 7 and
> > > > CentOS 7 users
> > > > in our COPR repository [1].
> > > > 
> > > > In order to install DNF follow the instructions here [2].
> > > > 
> > > 
> > > Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3"
> > > 
> > > dnf in epel it is a bit useless, it doesn't have copr plugin for
> > > example .
> > 
> > This is the problem:
> > 
> > Available Packages
> > hawkey.x86_64  0.5.8-2.git.0.202b194.el7  rhel-7-server-
> > rpms
> > hawkey.x86_64  0.6.3-4.el7rhel-7-server-
> > beta-rpms
> > libsolv.x86_64 0.6.11-1.el7   rhel-7-server-
> > rpms
> > libsolv.x86_64 0.6.20-5.el7   rhel-7-server-
> > beta-rpms
> > 
> > libsolv.x86_64   0.6.20-4.el7.centos
> > group_rpm-software-management-dnf-stack-el7
> > hawkey.x86_64 0.6.3-4.el7.centos
> > group_rpm-software-management-dnf-stack-el7
> > 
> > But it does like it will be possible to update dnf in EPEL7 when
> > EL7.3 comes
> > out with updated hawkey and libsolv.
> 
> yes, we will update it once RHEL7.3 is out.

https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/dnf-stack-el7/

works great btw 

> 
> Honza
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedorapr
> oject.org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: new DNF for everyone

[Sérgio Basto]

On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
> Hi,
> 
> DNF is in EPEL for more than one year, unfortunately there was still
> the old
> DNF-0.6.4
> version. Over that time in DNF were implemented a lot of great
> features and
> plenty of bugs
> have been fixed. DNF (especially its libraries) could not be updated
> in EPEL
> repository
> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL
> 7 and
> CentOS 7 users
> in our COPR repository [1].
> 
> In order to install DNF follow the instructions here [2].
> 

Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3" 

dnf in epel it is a bit useless, it doesn't have copr plugin for
example . 

> Honza
> 
> [1] https://copr.fedorainfracloud.org/coprs/g/rpm-software-management
> /dnf-stack-el7/
> [2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos
> -7/
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedorapr
> oject.org
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Python 2 macros on EL 6

[Sérgio Basto]

Hi, 
%{python2_sitelib} doesn't exist on epel6 ? 

from https://copr-be.cloud.fedoraproject.org/results/sergiomb/builds_fo
r_Stable_Releases/epel-6-i386/00173942-subdownloader/build.log.gz

I got: 
RPM build errors:
File must begin with "/": %{python2_sitelib}/subdownloader

which means %{python2_sitelib} is wasn't defined .

Thanks,
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] po4a problems

[Sérgio Basto]

Hi, epel List 
In bug 1134624 [1] someone asked to build po4a for EPEL 7.
I miss some reading and po4a is only need to be build for ppc64 ,
because in meantime CentOS built it, but only for epel 7 not for 6 and
according Dominik Mierzejewski on comment #23 ... is part of CentOS
main distribution, which is x86_64 only. So when packages came from
CentOS they are x86_64 only and this happens with po4a .
By guidelines in comment #34 , I shouldn't build it with a new version
which unfortunately happened, I built po4a-0.45 when CentOS build
po4a-0.44 , but in comment #39 I concluded that is a copy of Fedora
source which was completely out-date , so I think the best solution was
Centos updated it also . If not, we need remove po4a-0.45-3.el7 from
epel7 stable , which I haven't way/permissions to do it ... 
Suggestions please ? 

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1134624

Thanks,
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel