[EPEL-devel] Re: Qt update and packages rebuild
As I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c11 I did not know that epel packages are used also in CentOS Stream, sometimes causing issues like the one previously mentioned. In fact this behaviour obliges epel maintainers that wanted to maintain RHEL only, to work to maintain CentOS Stream too. This an additional source of troubles for package maintainers ___ 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: Qt update and packages rebuild
There hasn't been a qt update in CentOS Stream 8 or 9 since May 2022, so you'll have to give more information. I double checked and I found out the origin of my misunderstanding. I wrote everything in this comment https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c8 ___ 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: Qt update and packages rebuild
any update on this matter? A few days ago I got another bugreport concerning CentOS Stream Qt update breaking an application ___ 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: failed build of kernel 4.x for EL7
A colleague suggested me to use http://elrepo.org/tiki/kernel-ml so I no longer need help for the Copr build. Best regards ___ 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] failed build of kernel 4.x for EL7
Good day, on Fedora Copr I am trying to build kernel 4.x [1] for EL7. The problem is that the build [2] fails on "No Package found for llvm-toolset-7.0" I checked the srpm and devtoolset for llvm are present and also enabled (line 1110), so I really wonder what is wrong. Thank you for your help [1]: https://vault.centos.org/7.9.2009/updates/Source/SPackages/kernel-4.18.0-348.20.1.el7.src.rpm [2]: https://copr.fedorainfracloud.org/coprs/germano/kernel_4.x_for_centos_7/build/4436937/ ___ 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: Qt update and packages rebuild
Il 29/04/22 21:42, Troy Dawson ha scritto:
On Fri, Apr 29, 2022 at 11:28 AM Germano Massullo
wrote:
Recent CentOS Stream Qt update broke some EPEL packages like
keepassxc
that needed a rebuild against the new Qt version.
Can we talk about a way to prevent this from happening again?
Best regards
Looking at keepassxc specifically, I'd say take the following line
out of the spec file.
%{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
If you let rpmbuild figure out the dependencies (which it is already
doing fairly well), then it will know when there is a real ABI change
and you need to rebuild the package.
Looking at
"dnf repoquery --requires keepassxc | grep -i qt"
and then looking at the changes that happened in qt5, it looks like it
wouldn't have needed a rebuild if the Requires wasn't manually set.
I'm not saying rpmbuild is 100% perfect for figuring out requires, but
in this case it was doing it right.
That macro is needed to avoid situations where users somehow manage to
install keepassxc on a system with old Qt version like in following
bugreport
https://bugzilla.redhat.com/show_bug.cgi?id=2068981___
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] Qt update and packages rebuild
Recent CentOS Stream Qt update broke some EPEL packages like keepassxc that needed a rebuild against the new Qt version. Can we talk about a way to prevent this from happening again? Best regards [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2077742 ___ 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] apcupsd now available on EPEL 8
Good day, package "apcupsd" (client for APC Uninterruptible Power Supply) is now available on EPEL 8. So if you own such UPS and an Enterprise Linux 8 workstation you can enjoy using this service. Best regards ___ 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] boinc-tui available
Good day, BOINC Text User Interface is now available on EPEL 7 and 8, so you can better manage BOINC client on headless systems. Just install boinc-tui package and enjoy! P.S. you may want to join BOINC volunteers to help scientific research against COVID19. More informations at https://boinc.bakerlab.org/ ___ 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: yum does not find a package that I submitted to EPEL7 stable
Il 25/03/2018 00:24, Jason L Tibbitts III ha scritto: > The package should appear in the repositories with the next EPEL7 > compose. > > - J< > Thank you Jason, when next EPEL7 compose will happen? ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] yum does not find a package that I submitted to EPEL7 stable
I released open-eid as a new package in epel7-testing [1], but when I run # yum --enablerepo=epel-testing install open-eid I obtain various message like Error: Package: webextension-token-signing-1.0.6-4.el7.x86_64 (epel-testing) Requires: esteidcerts but esteidcerts package is in EPEL7 *stable* repositories [2], so why do I get such message? Best regards [1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e7b4a7b2ad [2]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7d396fb6e6 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: darktable / EPEL / SL7
Il 03/01/2018 10:25, Anssi Johansson ha scritto: > Please upgrade to SL 7.4 and see if the problems persist. darktable in > EPEL was compiled in RHEL 7.4. Exactly! // darktable co-maintainer here :-) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Desktop application major update (darktable)
https://bugzilla.redhat.com/show_bug.cgi?id=1381507#c9 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Desktop application major update (darktable)
Other feedbacks? ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Desktop application major update (darktable)
Il 25/10/2016 19:07, Kevin Fenzi ha scritto: > Well, we need more information (or at least I do): > > * Is 1.x still supported by upstream? No > * is 1.x still supported by anyone else (rhel, other lts distros, > people you could work with on backporting fixes). I don't think so, and I have never seen a new 1.x release since darktable 2.x has been released > * Are there any known 1.x security issues? No > * Is the upgrade from 1.x to 2.x transparent for the user? ie, would > they have to do any manual steps to move config? or is that all done > by the application? No action is required by the user > * Is the "user experence" different between 1.x and 2.x? It is almost the same, even if there are more features on 2.x ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Announce owncloud-client 2.x in epel7
Hi, I would like to inform you that the first build of owncloud-client is going to be pushed in testing repositories. So I am glad that people who use EPEL7 on their machine can now benefit of that great piece of software that owncloud is. Have a nice day ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Please test Darktable 2.0.1 for inclusion in EPEL7
Just fixed the problem (thank you Rex Dieter) and built 2.0.3 https://copr.fedorainfracloud.org/coprs/germano/Darktable_2.0_release_candidate/build/172878/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]Re: TexLive
Il 23/11/2015 23:22, R P Herrold ha scritto: > On Sat, 21 Nov 2015, Germano Massullo wrote: > >> Did you try to ask them to include all TeXLive packages that are >> available from upstream? If not, I can try > there are lots of licenses to audit, per sub-package, and > dependency trees of matter limited to non-commercial and so > forth > > -- Russ herrold You can simply re use the collection of texlive-scheme-full for Fedora (non EPEL) ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]Re: TexLive
Il 21/11/2015 04:56, Orion Poplawski ha scritto: > On 11/20/2015 03:51 AM, Germano Massullo wrote: >> I saw https://admin.fedoraproject.org/pkgdb/package/texlive/ that there >> is not texlive for EPEL7. >> But in a CentOS 7 installation, if I do "yum search texlive" you get >> many packages. They have been simply automatically ported from the EPEL >> 6 repos? Why are them so less in amount, compared to the Fedora >> texlive-full-scheme? > > The main texlive package lives in RHEL. For RHEL7 they stripped out a > lot of packages, which made a lot of people (including myself) > unhappy. A couple have been added to RHEL7.2, but now there is also > texlive-extension in EPEL7 which provides some (but not all) of the > missing packages. Did you try to ask them to include all TeXLive packages that are available from upstream? If not, I can try ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]TexLive
I saw https://admin.fedoraproject.org/pkgdb/package/texlive/ that there is not texlive for EPEL7. But in a CentOS 7 installation, if I do "yum search texlive" you get many packages. They have been simply automatically ported from the EPEL 6 repos? Why are them so less in amount, compared to the Fedora texlive-full-scheme? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] Darktable major update
Il 09/11/2015 21:46, Stephen John Smoogen ha scritto: > On 9 November 2015 at 13:30, Germano Massullo > <germano.massu...@gmail.com> wrote: >> Hi, I am one of the Darktable maintainers. >> Darktable 2.0 is going too be released soon. According to EPEL policies, I >> could not release such major release for EPEL/RHEL 7. >> Do you usually apply this rule strictly or sometimes you make an exception? >> New version of Darktable will rely on GTK3, but concerning the remaining >> libraries, there will not be a great change. >> >> > My usual decision tree on upgrades are: > 1) Does upstream have a LTS edition? > 2) Does the application upgrade itself cleanly? > > If they have an LTS version, then I prefer that is what is in EPEL > versus other tools. If they do not and they only fix the latest > version then that usually means pushing to the newest semi long term > version. > > The next point is if the application upgrades itself cleanly or not. > If an app can see the old configs and just go "ok I know that this > works this way etc etc." then it can be easily upgraded in EPEL. If it > doesn't then it comes down to how much pain will users and the > developer have if it stays on an old version. > > Sometimes the answer is that the product just doesn't belong in EPEL > at all. Sometimes it means that you have to push to a newer version > with notification to various lists that the pain train is coming and > if you use the old version of the package expect some problems. > 1) No 2) Yes but once you open (with the 2.0 version) the XMP files attached to your photos, you cannot open them again with the older 1.6.x version, because the software updates those files to the newer format. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Darktable major update
Hi, I am one of the Darktable maintainers. Darktable 2.0 is going too be released soon. According to EPEL policies, I could not release such major release for EPEL/RHEL 7. Do you usually apply this rule strictly or sometimes you make an exception? New version of Darktable will rely on GTK3, but concerning the remaining libraries, there will not be a great change. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
