Re: Orphaned packages looking for new maintainers
On 2021-04-15 at 06:54 CEST, Miroslav Suchý wrote... Dne 12. 04. 21 v 18:32 Miro Hrončok napsal(a): cura-lulzbot orphan, spot 6 weeks ago fedora-jam-kde-theme jvlomax, orphan 0 weeks ago gnome-desktop alexl, caolanm, fmuellner, gnome-sig, 0 weeks ago orphan, rhughes How this can happen? I.e., orphaned package with one or more co-maintainers. This is definitively repetitive pattern. I wonder whether we have some process problem? Why the main admin does not ask co-maintainers first? And if they are not interested in, why they are still listed as co-maintainers? There're few problems which may cause that: 1) There is (was?) bug in pagure which allows any Fedora package to orphan any package in the distribution. 2) Some co-maintainers clicked "orphan" button to drop themself from the list of the maintainers but this button deletes silently main admin. 3) No notification was sent to co-maintainers in case if main admin orphaned the package. In case of (1) or (2) main admin is not being notified (happened to me once and I realized my package was orphaned by email from bugzilla (so if there're no bugs opened - the package may be silently orphaned). I think email to -owners@ at least should fix this issue. 4) Package may be orphaned by the team of maintainers (SIG) if all of them work in one team (SIG). 5) Main-admin does not have time for Fedora, he doesn't want to spend time to contact other people :( 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 -- Pavel ___ 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: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)
Dne 10. 04. 21 v 19:33 Fabio Valentini napsal(a): I have created the missing bodhi updates where the packagers obviously just forgot to file one, or missed the announcement of the updates-testing activation point (i.e. builds for f35 and f34 (and sometimes f33 or even f32) exist, but no bodhi update for f34 was created). We should advertise bodhi activation point more aggressively. I filed https://github.com/fedora-infra/bodhi/issues/4207 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
Re: Orphaned packages looking for new maintainers
Dne 12. 04. 21 v 18:32 Miro Hrončok napsal(a): cura-lulzbot orphan, spot 6 weeks ago fedora-jam-kde-theme jvlomax, orphan 0 weeks ago gnome-desktop alexl, caolanm, fmuellner, gnome-sig, 0 weeks ago orphan, rhughes How this can happen? I.e., orphaned package with one or more co-maintainers. This is definitively repetitive pattern. I wonder whether we have some process problem? Why the main admin does not ask co-maintainers first? And if they are not interested in, why they are still listed as co-maintainers? 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
Re: Mock fedora-34-x86_64 on Fedora 34 beta broken
Dne 14. 04. 21 v 17:50 Joe Doss napsal(a): Hey devel, Is anyone else getting this issue on Fedora 34 beta when using mock with the fedora-34-x86_64 chroot? mock -r fedora-33-x86_64 shell works just fine on Fedora 34 beta. Also mock -r fedora-34-x86_64 shell works on Fedora 33. What is the best way to troubleshoot this? I already nuked all the containers and repulled them. I can reproduce it as well. I filed https://github.com/rpm-software-management/mock/issues/720 The workaround is: Either use |config_opts['use_bootstrap_image'] = False| or |--no-bootstrap-image| Thank you for the report. 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
[Bug 1949736] perl-Geo-ShapeFile-3.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949736 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Geo-ShapeFile-3.01-1.fc32.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=65954772 -- 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 1949736] perl-Geo-ShapeFile-3.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949736 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1772007 --> https://bugzilla.redhat.com/attachment.cgi?id=1772007=edit [patch] Update to 3.01 (#1949736) -- 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 1949736] New: perl-Geo-ShapeFile-3.01 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949736 Bug ID: 1949736 Summary: perl-Geo-ShapeFile-3.01 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Geo-ShapeFile Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.01 Current version/release in rawhide: 3.00-6.fc34 URL: http://search.cpan.org/dist/Geo-ShapeFile/ 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/2921/ -- 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: F35 liburing dependent packages require rebuild
Forwarding to the devel@ list since the entire conversation was using the wrong address (just noticed the mail bouncing). Best, Michel On Wed, 2021-04-14 at 10:17 +0100, Richard W.M. Jones wrote: > On Wed, Apr 14, 2021 at 10:03:46AM +0100, Stefan Hajnoczi wrote: > > Hi, > > liburing upstream has released 2.0. It is source-compatible with > > liburing 0.7 but the size of several structs in has > > changed. Packages that depend on liburing must be rebuilt in > > rawhide. > > > > I have created a side tag containing liburing 2.0 here: f35-build- > > side-39896 > > > > If you maintain a package that depends on liburing, please rebuild > > your package with fedpkg build --target=f35-build-side-39896 and > > reply > > to this email. When all dependent packages have been rebuilt an > > update > > will be pushed. > > > > The list of dependent packages is: > > > > ceph > > glusterfs > > folly > > mpd > > qemu > > samba > > Don't worry everyone, I'll deal with them. > > Rich. > > > This is my first time dealing with a library change that requires > > dependent packages to be rebuilt. Please let me know if I'm doing > > something wrong. > > > > Thank you! > > > > Stefan > -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ 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
[Help needed] Possible change from gcc failed both openxr and luxcorerender
Due to a possible change related to GCC, packages like openxr and luxcorereneder failed to build with these errors: /tmp/ccHa7xrs.ltrans2.ltrans.o: in function `RuntimeManifestFile::CreateIfValid(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, std::vectorstd::default_delete >, std::allocatorstd::default_delete > > >&)': :(.text+0x3b56): undefined reference to `std::experimental::filesystem::v1::current_path[abi:cxx11]()' /usr/bin/ld: :(.text+0x3ba6): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x3bc6): undefined reference to `std::experimental::filesystem::v1::canonical(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::__cxx11::path const&)' /usr/bin/ld: /tmp/ccHa7xrs.ltrans2.ltrans.o: in function `CheckAllFilesInThePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, bool, std::vector, std::allocator >, std::allocatorstd::char_traits, std::allocator > > >&)': :(.text+0x7da5): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x7dad): undefined reference to `std::experimental::filesystem::v1::status(std::experimental::filesystem::v1::__cxx11::path const&)' /usr/bin/ld: :(.text+0x7e9b): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x7eac): undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::directory_iterator(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::directory_options, std::error_code*)' /usr/bin/ld: :(.text+0x7f52): undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator*() const' /usr/bin/ld: :(.text+0x8033): undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator++()' /usr/bin/ld: /usr/bin/ld: DWARF error: invalid abstract instance DIE ref /tmp/ccHa7xrs.ltrans3.ltrans.o: in function `FileSysUtilsGetAbsolutePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, std::__cxx11::basic_string, std::allocator >&)': :(.text+0x15d7): undefined reference to `std::experimental::filesystem::v1::current_path[abi:cxx11]()' /usr/bin/ld: :(.text+0x1626): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x163e): undefined reference to `std::experimental::filesystem::v1::absolute(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::__cxx11::path const&)' /usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function `FileSysUtilsCombinePaths(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator >&) [clone .isra.0]': :(.text+0x1f05): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x1f69): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x1fc4): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function `FileSysUtilsGetParentPath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, std::__cxx11::basic_string, std::allocator >&) [clone .isra.0]': :(.text+0x234d): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x235d): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::parent_path() const' /usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function `FileSysUtilsIsAbsolutePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&) [clone .isra.0]': :(.text+0x25fd): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x2605): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::has_root_directory() const' /usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function `FileSysUtilsPathExists(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&) [clone .isra.0]': :(.text+0x271d): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' /usr/bin/ld: :(.text+0x2725): undefined reference to `std::experimental::filesystem::v1::status(std::experimental::filesystem::v1::__cxx11::path const&)' collect2: error: ld returned 1 exit status gmake[2]: *** [src/loader/CMakeFiles/openxr_loader.dir/build.make:273: src/loader/libopenxr_loader.so.1.0.15] Error 1 gmake[2]: Leaving directory '/builddir/build/BUILD/OpenXR-SDK-Source-release-1.0.15/x86_64-redhat-linux-gnu' gmake[1]: *** [CMakeFiles/Makefile2:338: src/loader/CMakeFiles/openxr_loader.dir/all]
Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)
Sorry for not responding to this in my previous reply. On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote: > I wanted to investigate this, but unfortunately, it's hard to check > right now, because all builds are non-reproducible (in the sense of > reproducible-builds.org), because we include the mtime of build > products in rpm metadata, so pretty much all binary rpms are > different. I'm thinking this isn't that important. In most current RPMs, the mtimes for files are in two places: 1. In the (main) rpm header 2. in the cpio header for the file in the payload. I can talk about the effect on RPMCow: the mtime isn't part of the identity of the file - it's just a content hash. When the files are actually installed, then the resulting inode is touch'ed to the right time. Therefore I think it's moot (MOOt?) from a CoW perspective, the reuse can happen. Matthew. ___ 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: F35 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote: > Unfortunately this doesn't work for two important cases: > - when a binary or shared library has been replaced on disk. E.g. > it is fairly common for packages to crash on upgrade, and the crash > could be in the _old_ code. When the metadata is loaded in a section, > we get it all nice and dandy in the coredump. If it's in an xattr, > we don't or even worse, get outdated info. That's fair - if it were possible to get an fd during dump, we could use fgetxattr. If not, we can use /proc/$pid/exe - even when deleted you can interact with it: [malmond@malmond-x1 ~]$ ls -l /proc/$$/exe lrwxrwxrwx. 1 malmond malmond 0 Apr 14 15:45 /proc/364665/exe -> '/home/malmond/testbash (deleted)' [malmond@malmond-x1 ~]$ attr -l /proc/$$/exe Attribute "selinux" has a 54 byte value for /proc/364665/exe (this is me copying bash, executing it, then deleting it). My thinking is this could go in systemd-coredump as it's invoked when dumping core anyway. Libraries are accessible from /proc/$pid/map_files/$range. > - it doesn't work for non-rpm stuff. I'm confused about this - I had put forth an idea for how to make rpm create this when installing packages (so it works with older or third party packages) but the same xattr could be created for any packaging system. Can you clarify what is rpm dependent here? Matthew. ___ 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
[389-devel] please review: Issue 4169 - UI - Migrate Replication tables to PF4
https://github.com/389ds/389-ds-base/pull/4722 -- 389 Directory Server Development Team ___ 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
[Bug 1949266] Please build perl-Email-Valid for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1949266 Tom "spot" Callaway changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Doc Type|--- |If docs needed, set a value Last Closed||2021-04-14 21:56:43 --- Comment #1 from Tom "spot" Callaway --- perl-Email-Valid has been in EPEL8 for two months now: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b314160e0b -- 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 1947324] Upgrade perl-SQL-Abstract-Limit to 0.143
https://bugzilla.redhat.com/show_bug.cgi?id=1947324 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2021-aa5d1e7730 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aa5d1e7730 -- 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: Announcing creation of Fedora Source-git SIG
On Wed, Apr 14, 2021 at 04:19:29PM +0100, Daniel P. Berrangé wrote: > One example approach to source-git I've used... > > Rather than having source-git branch names matching dist-git, > use a different naming convention that is based off the upstream > version primarily. > > eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33' > branch, and if I rebase Fedora to v1.2, then I'd just switch to > using a v1.2-f33 branch instead. The v1.0-f33 history remains > intact forever, no force push required to rebase to new version. As a concrete example, this is how the Fedora OCaml repo works (with a different naming convention): https://pagure.io/fedora-ocaml/branches?branchname=master Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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 Linux 34 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 34. Tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 34 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 22 April in #fedora-meeting-1. We will aim for the "target date #1" milestone of 27 April. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist [2] https://calendar.fedoraproject.org/meeting/9957/?from_date=2021-04-22 [3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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
[Test-Announce] Fedora Linux 34 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 34. Tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 34 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 22 April in #fedora-meeting-1. We will aim for the "target date #1" milestone of 27 April. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist [2] https://calendar.fedoraproject.org/meeting/9957/?from_date=2021-04-22 [3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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/test-annou...@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: Announcing creation of Fedora Source-git SIG
On 14.04.21 10:45, Tomas Tomecek wrote: > Good morning, I'd like to announce the creation of Fedora Source-git SIG: > https://fedoraproject.org/wiki/SIGs/Source-git > > Our main goal in the SIG right now is to establish a development > workflow for Fedora Linux packages using repositories with sources and > upstream history (this is what we call source-git), instead of just > distribution files with links to tarballs (dist-git). Just wondering: will there be some coordination with the Fedora kernel developers that are relying on a git based workflow since a few weeks now (for rawhide even longer)? To those who don't know: all the stuff in dist-git kernel is generated from https://gitlab.com/cki-project/kernel-ark these days afaik, so it might be wise to make sure the solution you work out works for them as well. Especially as I find find some parts of how they do it a bit questionable. The main tarball they use as Source0 for example doesn't match the tarball downloadable from kernel.org(¹); all the patches are stashed into one(²); patches for fedora specific stuff (like the configs needed for building the kernel) are in the same branch as the patches(³). I think that makes things quite confusing, especially for outsiders. Sometimes I wonder if some of what the kernel people do violates the Fedora Packaging Guidelines(⁴), but the kernel-ark people ensured me it's fine. CU, knurd (¹) https://src.fedoraproject.org/rpms/kernel/blob/f33/f/sources for example states: > SHA512 (linux-5.11.14.tar.xz) = > ccf0eaf6df0dacd2984c361621f67a3d16cf7a7174155ebdf646f1acfec43e19ff942e6c17e5bc3b5dc7a300c32bdc6ee37877162c099f5bd9924244f9445467 But: $ wget --quiet https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.14.tar.xz $ sha512sum linux-5.11.14.tar.xz 8dfc7ff184e5cb33fff74686071f1605f3a834669e201d272f3047aa00657339ec1a3cfd605d8761b8a0f335b8488c02c701e72ed30031856e9c154aa1ff2d88 linux-5.11.14.tar.xz (²) https://src.fedoraproject.org/rpms/kernel/blob/f33/f/patch-5.11-redhat.patch FWIW, links to the individual patches can be found here: https://src.fedoraproject.org/rpms/kernel/blob/f33/f/Patchlist.changelog (³) for example https://gitlab.com/cki-project/kernel-ark/-/commits/fedora-5.11 (⁴) like this part "sources used to build a package should be the vanilla sources available from upstream. To help reviewers and QA scripts verify this, the packager needs to indicate where a reviewer can find the source that was used to make the rpm". The quote is from here: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ ___ 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: Github Action for discovering active Fedora Releases
On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz wrote: > > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher napisał(a): > > Since I figured it might be useful to others, I have made it available > > publicly. See the Marketplace link[1] for usage examples. > > > > [1] https://github.com/marketplace/actions/get-fedora-releases > > #v+ > name: Get Fedora Releases > runs-on: ubuntu-latest > #v- > Yeah, the irony isn't lost on me, but it's the only Linux container host Github currently offers. ___ 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 1949641] New: perl-Net-DAVTalk-0.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949641 Bug ID: 1949641 Summary: perl-Net-DAVTalk-0.20 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Net-DAVTalk Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.20 Current version/release in rawhide: 0.19-4.fc34 URL: http://search.cpan.org/dist/Net-DAVTalk/ 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/12559/ -- 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: Github Action for discovering active Fedora Releases
Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher napisał(a): > Since I figured it might be useful to others, I have made it available > publicly. See the Marketplace link[1] for usage examples. > > [1] https://github.com/marketplace/actions/get-fedora-releases #v+ name: Get Fedora Releases runs-on: ubuntu-latest #v- :-) -- Tomasz TorczTo co nierealne – tutaj jest normalne. to...@pipebreaker.pl Ziomale na życie mają tu patenty specjalne. ___ 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 1949293] perl-Verilog-Perl-3.476 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949293 --- Comment #2 from Fedora Update System --- FEDORA-2021-33aca0c1fe 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-33aca0c1fe` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-33aca0c1fe 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 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 --- Comment #7 from Fedora Update System --- FEDORA-2021-02c2e1bda9 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-02c2e1bda9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-02c2e1bda9 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 1949283] perl-ExtUtils-MakeMaker-7.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949283 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2021-dfc46681cc 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-dfc46681cc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-dfc46681cc 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 1949183] perl-PDF-API2-2.040 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949183 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2021-20bd934576 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-20bd934576` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-20bd934576 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
Github Action for discovering active Fedora Releases
I'm sure there are others of you out there like me who are using Github Actions for continuous integration. Recently, I got tired of updating my CI workflow definition every time a new Fedora release branched, so I wrote a reusable Github Action[1] to query Bodhi for the list of "current" (aka "stable") and "pending" (AKA "branched" or "rawhide") releases and return them as a JSON array that can be used to dynamically generate the build matrix. Since I figured it might be useful to others, I have made it available publicly. See the Marketplace link[1] for usage examples. [1] https://github.com/marketplace/actions/get-fedora-releases ___ 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-34-20210414.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Failed openQA tests: 8/127 (aarch64), 10/189 (x86_64) New failures (same test not failed in Fedora-34-20210413.n.0): ID: 856266 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/856266 ID: 856286 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/856286 ID: 856361 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/856361 ID: 856388 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/856388 Old failures (same test failed in Fedora-34-20210413.n.0): ID: 856098 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/856098 ID: 856099 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/856099 ID: 856102 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/856102 ID: 856111 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/856111 ID: 856123 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/856123 ID: 856129 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/856129 ID: 856130 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/856130 ID: 856164 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/856164 ID: 856214 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/856214 ID: 856215 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/856215 ID: 856230 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/856230 ID: 856276 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/856276 ID: 856351 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/856351 ID: 856370 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/856370 Soft failed openQA tests: 5/127 (aarch64), 4/189 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-34-20210413.n.0): ID: 856380 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/856380 Old soft failures (same test soft failed in Fedora-34-20210413.n.0): ID: 856087 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/856087 ID: 856128 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/856128 ID: 856185 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/856185 ID: 856191 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/856191 ID: 856204 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/856204 ID: 856229 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/856229 ID: 856244 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/856244 ID: 856325 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/856325 Passed openQA tests: 175/189 (x86_64), 114/127 (aarch64) New passes (same test not passed in Fedora-34-20210413.n.0): ID: 856145 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/856145 ID: 856218 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/856218 ID: 856223 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/856223 ID: 856238 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/856238 ID: 856242 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/856242 ID: 856261 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/856261 ID: 856318 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/856318 ID: 856319 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/856319 ID: 856344 Test: x86_64
Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Apr 14, 2021 at 11:47:42AM -0400, Neal Gompa wrote: > On Wed, Apr 14, 2021 at 11:30 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote: > > > On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote: > > > > Or in other words: packaging metadata are sources too. If they change > > > > (and a version bump constitutes a change) the output might change, > > > > and > > > > that's expected. What's key really is that the only things that can > > > > effect generated output are the build/packaging environment and the > > > > sources, but not parameters outside of that, such as the actual > > > > wallclock. > > > > > > The main way that packaging "interferes" with the source is when > > > patches are applied - the original timestamp of a tarball (for example) > > > isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair. > > > > > > > > > > > > My concern centers around the Copy on Write (CoW) use case - when > > > > > packages are updated, some files changes, and some may stay the > > > > > same. > > > > > Where they are the same, we can save I/O and possibly download time > > > > > long term. > > > > > > > > Reproducible builds the way they are defined do not address such > > > > file-level CoW optimization so much. They do address CoW optimization > > > > on a package level much more however: i.e. the same package build > > > > will > > > > have the same files in them, no matter what. > > > > > > > > Or to say this differently: if you want reproducible to work the way > > > > ou think it should work, you'd have to start by convincing the > > > > uptream > > > > maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good > > > > luck with that. > > > > > > I think we should be careful to de-couple these two things. Just > > > because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not > > > proof that all binaries will. I remain concerned that this proposal > > > forces the issue and for every single version of every single ELF > > > binary *must* be different, even if they really didn't change. The > > > pattern I see is more automation and faster, smaller release cycles, > > > and this forcing downloads and writes of binaries that really didn't > > > change their code. > > > > Yeah, that's definitely something to think about. > > > > The proposed change indeed "forces the issue". This could be a big drawback > > or not, depending on how often identical binary builds happen for different > > package versions. If it turns out that the answer is "only rarely", then > > I wouldn't consider it too important. If the answer is "quite often", we > > would a chance for a nice optimization. > > > > I wanted to investigate this, but unfortunately, it's hard to check > > right now, because all builds are non-reproducible (in the sense of > > reproducible-builds.org), because we include the mtime of build > > products in rpm metadata, so pretty much all binary rpms are > > different. And in general other things make builds non-reproducible, > > and it's not obvious if *this* change makes things worse. I didn't > > want to dig into individual rpms to compare binaries. I *think* most > > packages are not actually rebuilt that often without changes…, but real > > data is definitely needed. > > > > We could start clamping times by default by adding the following to > redhat-rpm-config: > > %clamp_mtime_to_source_date_epoch 1 Oh, is this already a thing? Nice! https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/126 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
Mock fedora-34-x86_64 on Fedora 34 beta broken
Hey devel, Is anyone else getting this issue on Fedora 34 beta when using mock with the fedora-34-x86_64 chroot? mock -r fedora-33-x86_64 shell works just fine on Fedora 34 beta. Also mock -r fedora-34-x86_64 shell works on Fedora 33. What is the best way to troubleshoot this? I already nuked all the containers and repulled them. mock -r fedora-34-x86_64 shell INFO: mock.py version 2.9 starting (python version = 3.9.4, NVR = mock-2.9-2.fc34)... Start(bootstrap): init plugins INFO: selinux enabled Finish(bootstrap): init plugins Start: init plugins INFO: selinux enabled Finish: init plugins INFO: Signal handler active Start: run Start(bootstrap): chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled package manager cache Start(bootstrap): cleaning package manager metadata Finish(bootstrap): cleaning package manager metadata INFO: enabled HW Info plugin INFO: Using bootstrap image: registry.fedoraproject.org/fedora:34 INFO: Pulling image: registry.fedoraproject.org/fedora:34 Trying to pull registry.fedoraproject.org/fedora:34... Getting image source signatures Copying blob sha256:999e4fc5d528c12d604e932457da70575edba2e190e4b49889e6c0329ebf Copying config sha256:e9a62e90440de88a10995fec385993016911aa3410abee8d50035e84e430bb40 Writing manifest to image destination Storing signatures e9a62e90440de88a10995fec385993016911aa3410abee8d50035e84e430bb40 Error: no container with name or ID "time=\"2021-04-14T10:40:24-05:00\" level=warning msg=\"The input device is not a TTY. The --tty and --interactive flags might not work properly\"\n0810c4332dc722feede422372be9a57b397003cb75309bfde00a04340ee5b953" found: no such container ERROR: Command failed: # podman exec time="2021-04-14T10:40:24-05:00" level=warning msg="The input device is not a TTY. The --tty and --interactive flags might not work properly" 0810c4332dc722feede422372be9a57b397003cb75309bfde00a04340ee5b953 /usr/bin/dnf -y install dnf dnf-plugins-core -- Joe Doss j...@solidadmin.com ___ 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: F35 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Apr 14, 2021 at 11:30 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote: > > On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote: > > > Or in other words: packaging metadata are sources too. If they change > > > (and a version bump constitutes a change) the output might change, > > > and > > > that's expected. What's key really is that the only things that can > > > effect generated output are the build/packaging environment and the > > > sources, but not parameters outside of that, such as the actual > > > wallclock. > > > > The main way that packaging "interferes" with the source is when > > patches are applied - the original timestamp of a tarball (for example) > > isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair. > > > > > > > > > My concern centers around the Copy on Write (CoW) use case - when > > > > packages are updated, some files changes, and some may stay the > > > > same. > > > > Where they are the same, we can save I/O and possibly download time > > > > long term. > > > > > > Reproducible builds the way they are defined do not address such > > > file-level CoW optimization so much. They do address CoW optimization > > > on a package level much more however: i.e. the same package build > > > will > > > have the same files in them, no matter what. > > > > > > Or to say this differently: if you want reproducible to work the way > > > ou think it should work, you'd have to start by convincing the > > > uptream > > > maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good > > > luck with that. > > > > I think we should be careful to de-couple these two things. Just > > because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not > > proof that all binaries will. I remain concerned that this proposal > > forces the issue and for every single version of every single ELF > > binary *must* be different, even if they really didn't change. The > > pattern I see is more automation and faster, smaller release cycles, > > and this forcing downloads and writes of binaries that really didn't > > change their code. > > Yeah, that's definitely something to think about. > > The proposed change indeed "forces the issue". This could be a big drawback > or not, depending on how often identical binary builds happen for different > package versions. If it turns out that the answer is "only rarely", then > I wouldn't consider it too important. If the answer is "quite often", we > would a chance for a nice optimization. > > I wanted to investigate this, but unfortunately, it's hard to check > right now, because all builds are non-reproducible (in the sense of > reproducible-builds.org), because we include the mtime of build > products in rpm metadata, so pretty much all binary rpms are > different. And in general other things make builds non-reproducible, > and it's not obvious if *this* change makes things worse. I didn't > want to dig into individual rpms to compare binaries. I *think* most > packages are not actually rebuilt that often without changes…, but real > data is definitely needed. > We could start clamping times by default by adding the following to redhat-rpm-config: %clamp_mtime_to_source_date_epoch 1 > > I have just thought of an alternative proposition: for ELF objects (and > > ELF objects only): rpm could automatically, and systematically record > > the metadata in an xattr. This would work on images without rpmdb, > > works on most filesystem types, be serialized in archives. Most > > interestingly this could be implemented as an rpm plugin, and would > > work retroactively for packages that were built before this proposal. > > It could also be made to work for other packaging systems, and the > > tooling that reads it wouldn't need to know the original packaging > > system. > Unfortunately this doesn't work for two important cases: > - when a binary or shared library has been replaced on disk. E.g. > it is fairly common for packages to crash on upgrade, and the crash > could be in the _old_ code. When the metadata is loaded in a section, > we get it all nice and dandy in the coredump. If it's in an xattr, > we don't or even worse, get outdated info. > - it doesn't work for non-rpm stuff. > > 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 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To
[Bug 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 --- Comment #6 from Fedora Update System --- FEDORA-2021-5ef434ce27 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-5ef434ce27` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5ef434ce27 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: [Fedora-packaging] How to automatically handle Python namespace packages (e.g. in %pyproject_save_files)
On 14. 04. 21 15:55, Toshio Kuratomi wrote:
On Wed, Apr 14, 2021 at 5:18 AM Miro Hrončok wrote:
Hello Pythonistas.
I'd like to be able to automatically handle Python "namespace" packages from our
packaging macros.
The problem:
Several Python packages share a "namespace", let's take an artificial example
with food.spam and food.eggs Python packages.
1. the Python packages both have site-packages/food
2. sometimes such packages also both have site-packages/food/__init__.py
(usually empty or mostly empty, but with different mtimes etc.)
On RPM level, this means:
1. %{python3_sitelib}/food can be co-owned
OR it can be in an artificial python3-food(-filesystem) package [0]
OR it can be in an existing package that is always present [1]
2. %{python3_sitelib}/food/__init__.py and
%{python3_sitelib}/food/__pycache__/__init__.*.pyc
will conflict if present in multiple packages,
they need to be removed or shared from the python3-food(-filesystem)
package
I want to solve this once for all, define the best practice, document it in the
packaging guidelines and possible automate this in %pyproject_save_files [2].
My current idea is:
- sharing directories is safe and easy,
let's do that instead of artificial packages (those are hard to automate)
- namespace packages should not need __init__py with modern Python 3,
let's discourage that
This, unfortunately, needs to be done upstream, at least some of the
time. There are three different ways to do namespace packages in
Python. The modern Python 3 version does not require __init__.py
files but the other two (from before Python 3.3 added namespace
packages to the core interpreter. One is implemented via pkgutil from
the python stdlib and the other is implemented via a setuptools
feature) have logic in the __init__.py to turn the directory into a
namespace. The Python 3.3+ and pkgutil methods of namespace packaging
are largely compatible (Enough so I think your idea to convert
pkgutil-based packages to Python-3.3+ versions will work) but the
setuptools version is incompatible.[1]_
The problem with us trying to change the setuptools using python
modules that we package to use the modern Python 3 occurs when a user
installs a different package in the namespace from upstream. The user
then has two packages which implement the namespace in incompatible
ways. My testing shows that this will result in all of our packages
failing to be found by python.[2]_
You could modify your proposal to deal with setuptools based
namespaces in a different manner than the other two namespaces. This
might cause more mistakes (as packagers will have to figure out if
they're in the special case scenario of a setuptools based namespace)
but it does simplify packaging in the other two cases.
.. [1]_:
https://packaging.python.org/guides/packaging-namespace-packages/#creating-a-namespace-package
.. [2]_: Here's the procedure to test compatibility:
mkdir -p site-3.3/food/spam site-pkgutil/food/eggs site-setuptools/food/potato
echo "print('spam')" > site-3.3/food/spam/__init__.py
echo "__path__ = __import__('pkgutil').extend_path(__path__,
__name__)" > site-pkgutil/food/__init__.py
echo "print('eggs')" > site-pkgutil/food/eggs/__init__.py
echo "__import__('pkg_resources').declare_namespace(__name__)" >
site-setuptools/food/__init__.py
echo "print('potato')" > site-pkgutil/food/eggs/__init__.py
# These are both compatible
PYTHONPATH=site-3.3:site-pkgutil python3 -c 'import food.spam, food.eggs'
PYTHONPATH=site-pkgutil:site-3.3 python3 -c 'import food.spam, food.eggs'
# The setuptools namespace makes it so Python does not register the
3.3-style namespace at all
PYTHONPATH=site-3.3:site-setuptools python3 -c 'import food.spam, food.potato'
PYTHONPATH=site-setuptools:site-3.3 python3 -c 'import food.spam, food.potato'
# The setuptools namespace causes the pkgutil namespace to silently fail
PYTHONPATH=site-setuptools:site-pkgutil python3 -c 'import food.eggs,
food.potato'
PYTHONPATH=site-setuptools:site-pkgutil python3 -c 'import food.eggs,
food.potato'
Thanks for the additional data, Toshio!
My idea was that if we %ghost the __init__.py, it won't be installed by the RPM
package at all and essentially the entire pkg_resources/pkgutil thing will be
removed.
However, I had not realized that when users pip-install another namespace
package like this to a different location on sys.path, it will blow up :(
I think we can special-case the pkg_resources one and make sure the automation
in %pyproject_save_files fails if it encounters the pkg_resources import in the
to-be-ghosted __init__.py.
--
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:
Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)
On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote: > On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote: > > Or in other words: packaging metadata are sources too. If they change > > (and a version bump constitutes a change) the output might change, > > and > > that's expected. What's key really is that the only things that can > > effect generated output are the build/packaging environment and the > > sources, but not parameters outside of that, such as the actual > > wallclock. > > The main way that packaging "interferes" with the source is when > patches are applied - the original timestamp of a tarball (for example) > isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair. > > > > > > My concern centers around the Copy on Write (CoW) use case - when > > > packages are updated, some files changes, and some may stay the > > > same. > > > Where they are the same, we can save I/O and possibly download time > > > long term. > > > > Reproducible builds the way they are defined do not address such > > file-level CoW optimization so much. They do address CoW optimization > > on a package level much more however: i.e. the same package build > > will > > have the same files in them, no matter what. > > > > Or to say this differently: if you want reproducible to work the way > > ou think it should work, you'd have to start by convincing the > > uptream > > maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good > > luck with that. > > I think we should be careful to de-couple these two things. Just > because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not > proof that all binaries will. I remain concerned that this proposal > forces the issue and for every single version of every single ELF > binary *must* be different, even if they really didn't change. The > pattern I see is more automation and faster, smaller release cycles, > and this forcing downloads and writes of binaries that really didn't > change their code. Yeah, that's definitely something to think about. The proposed change indeed "forces the issue". This could be a big drawback or not, depending on how often identical binary builds happen for different package versions. If it turns out that the answer is "only rarely", then I wouldn't consider it too important. If the answer is "quite often", we would a chance for a nice optimization. I wanted to investigate this, but unfortunately, it's hard to check right now, because all builds are non-reproducible (in the sense of reproducible-builds.org), because we include the mtime of build products in rpm metadata, so pretty much all binary rpms are different. And in general other things make builds non-reproducible, and it's not obvious if *this* change makes things worse. I didn't want to dig into individual rpms to compare binaries. I *think* most packages are not actually rebuilt that often without changes…, but real data is definitely needed. > I have just thought of an alternative proposition: for ELF objects (and > ELF objects only): rpm could automatically, and systematically record > the metadata in an xattr. This would work on images without rpmdb, > works on most filesystem types, be serialized in archives. Most > interestingly this could be implemented as an rpm plugin, and would > work retroactively for packages that were built before this proposal. > It could also be made to work for other packaging systems, and the > tooling that reads it wouldn't need to know the original packaging > system. Unfortunately this doesn't work for two important cases: - when a binary or shared library has been replaced on disk. E.g. it is fairly common for packages to crash on upgrade, and the crash could be in the _old_ code. When the metadata is loaded in a section, we get it all nice and dandy in the coredump. If it's in an xattr, we don't or even worse, get outdated info. - it doesn't work for non-rpm stuff. 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dda757d4a5 libopenmpt-0.5.7-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-93d78fa1a6 perl-Net-CIDR-Lite-0.22-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f08dc6b4c1 gnuchess-6.2.7-5.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-13ed778e19 singularity-3.7.3-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3f9b6786f4 clamav-0.103.2-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9daa9fc0b1 seamonkey-2.53.7-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing atop-2.6.0-6.el7 officeparser-0.20180820-4.el7 Details about builds: atop-2.6.0-6.el7 (FEDORA-EPEL-2021-76dc640120) An advanced interactive monitor to view the load on system and process level Update Information: Upstream patch to correct service file ChangeLog: * Tue Apr 13 2021 Gwyn Ciesla - 2.6.0-6 - Upstream patch to fix service file. References: [ 1 ] Bug #1945494 - atop logging doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1945494 [ 2 ] Bug #1948624 - atop service doesn't parse options correctly on RHEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1948624 officeparser-0.20180820-4.el7 (FEDORA-EPEL-2021-2d6a797a0c) Parse the format of OLE compound documents used by MS Office applications Update Information: Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild ChangeLog: ___ 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 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-58127424cd perl-Net-Netmask-2.0001-1.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4ceb7b7897 libopenmpt-0.5.7-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-125be1ea97 perl-Net-CIDR-Lite-0.22-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d8aad094e9 singularity-3.7.3-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-aa018d2e2a clamav-0.103.2-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-781b228611 seamonkey-2.53.7-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing OpenStego-0.7.4-2.el8 atop-2.6.0-6.el8 dd_rescue-1.99.10-14.el8 editorconfig-0.12.4-3.el8 koji-1.24.1-1.el8 libjwt-1.12.1-6.el8 md5deep-4.4-14.el8 medusa-2.2-15.20181216git292193b.el8 nikto-2.1.6-8.el8 officeparser-0.20180820-4.el8 onesixtyone-0.3.2-25.el8 packETH-2.1-3.el8 python-hexdump-3.4-0.14.20160818hg66325cb5fed8.el8 python-pyev-0.9.0-0.13.20130610gite31d137.el8 samdump2-3.0.0-20.el8 Details about builds: OpenStego-0.7.4-2.el8 (FEDORA-EPEL-2021-7131164412) Free Steganography solution Update Information: Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild ChangeLog: atop-2.6.0-6.el8 (FEDORA-EPEL-2021-667b444f64) An advanced interactive monitor to view the load on system and process level Update Information: Upstream patch to correct service file ChangeLog: * Tue Apr 13 2021 Gwyn Ciesla - 2.6.0-6 - Upstream patch to fix service file. References: [ 1 ] Bug #1945494 - atop logging doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1945494 [ 2 ] Bug #1948624 - atop service doesn't parse options correctly on RHEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1948624 dd_rescue-1.99.10-14.el8 (FEDORA-EPEL-2021-91d39ff0c3) Fault tolerant "dd" utility for rescuing data from bad media Update Information: Update to dd_rescue-1.99.10 and dd_rhelp-0.3.0 ChangeLog: editorconfig-0.12.4-3.el8 (FEDORA-EPEL-2021-ef22520a02) Parser for EditorConfig files written in C Update Information: Initial package for EPEL8. ChangeLog: References: [ 1 ] Bug #1948779 - Please build editorconfig for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1948779 koji-1.24.1-1.el8 (FEDORA-EPEL-2021-68d7a45403) Build system tools Update Information: Update to 1.24.1 upstream bugfix release. See https://lists.fedorahosted.org/archives/list/koji- de...@lists.fedorahosted.org/thread/EAUPV5BAZS52BBRTWQOMISVGDAV7SAQU/ for more information. ChangeLog: * Tue Apr 13 2021 Kevin Fenzi - 1.24.1-1 - Update to 1.24.1. Fixes rhbz#1948545 libjwt-1.12.1-6.el8 (FEDORA-EPEL-2021-ff2ffc617f) A Javascript Web Token library in C Update Information: Add libjwt to EPEL8 ChangeLog:
Re: Announcing creation of Fedora Source-git SIG
On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote: > On 14.04.2021 16:27, Tomas Tomecek wrote: > > Could you, please, be more constructive and say what the actual > > problems are for you with such repositories? > > 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge > (more than 100 GiB). I don't want to download them from upstream and then > upload to Fedora. > > 2. Keeping such huge repositories will take up a lot of disk space on the > maintainer's computers. Bear in mind that many maintainers already use a source-git workflow with Fedora, and are also involved in the upstream project. IOW, they already have these upstream repos present locally, and also be hosting it in some remote git server outside normal Fedora dist-git. source-git isn't proposed to be forced on all packages, and drive-by contributors can also take a shallow clone instead of fetching all history. Any possible "fedpkg" integration could potentially default to a shallow clone. > 3. Rebase problem. Maintainers will need do a manual rebase on every > upstream release/commit. Rebasing to the next major version will be a > serious problem for the projects with a lot of of downstream patches. That's not my experiance. The cases where I know of maintainers are using a source-git model with Fedora / RHEL already, are doing so precisely because it makes ongoing maint and rebasing way easier than with dist-git, especially when there are alot of downstream patches (100's or even 1000's). > 4. Some project have a weird git workflow between minor releases. I know at > least one project that uses Git tags with cherry-picked and manually > backported commits. Such detached tags cannot be merged into master branch > without resolving merge conflicts. I woudn't expect Fedora to track the git-master in most cases. You generally still want Fedora to be base off releases, so you'd want to track starting fron a release tag or branch. > 5. Force pushes must be enabled, which is too dangerous IMO. There are several ways you can do source git and they don't all imply force pushes, so I think this is probably inventing a problem where none yet exists. One example approach to source-git I've used... Rather than having source-git branch names matching dist-git, use a different naming convention that is based off the upstream version primarily. eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33' branch, and if I rebase Fedora to v1.2, then I'd just switch to using a v1.2-f33 branch instead. The v1.0-f33 history remains intact forever, no force push required to rebase to new version. If upstream has stable branches v1.0-maint and v1.2-maint, then v1.0-f33 branch might be initialized with v1.0-maint content. If upstream adds more commits to v1.0-maint branch, then you wouldn't force push v1.0-f33, you'd just do a git merge to pull them in. > > I understand that upstream repositories can have a long history - we > > could optimize and have shallow copies or only fetch recent upstream > > history if needed. Also, one would ideally only clone once and kept > > fetching new changes. > > Do you want to force switch all Fedora packages to a new workflow? There's no mention of forcing everyone to switch to source-git. Some upstreams don't even use git. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2021-601e6856e1 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-601e6856e1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-601e6856e1 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
Fedora-Rawhide-20210414.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 8/189 (x86_64), 7/127 (aarch64) Old failures (same test failed in Fedora-Rawhide-20210413.n.0): ID: 855800 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/855800 ID: 855848 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/855848 ID: 855863 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/855863 ID: 855918 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/855918 ID: 855960 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/855960 ID: 856009 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/856009 ID: 856016 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/856016 ID: 856031 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/856031 ID: 856032 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/856032 ID: 856035 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/856035 ID: 856064 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/856064 ID: 856065 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/856065 ID: 856067 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/856067 ID: 856077 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/856077 ID: 856078 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/856078 Soft failed openQA tests: 3/189 (x86_64), 5/127 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210413.n.0): ID: 855771 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/855771 ID: 855812 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/855812 ID: 855869 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/855869 ID: 855875 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/855875 ID: 855888 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/855888 ID: 855913 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/855913 ID: 855928 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/855928 ID: 855950 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/855950 Passed openQA tests: 178/189 (x86_64), 115/127 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210413.n.0): ID: 855763 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/855763 ID: 855764 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/855764 ID: 855857 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/855857 ID: 855883 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/855883 ID: 855939 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/855939 ID: 855962 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/855962 ID: 855971 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/855971 ID: 855972 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/855972 ID: 855979 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/855979 ID: 855999 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/855999 ID: 856001 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/856001 ID: 856017 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/856017 ID: 856027 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/856027 ID: 856034 Test: aarch64 universal install_mirrorlist_graphical@uefi URL:
Fedora-IoT-34-20210414.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210413.0): ID: 856508 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/856508 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-20210413.0): ID: 856491 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/856491 Passed openQA tests: 14/15 (aarch64), 15/16 (x86_64) New passes (same test not passed in Fedora-IoT-34-20210413.0): ID: 856512 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/856512 ID: 856520 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/856520 -- 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: Announcing creation of Fedora Source-git SIG
On 14.04.2021 16:27, Tomas Tomecek wrote: Could you, please, be more constructive and say what the actual problems are for you with such repositories? 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge (more than 100 GiB). I don't want to download them from upstream and then upload to Fedora. 2. Keeping such huge repositories will take up a lot of disk space on the maintainer's computers. 3. Rebase problem. Maintainers will need do a manual rebase on every upstream release/commit. Rebasing to the next major version will be a serious problem for the projects with a lot of of downstream patches. 4. Some project have a weird git workflow between minor releases. I know at least one project that uses Git tags with cherry-picked and manually backported commits. Such detached tags cannot be merged into master branch without resolving merge conflicts. 5. Force pushes must be enabled, which is too dangerous IMO. I understand that upstream repositories can have a long history - we could optimize and have shallow copies or only fetch recent upstream history if needed. Also, one would ideally only clone once and kept fetching new changes. Do you want to force switch all Fedora packages to a new workflow? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Announcing creation of Fedora Source-git SIG
comments inline On Wed, Apr 14, 2021 at 4:09 PM Daniel P. Berrangé wrote: > > On Wed, Apr 14, 2021 at 10:45:23AM +0200, Tomas Tomecek wrote: > > Good morning, I'd like to announce the creation of Fedora Source-git SIG: > > > > https://fedoraproject.org/wiki/SIGs/Source-git > > > > Our main goal in the SIG right now is to establish a development > > workflow for Fedora Linux packages using repositories with sources and > > upstream history (this is what we call source-git), instead of just > > distribution files with links to tarballs (dist-git). > > > > Please head to the SIG wiki page to learn more about our proposed MVP. > > We are looking for maintainers of Fedora Linux packages who'd be > > interested in being early adopters and give us feedback during the > > development process. You don't need to do any coding unless you want > > to :) > > We might be interested in trialling it with some of the virt packages. > > I'm wondering about the scope of this statement from the wiki page > above: > > "Whatever we produce here, it MUST NOT violate Fedora Packaging >Guidelines (we should strive to change them if needed)." > > I can certainly understand the intent behind this when dealing with > legally restricted content. eg don't allow impls of patented algorithms > that are blocked from dist-git. > > In terms of scope I can reasonably audit the source for current git > master or a specific git tag to ensure legal compliance. > > I can't reasonably audit the entire source-git history of the project > back to day 1 though, to make sure the git repo has never had legally > restricted content at any point in the past 20 years of its life. > > IOW, I'd hope that in terms of FPG compliance, we only need to consider > the specific tag/branch that's being used to populate dist-git and can > ignore history. > > This could still potentially mean that source-git is a complication for > the packages where we have to re-create the tarballs after removing > patented crypto. Will legal allow it to remain in source git, but > require it to be purged when src-git syncs to dist-git or something > like that ? > > Overall this does seem to imply though that if Fedora hosts src-git > repos with upstream history itself, then it is potentially opening > a new liability that it hasn't had before. If we're going to host > src-git on a Fedora namespace on gitlab.com though, then its someone > else's problem to worry about, and Fedora only needs to worry about > what's synced to dist-git for the actual RPMs builds. Thank you, Daniel, very good points! I'll add this to the agenda of the first meeting to bring this to Fedora Legal. I also hope to make the legal aspect of this someone else's problem - on the other hand, if this workflow ever gets approved by FESCO and become official (aside from the dist-git workflow) the repos would need to be hosted on Fedora Infra. > Aside from legal, I also wonder about things like binary blobs or > bundled libraries. These are relatively common to see in upstream > git repos, even if they don't make it into the release tarballs that > Fedora traditionally consumes. > > Hopefully the requirement to comply with Fedora Pakaging Guidelines > will only apply to files in src-git that actually get used for > Fedora builds, and not stuff that exists but is skipped/ignored ? Yes, I'd say to files which are being put to dist-git and used for official builds. Short term, I don't think it's feasible to create production koji builds out of these source-git repositories. That would be the long term plan :) > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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
[Bug 1949293] perl-Verilog-Perl-3.476 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949293 --- Comment #1 from Fedora Update System --- FEDORA-2021-33aca0c1fe has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-33aca0c1fe -- 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: Announcing creation of Fedora Source-git SIG
On Wed, Apr 14, 2021 at 2:52 PM Vitaly Zaitsev via devel wrote: > > On 14.04.2021 10:45, Tomas Tomecek wrote: > > Our main goal in the SIG right now is to establish a development > > workflow for Fedora Linux packages using repositories with sources and > > upstream history (this is what we call source-git), instead of just > > distribution files with links to tarballs (dist-git). > > Debian style with full local copies of repositories? > > I don't think this is a good idea, because I don't want to clone > upstream repositories and store my SPECs in them. Could you, please, be more constructive and say what the actual problems are for you with such repositories? I understand that upstream repositories can have a long history - we could optimize and have shallow copies or only fetch recent upstream history if needed. Also, one would ideally only clone once and kept fetching new changes. Thank you, Tomas > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > 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
[Bug 1949293] perl-Verilog-Perl-3.476 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949293 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Verilog-Perl-3.476-1.f ||c35 Resolution|--- |RAWHIDE Last Closed||2021-04-14 14:15:49 -- 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-Verilog-Perl] PR #1: Tests
jplesnik merged a pull-request against the project: `perl-Verilog-Perl` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-Verilog-Perl/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: How to handle pull request with git?
On 4/14/21 3:28 PM, Mark Wielaard wrote: Hi, I got a "pull request" for one of my packages and wanted to make some changes to discuss with the submitter and see if we could merge it back with those changes to the rawhide branch. But somehow I did something wrong and I am not sure what or how to fix it. So I saw this webpage with the suggested change: https://src.fedoraproject.org/rpms/valgrind/pull-request/4 I added the following line to my .git/config at the end of the [remote "origin"] section to be able to pull it: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* Then git pulled and checkout pr/4, made the changes, committed them and pushed them back, hoping that would update the pr. But it didn't, apparently I created a new origin/pr/4 branch, which I am now unable to delete because: $ git push origin --delete pr/4 remote: Branch deletion is not allowed remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/valgrind ! [remote rejected] pr/4 (pre-receive hook declined) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind' What did I do wrong and how do I fix this? Thanks, Mark 1. You clone the forked repository 2. You checkout the branch where the modification has been made 3. You edit the files you want to change 4. You commit (or amend) the new changes 5. You push (or force push) the commit 6. Your commit will appear in the Pull Request ar "Rebased blah blah" 7. Merge your changes ___ 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-Verilog-Perl] PR #1: Tests
jplesnik opened a new pull-request against the project: `perl-Verilog-Perl` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Verilog-Perl/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: Announcing creation of Fedora Source-git SIG
On Wed, Apr 14, 2021 at 10:45:23AM +0200, Tomas Tomecek wrote: > Good morning, I'd like to announce the creation of Fedora Source-git SIG: > > https://fedoraproject.org/wiki/SIGs/Source-git > > Our main goal in the SIG right now is to establish a development > workflow for Fedora Linux packages using repositories with sources and > upstream history (this is what we call source-git), instead of just > distribution files with links to tarballs (dist-git). > > Please head to the SIG wiki page to learn more about our proposed MVP. > We are looking for maintainers of Fedora Linux packages who'd be > interested in being early adopters and give us feedback during the > development process. You don't need to do any coding unless you want > to :) We might be interested in trialling it with some of the virt packages. I'm wondering about the scope of this statement from the wiki page above: "Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed)." I can certainly understand the intent behind this when dealing with legally restricted content. eg don't allow impls of patented algorithms that are blocked from dist-git. In terms of scope I can reasonably audit the source for current git master or a specific git tag to ensure legal compliance. I can't reasonably audit the entire source-git history of the project back to day 1 though, to make sure the git repo has never had legally restricted content at any point in the past 20 years of its life. IOW, I'd hope that in terms of FPG compliance, we only need to consider the specific tag/branch that's being used to populate dist-git and can ignore history. This could still potentially mean that source-git is a complication for the packages where we have to re-create the tarballs after removing patented crypto. Will legal allow it to remain in source git, but require it to be purged when src-git syncs to dist-git or something like that ? Overall this does seem to imply though that if Fedora hosts src-git repos with upstream history itself, then it is potentially opening a new liability that it hasn't had before. If we're going to host src-git on a Fedora namespace on gitlab.com though, then its someone else's problem to worry about, and Fedora only needs to worry about what's synced to dist-git for the actual RPMs builds. Aside from legal, I also wonder about things like binary blobs or bundled libraries. These are relatively common to see in upstream git repos, even if they don't make it into the release tarballs that Fedora traditionally consumes. Hopefully the requirement to comply with Fedora Pakaging Guidelines will only apply to files in src-git that actually get used for Fedora builds, and not stuff that exists but is skipped/ignored ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
On Sun, Apr 11, 2021 at 1:52 PM Owen Taylor wrote: > > > On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro > wrote: > >> On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor >> wrote: >> > Did you notice that it also works for the Fedora Flatpaks (thanks, >> > Frank!) - basic proof of concept: >> > >> > $ flatpak run --command=sh --filesystem=home --share=network --devel >> > org.gnome.Aisleriot >> > [ org.gnome.Aisleriot ~]$ >> > DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/ >> > DEBUGINFOD_CACHE_PATH=~/.cache/debuginfod_client gdb /app/bin/sol >> > >> > (Without the --filesystem=home and DEBUGINFOD_CACHE_PATH, the cache >> > ends up in ~/.var/app/org.gnome.Aisleriot/cache/debuginfod_client/) >> >> I think that's OK for a manual debugging workflow, since it's pretty >> rare to want to do that under flatpak in my experience. Normally what's >> most important to me is being able to easily generate a backtrace for a >> previous crash using 'flatpak-coredumpctl'. Ideally >> 'flatpak-coredumpctl' would handle setting the right environment >> variables and executing flatpak with the right permissions to make it >> work. (In the future, ABRT could do something similar.) >> > > I think we could store the debuginfo urls in repository metadata (ostree > summary / oci json index) and have flatpak automatically set things up for > 'flatpak run --devel'. This isn't Fedora specific - e.g. there's an > eventual goal to have a debuginfo server for Flathub as well. > Filed an upstream pull-request for this (still needs some work): https://github.com/flatpak/flatpak/pull/4222 - Owen ___ 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: How to handle pull request with git?
On 14/04/2021 14:28, Mark Wielaard wrote: I added the following line to my .git/config at the end of the [remote "origin"] section to be able to pull it: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* Then git pulled and checkout pr/4, made the changes, committed them and pushed them back, hoping that would update the pr. Is there anywhere that works? I don't think even github allows you to push back to the generated head for the PR like that. If the person who opened the PR allowed it then you can push to their original branch to update the PR - no idea if pagure supports that. Possibly src.fpo should reject pushes to the PR heads to avoid this kind of accident though. But it didn't, apparently I created a new origin/pr/4 branch, which I am now unable to delete because: $ git push origin --delete pr/4 remote: Branch deletion is not allowed remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/valgrind ! [remote rejected] pr/4 (pre-receive hook declined) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind' What did I do wrong and how do I fix this? You pushed a branch into source git which is bad as hey can't be deleted. I believe in principle you can ask an admin to delete it so long as no builds have been done from it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
How to handle pull request with git?
Hi, I got a "pull request" for one of my packages and wanted to make some changes to discuss with the submitter and see if we could merge it back with those changes to the rawhide branch. But somehow I did something wrong and I am not sure what or how to fix it. So I saw this webpage with the suggested change: https://src.fedoraproject.org/rpms/valgrind/pull-request/4 I added the following line to my .git/config at the end of the [remote "origin"] section to be able to pull it: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* Then git pulled and checkout pr/4, made the changes, committed them and pushed them back, hoping that would update the pr. But it didn't, apparently I created a new origin/pr/4 branch, which I am now unable to delete because: $ git push origin --delete pr/4 remote: Branch deletion is not allowed remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/valgrind ! [remote rejected] pr/4 (pre-receive hook declined) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind' What did I do wrong and how do I fix this? Thanks, Mark ___ 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: Announcing creation of Fedora Source-git SIG
On Wed, Apr 14, 2021 at 10:45:23AM +0200, Tomas Tomecek wrote: > Please head to the SIG wiki page to learn more about our proposed MVP. > We are looking for maintainers of Fedora Linux packages who'd be > interested in being early adopters and give us feedback during the > development process. You don't need to do any coding unless you want > to :) Yeah, I'm interested. I have a few packages I maintain that I think would benefit from this workflow. -- 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: Outreachy 2021 applicant
Hi Kunal, good to hear you made it through C19. Feel free to solve the issue and open pull request when you are done. Currently we don't assign any issues and we don't merge pull requests. In this way, everyone can work on any issue and we can compare the communication, code in pull requests, etc... L. On Tue, Apr 13, 2021 at 8:47 PM KUNAL PRAKASH wrote: > Hello Lukas Brabec, > > I was in quarantine for 12 days because I was tested COVID positive. Due > to which I was unable to contribute to this project. But from now I want to > contribute to the project consistently. > > I like to solve the issue which shows on console tab in developers tool. > ___ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210414.n.0 changes
OLD: Fedora-34-20210413.n.0 NEW: Fedora-34-20210414.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-34-20210413.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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: Announcing creation of Fedora Source-git SIG
On 14.04.2021 10:45, Tomas Tomecek wrote: Our main goal in the SIG right now is to establish a development workflow for Fedora Linux packages using repositories with sources and upstream history (this is what we call source-git), instead of just distribution files with links to tarballs (dist-git). Debian style with full local copies of repositories? I don't think this is a good idea, because I don't want to clone upstream repositories and store my SPECs in them. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
How to automatically handle Python namespace packages (e.g. in %pyproject_save_files)
Hello Pythonistas.
I'd like to be able to automatically handle Python "namespace" packages from our
packaging macros.
The problem:
Several Python packages share a "namespace", let's take an artificial example
with food.spam and food.eggs Python packages.
1. the Python packages both have site-packages/food
2. sometimes such packages also both have site-packages/food/__init__.py
(usually empty or mostly empty, but with different mtimes etc.)
On RPM level, this means:
1. %{python3_sitelib}/food can be co-owned
OR it can be in an artificial python3-food(-filesystem) package [0]
OR it can be in an existing package that is always present [1]
2. %{python3_sitelib}/food/__init__.py and
%{python3_sitelib}/food/__pycache__/__init__.*.pyc
will conflict if present in multiple packages,
they need to be removed or shared from the python3-food(-filesystem) package
I want to solve this once for all, define the best practice, document it in the
packaging guidelines and possible automate this in %pyproject_save_files [2].
My current idea is:
- sharing directories is safe and easy,
let's do that instead of artificial packages (those are hard to automate)
- namespace packages should not need __init__py with modern Python 3,
let's discourage that
- If needed for %check, the __init__.py + .pyc should be %ghosted [3]
And with the %pyproject_save_files automation, let's say that if
%pyproject_save_files is used with a dot:
%pyproject_save_files food.spam
The dots separates a namespace and:
- food folder is co-owned
- food/__init__.py + .pyc is %ghosted if found, possibly with a warning
- any other Python files in food/ except spam.py or spam/ are not included
In case of nested namespaces (I have never seen that in reality), this can be
applied recursively.
Since %pyproject_save_files takes globs, I propose we split the argument on dot
and treat each part as a separate glob.
An alternate proposal which is less magical, more explicit about the "namespace"
situation but less explicit about what to include requires a special namespace flag:
%pyproject_save_files -N food
This says: Include food supackages, but food is a namespace package:
- food folder is co-owned
- food/__init__.py + .pyc is %ghosted if found, possibly with a warning
- all other Python files in food/ are included
Alternatively, this can be combined together somehow:
%pyproject_save_files -N food spam
But I don't like that.
Thoughts?
[0]
https://src.fedoraproject.org/rpms/python-jaraco-packaging/blob/rawhide/f/python-jaraco-packaging.spec#_29
[1]
https://src.fedoraproject.org/rpms/python-sphinx/blob/rawhide/f/python-sphinx.spec#_320
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1935266
[3]
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/5X3HTWDQ6AEHLUNUEORZ27VLOSMN2OCI/
--
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: Chain scratch builds in koji using a module
* Fabio Valentini: > On Wed, Apr 14, 2021 at 9:48 AM Honza Horak wrote: >> >> Hi folks, >> >> I found this thing and thought it might be useful for testing depended >> packages before committing, something similar to the chain scratch >> builds in koji, that are not available (to my knowledge). >> >> I didn't realize before we can use module builds for any package set, >> that does not even relate to any existing module in Fedora, so sharing >> for anybody who finds this useful. >> >> The use case here is that we have two or more packages that we want to >> test before changes land in production branch in dist-git, and where >> copr is not enough (for example we want all koji arches). (yes, for many >> things copr is much more powerful tool) >> >> The idea is to run a modular scratch build that picks the packages from >> concrete dist-git branches and build them in an expected order. >> >> The changes must be in a branch in dist-git (not in a fork), but it can >> be a private branch. Then we need a modulemd file like this: > > Note that "private" branches are not really a thing - if they ever > were (just look at [postgresql] for a particularly bad example), and > if any koji builds are done from those branches, they can *never* be > removed again either. So I would strongly advise *not* to do this. You don't need any private branches if all you want to do is rebuild things against a different buildroot. With side tags, this does in fact need branches because of the NVR uniqueness constraint, but modular builds already put unqiue numbers into the release string, so the need for dist-git changes is greatly reduced. I expect that in many cases, you can just reuse a commit from an official branch for the rebuild. Honza, this looks very interesting. Thanks for sharing it. Thanks, Florina ___ 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, 2021-04-14 at 12:58 +0200, Fabio Valentini wrote: > On Wed, Apr 14, 2021 at 12:35 PM Sérgio Basto > wrote: > > On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski > > wrote: > > > On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote: > > > > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto < > > > > ser...@serjux.com> > > > > wrote: > > [snip] > > > > It is arguably better to add the new config to local user mock > > > config > > > only instead of system-wide. I.e. put the new config in > > > $HOME/.config/mock . > > > > how ? $HOME/.config/mock directory ? > > Easiest solution: The "mock -r" accepts full paths to .cfg files, as > well as the .cfg-suffix-less names derived from system-wide > configuration files. > So just put the file anywhere you like, and supply the full path to > it > (including .cfg suffix) to mock's "-r" argument. > > e.g. "mock -r $HOME/Downloads/odubaj-autoconf-2.70_fedora-34- > x86_64.cfg > ./path-to.src.rpm" ah, ok, Thank you. Indeed mock man page have a good documentation (1) ... so option 1: mkdir $HOME/.config/mock copr mock-config odubaj/autoconf-2.70 fedora-34-x86_64 > odubaj- autoconf-2.70_fedora-34-x86_64.cfg mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg $HOME/.config/mock/ option 2 : copr mock-config odubaj/autoconf-2.70 fedora-34-x86_64 > odubaj- autoconf-2.70_fedora-34-x86_64.cfg mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg (1) -r CONFIG, --root=CONFIG Uses specified chroot configuration as defined in ~/.config/mock/.cfg or /etc/mock/.cfg. Optionally if CONFIG ends in '.cfg', it is interpreted as full path to config file. If none specified, uses the chroot config linked to by /etc/mock/default.cfg. > Fabio > ___ > 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 -- Sérgio M. B. ___ 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, Apr 14, 2021 at 12:35 PM Sérgio Basto wrote: > > On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski > wrote: > > On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote: > > > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto > > > wrote: [snip] > > It is arguably better to add the new config to local user mock config > > only instead of system-wide. I.e. put the new config in > > $HOME/.config/mock . > > how ? $HOME/.config/mock directory ? Easiest solution: The "mock -r" accepts full paths to .cfg files, as well as the .cfg-suffix-less names derived from system-wide configuration files. So just put the file anywhere you like, and supply the full path to it (including .cfg suffix) to mock's "-r" argument. e.g. "mock -r $HOME/Downloads/odubaj-autoconf-2.70_fedora-34-x86_64.cfg ./path-to.src.rpm" Fabio ___ 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: Chain scratch builds in koji using a module
On Wed, Apr 14, 2021 at 9:48 AM Honza Horak wrote: > > Hi folks, > > I found this thing and thought it might be useful for testing depended > packages before committing, something similar to the chain scratch > builds in koji, that are not available (to my knowledge). > > I didn't realize before we can use module builds for any package set, > that does not even relate to any existing module in Fedora, so sharing > for anybody who finds this useful. > > The use case here is that we have two or more packages that we want to > test before changes land in production branch in dist-git, and where > copr is not enough (for example we want all koji arches). (yes, for many > things copr is much more powerful tool) > > The idea is to run a modular scratch build that picks the packages from > concrete dist-git branches and build them in an expected order. > > The changes must be in a branch in dist-git (not in a fork), but it can > be a private branch. Then we need a modulemd file like this: Note that "private" branches are not really a thing - if they ever were (just look at [postgresql] for a particularly bad example), and if any koji builds are done from those branches, they can *never* be removed again either. So I would strongly advise *not* to do this. Fabio [postgresql]: https://src.fedoraproject.org/rpms/postgresql/branches?branchname=rawhide ___ 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 rawhide compose report: 20210414.n.0 changes
OLD: Fedora-Rawhide-20210413.n.0 NEW: Fedora-Rawhide-20210414.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 28 Dropped packages:2 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 43.70 MiB Size of dropped packages:2.47 MiB Size of upgraded packages: 404.14 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -512.96 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: gnome-kiosk-40~alpha-1.fc35 Summary: Window management and application launching for GNOME RPMs:gnome-kiosk gnome-kiosk-search-appliance Size:312.36 KiB Package: nginx-1:1.19.10-1.module_f35+11862+cfe0514e Summary: A high performance web server and reverse proxy server RPMs:nginx nginx-all-modules nginx-filesystem nginx-mod-http-image-filter nginx-mod-http-perl nginx-mod-http-xslt-filter nginx-mod-mail nginx-mod-stream Size:4.00 MiB Package: rust-ascii-canvas-2.0.0-1.fc35 Summary: Simple canvas for drawing lines and styled text and emitting to the terminal RPMs:rust-ascii-canvas+default-devel rust-ascii-canvas-devel Size:25.97 KiB Package: rust-buffered-reader-1.0.1-1.fc35 Summary: Super-powered Reader RPMs:rust-buffered-reader+bzip2-devel rust-buffered-reader+compression-bzip2-devel rust-buffered-reader+compression-deflate-devel rust-buffered-reader+compression-devel rust-buffered-reader+default-devel rust-buffered-reader+flate2-devel rust-buffered-reader-devel Size:83.59 KiB Package: rust-capnp-0.13.6-1.fc35 Summary: Runtime library for Cap'n Proto data encoding RPMs:rust-capnp+default-devel rust-capnp+quickcheck-devel rust-capnp+rpc_try-devel rust-capnp+std-devel rust-capnp+unaligned-devel rust-capnp-devel Size:98.46 KiB Package: rust-capnp-futures-0.13.2-1.fc35 Summary: Async serialization for Cap'n Proto messages RPMs:rust-capnp-futures+default-devel rust-capnp-futures-devel Size:23.10 KiB Package: rust-capnp-rpc-0.13.1-1.fc35 Summary: Implementation of the Cap'n Proto remote procedure call protocol RPMs:rust-capnp-rpc+default-devel rust-capnp-rpc-devel Size:54.07 KiB Package: rust-configparser-2.0.1-1.fc35 Summary: Simple configuration parsing utility with no dependencies RPMs:rust-configparser+default-devel rust-configparser-devel Size:30.73 KiB Package: rust-dyn-clone-1.0.4-1.fc35 Summary: Clone trait that is object-safe RPMs:rust-dyn-clone+default-devel rust-dyn-clone-devel Size:25.12 KiB Package: rust-ena-0.14.0-1.fc35 Summary: Union-find, congruence closure, and other unification code RPMs:rust-ena+bench-devel rust-ena+default-devel rust-ena-devel Size:44.75 KiB Package: rust-fallible-streaming-iterator-0.1.9-1.fc35 Summary: Fallible streaming iteration RPMs:rust-fallible-streaming-iterator+default-devel rust-fallible-streaming-iterator+std-devel rust-fallible-streaming-iterator-devel Size:31.43 KiB Package: rust-hashlink-0.6.0-1.fc35 Summary: HashMap-like containers with user-specified order RPMs:rust-hashlink+default-devel rust-hashlink+serde-devel rust-hashlink+serde_impl-devel rust-hashlink-devel Size:53.16 KiB Package: rust-lalrpop-0.19.5-1.fc35 Summary: Convenient LR(1) parser generator RPMs:lalrpop rust-lalrpop+default-devel rust-lalrpop+lexer-devel rust-lalrpop+pico-args-devel rust-lalrpop+test-devel rust-lalrpop-devel Size:5.85 MiB Package: rust-lalrpop-util-0.19.5-1.fc35 Summary: Runtime library for parsers generated by LALRPOP RPMs:rust-lalrpop-util+default-devel rust-lalrpop-util+lexer-devel rust-lalrpop-util+regex-devel rust-lalrpop-util+std-devel rust-lalrpop-util-devel Size:45.91 KiB Package: rust-memsec-0.6.0-1.fc35 Summary: Rust implementation of libsodium/utils RPMs:rust-memsec+alloc-devel rust-memsec+default-devel rust-memsec+getrandom-devel rust-memsec+libc-devel rust-memsec+nightly-devel rust-memsec+use_os-devel rust-memsec-devel Size:55.78 KiB Package: rust-nettle-7.0.1-1.fc35 Summary: Rust bindings for the Nettle cryptographic library RPMs:rust-nettle+default-devel rust-nettle-devel Size:257.82 KiB Package: rust-nettle-sys-2.0.6-1.fc35 Summary: Low-level Rust bindings for the Nettle cryptographic library RPMs:rust-nettle-sys+default-devel rust-nettle-sys-devel Size:38.34 KiB Package: rust-rusqlite-0.24.2-1.fc35 Summary: Ergonomic wrapper for SQLite RPMs:rust-rusqlite+array-devel rust-rusqlite+backup-devel rust-rusqlite+blob-devel rust-rusqlite+buildtime_bindgen-devel rust-rusqlite+byteorder-devel rust-rusqlite+chrono-devel rust-rusqlite+collation-devel rust-rusqlite+column_decltype-devel rust-rusqlite+csv-devel rust-rusqlite+csvtab-devel rust-rusqlite+default-devel rust-rusqlite+extra_check-devel rust-rusqlite+functions-devel rust-rusqlite+hooks-devel rust-rusqlite+i128_blob-devel rust-rusqlite+in_gecko-devel rust-rusqlite+lazy_static-devel rust
Re: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote: > > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto > > wrote: > > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > > > > > As I think this is not trivial we should add to How_To_Test > > > paragraph : > > > > > > After: > > > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > > > > odubaj-autoconf-2.70_fedora-34-x86_64.cfg > > > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock > > > > > > we may run: > > > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild > > > ufraw-0.23-0.11.20210413.fc35.src.rpm > > > > Added, thanks! > > It is arguably better to add the new config to local user mock config > only instead of system-wide. I.e. put the new config in > $HOME/.config/mock . how ? $HOME/.config/mock directory ? > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess > Irulan > ___ > 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 -- Sérgio M. B. ___ 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote: > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto wrote: > > > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > > > As I think this is not trivial we should add to How_To_Test paragraph : > > > > After: > > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > > > odubaj-autoconf-2.70_fedora-34-x86_64.cfg > > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock > > > > we may run: > > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild > > ufraw-0.23-0.11.20210413.fc35.src.rpm > > Added, thanks! It is arguably better to add the new config to local user mock config only instead of system-wide. I.e. put the new config in $HOME/.config/mock . Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Added, thanks! On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto wrote: > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > As I think this is not trivial we should add to How_To_Test paragraph : > > After: > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > > odubaj-autoconf-2.70_fedora-34-x86_64.cfg > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock > > we may run: > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild > ufraw-0.23-0.11.20210413.fc35.src.rpm > > Than you > -- > Sérgio M. B. > > ___ 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
#How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test As I think this is not trivial we should add to How_To_Test paragraph : After: copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > odubaj-autoconf-2.70_fedora-34-x86_64.cfg mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock we may run: mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild ufraw-0.23-0.11.20210413.fc35.src.rpm Than you -- Sérgio M. B. ___ 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-32-20210414.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210413.0): ID: 855750 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/855750 ID: 855757 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/855757 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[Bug 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 --- Comment #3 from Fedora Update System --- FEDORA-2021-601e6856e1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-601e6856e1 --- Comment #4 from Fedora Update System --- FEDORA-2021-5ef434ce27 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-5ef434ce27 -- 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 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 --- Comment #2 from Fedora Update System --- FEDORA-2021-02c2e1bda9 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02c2e1bda9 -- 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 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Crypt-OpenSSL-ECDSA-0. ||09-1.fc35 -- 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-Crypt-OpenSSL-ECDSA] PR #1: Tests
ppisar merged a pull-request against the project: `perl-Crypt-OpenSSL-ECDSA` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-ECDSA/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
[Bug 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 --- Comment #1 from Petr Pisar --- This release merges Fedora patches. Suitable for all Fedoras. -- 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-Crypt-OpenSSL-ECDSA] PR #1: Tests
ppisar opened a new pull-request against the project: `perl-Crypt-OpenSSL-ECDSA` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-ECDSA/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
Announcing creation of Fedora Source-git SIG
Good morning, I'd like to announce the creation of Fedora Source-git SIG: https://fedoraproject.org/wiki/SIGs/Source-git Our main goal in the SIG right now is to establish a development workflow for Fedora Linux packages using repositories with sources and upstream history (this is what we call source-git), instead of just distribution files with links to tarballs (dist-git). Please head to the SIG wiki page to learn more about our proposed MVP. We are looking for maintainers of Fedora Linux packages who'd be interested in being early adopters and give us feedback during the development process. You don't need to do any coding unless you want to :) With this email, I'd like to invite you to our first SIG meeting hosted on freenode IRC next week. The details will be specified by this Friday, please fill in "when is good" so we can pick a suitable time: https://whenisgood.net/bsyhsqq Regards, 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
[Bug 1949293] perl-Verilog-Perl-3.476 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949293 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|chitl...@gmail.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
[Bug 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |ppi...@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
[Bug 1949283] perl-ExtUtils-MakeMaker-7.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949283 --- Comment #1 from Fedora Update System --- FEDORA-2021-dfc46681cc has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-dfc46681cc -- 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: Getting conman into EPEL8
On Tue, 13 Apr 2021 11:27:08 -0400 Trey Dockendorf wrote: > On Tue, Apr 13, 2021 at 10:41 AM Dan Horák wrote: > > > > > > > I have Fedora accounts that I setup many years ago and honestly don't > > > recall if I was ever setup to be a packager for Fedora. If there is a way > > > to verify if I am setup as a packager I'd be happy to check, but most > > > likely I am not a packager in Fedora. > > > > that's a problem we can fix :-) New maintainers are always welcome. > > > > > > Dan > > > > > Would the best place to start be here? > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers. Any > pointers or additional information to get started on eventually becoming > EPEL8 conman maintainer is appreciated. please check also your spam folder, but the above link is generally a good start. For co-maintainers there is a short-cut possible. Dan ___ 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 1949283] perl-ExtUtils-MakeMaker-7.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949283 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-ExtUtils-MakeMaker-7.6 ||2-1.fc35 -- 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
Chain scratch builds in koji using a module
Hi folks, I found this thing and thought it might be useful for testing depended packages before committing, something similar to the chain scratch builds in koji, that are not available (to my knowledge). I didn't realize before we can use module builds for any package set, that does not even relate to any existing module in Fedora, so sharing for anybody who finds this useful. The use case here is that we have two or more packages that we want to test before changes land in production branch in dist-git, and where copr is not enough (for example we want all koji arches). (yes, for many things copr is much more powerful tool) The idea is to run a modular scratch build that picks the packages from concrete dist-git branches and build them in an expected order. The changes must be in a branch in dist-git (not in a fork), but it can be a private branch. Then we need a modulemd file like this: $ cat > testmodule.yaml
Fedora-Cloud-33-20210414.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210413.0): ID: 855577 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/855577 ID: 855584 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/855584 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[Bug 1949283] perl-ExtUtils-MakeMaker-7.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949283 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|mspa...@redhat.com, | |ppi...@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
[Bug 1949183] perl-PDF-API2-2.040 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949183 --- Comment #1 from Fedora Update System --- FEDORA-2021-20bd934576 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-20bd934576 -- 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 1949183] perl-PDF-API2-2.040 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949183 Jitka Plesnikova changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-PDF-API2-2.040-1.fc35 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
[Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1838000 Tomas Hoger changed: What|Removed |Added Depends On||1945144 -- 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
tmt hint 01
Hi! After the initial hint [1] describing the very first steps with tmt let's have a look at the available test execution options. The following user story was at the very beginning of tmt: As a tester or developer, I want to easily run tests in my preferred environment. Do you want to safely run tests without breaking your laptop? Use the default provision method 'virtual' which will execute tests under a virtual machine using libvirt with the help of testcloud: tmt run Would you like to execute tests a bit faster and don't need the full virtualization support? Run them in a container using podman: tmt run --all provision --how container Do you have an already prepared box where everything's ready for testing and you often ssh to it to experiment safely? tmt run --all provision --how connect --guest my.test.box Do you know exactly what the tests are doing and feel safe to quickly run them directly on your localhost? tmt run -a provision -h local Note that some provision methods require additional dependencies. Installing them is easy as well: sudo dnf install -y tmt-provision-container sudo dnf install -y tmt-provision-virtual See the tmt guide [2] and examples [3] for some more inspiration. Happy testing! :-) psss... [1] https://communityblog.fedoraproject.org/tmt-hints-basic-test/ [2] https://tmt.readthedocs.io/en/latest/guide.html [3] https://tmt.readthedocs.io/en/latest/examples.html ___ 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
[389-devel] 389 DS nightly 2021-04-14 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/04/14/report-389-ds-base-2.0.4-20210414git0a504c8e7.fc33.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
