Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36
On Tue, Sep 21, 2021 at 11:58 AM Miro Hrončok wrote: > On 17. 09. 21 11:07, Sahana Prasad wrote: > > Hello all, > > > > The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide > now. > > You can continue to port your changes for OpenSSL 3.0.0 now. > > > > The following packages FTBFS (attached), kindly have a look at them. > > I have switched the following packages to OpenSSL 1.1 explicitly as they > will > not support OpenSSL 3.0: > > python2.7 > python3.7 > python3.6 > pypy > pypy3.7 > > See an example PR for inspiration: > > https://src.fedoraproject.org/rpms/python3.6/pull-request/36 > > The constrict is compatible with Fedora 33-35 as well. > > It is not compatible with RHELs, but if deemed necessary, we can add > openssl1.1 > matapackage to EPEL. > > I've also requested the openssl1.1-devel provide to be added to RHEL 8, > but it > might be rejected or take a long time: > Hi Miro, Thanks for reporting this RFE. We have decided to provide support for it. Thank you, Regards, Sahana Prasad > > https://bugzilla.redhat.com/show_bug.cgi?id=2006238 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210928.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (aarch64), 1/8 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Cloud-34-20210927.0): ID: 1004339 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1004339 Old soft failures (same test soft failed in Fedora-Cloud-34-20210927.0): ID: 1004331 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1004331 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones wrote: > > On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote: > > Richard W.M. Jones wrote: > > > OCaml library code can in principle be dynamically linked, eg: > > > > > > $ rpm -ql ocaml-extlib | grep cmxs > > > /usr/lib64/ocaml/extlib/extLib.cmxs > > > $ file /usr/lib64/ocaml/extlib/extLib.cmxs > > > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, > > > version 1 (SYSV), dynamically linked, > > > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, > > > not stripped > > > > > > but upstream doesn't make it possible to ship OCaml binaries this way, > > > (they would still require rebuilding on every library update) and so > > > we only ship the DLLs not fully dynamically linked OCaml binaries > > > (except for the C code). > > > > Ah? > > > > So what sits in the main packages of libraries (e.g., in ocaml-facile as > > opposed to ocaml-facile-devel) then? Don't only shared libraries belong in > > the main package? > > The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot > of sense these days. Ideally we'd put them all in one package. > > > So I take back my comment that the OCaml stack is properly packaged. ;-) > > That sounds like almost as much of a mess as Go and Rust then. > > I'd hardly say OCaml packging is a mess. It's much closer to the > spirit of C packaging than those others. If you have *specific, > actionable* objections I will listen to them. > > I think Kevin's comment is meant more towards the way the language packages itself versus the rpm packaging of the language. Going from Kevin's comments on languages over the years, a 'good' language should not require such sort of rebuilding. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Tue, Sep 28, 2021 at 01:42:44PM +0200, Florian Weimer wrote: > * Kevin Kofler via devel: > > > Florian Weimer wrote: > > > >> * Kevin Kofler via devel: > >> > >>> (And for the record, I also think that Go and Rust should not work > >>> that way either! It is possible to build shared libraries of Go code, > >>> at least one Go toolchain supports it.) > >> > >> There is no stable Go ABI. Even minor updates change ABI because type > >> sizes and struct offsets change and are inlined across shared object > >> boundaries. You have to rebuild all reverse dependencies to avoid ABI > >> mismatches. Go's compatibility guarantees only apply at the source > >> level and do not preclude the addition of new struct fields, for > >> example. > > > > The same goes for OCaml and yet we still manage to ship almost > > everything in OCaml dynamically linked. We rebuild everything on every OCaml release, and ... > Interesting. Could you provide an example of such a dynamically linked > binary? C libraries of OCaml binaries are dynamically linked, eg: $ ldd /usr/bin/virt-v2v linux-vdso.so.1 (0x7ffce93ab000) libvirt.so.0 => /lib64/libvirt.so.0 (0x7f5a759c7000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x7f5a7593) libguestfs.so.0 => /lib64/libguestfs.so.0 (0x7f5a757cc000) libxml2.so.2 => /lib64/libxml2.so.2 (0x7f5a75643000) [etc] OCaml library code can in principle be dynamically linked, eg: $ rpm -ql ocaml-extlib | grep cmxs /usr/lib64/ocaml/extlib/extLib.cmxs $ file /usr/lib64/ocaml/extlib/extLib.cmxs /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, not stripped but upstream doesn't make it possible to ship OCaml binaries this way, (they would still require rebuilding on every library update) and so we only ship the DLLs not fully dynamically linked OCaml binaries (except for the C code). This is kind of OK because OCaml code doesn't suffer the slings and arrows of outrageous pointers. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
Richard W.M. Jones wrote: > OCaml library code can in principle be dynamically linked, eg: > > $ rpm -ql ocaml-extlib | grep cmxs > /usr/lib64/ocaml/extlib/extLib.cmxs > $ file /usr/lib64/ocaml/extlib/extLib.cmxs > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), dynamically linked, > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, > not stripped > > but upstream doesn't make it possible to ship OCaml binaries this way, > (they would still require rebuilding on every library update) and so > we only ship the DLLs not fully dynamically linked OCaml binaries > (except for the C code). Ah? So what sits in the main packages of libraries (e.g., in ocaml-facile as opposed to ocaml-facile-devel) then? Don't only shared libraries belong in the main package? So I take back my comment that the OCaml stack is properly packaged. ;-) That sounds like almost as much of a mess as Go and Rust then. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On 9/27/21 7:54 PM, Kevin Kofler via devel wrote: Robert Marcano via devel wrote: I think the only way the Java ecosystem to survive in Fedora outside of OpenJDK and some core components is to allow bundling (Even JavaScript bundling is already allowed), but how do to it without compromising security? The problem is that Java projects typically bundle prebuilt binaries, which is a complete no go. The big issue is not that the libraries are bundled, it is that they are bundled in prebuilt binary form, often even without the source code at all. Even in the case of SCM repositories committed binaries, allowing bundling would help a lot, add some kind of automation that replace these jar for the proposed local created maven repository, and link to them, and add the metadata to the RPM to know it need to be rebuilt when that dependency is updated. This is a lot more easier than fighting old build scripts that don't use some kind of dependency manager. It will probably be hard for these kind of packages, but any modern application using using a modern build system could become easier to package. Fixing this requires work no matter whether the packager works the way you propose or whether they simply unbundle the dependencies. So I do not see any valid reason to not just go ahead and unbundle. (At least for the typical application. Things like Eclipse plugins, using nested JARs, are the exception and might indeed need special treatment.) The Go and Rust case is different because the library packages are shipped as source code and the application packages then BuildRequire that source code. Doing the same for Java would require modifying the upstream build systems even more than just depending on a Fedora-built JAR would (because the Go/Rust way is not how Java normally works). So I do not see any advantage in doing things that way. (And for the record, I also think that Go and Rust should not work that way either! It is possible to build shared libraries of Go code, at least one Go toolchain supports it.) The JavaScript case is also different because everything that is bundled is bundled as source code. JavaScript does not have anything like a compiled JAR file. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210928.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210927.0): ID: 1004257 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1004257 ID: 1004265 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1004265 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210928.n.0 changes
OLD: Fedora-Rawhide-20210927.n.1 NEW: Fedora-Rawhide-20210928.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 2 Dropped packages:0 Upgraded packages: 52 Downgraded packages: 0 Size of added packages: 12.35 MiB Size of dropped packages:0 B Size of upgraded packages: 3.48 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 285.28 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20210928.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: eclipse-swt-1:4.21-1.fc36 Summary: Eclipse SWT: The Standard Widget Toolkit for GTK+ RPMs:eclipse-swt eclipse-swt-javadoc Size:12.34 MiB Package: golang-github-schollz-logger-1.2.0-1.fc36 Summary: Simplistic, opinionated logging for Golang RPMs:golang-github-schollz-logger-devel Size:11.40 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ansible-collection-community-mysql-2.3.0-1.fc36 Old package: ansible-collection-community-mysql-2.1.0-2.fc35 Summary: MySQL collection for Ansible RPMs: ansible-collection-community-mysql Size: 74.38 KiB Size change: 5.05 KiB Changelog: * Tue Sep 28 2021 Orion Poplawski - 2.3.0-1 - Update to 2.3.0 Package: cairomm-1.14.2-18.fc36 Old package: cairomm-1.14.2-17.fc36 Summary: C++ API for the cairo graphics library RPMs: cairomm cairomm-devel cairomm-doc Size: 1.70 MiB Size change: 42.96 KiB Changelog: * Mon Sep 27 2021 Benjamin A. Beasley 1.14.2-18 - Rename PDF documentation file Package: cairomm1.16-1.16.1-12.fc36 Old package: cairomm1.16-1.16.1-11.fc36 Summary: C++ API for the cairo graphics library RPMs: cairomm1.16 cairomm1.16-devel cairomm1.16-doc Size: 1.60 MiB Size change: -33.79 KiB Changelog: * Mon Sep 27 2021 Benjamin A. Beasley 1.16.1-12 - Rename PDF documentation file Package: chromium-94.0.4606.61-1.fc36 Old package: chromium-93.0.4577.82-2.fc36 Summary: A WebKit (Blink) powered web browser that Google doesn't want you to use RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 562.16 MiB Size change: 109.42 MiB Changelog: * Thu Sep 23 2021 Tom Callaway - 94.0.4606.54-1 - update to 94.0.4606.54 * Fri Sep 24 2021 Tom Callaway - 94.0.4606.61-1 - update to 94.0.4606.61 Package: cpp-hocon-0.3.0-15.fc36 Old package: cpp-hocon-0.3.0-14.fc36 Summary: C++ support for the HOCON configuration file format RPMs: cpp-hocon cpp-hocon-devel cpp-hocon-doc Size: 2.48 MiB Size change: 1.47 KiB Changelog: * Mon Sep 27 2021 Benjamin A. Beasley 0.3.0-15 - Rename PDF documentation file Package: dmlite-1.15.1-6.fc36 Old package: dmlite-1.15.1-4.fc36 Summary: Lcgdm grid data management and storage framework RPMs: dmlite-apache-httpd dmlite-devel dmlite-docs dmlite-dome dmlite-dpm-dsi dmlite-dpm-tester dmlite-dpm-xrootd dmlite-dpmdisk-domeonly dmlite-dpmhead-domeonly dmlite-libs dmlite-plugins-domeadapter dmlite-plugins-librarian dmlite-plugins-memcache dmlite-plugins-mysql dmlite-plugins-profiler dmlite-private-devel dmlite-puppet-dpm dmlite-shell python3-dmlite Size: 21.82 MiB Size change: 8.09 KiB Changelog: * Mon Sep 27 2021 Petr Vokac - 1.15.1-5 - Add HTTP protection for slow transfers - remove SRM dependencies if we don't build support for legacy DPM * Mon Sep 27 2021 Petr Vokac - 1.15.1-6 - Fix python3 shebang, fixes bug #1738911 Package: doctl-1.64.0-3.fc36 Old package: doctl-1.64.0-2.fc36 Summary: The official command line interface for the DigitalOcean API RPMs: doctl golang-github-digitalocean-doctl-devel Size: 25.30 MiB Size change: -14.04 KiB Changelog: * Mon Sep 20 2021 Mikel Olasagasti Uranga - 1.64.0-3 - Add build version flags Package: gedit-2:41~alpha-2.fc36 Old package: gedit-2:41~alpha-1.fc35 Summary: Text editor for the GNOME desktop RPMs: gedit gedit-devel Size: 14.80 MiB Size change: -17.23 KiB Changelog: * Mon Sep 27 2021 Ray Strode - 41~alpha-2 - Fix crash in open selector Resolves: #2007602 Package: gn-1938-3.20210927git0153d369.fc36 Old package: gn-1937-1.20210919gitde86ec41.fc36 Summary: Meta-build system that generates build files for Ninja RPMs: gn gn-doc Size: 3.27 MiB Size change: -324.92 KiB Changelog: * Mon Sep 27 2021 Benjamin A. Beasley 1938-1.20210927git0153d369 - Update to version 1938 * Mon Sep 27 2021 Benjamin A. Beasley 1938-2.20210927git0153d369 - Correctly stop overriding optimization flags * Mon Sep 27 2021 Benjamin A. Beasley 1938-3.20210927git0153d369 - Reduce macro indirection in the spec file Package: gtk3-3.24.30-4.fc36 Old package: gtk3-3.24.30-3.fc36 Summary
Re: Fedora ? Java: The Death of Two SIGs
On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote: > Richard W.M. Jones wrote: > > OCaml library code can in principle be dynamically linked, eg: > > > > $ rpm -ql ocaml-extlib | grep cmxs > > /usr/lib64/ocaml/extlib/extLib.cmxs > > $ file /usr/lib64/ocaml/extlib/extLib.cmxs > > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, > > version 1 (SYSV), dynamically linked, > > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, > > not stripped > > > > but upstream doesn't make it possible to ship OCaml binaries this way, > > (they would still require rebuilding on every library update) and so > > we only ship the DLLs not fully dynamically linked OCaml binaries > > (except for the C code). > > Ah? > > So what sits in the main packages of libraries (e.g., in ocaml-facile as > opposed to ocaml-facile-devel) then? Don't only shared libraries belong in > the main package? The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot of sense these days. Ideally we'd put them all in one package. > So I take back my comment that the OCaml stack is properly packaged. ;-) > That sounds like almost as much of a mess as Go and Rust then. I'd hardly say OCaml packging is a mess. It's much closer to the spirit of C packaging than those others. If you have *specific, actionable* objections I will listen to them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
Florian Weimer wrote: > Interesting. Could you provide an example of such a dynamically linked > binary? OCaml is interesting in that it does not use standard ELF .so files, but its own dynamic linking mechanism (those .cma files). This is a typical OCaml library (the ocaml-facile constraint satisfaction problem solver): https://koji.fedoraproject.org/koji/rpminfo?rpmID=27058403 You see that it has both Provides and Requires, and a -devel package: https://koji.fedoraproject.org/koji/rpminfo?rpmID=27058407 (I know that library because Kalzium, the KDE periodic table of elements application, depends on it. However, Kalzium is in C++ and actually statically links ocaml-facile and the OCaml runtime.) The OCaml compiler itself is also dynamically linked: https://koji.fedoraproject.org/koji/rpminfo?rpmID=27059751 For details, better ask Richard W.M. Jones. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Tue, Sep 28, 2021 at 02:00:58PM +0200, Kevin Kofler via devel wrote: > Florian Weimer wrote: > > Interesting. Could you provide an example of such a dynamically linked > > binary? > > OCaml is interesting in that it does not use standard ELF .so files, but its > own dynamic linking mechanism (those .cma files). .cma files are metadata for bytecode static linking. .cmxa files are metadata for native code static linking. .cmxs files are renamed *.so files and can be used for fully dynamic linking of OCaml native code. Other issues make it difficult to ship dynamically linked binaries of pure OCaml code, so in practice *.cmxs are only used for dlopen-style dynamic loading. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Strange mock chainbuild issue: package has incorrect checksum
W dniu 22.09.2021 o 21:07, Julian Sikorski pisze: Am 22.09.21 um 19:38 schrieb Fabio Valentini: On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski wrote: W dniu 21.09.2021 o 23:12, Richard W.M. Jones pisze: On Tue, Sep 21, 2021 at 10:16:17PM +0200, Julian Sikorski wrote: W dniu 21.09.2021 o 11:00, Richard W.M. Jones pisze: On Mon, Sep 20, 2021 at 11:45:39AM -0600, Jerry James wrote: On Mon, Sep 20, 2021 at 10:49 AM Julian Sikorski wrote: my local kernel rebuilds have started failing for no apparent reason - I was using a similar command successfully for several months. /mnt/openmediavault is a samba share. This is what gets output into the log: [snip] /mnt/openmediavault/kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm: (39, fsync failed: Permission denied) I suspect that is the real problem, and the incorrect checksum is a result of not being able to read or write the filesystem. Can you verify correct ownership and permissions on every directory in that path? If fsync(2) failed then that would be happening after the file descriptor was open, so it wouldn't be filesystem permissions but probably SELinux. Rich. I am seeing no errors in setroubleshoot and setting selinux to permissive does not help either. Can it be the selinux of the bootstrapped instance, and if so, how can I control it? There is nothing obvious in the logs of the host: AFAIK mock only ever uses one kernel (the host) so disabling SELinux on the host rules out my SELinux theory. Rich. This is all super strange. If I delete the pesign result dir, it is built without issues. Moreover, repodata folder is also created, with the sha256 checksum in the file matching the one of the pesign rpm. What is odd though, is that even after mock fails, gedit is claiming that repomd.xml and the data file extracted from primary.xml.gz keep changing on disk. Can it be some odd system clock issue between my desktop an my NAS? Oh my, that filesystem is mounted over a network? What filesystem is backing that directory? SMB? NFS? I assume that the issue you're seeing is caused by something like "NFS doesn't support the fsync call properly" ... Fabio It is a local network samba share, from a host running armbian and openmediavault. This used to work until last week or so, which is why I am starting to suspect some strange clock problem. I have tried rebooting the NAS but it did not help. Best regards, Julian I have now managed to generate logs on the NAS, see attached. There are two errors which stand out: NT_STATUS_NO_EAS_ON_FILE and NT_STATUS_ACCESS_DENIED later. Does this give any indication as to what might be happening? Best regards, JulianSep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.546997, 5, pid=4271, effective(1000, 100), real(1000, 0)] ../source3/smbd/uid.c:305(print_impersonation_info) Sep 28 09:18:34 odroidxu4 smbd[4271]: print_impersonation_info: Impersonated user: uid=(1000,1000), gid=(0,100), cwd=[/srv/dev-disk-by-label-omv/julian] Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.547470, 5, pid=4271, effective(1000, 100), real(1000, 0)] ../source3/smbd/filename.c:461(unix_convert) Sep 28 09:18:34 odroidxu4 smbd[4271]: unix_convert called on file "kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm" Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.548252, 5, pid=4271, effective(1000, 100), real(1000, 0)] ../source3/smbd/filename.c:662(unix_convert) Sep 28 09:18:34 odroidxu4 smbd[4271]: unix_convert begin: name = kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm, dirpath = , start = kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.548425, 5, pid=4271, effective(1000, 100), real(1000, 0)] ../source3/smbd/filename.c:685(unix_convert) Sep 28 09:18:34 odroidxu4 smbd[4271]: conversion of base_name finished kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm -> kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.548971, 5, pid=4271, effective(1000, 100), real(1000, 0), class=vfs] ../source3/smbd/vfs.c:1371(check_reduced_name) Sep 28 09:18:34 odroidxu4 smbd[4271]: check_reduced_name: kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm reduced to /srv/dev-disk-by-label-omv/julian/kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28 09:18:34.549436, 5, pid=4271, effective(1000, 100), real(1000, 0)] ../lib/dbwrap/dbwrap.c:130(dbwrap_lock_order_lock) Sep 28 09:18:34 odroidxu4 smbd[4271]: dbwrap_lock_order_lock: check lock order 1 for /var/run/samba/smbXsrv_open_global.tdb Sep 28 09:18:34 odroidxu4 smbd[4271]: [2021/09/28
Re: Fedora Java: The Death of Two SIGs
* Kevin Kofler via devel: > (And for the record, I also think that Go and Rust should not work > that way either! It is possible to build shared libraries of Go code, > at least one Go toolchain supports it.) There is no stable Go ABI. Even minor updates change ABI because type sizes and struct offsets change and are inlined across shared object boundaries. You have to rebuild all reverse dependencies to avoid ABI mismatches. Go's compatibility guarantees only apply at the source level and do not preclude the addition of new struct fields, for example. Just because there is a way to build shared objects does not mean it's possible to use this capability to short-circuit build processes like we do for most C and many C++ packages. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
Florian Weimer wrote: > * Kevin Kofler via devel: > >> (And for the record, I also think that Go and Rust should not work >> that way either! It is possible to build shared libraries of Go code, >> at least one Go toolchain supports it.) > > There is no stable Go ABI. Even minor updates change ABI because type > sizes and struct offsets change and are inlined across shared object > boundaries. You have to rebuild all reverse dependencies to avoid ABI > mismatches. Go's compatibility guarantees only apply at the source > level and do not preclude the addition of new struct fields, for > example. The same goes for OCaml and yet we still manage to ship almost everything in OCaml dynamically linked. IMHO, that is the way a binary distribution should work, not the way Go and Rust are currently packaged. Source code does not belong into binary packages. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
* Kevin Kofler via devel: > Florian Weimer wrote: > >> * Kevin Kofler via devel: >> >>> (And for the record, I also think that Go and Rust should not work >>> that way either! It is possible to build shared libraries of Go code, >>> at least one Go toolchain supports it.) >> >> There is no stable Go ABI. Even minor updates change ABI because type >> sizes and struct offsets change and are inlined across shared object >> boundaries. You have to rebuild all reverse dependencies to avoid ABI >> mismatches. Go's compatibility guarantees only apply at the source >> level and do not preclude the addition of new struct fields, for >> example. > > The same goes for OCaml and yet we still manage to ship almost everything in > OCaml dynamically linked. Interesting. Could you provide an example of such a dynamically linked binary? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Hacktoberfest] Adding Hacktoberfest tag to easyfix issues
Hello everyone, I'm Alberto from the Mindshare Committee. We are looking to participate in the Hacktoberfest[0] and solve some "easyfix" issues in our projects. To accomplish this, we need: * Set up push mirror from stub GitHub repositories to actual Pagure repositories for the participant's PR to be counted for the event. * Tag the current easyfix issues with the hacktoberfest tag. Maybe we can coordinate the work here and make this happen. Regards. [0] https://hacktoberfest.digitalocean.com/ [1] https://fedoraproject.org/easyfix/ ___ 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
Review request: mingw-python-pyqt5-sip
Hi I've got one last package needed for the mingw-sip-6.x upgrade: mingw-python-pyqt5-sip - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2008646 It's a trivial mingw-python package. Happy to review in exchange! Sandro ___ 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 CoreOS next stream rebased to Fedora Linux 35
Hi all, Fedora Linux 35 Beta was released today [1]. Our Fedora CoreOS `next` stream has been migrated to Fedora Linux 35 content. Existing nodes on the `next` stream will update as normal over the following days. Please test it out and report any issues in our issue tracker [2]. Thank you to everyone helping find issues by running the `next` stream! The Fedora CoreOS Team [1] https://fedoramagazine.org/announcing-fedora-35-beta/ [2] https://github.com/coreos/fedora-coreos-tracker/issues ___ 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
Packaging NW.js
I'm not familiar with packaging stuff like this so could use some pointers: https://github.com/nwjs/nw.js This is actually a prereq for another application I'd like to get in Fedora. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Tue, Sep 28, 2021 at 2:26 PM Robert Marcano via devel wrote: > > On 9/27/21 7:54 PM, Kevin Kofler via devel wrote: > > Robert Marcano via devel wrote: > >> I think the only way the Java ecosystem to survive in Fedora outside of > >> OpenJDK and some core components is to allow bundling (Even JavaScript > >> bundling is already allowed), but how do to it without compromising > >> security? > > > > The problem is that Java projects typically bundle prebuilt binaries, which > > is a complete no go. The big issue is not that the libraries are bundled, it > > is that they are bundled in prebuilt binary form, often even without the > > source code at all. > > Even in the case of SCM repositories committed binaries, allowing > bundling would help a lot, add some kind of automation that replace > these jar for the proposed local created maven repository, and link to > them, and add the metadata to the RPM to know it need to be rebuilt when > that dependency is updated. This is a lot more easier than fighting old > build scripts that don't use some kind of dependency manager. It will > probably be hard for these kind of packages, but any modern application > using using a modern build system could become easier to package. This is actually 100% how packaging applications that use ant + bundled dependencies (i.e. often .jar files in a "/lib/" directory) has worked for ages already. So the Java packaging tools we have in Fedora support this use case just fine. 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: Max age of side tags?
On Mon, Sep 27, 2021 at 05:25:33PM +0100, Richard W.M. Jones wrote: > On Mon, Sep 27, 2021 at 08:40:08AM -0700, Kevin Fenzi wrote: > > On Mon, Sep 27, 2021 at 11:58:44AM +0100, Richard W.M. Jones wrote: > > > OCaml 4.13 has just come out and we'll be rebuilding all the OCaml > > > packages in Rawhide into a side tag. Jerry James - who maintains some > > > of these packages - is not going to be available this week. That > > > means if I starts the builds now, we might need to keep the side tag > > > open for 2 or 3 weeks, whereas normally we'd complete everything in a > > > few days. > > > > > > Is this a problem? I vaguely recall that side tags had a short > > > maximum age (2 weeks?) but I cannot find anything about that in the > > > docs now. > > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/ > > > > > > If it's a problem then I can start doing the builds next week instead. > > > > It's currently set to clean up/remove side tags that are over 30days > > old, or over 14 days with nothing tagged into them. > > > > There was an announcement email, but yeah, should also be in docs. > > Any thoughts on where best to put it? > > I guess it's good that I wasn't imagining it! In the page > linked above probably. https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/34 kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On 9/27/21 8:31 AM, Richard W.M. Jones wrote: > On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote: >> On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones wrote: >>> >>> A question about this which is semi-related to your email. >>> >>> For some C library packages we have Java bindings, eg: >>> https://github.com/libguestfs/libguestfs/tree/master/java >>> >>> These have been disabled in Fedora for ~2 years, but when they were >>> around they had these BuildRequires: >>> >>> BuildRequires: java-1.8.0-openjdk >>> BuildRequires: java-1.8.0-openjdk-devel >>> BuildRequires: jpackage-utils >>> >>> I believe the only requirements are javac, javah, javadoc (optional) >>> and a JVM to run the tests on. >>> >>> Is it possible to keep this going, or would that require a lot of >>> work? I notice that javah no longer seems to exist. >>> >>> (Note I know almost nothing about how the modern JDK works) >>> >>> Rich. >> >> Hi, the functionality provided by javah has been folded into javac in >> recent JDKs. >> >> These days you can make one call to "javac -h" instead of having to >> call both "javac" and "javah" >> >> I ported quite a few packages this way when Fedora made the switch to >> Java 11 by default. If you like I can probably take a look libguestfs >> and send you a PR? > > Sure thing, thanks. > > However before you start you might also want to know that there are > apparently some serious GC-related problems with how those bindings > work: > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762 > > so it might be more of a saga than just changing a few commands. > > Rich. As the person who reported that bug, I don’t think it is likely to be hit normally. Most of the problems are either poor performance (not using direct ByteBuffers) or potential crashes in low memory conditions (which most users will not run into). I do not believe that any of these crashes are exploitable. That said, I am also unsure if anyone is using those bindings. Why were they added originally? Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Mon, Sep 27, 2021 at 9:09 PM Florian Weimer wrote: > > * Christopher: > > > My main point here was that treating the community as a single SIG > > makes no more sense than treating all packages whose software is > > written in C as a single "C SIG" community. It's too overwhelming for > > people to be able to know how to step in and help. > > I'm not sure this is actually true. Debian has Python and Perl > packaging teams which are quite successful, and the Java packaging may > also be in better shape there. > > I think the difference to C is that these languages come with their own > packaging/build systems, so creating a distribution package needs a > certain number of kludges, but once you've figured those out, you can > maintain a large number of packages. I thought that Java used to be > like this, too, thanks to ant and later Maven, but maybe this has > changed with Gradle, SBT, and whatnot. Yeah, there's good tooling support for packaging software that uses ant and maven. And ant and maven themselves will also continue to be maintained by Mikolaj, as far as I know. Projects that use "pure" ant or maven to handle their dependencies and build are *very easy* to package for Fedora, probably even easier than some standard C or Python packages. And the resulting binary packages are also very similar to how Python works (except that Java packages only ship compiled bytecode and no sources). But as you guessed, there's no such support for gradle, sbt, bazel, or whatever new build system Google has been cooking up recently. Nor is there support for Groovy (no longer available in Fedora, as it depended on gradle), Kotlin (was never packaged), or Scala (no longer available) - all of which are now dependencies of gradle. Oh, fun. While gradle *used* to be available as an option for Fedora Java packages, recent versions of gradle are a barely-open-source mess that apparently only upstream itself manages to build from source, and everybody else is supposed to "just build with internet access and use our binary JAR, it's fine (TM)". Another problem is projects that use ant or maven, but do horrendous, nonstandard things *within* those build systems, either with custom ant targets, or weird maven plugins. Maintaining packages that do this sort of thing is very tedious and error-prone, because you as the package maintainer need to keep all the weird "undo this unspeakable upstream horror" changes in sync for new upstream versions. And if upstream decides to port their project from maven to gradle (as some have recently done), then good luck with forward-porting the old maven pom.xml files to new versions. I'm sorry if I sound overly negative here. But the fact that 1) using maven is actually not terrible for making RPM packages, 2) packaging tools for Java are actually pretty comprehensive, but still 3) upstream projects are increasingly doing non-standard things making tools in 1) and 2) obsolete and packaging a very frustrating experience, makes me sad. But since most upstream projects stance is to "just download the JAR we built for you from Maven Central, why are you even looking at our source code, ewww", that is unlikely to change. But I'm not sure if that really fits the FOSS definition any longer, either. 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
Fedora 35 compose report: 20210928.n.0 changes
OLD: Fedora-35-20210927.n.0 NEW: Fedora-35-20210928.n.0 = SUMMARY = Added images:2 Dropped images: 0 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 = Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-35-20210928.n.0.aarch64.raw.xz Image: SoaS raw-xz aarch64 Path: Spins/aarch64/images/Fedora-SoaS-35-20210928.n.0.aarch64.raw.xz = DROPPED IMAGES = = 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
[Test-Announce] Fedora Linux 35 Beta Release Announcement
Fedora Linux 35 Beta Released -- The Fedora Project is pleased to announce the immediate availability of Fedora 35 Beta, the next step towards our planned Fedora 35 release at the end of October. Download the prerelease from our Get Fedora site: * Get Fedora 35 Beta Workstation: https://getfedora.org/workstation/download/ * Get Fedora 35 Beta Server: https://getfedora.org/server/download/ * Get Fedora 35 IoT: https://getfedora.org/iot/download/ Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices: * Get Fedora 35 Beta Spins: https://spins.fedoraproject.org/prerelease * Get Fedora 35 Beta Labs: https://labs.fedoraproject.org/prerelease * Get Fedora 35 Beta ARM: https://arm.fedoraproject.org/prerelease ## Beta Release Highlights * Fedora 35 Workstation Beta includes GNOME 41 * Fedora Kinoite—a KDE Plasma environment based on rpm-ostree technology * Fedora Linux 35 builds on the switch to PipeWire for managing audio by introducing WirePlumber as the default session manager. * Python 3.10, Perl 5.34, PHP 8.0 updated versions. * And more ... For more details about the release, read the full announcement at * https://fedoramagazine.org/announcing-fedora-35-beta/ or look for the prerelease pages in the download sections at * https://getfedora.org/ Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the t...@lists.fedoraproject.org mailing list or in #fedora-qa on Libera Chat. Regards, Mohan Boddu Fedora Release Engineering. ___ 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
Fedora-Rawhide-20210928.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 4 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud Failed openQA tests: 15/206 (x86_64), 9/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210927.n.1): ID: 1004380 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1004380 ID: 1004393 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1004393 ID: 1004397 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1004397 ID: 1004402 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1004402 ID: 1004417 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/1004417 ID: 1004450 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/1004450 ID: 1004465 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1004465 ID: 1004582 Test: x86_64 universal install_sata **GATING** URL: https://openqa.fedoraproject.org/tests/1004582 ID: 1004650 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/1004650 ID: 1004688 Test: aarch64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/1004688 Old failures (same test failed in Fedora-Rawhide-20210927.n.1): ID: 1004432 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1004432 ID: 1004438 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/1004438 ID: 1004440 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1004440 ID: 1004443 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1004443 ID: 1004445 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1004445 ID: 1004488 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1004488 ID: 1004531 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1004531 ID: 1004547 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1004547 ID: 1004554 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1004554 ID: 1004587 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/1004587 ID: 1004654 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1004654 ID: 1004685 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1004685 ID: 1004707 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1004707 ID: 1004709 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1004709 Soft failed openQA tests: 4/206 (x86_64), 3/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210927.n.1): ID: 1004414 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1004414 ID: 1004456 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1004456 ID: 1004457 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1004457 ID: 1004468 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1004468 ID: 1004477 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1004477 ID: 1004534 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1004534 ID: 1004561 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1004561 Passed openQA tests: 187/206 (x86_64), 129/141 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210927.n.1): ID: 1004350 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1004350 ID: 1004352 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1004352 ID: 1004427 Test: x86_64 Workstation-live-iso desktop_login URL:
Re: Fedora Java: The Death of Two SIGs
> Yeah, there's good tooling support for packaging software that uses > ant and maven. > And ant and maven themselves will also continue to be maintained by > Mikolaj, as far as I know. > Projects that use "pure" ant or maven to handle their dependencies and > build are *very easy* to package for Fedora, probably even easier than > some standard C or Python packages. You're not wrong. Thanks to great tooling, there's many Java packages in Fedora whose spec file is simply this: %build %mvn_build %install %mvn_install However, I do feel the pain of upstream projects switching to gradle, not because they are experiencing problems with maven that gradle was designed to solve, but just because it's trendy. I personally ported several projects back over to maven build system to keep something vital in the distro. It's not difficult (maybe, for someone who has been using maven years and years and years), but quite tedious. -- Mat Booth http://fedoraproject.org/get-fedora ___ 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-35-20210928.n.0 compose check report
No missing expected images. Failed openQA tests: 10/204 (x86_64), 6/141 (aarch64) New failures (same test not failed in Fedora-35-20210927.n.0): ID: 1004738 Test: x86_64 Server-dvd-iso install_blivet_resize_lvm URL: https://openqa.fedoraproject.org/tests/1004738 ID: 1004751 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/1004751 ID: 1004765 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/1004765 ID: 1004794 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1004794 ID: 1004822 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/1004822 ID: 1004907 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1004907 ID: 1004909 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1004909 ID: 1005000 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1005000 ID: 1005009 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1005009 Old failures (same test failed in Fedora-35-20210927.n.0): ID: 1004736 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/1004736 ID: 1004756 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/1004756 ID: 1004802 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1004802 ID: 1004891 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1004891 ID: 1004914 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1004914 ID: 1004956 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1004956 ID: 1005020 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1005020 Soft failed openQA tests: 4/204 (x86_64), 4/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20210927.n.0): ID: 1004776 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1004776 ID: 1004818 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1004818 ID: 1004819 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1004819 ID: 1004830 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1004830 ID: 1004837 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1004837 ID: 1004894 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1004894 ID: 1004903 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1004903 ID: 1004921 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1004921 Passed openQA tests: 131/141 (aarch64), 190/204 (x86_64) New passes (same test not passed in Fedora-35-20210927.n.0): ID: 1004848 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1004848 ID: 1004985 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1004985 ID: 1005039 Test: aarch64 universal upgrade_2_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1005039 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.03 to 0.28 Previous test data: https://openqa.fedoraproject.org/tests/1003310#downloads Current test data: https://openqa.fedoraproject.org/tests/1004729#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 packages(s) removed since previous compose: biosdevname System load changed from 0.71 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/1003352#downloads Current test data: https://openqa.fedoraproject.org/tests/1004771#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) removed since previous compose: biosdevname Previous test data: https://openqa.fedoraproject.org/tests/1003354#downloads Current test data: https://openqa.fedoraproject.org/tests/1004773#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.96 to 1.29 Previous test data: https://openqa.fedoraproject.org/tests/1003378#downloads Current test data:
[Fedocal] Reminder meeting : Fedora Source-git SIG
Dear all, You are kindly invited to the meeting: Fedora Source-git SIG on 2021-09-29 from 14:30:00 to 15:30:00 GMT At meet.google.com/mic-otnv-kse The meeting will be about: Bi-weekly meeting of the Fedora source-git SIG Agenda: https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open SIG Info: https://fedoraproject.org/wiki/SIGs/Source-git Source: https://calendar.fedoraproject.org//meeting/10074/ ___ 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: Packaging NW.js
I was provided a link for how to build... It looks "fun"... https://nwjs.readthedocs.io/en/latest/For%20Developers/Building%20NW.js/#building-nwjs Looks like the forked V8 as well. Thanks, Richard ___ 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: Packaging NW.js
On Tue, 2021-09-28 at 14:57 -0500, Richard Shaw wrote: > I'm not familiar with packaging stuff like this so could use some > pointers: > > https://github.com/nwjs/nw.js > > This is actually a prereq for another application I'd like to get in > Fedora. you can try use nodejs-packaging-bundler https://src.fedoraproject.org/rpms/nodejs-packaging/tree/rawhide (in the end of README.md "How to bundle nodejs libraries in Fedora") https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_using_tarballs_for_bundling nod...@lists.fedoraproject.org https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/44SXBQO74IZSYQNDT7DGYZYIVOD6KXMS/ > Thanks, > Richard > ___ > 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: Package Update Guide: Updating inter-dependent packages
I logged an issue about this for the Package Maintainer Docs [1]. Similarly to all other other issues in that list, I intend to do something about this at some point, unless somebody else beats me to it. [1]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/33 Otto Miro Hrončok kirjoitti 23.9.2021 klo 12.29: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages Says: """ You may need a buildroot override to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild bar against the new libfoo package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new libfoo build until it reached the stable state. To resolve this dilemma, you can request a buildroot override, which causes the libfoo build to be included in the buildroot for a short time in order to get the bar package build done. """ However, I think side-tags should be the preferred solution, as their impact is isolated. Buildroot overrides create temporary broken dependencies for everybody, while side-tags don't. My understanding was that this is the de-facto consensus, so I'd lie to update the docs to say something like: """ You may need to build the inter-dependent packages in a side tag. For instance in the case described above, you may need to rebuild bar against the new libfoo package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new libfoo build until it reached the stable state. To resolve this dilemma, you can request a side tag and build both packages in it, which causes the libfoo build to be included in the bar build's buildroot. """ And than instead of describing the details, link to https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ Any suggestions or objections? ___ 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 35 Beta Release Announcement
Fedora Linux 35 Beta Released -- The Fedora Project is pleased to announce the immediate availability of Fedora 35 Beta, the next step towards our planned Fedora 35 release at the end of October. Download the prerelease from our Get Fedora site: * Get Fedora 35 Beta Workstation: https://getfedora.org/workstation/download/ * Get Fedora 35 Beta Server: https://getfedora.org/server/download/ * Get Fedora 35 IoT: https://getfedora.org/iot/download/ Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices: * Get Fedora 35 Beta Spins: https://spins.fedoraproject.org/prerelease * Get Fedora 35 Beta Labs: https://labs.fedoraproject.org/prerelease * Get Fedora 35 Beta ARM: https://arm.fedoraproject.org/prerelease ## Beta Release Highlights * Fedora 35 Workstation Beta includes GNOME 41 * Fedora Kinoite—a KDE Plasma environment based on rpm-ostree technology * Fedora Linux 35 builds on the switch to PipeWire for managing audio by introducing WirePlumber as the default session manager. * Python 3.10, Perl 5.34, PHP 8.0 updated versions. * And more ... For more details about the release, read the full announcement at * https://fedoramagazine.org/announcing-fedora-35-beta/ or look for the prerelease pages in the download sections at * https://getfedora.org/ Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the t...@lists.fedoraproject.org mailing list or in #fedora-qa on Libera Chat. Regards, Mohan Boddu Fedora Release Engineering. ___ 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-09-29 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://calendar.fedoraproject.org//meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee
Just a reminder, I won't be there this week. If you want to have it anyway, someone should start the meeting. #topic Old Business - epel9-next #topic EPEL-7 #topic EPEL-8 #topic EPEL-Packaging-SIG #topic General Issues / Open Floor Troy On Tue, Sep 28, 2021 at 9:00 AM wrote: > Dear all, > > You are kindly invited to the meeting: >EPEL Steering Committee on 2021-09-29 from 16:00:00 to 17:00:00 > US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > This is the weekly EPEL Steering Committee Meeting. > > A general agenda is the following: > > #meetingname EPEL > #topic Intros > #topic Old Business > #topic EPEL-7 > #topic EPEL-8 > #topic EPEL-9 > #topic Openfloor > #endmeeting > > > > > Source: https://calendar.fedoraproject.org//meeting/9854/ > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2007171] Upgrade perl-App-Cme to 1.033
https://bugzilla.redhat.com/show_bug.cgi?id=2007171 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version|perl-App-Cme-1.033-1.fc36 |perl-App-Cme-1.033-1.fc36 ||perl-App-Cme-1.033-1.fc35 Last Closed||2021-09-29 00:17:32 --- Comment #3 from Fedora Update System --- FEDORA-2021-b62483f3fc has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2007171 ___ 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 2007048] perl-Convert-ASN1-0.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2007048 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Convert-ASN1-0.33-1.fc |perl-Convert-ASN1-0.33-1.fc |36 |36 ||perl-Convert-ASN1-0.33-1.fc ||35 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2021-09-29 00:17:16 --- Comment #3 from Fedora Update System --- FEDORA-2021-8e22452051 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2007048 ___ 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 2006104] perl-CPAN-Perl-Releases-5.20210920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006104 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210920-1.fc36 |0210920-1.fc36 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210920-1.fc35 |0210920-1.fc35 ||perl-CPAN-Perl-Releases-5.2 ||0210920-1.fc34 --- Comment #8 from Fedora Update System --- FEDORA-2021-9065b6d76f has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006104 ___ 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 2006104] perl-CPAN-Perl-Releases-5.20210920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006104 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210920-1.fc36 |0210920-1.fc36 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210920-1.fc35 |0210920-1.fc35 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0210920-1.fc34 |0210920-1.fc34 ||perl-CPAN-Perl-Releases-5.2 ||0210920-1.fc33 --- Comment #9 from Fedora Update System --- FEDORA-2021-d85315adc7 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006104 ___ 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 2006106] perl-libwww-perl-6.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006106 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-libwww-perl-6.57-1.fc3 |perl-libwww-perl-6.57-1.fc3 |5 |5 |perl-libwww-perl-6.57-1.fc3 |perl-libwww-perl-6.57-1.fc3 |4 |4 ||perl-libwww-perl-6.57-1.fc3 ||3 --- Comment #10 from Fedora Update System --- FEDORA-2021-7ee8628b0c has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006106 ___ 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 2006089] perl-Module-CoreList-5.20210920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006089 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0920-1.fc36 |0920-1.fc36 |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0920-1.fc35 |0920-1.fc35 |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0920-1.fc34 |0920-1.fc34 ||perl-Module-CoreList-5.2021 ||0920-1.fc33 --- Comment #15 from Fedora Update System --- FEDORA-2021-f2ec83380b has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006089 ___ 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 2006106] perl-libwww-perl-6.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006106 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-libwww-perl-6.57-1.fc3 |perl-libwww-perl-6.57-1.fc3 |5 |5 ||perl-libwww-perl-6.57-1.fc3 ||4 --- Comment #9 from Fedora Update System --- FEDORA-2021-3174250ec8 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006106 ___ 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 2000615] perl-Locale-Codes-3.68 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2000615 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Locale-Codes-3.68-1.fc |perl-Locale-Codes-3.68-1.fc |35 |35 |perl-Locale-Codes-3.68-1.fc |perl-Locale-Codes-3.68-1.fc |34 |34 ||perl-Locale-Codes-3.68-1.fc ||33 --- Comment #9 from Fedora Update System --- FEDORA-2021-3cabff8a9f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2000615 ___ 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 2008705] perl-Devel-Hide-0.0015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2008705 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/modules/by-module/Devel/Devel-Hide-0.0015.tar.gz to ./Devel-Hide-0.0015.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008705 ___ 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 2008705] New: perl-Devel-Hide-0.0015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2008705 Bug ID: 2008705 Summary: perl-Devel-Hide-0.0015 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-Hide Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.0015 Current version/release in rawhide: 0.0014-3.fc35 URL: http://search.cpan.org/dist/Devel-Hide/ 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/11938/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008705 ___ 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 1949278] perl-Net-Stomp-0.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949278 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version|perl-Net-Stomp-0.61-1.fc36 |perl-Net-Stomp-0.61-1.fc36 ||perl-Net-Stomp-0.61-1.fc35 Last Closed||2021-09-29 00:17:19 --- Comment #4 from Fedora Update System --- FEDORA-2021-a66952c302 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1949278 ___ 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 2006089] perl-Module-CoreList-5.20210920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2006089 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0920-1.fc36 |0920-1.fc36 |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |0920-1.fc35 |0920-1.fc35 ||perl-Module-CoreList-5.2021 ||0920-1.fc34 --- Comment #14 from Fedora Update System --- FEDORA-2021-5a67f40b92 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2006089 ___ 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 2008137] perl-DBIx-Connector-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2008137 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2021-936e9343a8 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-936e9343a8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-936e9343a8 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. https://bugzilla.redhat.com/show_bug.cgi?id=2008137 ___ 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
