Re: Why doesn't iconv know ISO-8859-2 in rawhide?
Thanks Michael! Aha, it seems the rawhide buildroot from 6/23 still contained glibc with recommends on new package and not hard requires. I've explicitly added glibc-gconv-extra as a buildrequires for vim now - although as you told it is unnecessary right now, I guess it is a good thing to track what the package actually needs (dependencies can change with time, as I found out painfully over the years :D ). On 6/23/21 2:55 PM, Michael Catanzaro wrote: Hi Zdenek, See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ TL;DR: workaround is to manually install glibc-gconv-extra, but you shouldn't need to do anything really because this should already be fixed by having glibc depend on glibc-gconv-extra. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Banning bots from submitting automated koji builds
On June 22, 2021 1:26:30 PM UTC, "Miroslav Suchý" wrote: >Dne 20. 06. 21 v 10:42 Miro Hrončok napsal(a): >> Rather than "no bots allowed" policy, we might need a "bots that >violate our policies and guidelines or have a >> tendency to break things will be disabled until fixed" policy. > >Every bot has been written by somebody. 1) it should be always clear >who is responsible for the bot 2) The owner should >take conseq^H^H^H responsibility for it. I'd prefer this policy over an outright ban. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On June 24, 2021 6:08:17 PM UTC, "Zbigniew Jędrzejewski-Szmek" wrote: >On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: >> On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok >wrote: >> > >> > On 24. 06. 21 11:16, Tomas Tomecek wrote: >> > > ## Choosing git forge to host source-git repositories >> > > We need to find a home for all the source-git repositories. This >is >> > > actually a really hard task because we have many options >(github.com, >> > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or >> > > on-premise) and different expectations: some projects already >have >> > > repos set up on different platforms while Pagure is the primary >forge >> > > now. Since the CPE team is investigating GitLab as a forge, it's >even >> > > harder for us to figure out the primary forge. We may end up >> > > supporting both actually: pagure.io and gitlab.com. What are your >> > > thoughts on this topic? Would you prefer pagure.io or gitlab.com >> > > More info: >> > > * https://pagure.io/fedora-source-git/sig/issue/1 >> > > * https://pagure.io/fedora-source-git/sig/issue/7 >> > >> > I would expect that since the soruce git is just an intermediate >thing, >> > supporting "any forge" is nice to have, but hard. I'd start with >some common >> > options (Pagure + 1 other) and see where you'll get. >> >> Yep, that's exactly what I'd like us to do. As soon as we have the >> service which accepts processes events up and running, it shouldn't >be >> that hard to teach it new fedora-messaging messages or webhook >> payloads. >> >> > > ## High-level workflow proposal up for review >> > > Hunor proposed a high-level workflow linked below and I strongly >> > > recommend reading it. We have also started discussing many >details in >> > > the process, such as getting archives: should we generate one >from the >> > > source-git repo or use the official release archive from >upstream? >> > >> > One thing to consider is that the upstream tarballs might be >cryptographically >> > signed and packages should verify the signature in %prep. >> >> This is a very good point - in such a case, we should always pull the >> official upstream tarball instead of generating a new one downstream. > >Hmm, but how would that work? I thought that the whole point of >source-git is to build from a commit that contains some upstream >version + downstream patches + downstream distro config like the spec >file, >and that the build step of applying downstream patches just doesn't >exist. >If you reuse the upstream tarball, then by necessity those downstream >patches need to be serialized and applied on top like in dist-git. So >you lose the property that the checkout from version control is *the* >source you build, but you also lose the property that the source you >build is what was signed (since patches are applied). But if the tooling automatically creates the "correct" srpm for you (e.g. either upstream tarball + patches or a git tarball), then I'd consider that a valuable improvement already. Sure, it might not be perfect, but it would help. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" wrote: >On 24. 06. 21 23:07, Miroslav Suchý wrote: >> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): One thing to consider is that the upstream tarballs might be >cryptographically signed and packages should verify the signature in %prep. >>> This is a very good point - in such a case, we should always pull >the >>> official upstream tarball instead of generating a new one downstream >> >> Does it matter? If you are able to generate byte2byte identical >tarball then >> you can choose any of them. > >AFAIK git does not grantee to produce byte2byte identical archives >across >different versions of git, zlib, gzip etc. So even if upstream signs >the git >generated archive, generating a byte2byte identical one might be >tricky. Especially with xz, which iirc has reproducibility issues in parallel mode. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: help request: libksysguard build failure on Stream 8
On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote: > On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz > wrote: > > > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the > > > updated qt5 that is there. I am using what is in F34 for the update. > > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the > > > buildroot. > > > For libksysguard I believe I have all other dependencies built and in the > > > buildroot. > > > But it just keeps failing, despite everything I've tried.[1][2] > > > I get the same error on all arches. The same error on version 5.22.1, > > > 5.22.2 and even 5.21.4. > > > I've tried passing build parameters that I thought went along with the > > > error, but nothing changed. > > > > > > I think this is the critical error, but it's possible I'm wrong > > > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > .localalias.209]': > > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to > > > `std::filesystem::__cxx11::path::_M_split_cmpts()' > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > .localalias.209]': > > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to > > > > > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::files > > ys > > > tem::__cxx11::path > > > const&, std::filesystem::directory_options, std::error_code*)' > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': > > > /builddir/build/BUILD/libksysguard- > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > undefined reference to > > > `std::filesystem::__cxx11::directory_iterator::operator*() const' > > > /builddir/build/BUILD/libksysguard- > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > undefined reference to > > > `std::filesystem::__cxx11::directory_iterator::operator++()' > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > .localalias.209]': > > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to > > > `std::filesystem::status(std::filesystem::__cxx11::path const&)' > > > collect2: error: ld returned 1 exit status > > > > std::filesystem was originally added as an experimental extension to C++, > > and > > at first required explicitly linking with -lstdc++fs. GCC 9 removed the > > requirement for the additional link library [1], but RHEL 8's default > > compiler > > is GCC 8. Therefore, for EPEL 8, you would have to create a patch which > > adds > > stdc++fs to the target_link_libraries of the processcore target. > > > > [1] https://gcc.gnu.org/gcc-9/changes.html > > > > HTH, > > > > My cmake skills are not up to snuff. A little more help is needed. > I seems -lstdc++fs needs to be added at the end of the compile command > /usr/bin/c++ -lstdc++fs > instead of at the beginning or middle of the options > /usr/bin/c++ -lstdc++fs > > I can do that manually, and it compiles correctly. > > But getting cmake to do it, I'm clearly missing something. > Is there a cmake command line option to put -lstdc++fs at the end? > There are several cmake and cmake.in files. Would I put it in one, and if > so, what is the syntax? Add stdc++fs to the end of this list: https://github.com/KDE/libksysguard/blob/master/processcore/CMakeLists.txt#L29-L39 -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc. ___ 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
[Bug 1976029] New: perl-IPC-Shareable-1.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976029 Bug ID: 1976029 Summary: perl-IPC-Shareable-1.01 is available Product: Fedora Version: rawhide Status: NEW Component: perl-IPC-Shareable Keywords: FutureFeature, Triaged Assignee: spo...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 1.01 Current version/release in rawhide: 1.00-1.fc35 URL: http://search.cpan.org/dist/IPC-Shareable Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7130/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1976029] perl-IPC-Shareable-1.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976029 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/authors/id/M/MS/MSOUTH/IPC-Shareable-1.01.tar.gz to ./IPC-Shareable-1.01.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL 8 Next is now available
Howdy folks, On behalf of the EPEL Steering Committee, I'm happy to announce the availability of EPEL 8 Next. This is an additional repository that allows package maintainers to build against CentOS Stream 8 instead of RHEL 8. This is sometimes necessary when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL. You can read more about it in the wiki [0]. Special thanks goes out to the Fedora Release Engineering team for their help implementing this. [0] https://fedoraproject.org/wiki/EPEL_Next -- 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c4678a5e4b radare2-5.3.1-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-49226a1ff0 aom-3.1.1-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-92a8baa028 tor-0.3.5.15-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4d814b358 quassel-0.12.5-2.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1ad14f84b0 ansible-2.9.23-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing unrealircd-5.2.0.1-1.el7 Details about builds: unrealircd-5.2.0.1-1.el7 (FEDORA-EPEL-2021-8309c061ec) Open Source IRC server Update Information: UnrealIRCd 5.2.0.1 == This is a small update for the 5.2.0 release. In channels, spamfilters of type `p` were run instead of type `c`. Although this is not a major issue for many, as spamfilter are often placed on both (`pc`), there is now this dot release to make sure new installs don't have this bug. ChangeLog: * Wed Jun 16 2021 Robert Scheck 5.2.0.1-1 - Upgrade to 5.2.0.1 (#1972543) References: [ 1 ] Bug #1972543 - unrealircd-5.2.0.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1972543 ___ 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
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1837988 Christian Horn changed: What|Removed |Added CC||ch...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: help request: libksysguard build failure on Stream 8
On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz wrote: > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the > > updated qt5 that is there. I am using what is in F34 for the update. > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the > > buildroot. > > For libksysguard I believe I have all other dependencies built and in the > > buildroot. > > But it just keeps failing, despite everything I've tried.[1][2] > > I get the same error on all arches. The same error on version 5.22.1, > > 5.22.2 and even 5.21.4. > > I've tried passing build parameters that I thought went along with the > > error, but nothing changed. > > > > I think this is the critical error, but it's possible I'm wrong > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to > > `std::filesystem::__cxx11::path::_M_split_cmpts()' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to > > > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesys > > tem::__cxx11::path > > const&, std::filesystem::directory_options, std::error_code*)' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': > > /builddir/build/BUILD/libksysguard- > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > undefined reference to > > `std::filesystem::__cxx11::directory_iterator::operator*() const' > > /builddir/build/BUILD/libksysguard- > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > undefined reference to > > `std::filesystem::__cxx11::directory_iterator::operator++()' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to > > `std::filesystem::status(std::filesystem::__cxx11::path const&)' > > collect2: error: ld returned 1 exit status > > std::filesystem was originally added as an experimental extension to C++, > and > at first required explicitly linking with -lstdc++fs. GCC 9 removed the > requirement for the additional link library [1], but RHEL 8's default > compiler > is GCC 8. Therefore, for EPEL 8, you would have to create a patch which > adds > stdc++fs to the target_link_libraries of the processcore target. > > [1] https://gcc.gnu.org/gcc-9/changes.html > > HTH, > My cmake skills are not up to snuff. A little more help is needed. I seems -lstdc++fs needs to be added at the end of the compile command /usr/bin/c++ -lstdc++fs instead of at the beginning or middle of the options /usr/bin/c++ -lstdc++fs I can do that manually, and it compiles correctly. But getting cmake to do it, I'm clearly missing something. Is there a cmake command line option to put -lstdc++fs at the end? There are several cmake and cmake.in files. Would I put it in one, and if so, what is the syntax? Thanks 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
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021, at 5:22 PM, Miro Hrončok wrote: > On 24. 06. 21 23:07, Miroslav Suchý wrote: > > Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): > >>> One thing to consider is that the upstream tarballs might be > >>> cryptographically > >>> signed and packages should verify the signature in %prep. > >> This is a very good point - in such a case, we should always pull the > >> official upstream tarball instead of generating a new one downstream > > > > Does it matter? If you are able to generate byte2byte identical tarball > > then > > you can choose any of them. > > AFAIK git does not grantee to produce byte2byte identical archives across > different versions of git, zlib, gzip etc. So even if upstream signs the git > generated archive, generating a byte2byte identical one might be tricky. See also https://github.com/cgwalters/git-evtag ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On 24. 06. 21 23:07, Miroslav Suchý wrote: Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): One thing to consider is that the upstream tarballs might be cryptographically signed and packages should verify the signature in %prep. This is a very good point - in such a case, we should always pull the official upstream tarball instead of generating a new one downstream Does it matter? If you are able to generate byte2byte identical tarball then you can choose any of them. AFAIK git does not grantee to produce byte2byte identical archives across different versions of git, zlib, gzip etc. So even if upstream signs the git generated archive, generating a byte2byte identical one might be tricky. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a): One thing to consider is that the upstream tarballs might be cryptographically signed and packages should verify the signature in %prep. This is a very good point - in such a case, we should always pull the official upstream tarball instead of generating a new one downstream Does it matter? If you are able to generate byte2byte identical tarball then you can choose any of them. Miroslav ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Requesting missing devel packages: How to request one be put in RHEL 8 CRB
During our last round of proposals for solutions to missing devel packages, it was noted that EPEL and CentOS has very different documentation for requesting a package be put into RHEL 8.[1][2] I am betting that CentOS's documentation is correct. It was written after ours. When I was talking to the Red Hat people who know, it was noted that Red Hat has much better communication with the Fedora and CentOS communities than the EPEL community.[3] They wanted to start fixing that communication gap, and figured this would be a good way to start. So I'm asking Josh Boyer to answer this question on behalf of Red Hat. How would Red Hat like us, EPEL maintainers and developers, to request missing devel packages? (devel packages that are built at the same time as a released library in RHEL8, but not released in RHEL8. Such as lmdb-devel) If we follow Red Hat's procedure, what are the odds that the package will make it into RHEL 8 CRB? Thanks Troy Dawson [1] - https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F [2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages [3] - Yes, I write my emails here from my redhat email address, but I do not represent Red Hat in my EPEL capacities. ___ 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
Re: F35 Change: Node.js 16.x by default (System-Wide Change proposal)
I'm a little behind on this, but I've created side-tag
f35-build-side-42997 to perform any necessary nodejs-* rebuilds.
Currently I'm only aware of the `nodejs` and `R-V8` packages needing
to be rebuilt there. Most Node.js packages don't have a tight
dependency on the interpreter. If you have a package that needs to be
rebuilt against Node.js 16 (currently 16.4.0), please let me know
immediately, as well as whether you want me to rebuild it for you or
you will be doing it yourself in the side-tag.
On Thu, May 27, 2021 at 10:11 AM Stephen Gallagher wrote:
>
> Just a quick reminder, this switch will be occurring in a little over
> three weeks, so make sure to test your NPM packages with Node.js 16.x!
>
> On Thu, Apr 29, 2021 at 3:46 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Nodejs16
> >
> > == Summary ==
> > The latest release of Node.js to carry a 30-month lifecycle is the
> > 16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
> > will carry 16.x as the default Node.js interpreter for the system. The
> > 14.x and 12.x interpreters will remain available as non-default module
> > streams.
> >
> > == Owner ==
> > * Name: [[User:zvetlik| Zuzana Svetlikova]]
> > * Email: zsvet...@redhat.com
> > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > * Email: sgall...@fedoraproject.org
> > * Responsible SIG: Node.js SIG
> >
> >
> >
> > == Detailed Description ==
> > Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
> > install nodejs''' will give users nodejs-16.x and the matching npm
> > package.
> >
> > == Benefit to Fedora ==
> > Node.js is a popular server-side JavaScript engine. Keeping Fedora on
> > the latest release allows us to continue tracking the state-of-the-art
> > in that space. For those whose applications do not yet work with the
> > 16.x release, Fedora 35 will also have the 14.x and 12.x releases
> > available as selectable module streams.
> >
> > == Scope ==
> > * Proposal owners: The packages are already built for Fedora 33, 34
> > and 35 in a non-default module stream. On June 14th, 2021, the
> > nodejs-16.x packages will be built in the non-modular repository and
> > thus become the default in Fedora 35.
> >
> > * Other developers: Any developer with a package that depends on
> > Node.js at run-time or build-time should test with the 16.x module
> > stream enabled as soon as possible. Issues should be reported to
> > nod...@lists.fedoraproject.org
> >
> > * Release engineering: We will coordinate with the Node.js SIG to
> > create a side-tag to perform the rebuilds before making 16.x the
> > default.
> > * Policies and guidelines: N/A (not needed for this Change)
> > * Trademark approval: N/A (not needed for this Change)
> >
> >
> > == Upgrade/compatibility impact ==
> > As with previous releases, users running Fedora 33 or Fedora 34 with
> > the non-modular nodejs-14.x packages will be automatically upgraded to
> > the 16.x packages when they upgrade to Fedora 35, which may cause
> > issues. If users are running software known not to support Node.js
> > 16.x yet, they can switch the system to use 14.x with '''dnf module'''
> > commands.
> >
> > == How To Test ==
> > * Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
> > * Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
> > installed (non-modular) results in an upgrade to nodejs-16.x
> > * Confirm that upgrading from Fedora 33 or Fedora 34 with the
> > `nodejs:14` module enabled does *not* result in an upgrade to 16.x and
> > still has `nodejs:14` enabled on Fedora 35.
> > * Confirm that upgrading from Fedora 33 or Fedora 34 with the
> > `nodejs:16` module enabled upgrades successfully and still has
> > `nodejs:16` enabled on Fedora 33.
> >
> > == User Experience ==
> > Users will have the 16.x release of Node.js available by default. See
> > the "Upgrade/compatibility impact" section for specific details.
> >
> > == Dependencies ==
> > All packages prefixed with `nodejs-` depend on this package. If they
> > do not work with Node.js 16.x, they will need to be updated, made
> > modular and dependent upon the `nodejs:14` stream or else removed from
> > Fedora 35.
> >
> > Prior to the switchover date to Node.js 16.x as the default, packagers
> > are strongly encouraged to test their existing Node modules with 16.x
> > via the Modular version by running:
> >
> >
> > dnf module reset nodejs
> > dnf module install nodejs:16/development
> >
> >
> > Packagers can also test their builds using `mock` by creating the file
> > `/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
> > contents:
> >
> >
> > config_opts['target_arch'] = 'x86_64'
> > config_opts['legal_host_arches'] = ('x86_64',)
> > config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
> > config_opts['module_install'] = ['nodejs:16/development']
> >
> > include('templates/fedora-rawhide.tpl')
> >
> >
> > Then call
> >
> > mock -r
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: > On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok wrote: > > > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > > > ## Choosing git forge to host source-git repositories > > > We need to find a home for all the source-git repositories. This is > > > actually a really hard task because we have many options (github.com, > > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > > > on-premise) and different expectations: some projects already have > > > repos set up on different platforms while Pagure is the primary forge > > > now. Since the CPE team is investigating GitLab as a forge, it's even > > > harder for us to figure out the primary forge. We may end up > > > supporting both actually: pagure.io and gitlab.com. What are your > > > thoughts on this topic? Would you prefer pagure.io or gitlab.com > > > More info: > > > * https://pagure.io/fedora-source-git/sig/issue/1 > > > * https://pagure.io/fedora-source-git/sig/issue/7 > > > > I would expect that since the soruce git is just an intermediate thing, > > supporting "any forge" is nice to have, but hard. I'd start with some common > > options (Pagure + 1 other) and see where you'll get. > > Yep, that's exactly what I'd like us to do. As soon as we have the > service which accepts processes events up and running, it shouldn't be > that hard to teach it new fedora-messaging messages or webhook > payloads. > > > > ## High-level workflow proposal up for review > > > Hunor proposed a high-level workflow linked below and I strongly > > > recommend reading it. We have also started discussing many details in > > > the process, such as getting archives: should we generate one from the > > > source-git repo or use the official release archive from upstream? > > > > One thing to consider is that the upstream tarballs might be > > cryptographically > > signed and packages should verify the signature in %prep. > > This is a very good point - in such a case, we should always pull the > official upstream tarball instead of generating a new one downstream. Hmm, but how would that work? I thought that the whole point of source-git is to build from a commit that contains some upstream version + downstream patches + downstream distro config like the spec file, and that the build step of applying downstream patches just doesn't exist. If you reuse the upstream tarball, then by necessity those downstream patches need to be serialized and applied on top like in dist-git. So you lose the property that the checkout from version control is *the* source you build, but you also lose the property that the source you build is what was signed (since patches are applied). Zbyszek ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975266] perl-Graphics-TIFF-16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975266 --- Comment #5 from Fedora Update System --- FEDORA-2021-2df9389925 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2df9389925` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2df9389925 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1970380] Upgrade perl-Image-ExifTool to 12.26
https://bugzilla.redhat.com/show_bug.cgi?id=1970380 --- Comment #7 from Fedora Update System --- FEDORA-2021-ae3f5b1d01 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ae3f5b1d01` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ae3f5b1d01 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975873] perltidy-20210625 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975873 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perltidy-20210625-1.fc35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-06-24 17:29:49 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=70749086 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1959040] perl-HTTP-Message-6.30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1959040 --- Comment #6 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1936048] perl-HTTP-Message-6.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1936048 --- Comment #7 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1940699] perl-Net-HTTP-6.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1940699 --- Comment #13 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1936221] perl-libwww-perl-6.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1936221 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-libwww-perl-6.53-1.fc3 |perl-libwww-perl-6.53-1.fc3 |5 |5 ||perl-libwww-perl-6.48-34202 ||10615084339.93f36231 --- Comment #14 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1935417] perl-HTML-Parser-3.76 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1935417 --- Comment #6 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1930887] perl-HTTP-Message-6.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1930887 Fedora Update System changed: What|Removed |Added Resolution|NEXTRELEASE |ERRATA --- Comment #4 from Fedora Update System --- FEDORA-MODULAR-2021-05ccc9574c has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c4678a5e4b radare2-5.3.1-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-49226a1ff0 aom-3.1.1-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-92a8baa028 tor-0.3.5.15-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4d814b358 quassel-0.12.5-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing ansible-2.9.23-1.el7 java-latest-openjdk-16.0.1.0.9-3.rolling.el7 perl-Fsdb-2.74-1.el7 perl-Image-ExifTool-12.26-1.el7 python-dbutils-2.0.1-1.el7 python34-3.4.10-8.el7 tito-0.6.18-1.el7 Details about builds: ansible-2.9.23-1.el7 (FEDORA-EPEL-2021-1ad14f84b0) SSH-based configuration management, deployment, and task execution system Update Information: Upgrade to 2.9.23. Fixes CVE-2021-3583 ChangeLog: * Tue Jun 22 2021 Kevin Fenzi - 2.9.23-1 - Update to 2.9.23. Fixes rhbz#1974592 - Add patch for Rocky Linux. Fixes rhbz#1968728 * Mon May 24 2021 Kevin Fenzi - 2.9.22-1 - Update to 2.9.22. References: [ 1 ] Bug #1945983 - Ansible no longer converging on enabling firewalld ports https://bugzilla.redhat.com/show_bug.cgi?id=1945983 java-latest-openjdk-16.0.1.0.9-3.rolling.el7 (FEDORA-EPEL-2021-9b6a3a5183) OpenJDK 16 Runtime Environment Update Information: Various fixes (including rhbz#1971120) ChangeLog: * Thu Jun 17 2021 Petra Alice Mikova - 1:16.0.1.0.9-4.rolling - fix patch rh1648249-add_commented_out_nss_cfg_provider_to_java_security.patch which made the SunPKCS provider show up again - Resolves: rhbz#1971120 * Thu Apr 29 2021 Jiri Vanek - 1:16.0.1.0.9-2.rolling - adapted to debug handling in newer cjc - The rest of the "rpm 4.17" patch must NOT be backported, as on rpm 4.16 and down, it would casue double execution - Disable copy-jdk-configs for Flatpak builds References: [ 1 ] Bug #1971120 - SunPKCS11 provider is missing from java.security https://bugzilla.redhat.com/show_bug.cgi?id=1971120 perl-Fsdb-2.74-1.el7 (FEDORA-EPEL-2021-0ef10aab71) A set of commands for manipulating flat-text databases from the shell Update Information: See http://www.isi.edu/~johnh/SOFTWARE/FSDB/ ChangeLog: * Wed Jun 23 2021 John Heidemann 2.74-1 - See http://www.isi.edu/~johnh/SOFTWARE/FSDB/ perl-Image-ExifTool-12.26-1.el7 (FEDORA-EPEL-2021-084fd8b4b3) Utility for reading and writing image meta info Update Information: Update to 12.26, latest stable. ChangeLog: * Wed Jun 23 2021 Tom Callaway - 12.26-1 - update to latest stable (12.26) References: [ 1 ] Bug #1970380 - Upgrade perl-Image-ExifTool to 12.26 https://bugzilla.redhat.com/show_bug.cgi?id=1970380 python-dbutils-2.0.1-1.el7 (FEDORA-EPEL-2021-bb111dff9e) Tools providing solid, persistent and pooled connections to a database Update Information: Initial Release ChangeLog:
[Bug 1970380] Upgrade perl-Image-ExifTool to 12.26
https://bugzilla.redhat.com/show_bug.cgi?id=1970380 --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2021-084fd8b4b3 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-084fd8b4b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need assistance to build Blender
The “pyconfig.h” header lives in a python-version-specific subdirectory. Some
of the compiler invocations earlier in the build log contain
“-I/usr/include/python3.10”, but the one that is failing does not.
I haven’t tried it, but I would guess that something like the following would
resolve the problem. The libraries may or may not be necessary—I didn’t take
time to investigate.
--- blender-2.93.0-original/source/blender/io/usd/CMakeLists.txt
2021-04-21 10:23:41.0 -0400
+++ blender-2.93.0/source/blender/io/usd/CMakeLists.txt 2021-06-24
13:02:05.568490263 -0400
@@ -53,6 +53,7 @@
${USD_INCLUDE_DIRS}
${BOOST_INCLUDE_DIR}
${TBB_INCLUDE_DIR}
+ ${PYTHON_INCLUDE_DIRS}
)
set(SRC
@@ -86,6 +87,8 @@
list(APPEND LIB
${BOOST_LIBRARIES}
+ ${PYTHON_LINKFLAGS}
+ ${PYTHON_LIBRARIES}
)
list(APPEND LIB
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Bug 1970380] Upgrade perl-Image-ExifTool to 12.26
https://bugzilla.redhat.com/show_bug.cgi?id=1970380 --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2021-61fac447f9 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-61fac447f9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1970380] Upgrade perl-Image-ExifTool to 12.26
https://bugzilla.redhat.com/show_bug.cgi?id=1970380 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2021-f579bfac80 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f579bfac80` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f579bfac80 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975266] perl-Graphics-TIFF-16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975266 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2021-b4304b3d24 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b4304b3d24` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b4304b3d24 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1932205] perl-IPTables-libiptc-0.52-36.fc35 FTBFS: iptables-detect-version.c:65:2: warning: #warning "This version of xtables is currently not supported by this Perl package
https://bugzilla.redhat.com/show_bug.cgi?id=1932205 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-IPTables-libiptc-0.52- |perl-IPTables-libiptc-0.52- |37.fc35 |37.fc35 ||perl-IPTables-libiptc-0.52- ||37.fc34 Resolution|RAWHIDE |ERRATA --- Comment #4 from Fedora Update System --- FEDORA-2021-aa5ee7a292 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1972637] FTBFS with glibc-devel-2.33.9000-18.fc35: Installed (but unpackaged) file(s) found: /usr/lib64/perl5/features-time64.ph
https://bugzilla.redhat.com/show_bug.cgi?id=1972637 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-5.34.0-479.fc35|perl-5.34.0-479.fc35 |perl-5.32.1-476.fc34|perl-5.32.1-476.fc34 ||perl-5.32.1-470.fc33 --- Comment #5 from Fedora Update System --- FEDORA-2021-2eadd2c263 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Heads-up: python-sure 2.0.0 coming to Rawhide (minor API changes)
In one week, I will update python-sure to 2.0.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1974521). This includes the following breaking API change: > No longer patch the builtin `dir()` function, which fixes pytest in some cases such as projects using gevent. I do not think this update will have any consequences for other packages. Only python-httpretty, maintained by jpopelka, depends on this package, and it rebuilt successfully in a COPR (https://copr.fedorainfracloud.org/coprs/music/sure-2.0/builds/). ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire python2-setuptools
On 23. 06. 21 19:52, Miro Hrončok wrote: To compensate a rather ugly scriptlet is needed. The changes were proposed: https://src.fedoraproject.org/rpms/python-psutil/pull-request/10 https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1 The pull requests were adapted to include a less ugly workaround. The egg-info directory is artificially re-created during build. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire python2-setuptools
On 23. 06. 21 19:52, Miro Hrončok wrote: To compensate a rather ugly scriptlet is needed. The changes were proposed: https://src.fedoraproject.org/rpms/python-psutil/pull-request/10 https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1 The pull requests were adapted to include a less ugly workaround. The egg-info directory is artificially re-created during build. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975578] perl-Data-Dmp-0.241 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975578 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Data-Dmp-0.241-1.fc35 Resolution|--- |RAWHIDE Last Closed||2021-06-24 16:33:34 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Data-Dmp] PR #1: Tests
jplesnik merged a pull-request against the project: `perl-Data-Dmp` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-Data-Dmp/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
... I still don't understand what Frankenstein buildroot we are using. 2 lines in a mock file allow to be aware of modules... modules=1 ... config_opts['module_enable'] = ['php:7.4', ... 2h of work to find the proper configuration and I was able to build such packages since the day RHEL-8-Beta was made publicly available, in May 2018... 3 years ago and still waiting for something to happen in EPEL Maybe allow some spec switch to do that? But it is noobs suggestion based on not-knwoing. It is easy to do this in a mock. It isn't easy to do this in koji and or mbs because they assume they 'built' everything they are going to use to build other things. This means we either have to build all of RHEL with the Fedora koji/mbs packages so they 'understand' what is there.. or you have to come up with some sort of hack which does something like this: 1. koji/mbs create the mock.cfg file and start setting up a buildroot on a builder. 2. your script rewrites the mock.cfg with the config items and fake koji/mbs into everything is ok. 3. koji/mbs continues the build The problems with this method are the following: 1. You have to hand edit the script to know what modules are being used and for when. 2. You have to hope that 2 doesn't get abused in multiple ways 3. It is kludgy and breaks a lot so you end up doing a 'repeat build until either fail_counter=X || build_complete' 4. You end up needing to do this separately from the regular Fedora koji/mbs because if you can do this in one build root, you can do it in all.. The way EPEL is set up is a third way which is a 'best of worst worlds' method: 1. You download RHEL packages into a repository 2. You run a demodularizer which breaks apart the modules into a one tree. You have to be careful because some modules conflict so you only do the ones which are 'Default' or in CodeReady If I take look to my error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Then from thsi demodualrize-explaining sentence I would guess, that I'm useing jsut wrong versions . I already tried to play with various BuildRequires xyz > or < a.b but mostly did it just worse. In addition, I had failed to search koji/centos builder for this dependence checks and was moreover blindly shooting. thoughts? Thanx a lot for all the inputs! 3. You rebuild this into a single repository 4. koji looks at this as an external repository like it has done from EPEL-5 days. This uses a method which was meant for just kickstarting a build tree by having an external tree to point to but works for RHEL. Koji tries to deal with this but it causes issues 5. mbs still only knows how to use modules it built itself.. This means that the external modules in RHEL are invisible to it. This is what breaks it from being able to build PHP modules. In the end, the core problem is that we are (ab)using the koji/mbs build structure to do things it was never intended to do. It has been made to do it, but deep down it is like making pizza on a shovel at a blacksmith.. you can do it but neither the forge or the shovel were meant for this and you end up constantly trying to figure out how to remove coal tar from the food. Ex: https://rpms.remirepo.net/temp/epel-temp.repo And mock configuration https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg Remi ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: libmemcached-awesome (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/libmemcached-awesome == Summary == Switch from libmemcached to libmemcached-awesome == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == libmemcache 1.0.18 was released in February 2014, so hasn't received an update for 7 years. libmemcache-awesome is a fork providing same libraries, tools with API/ABI compatibility. == Benefit to Fedora == Rely on a maintained project. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * install and play with your application == User Experience == Developers and system administrators will have the great benefit or running a maintained library. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * [https://awesomized.github.io/libmemcached/ Upstream documentation] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210624.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/199 (x86_64), 12/134 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210623.n.0): ID: 915304 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/915304 ID: 915315 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/915315 ID: 915329 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/915329 ID: 915348 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/915348 ID: 915420 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/915420 ID: 915448 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/915448 ID: 915476 Test: x86_64 universal install_delete_pata **GATING** URL: https://openqa.fedoraproject.org/tests/915476 ID: 915558 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/915558 ID: 915561 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/915561 ID: 915585 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/915585 Old failures (same test failed in Fedora-Rawhide-20210623.n.0): ID: 915306 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/915306 ID: 915312 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/915312 ID: 915357 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/915357 ID: 915395 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/915395 ID: 915429 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/915429 ID: 915431 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/915431 ID: 915435 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/915435 ID: 915436 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/915436 ID: 915437 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/915437 ID: 915562 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/915562 Soft failed openQA tests: 3/199 (x86_64), 3/134 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210623.n.0): ID: 915375 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/915375 ID: 915382 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/915382 ID: 915439 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/915439 ID: 915465 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/915465 ID: 915474 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/915474 ID: 915504 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/915504 Passed openQA tests: 105/134 (aarch64), 188/199 (x86_64) New passes (same test not passed in Fedora-Rawhide-20210623.n.0): ID: 915433 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/915433 ID: 915472 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/915472 ID: 915486 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/915486 ID: 915491 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/915491 ID: 915507 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/915507 ID: 915553 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/915553 ID: 915566 Test: aarch64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/915566 Skipped non-gating openQA tests: 14 of 333 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.23 to 0.10 Previous test data:
F35 Change: libmemcached-awesome (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/libmemcached-awesome == Summary == Switch from libmemcached to libmemcached-awesome == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == libmemcache 1.0.18 was released in February 2014, so hasn't received an update for 7 years. libmemcache-awesome is a fork providing same libraries, tools with API/ABI compatibility. == Benefit to Fedora == Rely on a maintained project. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * install and play with your application == User Experience == Developers and system administrators will have the great benefit or running a maintained library. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * [https://awesomized.github.io/libmemcached/ Upstream documentation] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need assistance to build Blender
On 24. 06. 21 17:30, Scott Talbert wrote: On Thu, 24 Jun 2021, Luya Tshimbalanga wrote: Hello team, I am not sure why Blender failed to build recently. It seems some changes in the repository affect the buildand I am unable to find the cause. Can someone investigate please? The build in question is on https://download.copr.fedorainfracloud.org/results/luya/blender-egl/fedora-rawhide-x86_64/02297108-blender/ Looks like you might need to BuildRequire: python3-devel. Already does: BuildRequires: pkgconfig(python3) >= 3.7 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975873] perltidy-20210625 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975873 --- Comment #1 from Upstream Release Monitoring --- Unable to resolve the hostname for one of the package's Source URLs -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975873] New: perltidy-20210625 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975873 Bug ID: 1975873 Summary: perltidy-20210625 is available Product: Fedora Version: rawhide Status: NEW Component: perltidy Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 20210625 Current version/release in rawhide: 20210402-2.fc35 URL: http://search.cpan.org/dist/Perl-Tidy/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3553/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975580] perl-XXX-0.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975580 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need assistance to build Blender
On Thu, 24 Jun 2021, Luya Tshimbalanga wrote: Hello team, I am not sure why Blender failed to build recently. It seems some changes in the repository affect the buildand I am unable to find the cause. Can someone investigate please? The build in question is on https://download.copr.fedorainfracloud.org/results/luya/blender-egl/fedora-rawhide-x86_64/02297108-blender/ Looks like you might need to BuildRequire: python3-devel. Scott ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Data-Dmp] PR #1: Tests
jplesnik opened a new pull-request against the project: `perl-Data-Dmp` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Data-Dmp/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Need assistance to build Blender
Hello team, I am not sure why Blender failed to build recently. It seems some changes in the repository affect the buildand I am unable to find the cause. Can someone investigate please? The build in question is on https://download.copr.fedorainfracloud.org/results/luya/blender-egl/fedora-rawhide-x86_64/02297108-blender/ Thanks in advance -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Heads-up: python-starlette 0.15.0 coming to Rawhide (minor API changes)
In one week, I will update python-starlette to 0.15.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1975613). This includes some minor API changes; please see the release notes at https://github.com/encode/starlette/releases/tag/0.15.0. The following packages depend on this package, with maintainers in parentheses: • python-authlib (v02460) • python-databases (music) • python-fastapi (music); FTBFS due to dependency problems since Python 3.10 (https://bugzilla.redhat.com/show_bug.cgi?id=1968972) Maintainers of potentially-affected packages should have received this email directly. I have rebuilt all packages in a COPR (https://copr.fedorainfracloud.org/coprs/music/starlette-0.15/) without incident (except the pre-existing python-fastapi FTBFS), so I think no changes to dependent packages will be required. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire python2-setuptools
On Thu, Jun 24, 2021 at 02:13:03AM -0400, Nico Kadel-Garcia wrote: > On Thu, Jun 24, 2021 at 12:52 AM Kevin Fenzi wrote: > > > > On Wed, Jun 23, 2021 at 08:52:02PM -0400, Nico Kadel-Garcia wrote: > > ...snip... > > > > > > I see that the ansible SRPM in rawhide has already discarded any > > > support for python2, so that cannot be easily backported to RHEL 7 > > > with continuing use of python2. Our friends doing EPEL support will > > > have to either do considerable work to continue python2 support, say > > > with "pyp2rpm", or cooperate with the switch to python3. > > > > The epel7 ansible (classic/2.9) builds both python2 and python2 > > versions, you can use whatever one you prefer. The epel7 branch has just > > diverged from rawhide. It's also as up to date as rawhide is version > > wise. > > Exactly. It's had to be diverged. And they're not identical versions, > epel7 has 2.9.21, and Fedora 34 has 2.9.23. Both git branches should have the same version? Where do you see 2.9.21? > > I guess I don't understand what your concern is here... if we required > > rawhide to build for all targets, why do we have branches at all? > > I'm suggesting that we avoid making things more difficult if we don't need to. But we did need to. One spec file that works for epel7/epel8/fedora when we were switching fedora to python3 and some versions had python2 and some python3 and some both and some couldn't build docs due to some package versions and some had to exclude some tests due to some versions became too complex. It was much easier and clearer to diverge branches and only have the needed items for each branch. > > To me it's a balancing act... some level of conditional is worth it to > > allow rawhide's spec to work on other branches, but when it reaches a > > level where it's confusing, it's better to break the relationship and > > let branches diverge to handle their branch/target only. > > Sure. I'm suggesting that there is a risk and difficulty to abandoning > python2-setuptools. I'm still not sure I follow why you think so. If epel branches still use/need it, maintainers can either add conditionals and share a spec file or diverge branches if they need to. Either way, the issue is solved? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1974093] perl-Module-CoreList-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974093 --- Comment #3 from Fedora Update System --- FEDORA-2021-ee3a08c3c6 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ee3a08c3c6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee3a08c3c6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1974101] perl-CPAN-Perl-Releases-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974101 --- Comment #3 from Fedora Update System --- FEDORA-2021-d660cbdfae has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d660cbdfae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d660cbdfae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, 24 Jun 2021 at 10:03, Remi Collet wrote: > > Le 24/06/2021 à 15:33, Matthew Miller a écrit : > > On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: > >> P.S. yes, I'm really disappointed by how Fedora evolves, > >> not being able to use a proper build system (modules aware) > > > > If you could wave a magic wand here, what would a proper build system look > > like? > > I'm fine with current tooling (Koji) > > I only like to be able to build additional packages for existing modules > (e.g. php extensions in EPEL for php streams in RHEL) so > in some new module (php-extras) or better in the same one (php) > > In short being able to run "fedpkg module build" from > https://src.fedoraproject.org/modules/php-extras/tree/7.3 > (work is ready for months) > > I still don't understand what Frankenstein buildroot we are using. > > 2 lines in a mock file allow to be aware of modules... > > modules=1 > ... > config_opts['module_enable'] = ['php:7.4', ... > > 2h of work to find the proper configuration and > I was able to build such packages since the day RHEL-8-Beta > was made publicly available, in May 2018... 3 years ago > and still waiting for something to happen in EPEL > It is easy to do this in a mock. It isn't easy to do this in koji and or mbs because they assume they 'built' everything they are going to use to build other things. This means we either have to build all of RHEL with the Fedora koji/mbs packages so they 'understand' what is there.. or you have to come up with some sort of hack which does something like this: 1. koji/mbs create the mock.cfg file and start setting up a buildroot on a builder. 2. your script rewrites the mock.cfg with the config items and fake koji/mbs into everything is ok. 3. koji/mbs continues the build The problems with this method are the following: 1. You have to hand edit the script to know what modules are being used and for when. 2. You have to hope that 2 doesn't get abused in multiple ways 3. It is kludgy and breaks a lot so you end up doing a 'repeat build until either fail_counter=X || build_complete' 4. You end up needing to do this separately from the regular Fedora koji/mbs because if you can do this in one build root, you can do it in all.. The way EPEL is set up is a third way which is a 'best of worst worlds' method: 1. You download RHEL packages into a repository 2. You run a demodularizer which breaks apart the modules into a one tree. You have to be careful because some modules conflict so you only do the ones which are 'Default' or in CodeReady 3. You rebuild this into a single repository 4. koji looks at this as an external repository like it has done from EPEL-5 days. This uses a method which was meant for just kickstarting a build tree by having an external tree to point to but works for RHEL. Koji tries to deal with this but it causes issues 5. mbs still only knows how to use modules it built itself.. This means that the external modules in RHEL are invisible to it. This is what breaks it from being able to build PHP modules. In the end, the core problem is that we are (ab)using the koji/mbs build structure to do things it was never intended to do. It has been made to do it, but deep down it is like making pizza on a shovel at a blacksmith.. you can do it but neither the forge or the shovel were meant for this and you end up constantly trying to figure out how to remove coal tar from the food. > Ex: > https://rpms.remirepo.net/temp/epel-temp.repo > And mock configuration > https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg > > > > Remi > ___ > devel mailing list -- devel@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/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 BBS... time to reboot. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975578] perl-Data-Dmp-0.241 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1975578 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Le 24/06/2021 à 15:33, Matthew Miller a écrit : On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: P.S. yes, I'm really disappointed by how Fedora evolves, not being able to use a proper build system (modules aware) If you could wave a magic wand here, what would a proper build system look like? I'm fine with current tooling (Koji) I only like to be able to build additional packages for existing modules (e.g. php extensions in EPEL for php streams in RHEL) so in some new module (php-extras) or better in the same one (php) In short being able to run "fedpkg module build" from https://src.fedoraproject.org/modules/php-extras/tree/7.3 (work is ready for months) I still don't understand what Frankenstein buildroot we are using. 2 lines in a mock file allow to be aware of modules... modules=1 ... config_opts['module_enable'] = ['php:7.4', ... 2h of work to find the proper configuration and I was able to build such packages since the day RHEL-8-Beta was made publicly available, in May 2018... 3 years ago and still waiting for something to happen in EPEL Ex: https://rpms.remirepo.net/temp/epel-temp.repo And mock configuration https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg Remi ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 1:01 PM PGNet Dev wrote: > > On 6/24/21 6:40 AM, Miro Hrončok wrote: > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > >> ## Choosing git forge to host source-git repositories > >> We need to find a home for all the source-git repositories. This is > >> actually a really hard task because we have many options (github.com, > >> gitlab.com, pagure.io, src.fedoraproject.org, something custom or > >> on-premise) and different expectations: some projects already have > >> repos set up on different platforms while Pagure is the primary forge > >> now. Since the CPE team is investigating GitLab as a forge, it's even > >> harder for us to figure out the primary forge. We may end up > >> supporting both actually: pagure.io and gitlab.com. What are your > >> thoughts on this topic? Would you prefer pagure.io or gitlab.com > >> More info: > >> * https://pagure.io/fedora-source-git/sig/issue/1 > >> * https://pagure.io/fedora-source-git/sig/issue/7 > > Indirectly related: > > my scm-sourced COPR projects often pull from git repos (upstream @ Fedora src > projects), and use forgemeta macros in rpm config. > > ime, forgemeta had lots of issues in the past with gitlab source matching > when pulling specific tags/commits, requiring customized source strings -- > usually after a bunch of trial-n-error. > > github & pagure had no such problems. > > to work around the challenges, I 1st mirrored gitlab repos to pagure, then > pulled from there in my COPR specs, originally specifying commits/tags. > > I haven't revisited gitlab for a fairly long while to check again. > > Neither have I tested forgemeta's newer support for packaging a branch state > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_branch_example > > which is now available, stable & terribly convenient -- for github & pagure. > > TL;DR in this particular case: as long as it plays nicely with COPR forgemeta > source-reference macros, no preference Thank you for your suggestion! I don't have any experience with those macros myself so can't comment. I created an issue for us to investigate further: https://pagure.io/fedora-source-git/sig/issue/12 > ___ > devel mailing list -- devel@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-34-20210624.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210623.0): ID: 915604 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/915604 ID: 915608 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/915608 ID: 915610 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/915610 ID: 915617 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/915617 ID: 915621 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/915621 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210623.0): ID: 915599 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/915599 Passed openQA tests: 13/16 (x86_64), 12/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.18 to 0.07 Previous test data: https://openqa.fedoraproject.org/tests/914966#downloads Current test data: https://openqa.fedoraproject.org/tests/915594#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok wrote: > > On 24. 06. 21 11:16, Tomas Tomecek wrote: > > ## Choosing git forge to host source-git repositories > > We need to find a home for all the source-git repositories. This is > > actually a really hard task because we have many options (github.com, > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > > on-premise) and different expectations: some projects already have > > repos set up on different platforms while Pagure is the primary forge > > now. Since the CPE team is investigating GitLab as a forge, it's even > > harder for us to figure out the primary forge. We may end up > > supporting both actually: pagure.io and gitlab.com. What are your > > thoughts on this topic? Would you prefer pagure.io or gitlab.com > > More info: > > * https://pagure.io/fedora-source-git/sig/issue/1 > > * https://pagure.io/fedora-source-git/sig/issue/7 > > I would expect that since the soruce git is just an intermediate thing, > supporting "any forge" is nice to have, but hard. I'd start with some common > options (Pagure + 1 other) and see where you'll get. Yep, that's exactly what I'd like us to do. As soon as we have the service which accepts processes events up and running, it shouldn't be that hard to teach it new fedora-messaging messages or webhook payloads. > > ## High-level workflow proposal up for review > > Hunor proposed a high-level workflow linked below and I strongly > > recommend reading it. We have also started discussing many details in > > the process, such as getting archives: should we generate one from the > > source-git repo or use the official release archive from upstream? > > One thing to consider is that the upstream tarballs might be cryptographically > signed and packages should verify the signature in %prep. This is a very good point - in such a case, we should always pull the official upstream tarball instead of generating a new one downstream. Miro, thank you for your insights! Tomas > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 3:39 PM Ben Cotton wrote: > > Hi Tomas, > > This is great. Do you mind if I republish this in the Fedora Community > Blog? https://communityblog.fedoraproject.org Go for it, Ben :) My inspiration for the report comes from the Q1 update of the CentOS Hyperscale SIG: https://blog.centos.org/2021/04/centos-hyperscale-sig-quarterly-report/ I also like these condensed reports where one knows what the project is up to within a few minutes. Thank you for reaching out! Tomas > (Replying on-list to encourage others to submit this kind of content > to the CommBlog and to read it, too) > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Path-Tiny] PR #1: Remove runtime depencendy for Digest::MD5
pghmcfc merged a pull-request against the project: `perl-Path-Tiny` that you are following. Merged pull-request: `` Remove runtime depencendy for Digest::MD5 `` https://src.fedoraproject.org/rpms/perl-Path-Tiny/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20210619.n.0 changes
> > > > What *is* the purpose of RH Container Bot? A google search shows various > repos seemingly used by it, but why and how? > I had set it up to package and push updates to repos under https://github.com/containers . The gitlab job can be found here: https://gitlab.com/rhcontainerbot/pkg-builder/-/tree/rawhide . Jobs have been disabled now. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
Hi Tomas, This is great. Do you mind if I republish this in the Fedora Community Blog? https://communityblog.fedoraproject.org (Replying on-list to encourage others to submit this kind of content to the CommBlog and to read it, too) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20210619.n.0 changes
> > > * Sat Jun 19 2021 RH Container Bot > - 0.7.8-2.dev.git5f666c1 > > - bump to 0.7.8 > > - autobuilt 5f666c1 > I swear ... is rhcontainerbot at it again? > https://pagure.io/fesco/issue/2624 > > Both of those look like obvious mistakes, since they're not just > "versioning snafu"s but real version downgrades. > > This happened due to the branch rename from master to main. I'll fix this asap. Anyway, I have disabled autobuilds and we'll be switching to packit soon anyway. Sorry about that. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: > P.S. yes, I'm really disappointed by how Fedora evolves, > not being able to use a proper build system (modules aware) If you could wave a magic wand here, what would a proper build system look like? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Thu, Jun 24, 2021 at 11:16:11AM +0200, Tomas Tomecek wrote: > Greetings from the Fedora source-git SIG! We are planning to start > publishing reports of what we are working on so everyone can easily > pay attention and get involved if interested. If you have any ideas, > comments or requests, don’t be shy and let us know :) Awesome -- I appreciate summary reports like this _so much_. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jun 24, 2021 at 9:09 AM Remi Collet wrote: > > Le 23/06/2021 à 10:57, Nico Kadel-Garcia a écrit : > > > I can't find *anyone* who likes modularity. > > I like modules ! > > BTW > > Community have killed SCL > Community is killing modules > Software Collections made the assumption that packager ergonomics did not matter. That is obviously patently false. Today, I could probably come up with an implementation of SCLs that is more packager-friendly by leveraging the existing abstractions in RPM and macros. We actually do this for Flatpak builds, so it's not a foreign concept. Conceptually, I like modules. However, after doing work to implement modularity in a build system, I want a better version of it. I'm not sure that will happen anytime soon, though. > EPEL-8 is IMHO partially broken, > and perhaps should be consider as dead. > > > > I'm devoutly hoping that it is discarded for RHEL 9. > > I rather hope than EPEL-9 will be better > and available for "Beta" time. > > > Remi > > > P.S. yes, I'm really disappointed by how Fedora evolves, > not being able to use a proper build system (modules aware) > in 2 years, while everyone else seems to be able to > do it quite shortly (CentOS, Alma, Rocky, Oracle...) The amount of cursing I've heard from the developers of all of those distributions over the modularity implementation should not be ignored. Every one of those did it because Red Hat did it, and I've advised a fair number of them on how to do it. At least one of them considered deviating from RHEL to get rid of it because the implementation is terrible. Among distribution tooling developers, the current modularity implementation is nearly universally hated. It makes assumptions about what kind of access the build system has, is deeply tied into Koji+MBS, has poor local build support, and the modulemd formats weren't designed for outside use in mind (assumptions around dist-git, commitish, direct access to cherry-pick from Koji, etc.). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Le 23/06/2021 à 10:57, Nico Kadel-Garcia a écrit : I can't find *anyone* who likes modularity. I like modules ! BTW Community have killed SCL Community is killing modules EPEL-8 is IMHO partially broken, and perhaps should be consider as dead. > I'm devoutly hoping that it is discarded for RHEL 9. I rather hope than EPEL-9 will be better and available for "Beta" time. Remi P.S. yes, I'm really disappointed by how Fedora evolves, not being able to use a proper build system (modules aware) in 2 years, while everyone else seems to be able to do it quite shortly (CentOS, Alma, Rocky, Oracle...) ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Path-Tiny] PR #1: Remove runtime depencendy for Digest::MD5
mspacek commented on the pull-request: `Remove runtime depencendy for Digest::MD5` that you are following: `` Yes, that's true, thanks. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Path-Tiny/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Banning bots from submitting automated koji builds
On Tue, Jun 22, 2021 at 04:48:26PM -0700, Adam Williamson wrote: > Matthew was referring to a plan (AIUI) to have two locations where > "Rawhide" composes would be synced, one where all completed composes > would be synced (as today), one where only composes that passed gating > would be synced. I don't recall this plan, and don't know what happened > to it, but that's what the idea was, I think. Yes, that was it. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning rubygem-fssm
Hi, I'm orphaning rubygem-fssm, since I don't have any use for this package. It appears to be abandoned upstream, so probably better to let it go completely. Vít ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On 6/24/21 6:40 AM, Miro Hrončok wrote: On 24. 06. 21 11:16, Tomas Tomecek wrote: ## Choosing git forge to host source-git repositories We need to find a home for all the source-git repositories. This is actually a really hard task because we have many options (github.com, gitlab.com, pagure.io, src.fedoraproject.org, something custom or on-premise) and different expectations: some projects already have repos set up on different platforms while Pagure is the primary forge now. Since the CPE team is investigating GitLab as a forge, it's even harder for us to figure out the primary forge. We may end up supporting both actually: pagure.io and gitlab.com. What are your thoughts on this topic? Would you prefer pagure.io or gitlab.com More info: * https://pagure.io/fedora-source-git/sig/issue/1 * https://pagure.io/fedora-source-git/sig/issue/7 Indirectly related: my scm-sourced COPR projects often pull from git repos (upstream @ Fedora src projects), and use forgemeta macros in rpm config. ime, forgemeta had lots of issues in the past with gitlab source matching when pulling specific tags/commits, requiring customized source strings -- usually after a bunch of trial-n-error. github & pagure had no such problems. to work around the challenges, I 1st mirrored gitlab repos to pagure, then pulled from there in my COPR specs, originally specifying commits/tags. I haven't revisited gitlab for a fairly long while to check again. Neither have I tested forgemeta's newer support for packaging a branch state https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_branch_example which is now available, stable & terribly convenient -- for github & pagure. TL;DR in this particular case: as long as it plays nicely with COPR forgemeta source-reference macros, no preference ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On 24. 06. 21 11:16, Tomas Tomecek wrote: ## Choosing git forge to host source-git repositories We need to find a home for all the source-git repositories. This is actually a really hard task because we have many options (github.com, gitlab.com, pagure.io, src.fedoraproject.org, something custom or on-premise) and different expectations: some projects already have repos set up on different platforms while Pagure is the primary forge now. Since the CPE team is investigating GitLab as a forge, it's even harder for us to figure out the primary forge. We may end up supporting both actually: pagure.io and gitlab.com. What are your thoughts on this topic? Would you prefer pagure.io or gitlab.com More info: * https://pagure.io/fedora-source-git/sig/issue/1 * https://pagure.io/fedora-source-git/sig/issue/7 I would expect that since the soruce git is just an intermediate thing, supporting "any forge" is nice to have, but hard. I'd start with some common options (Pagure + 1 other) and see where you'll get. ## High-level workflow proposal up for review Hunor proposed a high-level workflow linked below and I strongly recommend reading it. We have also started discussing many details in the process, such as getting archives: should we generate one from the source-git repo or use the official release archive from upstream? One thing to consider is that the upstream tarballs might be cryptographically signed and packages should verify the signature in %prep. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME on Wayland does not work on latest Rawhide
* Florian Weimer: > We could use some basic GNOME SHell debugging help here. Ideally, we'd > like to run GNOME Shell in such a way that it does not perform X > fallback and does not re-exec itself, and uses a specified VT (so that > we can launch it over an SSH session). > > (This is about bug 1974970.) I got what I need. Now to deciphering dynamic loader code. 8-/ Thanks, Florian ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210624.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210623.0): ID: 915159 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/915159 ID: 915168 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/915168 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora Source-git SIG report #1 (June 2021)
Greetings from the Fedora source-git SIG! We are planning to start publishing reports of what we are working on so everyone can easily pay attention and get involved if interested. If you have any ideas, comments or requests, don’t be shy and let us know :) Here’s a short list of things which we are working on. ## Choosing git forge to host source-git repositories We need to find a home for all the source-git repositories. This is actually a really hard task because we have many options (github.com, gitlab.com, pagure.io, src.fedoraproject.org, something custom or on-premise) and different expectations: some projects already have repos set up on different platforms while Pagure is the primary forge now. Since the CPE team is investigating GitLab as a forge, it's even harder for us to figure out the primary forge. We may end up supporting both actually: pagure.io and gitlab.com. What are your thoughts on this topic? Would you prefer pagure.io or gitlab.com More info: * https://pagure.io/fedora-source-git/sig/issue/1 * https://pagure.io/fedora-source-git/sig/issue/7 ## High-level workflow proposal up for review Hunor proposed a high-level workflow linked below and I strongly recommend reading it. We have also started discussing many details in the process, such as getting archives: should we generate one from the source-git repo or use the official release archive from upstream? Another big topic in terms of workflows are rebases (= updates to the latest upstream release, which are very common in Rawhide). Rebases are straightforward in dist-git, but when your source-git repo has complete upstream git history, they are no longer trivial, especially if one wants to get a review of a rebase. More info: * https://pagure.io/fedora-source-git/sig/issue/2 * Workflow proposal: https://pagure.io/fedora-source-git/docs/pull-request/2 * https://pagure.io/fedora-source-git/docs/blob/main/f/resources/CommitRules.pdf * https://pagure.io/fedora-source-git/sig/issue/8 ## Tooling Packit is the tooling which will be used to work with source-git repos. No surprise there I assume :D * https://packit.dev/ We've done a lot of work here lately, mainly to polish the process of creating source-git repos and doing updates of dist-git repositories based on the source-git content. * https://packit.dev/docs/source-git/work-with-source-git/ * https://github.com/packit/packit/releases ## Interested? We meet biweekly on Wednesdays via gmeet, 2:30 - 3:30 UTC, next one is scheduled for July 7th. * https://calendar.fedoraproject.org/SIGs/2021/7/5/#m9982 Everyone is welcome to join the SIG or provide any feedback on the issues and PRs above. You can always find the latest information over here: * https://fedoraproject.org/wiki/SIGs/Source-git * https://pagure.io/fedora-source-git/sig/issues I'd like to thank all the SIG members for being so active, so happy to work with all of you! Cheers, Tomas ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME on Wayland does not work on latest Rawhide
We could use some basic GNOME SHell debugging help here. Ideally, we'd like to run GNOME Shell in such a way that it does not perform X fallback and does not re-exec itself, and uses a specified VT (so that we can launch it over an SSH session). (This is about bug 1974970.) Thanks, Florian ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1975700] New: start_server (or Server::Starter) should depend on Net::Server::SS::PreFork
https://bugzilla.redhat.com/show_bug.cgi?id=1975700
Bug ID: 1975700
Summary: start_server (or Server::Starter) should depend on
Net::Server::SS::PreFork
Product: Fedora
Version: 34
Status: NEW
Component: perl-Server-Starter
Severity: low
Assignee: rc040...@freenet.de
Reporter: k...@fi.muni.cz
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
Target Milestone: ---
Classification: Fedora
Description of problem:
The start_server script uses Net::Server::SS::PreFork personality of
Net::Server, so it should explicitly depend on it.
Version-Release number of selected component (if applicable):
perl-Server-Starter-0.35-5.fc34.noarch
perl-Server-Starter-start_server-0.35-5.fc34.noarch
How reproducible:
Steps to Reproduce:
1. yum -y install perl-Server-Starter-start_server perl-Starman
2. cat > app.psgi <<'EOF'
#!/usr/bin/perl
use strict;
my $app = sub {
my $env = shift;
return [
'200',
[ 'Content-Type' => 'text/plain' ],
[ "Hello World\n" ], # or IO::Handle-like object
];
};
EOF
3. start_server --port 0.0.0.0:5000 -- starman --workers 4 app.psgi
Actual results:
start_server (pid:5091) starting now...
starting new worker 5092
Can't locate Net/Server/SS/PreFork.pm in @INC (you may need to install the
Net::Server::SS::PreFork module) (@INC contains: /usr/local/lib64/perl5/5.32
/usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at
/usr/share/perl5/vendor_perl/Plack/Handler/Starman.pm line 14.
new worker 5092 seems to have failed to start, exit status:512
Expected results:
starman should be up and running
Additional info:
The dependency on Net::Server::SS::PreFork is described here:
https://metacpan.org/pod/Server::Starter
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Bug 1965763] perl-ExtUtils-CppGuess-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1965763 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-ExtUtils-CppGuess-0.23 ||-1.fc35 Resolution|--- |ERRATA Last Closed||2021-06-24 08:35:12 --- Comment #7 from Fedora Update System --- FEDORA-2021-d361222110 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1965763] perl-ExtUtils-CppGuess-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1965763 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #6 from Fedora Update System --- FEDORA-2021-d361222110 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d361222110 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210624.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210623.0): ID: 915143 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/915143 ID: 915152 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/915152 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Dne 23. 06. 21 v 19:34 Joan Moreau via devel napsal(a): Hello How can I move forward on this ? You have to address the issues in comment #1 of https://bugzilla.redhat.com/show_bug.cgi?id=1953340#c1 And iterate until you get APPROVED comment and flag fedora-review+ And now, how to get things moving ? Isnt' there just a repo where to push the RPM ? (similar to Arch) thank you so much Untill you get your package to Fedora stable you can use Copr https://copr.fedorainfracloud.org/ which has no barrier. Miroslav ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Path-Tiny] PR #1: Remove runtime depencendy for Digest::MD5
ppisar commented on the pull-request: `Remove runtime depencendy for Digest::MD5` that you are following: `` I also recommend moving "BuildRequires: perl(Digest::MD5)" from "Module Runtime" to "Test Suite" section in the spec file. In the end, that's the reason for the explicit "use Digest:MD5" at t/digest.t:11. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Path-Tiny/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] 389 DS nightly 2021-06-24 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/06/24/report-389-ds-base-2.0.6-20210624gitc0ca290ff.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire python2-setuptools
On Thu, Jun 24, 2021 at 12:52 AM Kevin Fenzi wrote: > > On Wed, Jun 23, 2021 at 08:52:02PM -0400, Nico Kadel-Garcia wrote: > ...snip... > > > > I see that the ansible SRPM in rawhide has already discarded any > > support for python2, so that cannot be easily backported to RHEL 7 > > with continuing use of python2. Our friends doing EPEL support will > > have to either do considerable work to continue python2 support, say > > with "pyp2rpm", or cooperate with the switch to python3. > > The epel7 ansible (classic/2.9) builds both python2 and python2 > versions, you can use whatever one you prefer. The epel7 branch has just > diverged from rawhide. It's also as up to date as rawhide is version > wise. Exactly. It's had to be diverged. And they're not identical versions, epel7 has 2.9.21, and Fedora 34 has 2.9.23. > I guess I don't understand what your concern is here... if we required > rawhide to build for all targets, why do we have branches at all? I'm suggesting that we avoid making things more difficult if we don't need to. > To me it's a balancing act... some level of conditional is worth it to > allow rawhide's spec to work on other branches, but when it reaches a > level where it's confusing, it's better to break the relationship and > let branches diverge to handle their branch/target only. Sure. I'm suggesting that there is a risk and difficulty to abandoning python2-setuptools. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
