[Bug 1699237] perl-Mojolicious-Plugin-CHI-0.15-7.fc29 FTBFS: tests fail with perl-Mojolicious-8.06
https://bugzilla.redhat.com/show_bug.cgi?id=1699237 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- perl-Mojolicious-Plugin-CHI-0.20-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fff1d008fc -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F29 to F30
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2019-03-01 at 13:52 +0800, Robin Lee wrote: > On Thu, Feb 28, 2019 at 5:23 PM Miroslav Suchý wrote: > > > > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > > try to run: > > > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 -- > > enablerepo=updates-testing distro-sync > > > > If you get this prompt: > > > > ... > > Total download size: XXX M > > Is this ok [y/N]: > > > > you can answer N and nothing happens, no need to test the real upgrade. > > Upgrades will be fine for you. > > > > But very likely you get some dependency problem now. In that case please > > report it against appropriate package. A quick upgrade test this morning with 30 beta and all current updates on a 'workstation' install. Issue: Downgrading: freerdp-libs x86_64 2:2.0.0-48.20190228gitce386c8.fc30 libwinpr x86_64 2:2.0.0-48.20190228gitce386c8.fc30 Info: Rawhide, f29 and f28 are all on -49, but 30 is not and no updates pending in testing. Regards Phil - -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Twitter: kathenasorg IRC: kathenas Web: https://kathenas.org Github: https://github.com/kathenas GitLab: https://gitlab.com/kathenas GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJcsp3QAAoJEDM/YNywubt3DpUQAKuv9+8EPvDs5DVdVFRfvZHC 7uFk0iFeGMSxIOpNM7BSNhBh8wjyMGGIH58upgg8pL1vJxGO3kg9JLIINwi6zBS/ WfDm4KDuHSM2cB9BUyNiuh1LgEedH8t2b+CDkg+NRo72+8MA98qEqcx78wdsWEdM 0kYdP0sUy4wf9uwp+tKc0sIx71Rei2RcElLH/5Ih82krtG78ffwWpv0iihAl0bNe 4G0TwLQ7UzCwCzZ5CGz/gapA2r8AWhpJtinDID8BgsfHOzHc4hEf+M8sgAJbb+95 NDHdBH5wiydilecP1/SMDmlFwari6mJyLhLCeB1HJjlHRQx2l6oBkD+/p5L4EhHn D6i7Abep+fhwck7TDecxLnqPQhxzqBuF2HlJAMpPdHrsTL6bw+f/zwLHFTHDEcR2 a3Nm88SZFXnMhVzAxqCqkmFL8xGDxk6RyAJzSAeonJ1EY32vufVP81smxhSqEHb8 +SC9KSlPrE3kDNQ/kocAr878nniHPHIWVoNwi2dQyt2H29HTGiYwZL9jf/XP1Xuo o5pno0Ek7RDHnuh8/Aw6kUoVKJ1Am1b+vEz9HMIA/s6gh52P2jeZR9fRqFWyQqHu /ksajAvmlQ5zhVzt9F6cjltLAoRzg2j4pRnGkdSOS7EcMcSdS1dG0YOtb6KBByOD 6ebOf+ltAvcQ9fJzgsth =ZnW2 -END 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-04-14 - 92% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/04/14/report-389-ds-base-1.4.1.2-20190413gitab94fc1.fc29.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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Fedora 30-20190413.n.1 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Failed openQA tests: 9/146 (x86_64), 1/2 (arm) ID: 382789 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/382789 ID: 382790 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/382790 ID: 382793 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/382793 ID: 382816 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/382816 ID: 382818 Test: x86_64 Silverblue-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/382818 ID: 382828 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/382828 ID: 382835 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/382835 ID: 382867 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/382867 ID: 382877 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/382877 ID: 382886 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/382886 Soft failed openQA tests: 4/146 (x86_64), 3/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 382745 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/382745 ID: 382746 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/382746 ID: 382776 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/382776 ID: 382777 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/382777 ID: 382795 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/382795 ID: 382796 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/382796 ID: 382799 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/382799 Passed openQA tests: 133/146 (x86_64), 21/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 compose report: 20190413.n.1 changes
OLD: Fedora-30-20190412.n.0 NEW: Fedora-30-20190413.n.1 = SUMMARY = Added images:5 Dropped images: 5 Added packages: 23 Dropped packages:1 Upgraded packages: 198 Downgraded packages: 0 Size of added packages: 81.43 MiB Size of dropped packages:62.50 KiB Size of upgraded packages: 6.91 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 45.43 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190413.n.1.s390x.qcow2 Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190413.n.1.s390x.raw.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190413.n.1.s390x.vmdk Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-30-20190413.n.1.iso Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-30-20190413.n.1.iso = DROPPED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-30-20190412.n.0-sda.raw.xz Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190412.n.0.x86_64.vagrant-libvirt.box Image: LXDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXDE-armhfp-30-20190412.n.0-sda.raw.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-30-20190412.n.0.x86_64.vagrant-virtualbox.box Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-30-20190412.n.0.iso = ADDED PACKAGES = Package: gnome-books-3.32.0-2.fc30 Summary: E-Book Manager RPMs:gnome-books Size:1.92 MiB Package: golang-github-alexcesaro-quotedprintable-v3-3.0.0-1.fc30 Summary: A Go package concerning quoted-printable encoding RPMs:golang-github-alexcesaro-quotedprintable-v3-devel golang-gopkg-3-alexcesaro-quotedprintable-devel golang-gopkg-alexcesaro-quotedprintable-3-devel Size:56.96 KiB Package: golang-github-armon-consul-api-0-0.1.20190408giteb2c6b5.fc30 Summary: Golang API client for Consul RPMs:golang-github-armon-consul-api-devel Size:27.60 KiB Package: golang-github-bufio-v1-1.0.0-1.fc30 Summary: Package bufio implements buffered I/O RPMs:golang-github-bufio-v1-devel golang-gopkg-1-bufio-devel golang-gopkg-bufio-1-devel Size:86.68 KiB Package: golang-github-eapache-xerial-snappy-0-0.1.20190408git776d571.fc30 Summary: Xerial-compatible Snappy framing support for golang RPMs:golang-github-eapache-xerial-snappy-devel Size:14.38 KiB Package: golang-github-facebookarchive-inject-0-0.1.20190326gitf23751c.fc30 Summary: Package inject provides a reflect based injector RPMs:golang-github-facebookarchive-inject-devel Size:18.72 KiB Package: golang-github-facebookarchive-structtag-0-0.1.20190327git217e25f.fc30 Summary: Package structtag provides parsing of the defacto struct tag style RPMs:golang-github-facebookarchive-structtag-devel Size:11.15 KiB Package: golang-github-grpc-ecosystem-middleware-1.0.0-1.fc30 Summary: Golang gRPC Middlewares: interceptor chaining, auth, logging, retries and more RPMs:golang-github-grpc-ecosystem-middleware-devel Size:86.61 KiB Package: golang-github-mail-v2-2.3.1-1.fc30 Summary: Gomail is a simple and efficient package to send emails RPMs:golang-github-mail-v2-devel golang-gopkg-mail-2-devel Size:55.88 KiB Package: golang-github-masterminds-semver-1-1.4.2-1.fc30 Summary: Work with semantic versions in go RPMs:golang-github-masterminds-semver-1-devel Size:137.54 KiB Package: golang-github-mattn-pointer-0-0.1.20190408git49522c3.fc30 Summary: Utility for cgo RPMs:golang-github-mattn-pointer-devel Size:9.34 KiB Package: golang-github-tmc-grpc-websocket-proxy-0-0.1.20190408git0ad062e.fc30 Summary: A proxy to transparently upgrade grpc-gateway streaming endpoints to use websockets RPMs:golang-github-tmc-grpc-websocket-proxy-devel Size:13.29 KiB Package: golang-github-vividcortex-mysqlerr-0-0.1.20190326git6c6b55f.fc30 Summary: MySQL server error constants RPMs:golang-github-vividcortex-mysqlerr-devel Size:21.77 KiB Package: golang-uber-zap-1.9.1-1.fc30 Summary: Blazing fast, structured, leveled logging in Go RPMs:golang-uber-zap-devel Size:114.38 KiB Package: luxcorerender-2.2-0.2.alpha1.fc30 Summary: LuxCore Renderer, an unbiased rendering system RPMs:blender-luxcorerender luxcorerender luxcorerender-core luxcorerender-devel luxcorerender-libs Size:34.47 MiB Package: nsdiff-1.77-1.fc30 Summary: create an "nsupdate" script from DNS zone file differences RPMs:nsdiff Size:32.15 KiB Package: ocaml-ocp-indent-1.7.0-2.fc30 Summary: A simple tool to indent OCaml programs RPMs:ocaml-ocp-indent ocaml-ocp-indent-devel Size:7.58 MiB Package: oidn-0.8.2-4.fc30 Summary: Library of denoising filters for images rendered with ray tr
Re: Can we use SCLs for building for EPEL 6?
Neal Gompa wrote: > If devtoolset is available for EPEL6 (which I think it is?) I don't believe devtoolset was enabled for el6 in koji. When it was added to the mock configs for el6/el7, the consensus on the epel list was that it would be added to el6 if there was sufficient demand. I've only seen it come up once (or maybe twice) since then on the epel list. I'm not familiar enough with the koji commands to confirm it. I can see that rhel7-server-rhscl-7 is listed in the external repos, but I don't see a similar rhel6 SCL. Apologies if I simply missed an announcement on the epel lists and am passing on outdated data. -- Todd 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 43 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-06b243cced guacamole-server-1.0.0-1.el6 23 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-62f9745b71 drupal7-7.65-1.el6 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8d5207833a ntfs-3g-2017.3.23-11.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-73e99f4a82 python34-3.4.10-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing python-whoosh-2.7.4-3.el6 python3-jinja2-2.8.1-2.el6 Details about builds: python-whoosh-2.7.4-3.el6 (FEDORA-EPEL-2019-7569fe8565) Fast, pure-Python full text indexing, search, and spell checking library Update Information: Update to 2.7.4 Build for python 3.4 ChangeLog: * Wed Oct 12 2016 Orion Poplawski - 2.7.4-3 - Ship python2-whoosh - Build python3 package for EPEL7 - Modernize spec * Mon May 2 2016 Robert Kuska - 2.7.4-1 - Update to 2.7.4 python3-jinja2-2.8.1-2.el6 (FEDORA-EPEL-2019-9f732040bd) General purpose template engine Update Information: Update to 2.8.1 Security fix for CVE-2016-10745 Security fix for CVE-2019-10906 ChangeLog: * Sat Apr 13 2019 Orion Poplawski - 2.8.1-2 - Backport fix for CVE-2016-10745 (bugz#1698839) * Sat Apr 13 2019 Orion Poplawski - 2.8.1-1 - Update to 2.8.1 (CVE-2016-10745 bugz#1698350) * Thu Apr 4 2019 Orion Poplawski - 2.8-4 - Build for python3_other * Thu Mar 7 2019 Troy Dawson - 2.8-3 - Rebuilt to change main python from 3.4 to 3.6 References: [ 1 ] Bug #1698345 - CVE-2016-10745 python-jinja2: Sandbox escape due to information disclosure via str.format https://bugzilla.redhat.com/show_bug.cgi?id=1698345 [ 2 ] Bug #1698839 - CVE-2019-10906 python-jinja2: str.format_map allows sandbox escape https://bugzilla.redhat.com/show_bug.cgi?id=1698839 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
On Sat, Apr 13, 2019 at 4:37 PM Jonathan Dieter wrote: > > On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote: > > > Unfortunately, the gcc in EL6 is too old to build zchunk > > > > In what specific way(s)? Can the complaints from gcc [which version?], > > or other tools in the toolchain, be listed here? > > Other developers may have faced the same or similar problems, > > and may have tools to help. > > Sorry, I should have shared that the first time around. > > The version of gcc that comes with EL6 is 4.4.7. > > When building zchunk, I get a number of messages that look like: > $ ninja-build > [1/178] Compiling C object 'src/lib/zck@sha/comp_zstd_zstd.c.o'. > FAILED: src/lib/zck@sha/comp_zstd_zstd.c.o > cc -Isrc/lib/zck@sha -Isrc/lib -I../src/lib -Iinclude -I../include -pipe > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O0 -g -DZCHUNK_ZSTD > -DZCHUNK_OPENSSL -fvisibility=hidden -fPIC -MMD -MQ > 'src/lib/zck@sha/comp_zstd_zstd.c.o' -MF > 'src/lib/zck@sha/comp_zstd_zstd.c.o.d' -o > 'src/lib/zck@sha/comp_zstd_zstd.c.o' -c ../src/lib/comp/zstd/zstd.c > In file included from ../src/lib/comp/zstd/zstd.c:34: > ../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx' > include/zck.h:49: note: previous declaration of 'zckCtx' was here > ../src/lib/zck_private.h:106: error: redefinition of typedef 'zck_log_type' > include/zck.h:47: note: previous declaration of 'zck_log_type' was here > ../src/lib/zck_private.h:117: error: redefinition of typedef 'zckHash' > include/zck.h:50: note: previous declaration of 'zckHash' was here > ../src/lib/zck_private.h:150: error: redefinition of typedef 'zckDL' > include/zck.h:54: note: previous declaration of 'zckDL' was here > ../src/lib/zck_private.h:165: error: redefinition of typedef 'zckChunk' > include/zck.h:51: note: previous declaration of 'zckChunk' was here > ../src/lib/zck_private.h:177: error: redefinition of typedef 'zckIndex' > include/zck.h:52: note: previous declaration of 'zckIndex' was here > ../src/lib/zck_private.h:193: error: redefinition of typedef 'zckRange' > include/zck.h:53: note: previous declaration of 'zckRange' was here > ../src/lib/zck_private.h:224: error: redefinition of typedef 'zckComp' > ../src/lib/zck_private.h:91: note: previous declaration of 'zckComp' was here > ../src/lib/zck_private.h:298: error: redefinition of typedef 'zckCtx' > ../src/lib/zck_private.h:92: note: previous declaration of 'zckCtx' was here > > For reference, you can find zck.h.in (which gets processed into zck.h > with the version added) at: > https://github.com/zchunk/zchunk/blob/master/include/zck.h.in > > and zck_private.h at: > https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h > > As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same > struct to the same type twice. Later versions don't see it as a > problem at all. > > (Just to be clear, this still happens if I change zck_private.h to say: > typedef struct zckCtx zckCtx;) > If devtoolset is available for EPEL6 (which I think it is?), you can simply use it by doing the following: Insert into BRs: BuildRequires: devtoolset-7-toolchain Then add to top of %build: source /opt/rh/devtoolset-7/enable -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
In file included from ../src/lib/comp/zstd/zstd.c:34:
../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx'
include/zck.h:49: note: previous declaration of 'zckCtx' was here
As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same
struct to the same type twice. Later versions don't see it as a
problem at all.
How about this:
#ifndef zckCtx_DEFINED /*{ workaround for gcc-4.4.7 */
#define zckCtx_DEFINED 1 /* gcc-4.4.7 demands only one declaration of a
typedef */
typedef struct zckCtx zckCtx;
#endif /*}*/
and similarly for the other 8 "multiply-defined" typedefs? After
pre-processing,
then the compiler will see exactly one definition of the typedef.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote: > > Unfortunately, the gcc in EL6 is too old to build zchunk > > In what specific way(s)? Can the complaints from gcc [which version?], > or other tools in the toolchain, be listed here? > Other developers may have faced the same or similar problems, > and may have tools to help. Sorry, I should have shared that the first time around. The version of gcc that comes with EL6 is 4.4.7. When building zchunk, I get a number of messages that look like: $ ninja-build [1/178] Compiling C object 'src/lib/zck@sha/comp_zstd_zstd.c.o'. FAILED: src/lib/zck@sha/comp_zstd_zstd.c.o cc -Isrc/lib/zck@sha -Isrc/lib -I../src/lib -Iinclude -I../include -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O0 -g -DZCHUNK_ZSTD -DZCHUNK_OPENSSL -fvisibility=hidden -fPIC -MMD -MQ 'src/lib/zck@sha/comp_zstd_zstd.c.o' -MF 'src/lib/zck@sha/comp_zstd_zstd.c.o.d' -o 'src/lib/zck@sha/comp_zstd_zstd.c.o' -c ../src/lib/comp/zstd/zstd.c In file included from ../src/lib/comp/zstd/zstd.c:34: ../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx' include/zck.h:49: note: previous declaration of 'zckCtx' was here ../src/lib/zck_private.h:106: error: redefinition of typedef 'zck_log_type' include/zck.h:47: note: previous declaration of 'zck_log_type' was here ../src/lib/zck_private.h:117: error: redefinition of typedef 'zckHash' include/zck.h:50: note: previous declaration of 'zckHash' was here ../src/lib/zck_private.h:150: error: redefinition of typedef 'zckDL' include/zck.h:54: note: previous declaration of 'zckDL' was here ../src/lib/zck_private.h:165: error: redefinition of typedef 'zckChunk' include/zck.h:51: note: previous declaration of 'zckChunk' was here ../src/lib/zck_private.h:177: error: redefinition of typedef 'zckIndex' include/zck.h:52: note: previous declaration of 'zckIndex' was here ../src/lib/zck_private.h:193: error: redefinition of typedef 'zckRange' include/zck.h:53: note: previous declaration of 'zckRange' was here ../src/lib/zck_private.h:224: error: redefinition of typedef 'zckComp' ../src/lib/zck_private.h:91: note: previous declaration of 'zckComp' was here ../src/lib/zck_private.h:298: error: redefinition of typedef 'zckCtx' ../src/lib/zck_private.h:92: note: previous declaration of 'zckCtx' was here For reference, you can find zck.h.in (which gets processed into zck.h with the version added) at: https://github.com/zchunk/zchunk/blob/master/include/zck.h.in and zck_private.h at: https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same struct to the same type twice. Later versions don't see it as a problem at all. (Just to be clear, this still happens if I change zck_private.h to say: typedef struct zckCtx zckCtx;) Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
Unfortunately, the gcc in EL6 is too old to build zchunk In what specific way(s)? Can the complaints from gcc [which version?], or other tools in the toolchain, be listed here? Other developers may have faced the same or similar problems, and may have tools to help. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Can we use SCLs for building for EPEL 6?
So, the background is that I'd like to build zchunk for EPEL 6 (it's already built for EPEL 7). Unfortunately, the gcc in EL6 is too old to build zchunk, so I'd prefer to use a newer version from an SCL, rather than rewrite zchunk to be compatible with an ancient version of gcc. I noticed that SCLs are available for EPEL 7 (note the final repository in the list at https://koji.fedoraproject.org/koji/taginfo?tagID=259), but not for EPEL 6 (see https://koji.fedoraproject.org/koji/taginfo?tagID=140). So, is there any way we can use SCLs for building on EPEL 6, or should I stop tilting at windmills and just say EL6 is too old for zchunk? Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Updating/rebuilding of coin-or packages
Dear list.
I see often this "packaging style" of the documentation files:
%doc %{_docdir}/%{name}/html
Is it correct tagging an absolute path with %doc?
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.fedoraproject.org/
signature.asc
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190413.n.0 compose check report
Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 4 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 21/146 (x86_64), 1/2 (arm), 5/24 (i386) ID: 382298 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/382298 ID: 382302 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/382302 ID: 382320 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/382320 ID: 382325 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/382325 ID: 382553 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/382553 ID: 382561 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/382561 ID: 382562 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/382562 ID: 382565 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/382565 ID: 382566 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/382566 ID: 382567 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/382567 ID: 382568 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/382568 ID: 382569 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/382569 ID: 382591 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/382591 ID: 382592 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/382592 ID: 382593 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/382593 ID: 382597 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/382597 ID: 382601 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/382601 ID: 382602 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/382602 ID: 382613 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/382613 ID: 382614 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/382614 ID: 382616 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/382616 ID: 382617 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/382617 ID: 382620 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/382620 ID: 382621 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/382621 ID: 382622 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/382622 ID: 382623 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/382623 ID: 382675 Test: x86_64 Silverblue-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/382675 Soft failed openQA tests: 12/146 (x86_64), 3/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 382304 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/382304 ID: 382345 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/382345 ID: 382348 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/382348 ID: 382400 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/382400 ID: 382401 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/382401 ID: 382402 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/382402 ID: 382403 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/382403 ID: 382478 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/382478 ID: 382543 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/382543 ID: 382544 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/382544 ID: 382545 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/382545 ID: 382546 Test: i386 Server-boot-iso install_default
[Bug 1694424] perl-Inline-Files-0.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1694424 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Inline-Files-0.71-1.fc |perl-Inline-Files-0.71-1.fc |31 |31 |perl-Inline-Files-0.71-1.fc |perl-Inline-Files-0.71-1.fc |30 |30 |perl-Inline-Files-0.71-1.fc |perl-Inline-Files-0.71-1.fc |28 |28 ||perl-Inline-Files-0.71-1.fc ||29 --- Comment #11 from Fedora Update System --- perl-Inline-Files-0.71-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1694428] perl-ExtUtils-CBuilder-0.280231 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1694428 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-ExtUtils-CBuilder-0.28 |perl-ExtUtils-CBuilder-0.28 |0231-1.fc31 |0231-1.fc31 |perl-ExtUtils-CBuilder-0.28 |perl-ExtUtils-CBuilder-0.28 |0231-1.fc30 |0231-1.fc30 |perl-ExtUtils-CBuilder-0.28 |perl-ExtUtils-CBuilder-0.28 |0231-1.fc28 |0231-1.fc28 ||perl-ExtUtils-CBuilder-0.28 ||0231-1.fc29 --- Comment #10 from Fedora Update System --- perl-ExtUtils-CBuilder-0.280231-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1694465] perl-Inline-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1694465 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Inline-0.82-1.fc31 |perl-Inline-0.82-1.fc31 |perl-Inline-0.82-1.fc30 |perl-Inline-0.82-1.fc30 |perl-Inline-0.82-1.fc28 |perl-Inline-0.82-1.fc28 ||perl-Inline-0.82-1.fc29 --- Comment #10 from Fedora Update System --- perl-Inline-0.82-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Could not execute import_srpm
We tracked this down to the most recent Fedora 29 httpd update. Things should be fixed now, can everyone who had problems uploading please try now and if you still have an issue, open a ticket or reopen the upload ticket ( https://pagure.io/fedora-infrastructure/issue/7704 ) Thanks and sorry for the hassles. ;( kevin signature.asc 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1698803] Upgrade perl-File-Slurp to 9999.27
https://bugzilla.redhat.com/show_bug.cgi?id=1698803 --- Comment #4 from Fedora Update System --- perl-File-Slurp-.27-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b4383b7c3d -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, 12 Apr 2019 11:21:13 +0200 Lennart Poettering wrote: > On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosow...@nist.gov) > wrote: > > > > The logic in systemd is more strict on putting boundaries on > > > resource usage, and thus will by default not allow you to consume > > > resources while you are not logged in. It's really how this > > > always should have been designed. However, we fully acknowledge > > > that there are many uses where the ability to run stuff > > > independently of any login as your own user is fine, but you need > > > to turn on lingering for that (which is privileged), so that this > > > is explicitly marked OK. > > > > It IS very useful for systemctl to prevent resource leaks by > > killing errant processes (hanging browser, etc)---however, as we > > discussed, some processes should not be killed; I know which > > processes I want to annoint this way, and I take responsibility for > > their possible misbehavior. > > > > I understand that set-linger disables process harvesting for all > > processes in the session, though, and I would like to just do it > > only for SOME processes. > > If you enable lingering for a user, it's the "systemd --user" instance > (i.e. the per-user service manager) that is started at boot and > terminated at shutdown (instead of started at first login and > terminated at last logout of the user), that's all. > > If you then run code as user service (i.e. as a service started and > managed by the "systemd --user" instance instead of PID 1) then it is > lifecycled (and its processes killed as needed) by the user service > manager. And you can configure the way you want killing to behave like > you would for any systemd service: with KillMode= in the unit file. This doesn't really fit with the security requirements we need. Anything run outside of a user session needs to have an audit session id and login uid assigned to anything run. We also need to have the ability to know the name of the script that is being run in an audit event. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, 12 Apr 2019 10:01:33 +0200 Dridi Boukelmoune wrote: > > Was this the privileged operation? What privilege does it require? I > > just run the command as a non-admin user and saw no errors or > > prompts for passwords or anything. > > Are you part of the wheel group No, this account does not have wheel. That's what I meant by non-sysadmin acct. > and is wheel configured to be password-less in sudo? Default F29 sudo config. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introduction for gaming packaging/maintaining
Hi Andi, clones are usually ok, as long as they are clean-room reimplementations and do not redistribute the original games' assets, which most of them according to my knowledge don't. For the other games a flatpak would be probably the best fit, as flatpaks can contain more or less arbitrary dependencies and also be closed source. Cheers, Dan Karsten Andreas Artz writes: > Hi Dan, > I’ve checked again and I guess the clones should be the one which can be > included on Fedora, can’t they? > Let me list my favors: Pizza Buisness, FreeRails, Jagged Alliance 2 - > Steaciatella. > This should be not proprietary, shouldn’t they? > Thx in forward! > Cheers > Andi > > Sent from Yahoo Mail for iPhone > > > On Wednesday, April 10, 2019, 10:30 AM, Dan Čermák > wrote: > > Hi Andi, > > the games you listed are proprietary and can thus not be shipped with > Fedora. > > What you could do, is to try to improve the out of the box experience > when trying to install and play these games. But that is quite an > undertaking as that will require diving into the guts of wine. > > My recommendation would be: find something in Fedora that annoys you or > that you think it lacks and try to work on that. > > > Cheers, > > Dan > > Karsten Andreas Artz writes: > >> Hi Dan, >> thx for welcoming me to the pack! >> I’ve skimmed through the games. I have different games in favor: Raildroad >> Tycoon, Pizza Tycoon and escape from Monkey Island. >> What are the first steps to start? >> Thx in forward >> Cheers >> Andi >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Tuesday, April 9, 2019, 10:48 AM, Dan Čermák >> wrote: >> >> Hi Andi, >> >> welcome to the pack! >> >> You can try to review some packages or submit your own package, whatever >> you feel like doing (if you submit a package, you'll need to get >> sponsored though and reviewing packages is a good way how to get >> sponsored). >> >> In case you want to package some games, there's a pretty long list of >> open source game clones: https://osgameclones.com/ >> Most of these are afaik not in Fedora (yet) and some smaller ones could >> be a nice start (although you should watch out for licensing issues). >> >> In case you are looking for other ways to contribute, there's always >> this site: https://whatcanidoforfedora.org/ >> >> >> Cheers, >> >> Dan >> >> Karsten Andreas Artz writes: >> >>> Hi Benson, >>> thx for welcoming me on Fedora and thx for providing the links. >>> I’ve read through them and skimmed them. >>> Should I start reviewing packages or do you have another idea? >>> Regards >>> Andi >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, April 8, 2019, 9:35 PM, Benson Muite >>> wrote: >>> >>> >>> Hi Andi, >>> Welcome to Fedora. Some general information is at: >>> https://docs.fedoraproject.org/en-US/project/ >>> The get involved page still needs an update: >>> https://docs.fedoraproject.org/en-US/project/join/ >>> but packaging guidelines are here: >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/ >>> >>> most people start by reviewing packages - though there are other ways to >>> contribute other than packaging. >>> >>> >>> >>> Regards, >>> Benson >>> >>> >>> On 4/8/19 7:32 PM, Karsten Andreas Artz wrote: >>> >>> >>> Hi guys, >>> my name is Andi, 29 and I'm from Germany. I'm using Fedora almost 2 years >>>(Fedora 26). My programming skills are on Python, Java/Java Script, and >>>C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts >>>History, Archaeology and Cath.Theology. Besides this, I can speak a lot of >>>languages: German, English, French, a bit Italian and Spanish. >>> >>> It would be glad starting contributing on Fedora as a maintainer. >>>Therefore I hope to work on a small project soon. >>> I'm interested in games packaging, but I don't know where to start. >>> >>> >>> Regards >>> Andi >>> >>> >>> >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >>> >>> >>> >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to
Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:43 PM Mikolaj Izdebski wrote: > > On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini wrote: > > > > On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski > > wrote: > > > > > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth wrote: > > > > Eclipse in Fedora has dropped support for 32 bit architectures. The > > > > newest builds of Eclipse 4.11 for F30 and newer reflect this and are > > > > built for 64 bit architectures only. > > > > > > > > By now I have touched most Eclipse plug-in packages to limit their > > > > availability to the same architectures as Eclipse itself. If you own a > > > > package that is not an Eclipse plug-in but it does have a build or > > > > runtime dependency on Eclipse, then you will need to follow suit and > > > > make your package also exclude 32 bit architecture. If your package > > > > simply depends on Eclipse/Equinox for OSGi APIs, then you might be > > > > better switching your package to build against the OSGi APIs provided > > > > by the osgi-core/osgi-compendium packages instead to stay available on > > > > all architecture. Feel free to ping if you are unsure how to proceed. > > > > On koschei, I'm getting the following issues for the stewardship-sig > > packages (there are probably more, but builds don't always hit 32-bit > > builders): > > > > avalon-framework: > > Problem: package log4j-2.11.1-3.fc30.noarch requires > > mvn(org.eclipse.persistence:javax.persistence), but none of the > > providers can be installed > > - conflicting requests > > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > > > avalon-logkit: > > Problem: package log4j-2.11.1-3.fc30.noarch requires > > mvn(org.eclipse.persistence:javax.persistence), but none of the > > providers can be installed > > - conflicting requests > > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > > > log4j: > > Problem: conflicting requests > > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > > > If I understand correctly, that's a case where we should "switch" > > log4j to using the different "OSGi APIs" you mentioned? > > For now, I've added an "x86_64" arch override to these three packages > > in koschei, so we can see if they can build successfully on at least > > one architecture. > > First, some cotext: > Apache Log4j is a logging library. Among other possibilities, it can > log to a relational database through JPA [1]. > Log4j uses EclipseLink as it is the reference implementations of JPA. > EclipseLink (obviously) depends on Eclipse, which is now unavailable > on 32-bit arches. > But EclipseLink is not the only available implementation of JPA. We > also have other implementations packaged. The ones I am aware of: > Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA. > > Possible solutions that I can think of (in order from most to least > preferred): > 1. make EclipseLink not depend on Eclipse (but I don't how feasible > that would be) > 2. switch log4j to use different implementation of JPA (should be easy) > 3. disable JPA support in log4j (trivial, but will break users) > > [1] https://en.wikipedia.org/wiki/Java_Persistence_API Ah, I see. Thanks for the clarification. I've worked on a Project using springframework / JPA / hibernate before, but I didn't know how all the pieces fit together under the hood. So Option 1 would require help from the eclipse/EclipseLink maintainers? So ... Option 2 sounds like the probable outcome. Fabio > -- > Mikolaj Izdebski > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:42 PM Mikolaj Izdebski wrote: > But EclipseLink is not the only available implementation of JPA. We > also have other implementations packaged. The ones I am aware of: > Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA. Searching in Java Deptools [1] revealed that another packaged implementation is Apache Geronimo. [1] https://java-deptools.fedorainfracloud.org/?qtype=classes=f31=javax.persistence.EntityManager -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini wrote: > > On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski wrote: > > > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth wrote: > > > Eclipse in Fedora has dropped support for 32 bit architectures. The > > > newest builds of Eclipse 4.11 for F30 and newer reflect this and are > > > built for 64 bit architectures only. > > > > > > By now I have touched most Eclipse plug-in packages to limit their > > > availability to the same architectures as Eclipse itself. If you own a > > > package that is not an Eclipse plug-in but it does have a build or > > > runtime dependency on Eclipse, then you will need to follow suit and make > > > your package also exclude 32 bit architecture. If your package simply > > > depends on Eclipse/Equinox for OSGi APIs, then you might be better > > > switching your package to build against the OSGi APIs provided by the > > > osgi-core/osgi-compendium packages instead to stay available on all > > > architecture. Feel free to ping if you are unsure how to proceed. > > On koschei, I'm getting the following issues for the stewardship-sig > packages (there are probably more, but builds don't always hit 32-bit > builders): > > avalon-framework: > Problem: package log4j-2.11.1-3.fc30.noarch requires > mvn(org.eclipse.persistence:javax.persistence), but none of the > providers can be installed > - conflicting requests > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > avalon-logkit: > Problem: package log4j-2.11.1-3.fc30.noarch requires > mvn(org.eclipse.persistence:javax.persistence), but none of the > providers can be installed > - conflicting requests > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > log4j: > Problem: conflicting requests > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed > by eclipselink-persistence-api-2.1.0-7.fc30.noarch > > If I understand correctly, that's a case where we should "switch" > log4j to using the different "OSGi APIs" you mentioned? > For now, I've added an "x86_64" arch override to these three packages > in koschei, so we can see if they can build successfully on at least > one architecture. First, some cotext: Apache Log4j is a logging library. Among other possibilities, it can log to a relational database through JPA [1]. Log4j uses EclipseLink as it is the reference implementations of JPA. EclipseLink (obviously) depends on Eclipse, which is now unavailable on 32-bit arches. But EclipseLink is not the only available implementation of JPA. We also have other implementations packaged. The ones I am aware of: Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA. Possible solutions that I can think of (in order from most to least preferred): 1. make EclipseLink not depend on Eclipse (but I don't how feasible that would be) 2. switch log4j to use different implementation of JPA (should be easy) 3. disable JPA support in log4j (trivial, but will break users) [1] https://en.wikipedia.org/wiki/Java_Persistence_API -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski wrote: > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth wrote: > > Eclipse in Fedora has dropped support for 32 bit architectures. The newest > > builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 > > bit architectures only. > > > > By now I have touched most Eclipse plug-in packages to limit their > > availability to the same architectures as Eclipse itself. If you own a > > package that is not an Eclipse plug-in but it does have a build or runtime > > dependency on Eclipse, then you will need to follow suit and make your > > package also exclude 32 bit architecture. If your package simply depends on > > Eclipse/Equinox for OSGi APIs, then you might be better switching your > > package to build against the OSGi APIs provided by the > > osgi-core/osgi-compendium packages instead to stay available on all > > architecture. Feel free to ping if you are unsure how to proceed. On koschei, I'm getting the following issues for the stewardship-sig packages (there are probably more, but builds don't always hit 32-bit builders): avalon-framework: Problem: package log4j-2.11.1-3.fc30.noarch requires mvn(org.eclipse.persistence:javax.persistence), but none of the providers can be installed - conflicting requests - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by eclipselink-persistence-api-2.1.0-7.fc30.noarch avalon-logkit: Problem: package log4j-2.11.1-3.fc30.noarch requires mvn(org.eclipse.persistence:javax.persistence), but none of the providers can be installed - conflicting requests - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by eclipselink-persistence-api-2.1.0-7.fc30.noarch log4j: Problem: conflicting requests - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by eclipselink-persistence-api-2.1.0-7.fc30.noarch If I understand correctly, that's a case where we should "switch" log4j to using the different "OSGi APIs" you mentioned? For now, I've added an "x86_64" arch override to these three packages in koschei, so we can see if they can build successfully on at least one architecture. Fabio > I'd like to follow up on this. Right now many Java packages fail to > install and/or build on 32-bit arches (primary and secondary) in > Fedora 30 and rawhide to install or build. > > For example, for Apache Log4j (one of basic libraries that many other > packages depend on): > > Problem: package log4j-2.11.1-3.fc30.noarch requires > mvn(org.eclipse.persistence:javax.persistence), but none of the > providers can be installed > - conflicting requests > - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by > eclipselink-persistence-api-2.1.0-7.fc30.noarch > > Java modules (maven, ant, javapackages-tools) are not affected by this > issue and they continue to work and build on 32-bit arches. > > -- > Mikolaj Izdebski > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
