Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
Some results from a Rawhide podman container:
# koji download-build --arch x86_64 coreutils-9.0-1.fc36
# dnf install coreutils-common-9.0-1.fc36.x86_64.rpm
coreutils-9.0-1.fc36.x86_64.rpm
# git clone https://github.com/systemd/systemd
# cd systemd
# /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
# echo $?
1
Some further tests:
# mkdir test
# cd test
# touch testfile
# ln -s testfile testlink
# strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w .
execve("/usr/bin/chmod", ["/usr/bin/chmod", "-R", "a+rX,u+w,g-w,o-w", "."],
0x7ffc34d019f8 /* 13 vars */) = 0
brk(NULL) = 0x5589ce102000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc33618dc0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
... snip ...
newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
fchmodat(AT_FDCWD, ".", 0755) = 0
openat(AT_FDCWD, ".", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0
fcntl(3, F_GETFL) = 0x18800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fcntl(3, F_DUPFD_CLOEXEC, 3)= 4
getdents64(3, 0x5589ce107120 /* 4 entries */, 32768) = 112
getdents64(3, 0x5589ce107120 /* 0 entries */, 32768) = 0
close(3)= 0
newfstatat(4, "testfile", {st_mode=S_IFREG|0644, st_size=0, ...},
AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "testfile", 0644) = 0
newfstatat(4, "testlink", {st_mode=S_IFLNK|0777, st_size=8, ...},
AT_SYMLINK_NOFOLLOW) = 0
close(4)= 0
close(1)= 0
close(2)= 0
exit_group(1) = ?
+++ exited with 1 +++
However, with coreutils-8.32-31.fc36.x86_64:
# strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w .
... snip ...
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=346132, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 346132, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fcfb35d2000
close(3)= 0
umask(000) = 022
newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
fchmodat(AT_FDCWD, ".", 0755) = 0
openat(AT_FDCWD, ".", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0
fcntl(3, F_GETFL) = 0x18800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fcntl(3, F_DUPFD_CLOEXEC, 3)= 4
getdents64(3, 0x55748075f120 /* 4 entries */, 32768) = 112
getdents64(3, 0x55748075f120 /* 0 entries */, 32768) = 0
close(3)= 0
newfstatat(4, "testfile", {st_mode=S_IFREG|0644, st_size=0, ...},
AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "testfile", 0644) = 0
newfstatat(4, "testlink", {st_mode=S_IFLNK|0777, st_size=8, ...},
AT_SYMLINK_NOFOLLOW) = 0
close(4)= 0
close(1)= 0
close(2)= 0
exit_group(0) = ?
+++ exited with 0 +++
On 10/4/21 13:33, František Šumšal wrote:
I just noticed that as well in our systemd Packit runs, but so far
only on i386, because the repos for x86_64, ppc64le, and aarch64
are still on coreutils-8.32-32.fc36 (whereas i386 has
coreutils-9.0-1.fc36):
https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-20923/build/2873236/
https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-20926/build/2873203/
On 10/4/21 11:57, Miro Hrončok wrote:
Hello,
I see this failure in dnf in Copr and Koji:
https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/
https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf dnf-4.9.0
+ /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd dnf-4.9.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep)
Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep)
I am perplexed with the error.
Could it be some problem with updated coreutils?
___
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
--
PGP Key ID: 0xFB738CE27B634E4B
OpenPGP_signature
Description: OpenPGP digital signature
Fedora rawhide compose report: 20211004.n.0 changes
OLD: Fedora-Rawhide-20211003.n.0 NEW: Fedora-Rawhide-20211004.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 60 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 673.21 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 21.10 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20211004.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: asciinema-2.1.0-1.fc36 Old package: asciinema-2.0.2-8.fc35 Summary: Terminal session recorder RPMs: asciinema Size: 105.90 KiB Size change: 29.70 KiB Changelog: * Sun Oct 03 2021 Carl George - 2.1.0-1 - Latest upstream - Resolves: rhbz#2010110 Package: bcm283x-firmware-20210930-1.b5257da.fc36 Old package: bcm283x-firmware-20210921-1.f9bc224.fc36 Summary: Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware bcm283x-overlays Size: 13.71 MiB Size change: 6.46 KiB Changelog: * Sun Oct 03 2021 Peter Robinson 20210930-1.b5257da - Update to latest firmware Package: calc-2.14.0.3-1.fc36 Old package: calc-2.13.0.1-5.fc35 Summary: Arbitrary precision arithmetic system and calculator RPMs: calc calc-devel calc-libs calc-stdrc Size: 5.56 MiB Size change: 114.32 KiB Changelog: * Sun Oct 03 2021 Matthew Miller 2.14.0.3-1 - Update to "unstable" 2.14.0.3 release in rawhide. See upstream changelog. * Sat Aug 07 2021 Matthew Miller 2.13.0.1-6 - auto, auth, whatever * Wed Jul 21 2021 Fedora Release Engineering - 2.13.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Wed Apr 21 2021 Matthew Miller - 2.13.0.1-1 - update to new "stable" upstream release, which is the same as 2.13.0.0 but adds PREFIX to the makefile. So, change this spec file to use that instead of setting BINDIR, MANDIR, etc. separately. (Still need LIBDIR for lib64 though.) * Fri Apr 09 2021 Matthew Miller - 2.13.0.0-1 - update to new "unstable" upstream release. - Includes incompatible change to "argv()" function * Thu Mar 04 2021 Matthew Miller - 2.12.8.2-1 - new upstream stable release - the value of exponent expressins which equal zero (like 0^(0) or 0^zero where zero is a variable with value 0) is now 1, just like 0^0 - Calc shell scripts now need to be called with and -s -f at the end of the shebang #! line. - set ARCH_CFLAGS to nothing, because otherwise it will now default to putting -march=native in there, which reduces portability and may conflict with rpm opt flags. * Tue Jan 26 2021 Fedora Release Engineering - 2.12.7.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 2.12.7.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Jan 28 2020 Fedora Release Engineering - 2.12.7.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild Package: catfish-4.16.3-2.fc36 Old package: catfish-4.16.3-1.fc36 Summary: A handy file search tool RPMs: catfish Size: 339.82 KiB Size change: 260 B Changelog: * Sun Oct 03 2021 Mamoru TASAKA - 4.16.3-2 - get_exo_preferred_file_manager: check if the requested key exists before actually use it (bug 2009994) Package: fakeroot-1.26-2.fc36 Old package: fakeroot-1.26-1.fc36 Summary: Gives a fake root environment RPMs: fakeroot fakeroot-libs Size: 667.81 KiB Size change: -624 B Changelog: * Sun Oct 03 2021 S??rgio Basto - 1.26-2 - Relax autoconf version - t.tar test, now just fail on ppc64le Package: gamehub-0.16.1.2-1.fc36 Old package: gamehub-0.16.0.1-4.fc35 Summary: All your games in one place RPMs: gamehub Size: 3.94 MiB Size change: 126.60 KiB Changelog: * Sun Oct 03 2021 Artem Polishchuk - 0.16.1.2-1 - Update to 0.16.1-2-master Package: gnome-shell-extension-gsconnect-48-1.fc36 Old package: gnome-shell-extension-gsconnect-47-2.fc35 Summary: KDE Connect implementation for GNOME Shell RPMs: gnome-shell-extension-gsconnect nautilus-gsconnect nemo-gsconnect webextension-gsconnect Size: 1.44 MiB Size change: 23.86 KiB Changelog: * Sun Oct 03 2021 Mohamed El Morabity - 48-1 - Update to 48 Package: golang-github-jedisct1-xsecretbox-1.0.2-1.fc36 Old package: golang-github-jedisct1-xsecretbox-1.0.1-3.fc35 Summary: Go implementation of crypto_secretbox_xchacha20poly1305 RPMs: golang-github-jedisct1-xsecretbox-d
Re: Fedora Java: The Death of Two SIGs
We had a spirited and detailed discussion so far. But nevertheless, I think we
are none the wiser at the moment. We have many informative contributions to the
discussion and analyses of the situation.
However, we lack concepts on how to proceed after removing java-maint-sig. What
consequences do we draw from the analyses?
Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts on
those? I posted on the java list some ideas some time ago ('Empowering Fedora
Java’). Any comments on those?
Peter
___
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: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On 04. 10. 21 14:06, Kamil Dudka wrote: On Monday, October 4, 2021 11:57:14 AM CEST Miro Hrončok wrote: Hello, I see this failure in dnf in Copr and Koji: https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf dnf-4.9.0 + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd dnf-4.9.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) I am perplexed with the error. Could it be some problem with updated coreutils? Yes. The error message comes from rpmbuild. chmod itself did not provide any diagnostic message. Is it possible to trigger the error locally? František was able to: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6MRWXL2UW6MPM7ONPNLZ4OFQVZFITQUG/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On 04. 10. 21 14:16, Kamil Dudka wrote: On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote: Some results from a Rawhide podman container: # koji download-build --arch x86_64 coreutils-9.0-1.fc36 # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm coreutils-9.0-1.fc36.x86_64.rpm # git clone https://github.com/systemd/systemd # cd systemd # /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . # echo $? 1 Some further tests: # mkdir test # cd test # touch testfile # ln -s testfile testlink # strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w . Thanks for the reproducer! This is a regression in the new upstream release: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-2-ge8b56ebd536 I will submit a fixed build as soon as I figure out how to untag the broken one: $ koji untag-build f36 coreutils-8.32-31.fc36 2021-10-04 14:16:18,518 [ERROR] koji: ActionNotAllowed: tag requires autosign permission It seems that coreutils itself builds fine, so there should be no need to untag jut to fix it: https://koji.fedoraproject.org/koji/taskinfo?taskID=76673896 But either way: to answer the question how to untag: You need a releng person to do that. Or, you can: $ fedpkg request-side-tag $ koji tag f36-build-side-12345 coreutils-8.32-32.fc36 $ koji wait-repo f36-build-side-12345 --build coreutils-8.32-32.fc36 $ fedpkg build --target f36-build-side-12345 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On Monday, October 4, 2021 2:24:22 PM CEST Miro Hrončok wrote: > On 04. 10. 21 14:16, Kamil Dudka wrote: > > On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote: > >> Some results from a Rawhide podman container: > >> > >> # koji download-build --arch x86_64 coreutils-9.0-1.fc36 > >> # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm > >> coreutils-9.0-1.fc36.x86_64.rpm > >> > > # git clone > >> > >> https://github.com/systemd/systemd > >> # cd systemd > >> # /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . > >> # echo $? > >> 1 > >> > >> Some further tests: > >> # mkdir test > >> # cd test > >> # touch testfile > >> # ln -s testfile testlink > >> # strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w . > > > > Thanks for the reproducer! This is a regression in the new upstream > > release: > > https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v > > 9.0-2-ge8b56ebd536> > > I will submit a fixed build as soon as I figure out how to untag the > > broken one: > > > > $ koji untag-build f36 coreutils-8.32-31.fc36 > > 2021-10-04 14:16:18,518 [ERROR] koji: ActionNotAllowed: tag requires > > autosign permission > It seems that coreutils itself builds fine, so there should be no need to > untag jut to fix it: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=76673896 Indeed. A build of coreutils with the upstream fix applied is running: https://koji.fedoraproject.org/koji/buildinfo?buildID=1840134 Thank you both for the help and sorry for the breakage! Kamil > But either way: to answer the question how to untag: You need a releng > person to do that. > > Or, you can: > > $ fedpkg request-side-tag > $ koji tag f36-build-side-12345 coreutils-8.32-32.fc36 > $ koji wait-repo f36-build-side-12345 --build coreutils-8.32-32.fc36 > $ fedpkg build --target f36-build-side-12345 ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-10-04.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change dnstracer orphan 4 weeks ago fedmodnphilipp, orphan 1 weeks ago golang-github-hanwen-fuse orphan 0 weeks ago golang-github-jacobsa-crypto orphan 0 weeks ago golang-github-jacobsa-oglemockorphan 0 weeks ago golang-github-jacobsa-ogletestorphan 0 weeks ago golang-github-jacobsa-reqtraceorphan 0 weeks ago golang-github-rfjakob-gocryptfs orphan 0 weeks ago golang-github-sabhiram- orphan 0 weeks ago gitignore jakarta-commons-httpclientjava-maint-sig, mizdebsk,6 weeks ago orphan kdevelop-python dvratil, jgrulich, kde-sig, 1 weeks ago orphan kdocker kde-sig, orphan, rdieter 1 weeks ago mingw-brotli etrunko, orphan 1 weeks ago mingw-libpsl etrunko, orphan 1 weeks ago mingw-libunistringetrunko, orphan 1 weeks ago perl-WebService-Dropbox mathstuf, orphan 1 weeks ago python-email_reply_parser orphan, python-sig 1 weeks ago python-first orphan, python-sig 1 weeks ago python-graphene-sqlalchemyorphan 1 weeks ago python-graphql-server orphan 1 weeks ago python-opencensus orphan 5 weeks ago python-parallel-ssh orphan 1 weeks ago python-pipreqsorphan, python-sig 1 weeks ago python-plette orphan, pkopkan, python-sig 1 weeks ago python-power orphan, python-sig 1 weeks ago python-ssh2-pythonorphan 1 weeks ago python-yarg orphan, python-sig 1 weeks ago rubygem-ancestry jaruga, orphan 1 weeks ago rubygem-cliverorphan 3 weeks ago rubygem-gem-patch orphan 3 weeks ago rubygem-scoped_search orphan 3 weeks ago trac-customfieldadmin-plugin orphan 1 weeks ago trac-watchlist-plugin orphan 1 weeks ago waiverdb lholecek, lucarval, orphan, 1 weeks ago ralph, vmaljulin yarockkde-sig, martinkg, orphan1 weeks ago The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2021-10-04.txt See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan Affected (co)maintainers (either directly or via packages' dependencies): berrange: mingw-libpsl, mingw-brotli, mingw-libunistring dcavalca: golang-github-hanwen-fuse dvratil: kdevelop-python eclipseo: golang-github-hanwen-fuse elmarco: mingw-libpsl, mingw-brotli, mingw-libunistring eparis: golang-github-hanwen-fuse etrunko: mingw-libpsl, mingw-brotli, mingw-libunistring fidencio: mingw-libpsl, mingw-brotli, mingw-libunistring fpokorny: golang-github-hanwen-fuse go-sig: golang-github-hanwen-fuse infra-sig: golang-github-hanwen-fuse jaruga: rubygem-ancestry
Re: Fedora Java: The Death of Two SIGs
On Mon, 4 Oct 2021 at 13:07, Peter Boy wrote:
>
> We had a spirited and detailed discussion so far. But nevertheless, I think
> we are none the wiser at the moment. We have many informative contributions
> to the discussion and analyses of the situation.
>
> However, we lack concepts on how to proceed after removing java-maint-sig.
> What consequences do we draw from the analyses?
>
> Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts on
> those? I posted on the java list some ideas some time ago ('Empowering Fedora
> Java’). Any comments on those?
>
>
>
Like many Open Source projects, Fedora is a "do-ocracy" -- those who
step up to do the work win the responsibility of getting it done. If
you have a clear goal in mind, just go for it.
As I said before there's always a lot of discussion from people who,
in the end, never get involved. And then there are people who are
quietly working away and Getting Things Done™ without the need for
endless discussion. A good example is Nicolas De Amicis who recently
stepped up to revive SWT because he really cares about openjfx in
Fedora and SWT was a dependency. And that is awesome; it is the
do-ocracy in action! Picking a goal you care about and setting about
achieving it doesn't require a SIG, it requires you to "do."
So, do you have any specific, concrete goal you want to achieve? If
the removal of a Java package has affected you directly or a Java
application you care about is in danger of being removed that would be
a excellent place to start.
--
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
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On 04. 10. 21 13:33, František Šumšal wrote: I just noticed that as well in our systemd Packit runs, but so far only on i386, because the repos for x86_64, ppc64le, and aarch64 are still on coreutils-8.32-32.fc36 (whereas i386 has coreutils-9.0-1.fc36) That's because by defalt, Copr uses the Koji repo for i686 and the composed repo for other arches. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On Monday, October 4, 2021 11:57:14 AM CEST Miro Hrončok wrote: > Hello, > > I see this failure in dnf in Copr and Koji: > > https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ > https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401 > > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 > + umask 022 > + cd /builddir/build/BUILD > + cd /builddir/build/BUILD > + rm -rf dnf-4.9.0 > + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz > + /usr/bin/tar -xof - > + STATUS=0 > + '[' 0 -ne 0 ']' > + cd dnf-4.9.0 > + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . > error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) > Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) > > I am perplexed with the error. > > Could it be some problem with updated coreutils? Yes. The error message comes from rpmbuild. chmod itself did not provide any diagnostic message. Is it possible to trigger the error locally? Kamil ___ 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: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote: > Some results from a Rawhide podman container: > > # koji download-build --arch x86_64 coreutils-9.0-1.fc36 > # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm > coreutils-9.0-1.fc36.x86_64.rpm # git clone > https://github.com/systemd/systemd > # cd systemd > # /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . > # echo $? > 1 > > Some further tests: > # mkdir test > # cd test > # touch testfile > # ln -s testfile testlink > # strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w . Thanks for the reproducer! This is a regression in the new upstream release: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-2-ge8b56ebd536 I will submit a fixed build as soon as I figure out how to untag the broken one: $ koji untag-build f36 coreutils-8.32-31.fc36 2021-10-04 14:16:18,518 [ERROR] koji: ActionNotAllowed: tag requires autosign permission Kamil ___ 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 35 Branched 20211004.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 35 Branched 20211004.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20211001.n.0: anaconda-35.22.1-2.fc35.src, 20211004.n.0: anaconda-35.22.2-1.fc35.src python-blivet - 20211001.n.0: python-blivet-3.4.1-1.fc35.src, 20211004.n.0: python-blivet-3.4.2-1.fc35.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211004.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hi! I like this idea. As a new contributor, I am really scared to touch anything related to committing the package, for fear of screwing up, so something that is not screwable as onboarding sounds great. On 10/4/21 5:57 AM, Vít Ondruch wrote: Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ; 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. I like the first task a lot. The second task could be you merging your PR, or someone else's if someone has already merged yours. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Cheers! Bruno Larsen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20211004.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 3/16 (x86_64), 3/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20211003.0): ID: 1013062 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1013062 ID: 1013076 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1013076 ID: 1013086 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/1013086 Old failures (same test failed in Fedora-IoT-36-20211003.0): ID: 1013068 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1013068 ID: 1013083 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1013083 ID: 1013085 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/1013085 Passed openQA tests: 12/15 (aarch64), 13/16 (x86_64) New passes (same test not passed in Fedora-IoT-36-20211003.0): ID: 1013079 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/1013079 ID: 1013091 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/1013091 -- 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
Onboarding package
Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ;) 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modularity: New modulemd-packager format for building modules
V Sat, Oct 02, 2021 at 12:29:01PM -0600, Orion Poplawski napsal(a): > On 9/10/21 6:26 AM, Petr Pisar wrote: > > Good news, module maintainers. > > > > I'm relieved to announce an availability of the new module packaging format, > > modulemd-packager, version 3. > > > > Question: is this necessary for all modules to migrate to this format, or is > it primarily useful for modules that depend on other modules? > I cannot provide you with any better answer than I've already stated in my original message: It is primarily useful for modules which depends on other modules. It is not necessary for all modules right now, because both MBS and DNF support both of the formats. However, I won't speculate how long they will support them. -- Petr 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: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
Dne 02. 10. 21 v 18:02 Robert-André Mauchin napsal(a): On 7/19/21 18:17, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/WirePlumber == Summary == PipeWire currently uses a simple example session manager. This proposal is to move to the more powerful WirePlumber session manager. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taym...@gmail.com == Detailed Description == PipeWire requires a session manager that at least needs to implements the following features: * create and configure detected devices in the system. This includes audio cards, video and bluetooth devices. * configure applications and route audio/video to/from them to the devices and filters. * keep track of prefered devices and volumes. * move audio/video streams when devices appear and disappear. PipeWire uses a simple example session manager with limited features and configuration options. The proposal is to move to WirePlumber. WirePlumber is built on GNOME (GObject) technologies and has bindings for most languages using GObject introspection. WirePlumber allows one to implement many of the rules for setup and configuration using small LUA scripts, which are easier to maintain and customize. These are some of the functions that are scriptable in LUA: * setup and configuration of the devices and streams. This includes deciding if devices and streams need to operate in 5.1 or stereo mode, depending on the available devices. * routing of the streams based on metadata of the streams (Roles) and overall state of the system. * volume/mute restore of devices and streams == Benefit to Fedora == PipeWire currently uses a simple example session manager with mostly hardcoded logic and rules. This proposal wants to replace the session manager with a more advanced session manager, called WirePlumber. WirePlumber brings to following improvements * Drop-in replacement session manager for PipeWire, implements the exact same features as the example session manager * built with GObject, which provides a richer development experience and adds bindings for most languages * extensible with loadable modules * scriptable policy using small lua scripts * better integration with desktop settings The main benefits will be that this session manager would allow for more customization of the policy and rules. Initially we aim for feature parity with the current solution and work on more features in the next releases. == Scope == * Proposal owners: This is a rather isolated changed. Instead of starting the pipewire-media-session executable we would need to package and start WirePlumber instead. WirePlumber has been kept up to data with the features in the example session manager and would need testing. * Other developers: None. This is an isolated PipeWire change. * Release engineering: A new systemd service will need to be activated in the default install. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Should not cause any change. == How To Test == Experience should be the same as before. Retest all audio testcases. == User Experience == Should not cause any visible change. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?): If the feature can not be completed we continue using the existing pipewire-media-session. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) Just switched to F35 beta, no sound card was detected, I had to get back to pipewire-media-session to get sound again. I was fighting with something similar on Friday and I think the solution was something like: ~~~ $ systemctl --no-reload preset --global pipewire-pulse.service $ systemctl --no-reload preset --global pipewire-pulse.socket ~~~ The symptoms were that one or both of these services had this line in their `status` output: ~~~ Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; disabled; vendor preset: enabled) ~~~ I don't really how to figure what "disables" the unit file, assuming that enabling the pipewire-pulse.* was the right thing to do. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20211004.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-20211003.0): ID: 1011785 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1011785 ID: 1011793 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1011793 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: Self Introduction: John Wolfe
On Mon, Oct 04, 2021 at 05:11:48AM +, John Wolfe wrote: > Hello all, > > As a member of the VMware Tools team since 2016, I have actively participated > in the publication of granular change updates to the branches of https:// > github.com/vmware/open-vm-tools/. For the past year I have been responsible > for committing the changes to GitHub as well as publishing the last 5 releases > of open-vmtools, versions 11.1.5 through 11.3.5. > > To test open-vm-tools changes, VMware internally builds open-vm-tools packages > for actively supported Linux releases as well as in progress Linux builds. > This involves packaging changes both for RPM packaging and Debian dpkg > formats. Needed packaging changes are shared with Linux vendors when I file > rebase requests for each open-vm-tools release. > > I look forward to working with the Fedora community and particularly with the > open-vm-tools packaging team. Welcome to Fedora! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenSSH 8.7p1 in rawhide
On Wed, Sep 29, 2021 at 04:48:43PM +0200, Dmitry Belyavskiy wrote: > Dear colleagues, > > I recently added OpenSSH 8.7p1 to rawhide. > This version includes implementation of the SFTP protocol as the main transfer > protocol for the scp utility. In upstream, the SCP protocol is used by default > in the scp utility. The upcoming versions 8.9p1+ (version 8.8p1 is mostly a > security release) are expected to use SFTP protocol by default. This behavior > (SFTP as a default transfer protocol for scp utility) is backported to > rawhide. > > The same approach is planned for RHEL 9 GA, > > Please let me know if you have any questions/problems. Does this change the quoting of scp paths with spaces etc? The quoting of scp is insane but at least it's a known quantity, and we baked it into virt-p2v. 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: Fedora ? Java: The Death of Two SIGs
On Tue, Sep 28, 2021 at 02:40:18PM -0400, Demi Marie Obenour wrote: > That said, I am also unsure if anyone is using those bindings. Why were they > added originally? I think probably for oVirt, but oVirt now only uses the virt-* tools (ie. command line). 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: OpenSSH 8.7p1 in rawhide
Dear Richard, On Mon, Oct 4, 2021 at 10:23 AM Richard W.M. Jones wrote: > On Wed, Sep 29, 2021 at 04:48:43PM +0200, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > I recently added OpenSSH 8.7p1 to rawhide. > > This version includes implementation of the SFTP protocol as the main > transfer > > protocol for the scp utility. In upstream, the SCP protocol is used by > default > > in the scp utility. The upcoming versions 8.9p1+ (version 8.8p1 is > mostly a > > security release) are expected to use SFTP protocol by default. This > behavior > > (SFTP as a default transfer protocol for scp utility) is backported to > rawhide. > > > > The same approach is planned for RHEL 9 GA, > > > > Please let me know if you have any questions/problems. > > Does this change the quoting of scp paths with spaces etc? The > quoting of scp is insane but at least it's a known quantity, and we > baked it into virt-p2v. > Yes. There are changes in the quoting, documented in https://www.openssh.com/txt/release-8.7 and https://www.openssh.com/txt/release-8.8 If you still need an old quoting, AFAIK, you should explicitly specify the scp protocol via -O command-line option. > > -- Dmitry Belyavskiy ___ 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
RISC-V -- are we ready for more, and what do we need to do it?
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? * see http://fedora.riscv.rocks/koji/ -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Thoughts? I like the idea! We can block such a package from ever appearing in a compose in pungi. So, perhaps we seperate it into: open a bug, submit a pr, do a scratch build, look at ci get added as commit to onboarding package create pr, merge pr, do official build, submit update, etc Another possible way we could do this is have this setup in our staging env. ie, they do the same things, but it's in staging (which we never compose anyhow). That has the danger of something being broken in stg without us realizing it, or them diverging. Great idea tho, I like it. 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
Fedora-Rawhide-20211004.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 6/206 (x86_64), 11/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211003.n.0): ID: 1012056 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1012056 ID: 1012116 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1012116 Old failures (same test failed in Fedora-Rawhide-20211003.n.0): ID: 1011965 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1011965 ID: 1011978 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1011978 ID: 1011982 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1011982 ID: 1011984 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1011984 ID: 1012025 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1012025 ID: 1012090 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1012090 ID: 1012107 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1012107 ID: 1012113 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1012113 ID: 1012114 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1012114 ID: 1012139 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1012139 ID: 1012234 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1012234 ID: 1012239 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1012239 ID: 1012245 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1012245 ID: 1012269 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1012269 ID: 1012270 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1012270 Soft failed openQA tests: 4/206 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20211003.n.0): ID: 1011999 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1011999 ID: 1012041 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1012041 ID: 1012042 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1012042 ID: 1012053 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1012053 ID: 1012128 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1012128 ID: 1012146 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1012146 Passed openQA tests: 196/206 (x86_64), 128/141 (aarch64) New passes (same test not passed in Fedora-Rawhide-20211003.n.0): ID: 1011990 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1011990 ID: 1012017 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1012017 ID: 1012028 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1012028 ID: 1012030 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1012030 ID: 1012055 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/1012055 ID: 1012081 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1012081 ID: 1012082 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1012082 ID: 1012181 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1012181 ID: 1012225 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1012225 ID: 1012226 Test: x86_64 universal install_addrepo_metalink_graphical URL: https://openqa.fedoraproject.org/tests/1012226 ID: 1012261 Test: aarch64 universal install_kickstart_hdd@uefi URL: https://openqa.fedoraproject.org/tests/1012261 ID: 1012263 Test: aarch64 universal upgrade_2_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1012263 Installed system changes in test x86_64 Server-boot-iso install_default@uefi:
Re: Fedora Java: The Death of Two SIGs
Hello, I'm not a Fedora Maintainer, or packager, or developer. I was involved more in marketing and more "people person"[1] stuff. I hope this can close this thread. This email has a specific goal, but it doesn't have a great title: For starters, SIG can't die, because they aren't alive. Also the goal was to announce that there aren't active members of @java-maint-sig, which is ok, sometimes stuff like that happens in a community driven project. The problem is all the unnecessary words, and unnecessary responses in it. On one side: Ok, no one is working towards the objective of the @java-maint-sig, maybe someone later will pick it up, or simply it will remain inactive, that's it. Some people are happy working more freely without a heavy well organized structure, and it looks like the Java SIG works this way. On the other side: No need to be happy about something you don't like. It's not working anymore. Some people need more formal structure and it looks like the@java-maint-sig was working this way. No need to interchange any word, no need to trash, minimize or insult the work of any of the SIGs. I don't like Java, neither the language, the way it works with the JVM and JDK and JRE, neither the company it came from; but it's been around for 25 years and it probably will continue for a long time; and people will come and go to maintain what they need to work with it. Just please acknowledge that the @java-maint-sig has no active members, and continue with your lifes. Hope everyone is ok. Best regards [1] https://fedoraproject.org/wiki/Join#PeoplePerson -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative ___ 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-20211004.n.0 compose check report
No missing expected images. Failed openQA tests: 4/204 (x86_64), 7/141 (aarch64) New failures (same test not failed in Fedora-35-20211003.n.0): ID: 1012578 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1012578 ID: 1012666 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1012666 ID: 1012667 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1012667 ID: 1012767 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/1012767 ID: 1012784 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/1012784 ID: 1012847 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1012847 Old failures (same test failed in Fedora-35-20211003.n.0): ID: 1012658 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1012658 ID: 1012701 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1012701 ID: 1012724 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1012724 ID: 1012830 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1012830 ID: 1012869 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1012869 Soft failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211003.n.0): ID: 1012586 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1012586 ID: 1012628 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1012628 ID: 1012629 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1012629 ID: 1012640 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1012640 ID: 1012713 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1012713 ID: 1012731 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1012731 Passed openQA tests: 132/141 (aarch64), 196/204 (x86_64) New passes (same test not passed in Fedora-35-20211003.n.0): ID: 1012661 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1012661 ID: 1012674 Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1012674 ID: 1012677 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1012677 ID: 1012678 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1012678 ID: 1012722 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1012722 ID: 1012819 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1012819 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.01 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/1011406#downloads Current test data: https://openqa.fedoraproject.org/tests/1012520#downloads Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.02 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/1011407#downloads Current test data: https://openqa.fedoraproject.org/tests/1012521#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.07 to 0.24 Previous test data: https://openqa.fedoraproject.org/tests/1011425#downloads Current test data: https://openqa.fedoraproject.org/tests/1012539#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 4 MiB to 5 MiB System load changed from 0.56 to 0.70 Previous test data: https://openqa.fedoraproject.org/tests/1011467#downloads Current test data: https://openqa.fedoraproject.org/tests/1012581#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 services(s) removed since previous compose: fwupd.service System load changed from 0.67 to 0.48 Previous test data: https://openqa.fedoraproject.org/tests/1011469#downloads Current test data: https://openqa.fedoraproject.org/tests/1012583#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.81 to 0.93 Previous test data: https://openqa.fedoraproject.org/tests/1011493#downloads
Re: Onboarding package
On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi wrote: > > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Thoughts? > > I like the idea! It's indeed a good idea. > We can block such a package from ever appearing in a compose in pungi. You'd need to block it from ever appearing in the buildroots. You wouldn't want someone adding something to it that injected code that impacted the builds of other packages. josh > So, perhaps we seperate it into: > > > open a bug, submit a pr, do a scratch build, look at ci > > > get added as commit to onboarding package > create pr, merge pr, do official build, submit update, etc > > Another possible way we could do this is have this setup in our staging > env. ie, they do the same things, but it's in staging (which we never > compose anyhow). That has the danger of something being broken in stg > without us realizing it, or them diverging. > > Great idea tho, I like it. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20211004.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20211003.0): ID: 1013356 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1013356 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20211003.0): ID: 1013341 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1013341 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) New passes (same test not passed in Fedora-IoT-35-20211003.0): ID: 1013335 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1013335 ID: 1013349 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1013349 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.48 to 0.35 Previous test data: https://openqa.fedoraproject.org/tests/1011768#downloads Current test data: https://openqa.fedoraproject.org/tests/1013350#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
I've been wanting to work with RISC-V for a while, but it's been really difficult to get my hands on a dev board. I spoke with Mark Himmelstein from RISC-V International last week and he mentioned that they are pushing hard to get more dev boards out... but they're getting hit with the chip shortage just like everyone else. I really look forward to the day when Open ISAs like RISC-V and OpenPower have better availability. I know I'm eager to move to them as soon as I can. I have no experience with emulating it, so I can't really give any feedback on that. Do we have a RISC-V SIG? JT On Mon, Oct 4, 2021 at 1:03 PM Matthew Miller wrote: > Hi all! I just got back from Open Source Summit, several of the talks I > found interesting were on RISC-V -- a high-level one about the > organizational structure, and Drew Fustini's more technical talk. > > In that, he noted that there's a Fedora build *, but it isn't an official > Fedora arch. As I understand it, the major infrastructure blocker is simply > that there isn't server-class hardware (let alone hardware that will build > fast enough that it isn't a frustrating bottleneck). > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > as builders, could we build fast enough under QEMU emulation to work? We > have a nice early advantage, but if we don't keep moving, we'll lose that. > > But beyond that: What other things might be limits? Are there key bits of > the distro which don't build yet? Is there a big enough risc-v team to > respond to arch-specific build failures? And, do we have enough people to > do > QA around release time? > > > > * see http://fedora.riscv.rocks/koji/ > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: Like others, I like the idea. > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) Let's make this package use rpmautospec with %autorelease and %autochangelog. This will keep simultaneous PRs from new contributors from arbitrarily conflicting _every time_, and also help introduce people to the new way of doing things. So given that, let's make the actual change to CONTRIBUTORS. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, 4 Oct 2021 at 13:25, Josh Boyer wrote: > > On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi wrote: > > > > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > > Thoughts? > > > > I like the idea! > > It's indeed a good idea. > > > We can block such a package from ever appearing in a compose in pungi. > > You'd need to block it from ever appearing in the buildroots. You > wouldn't want someone adding something to it that injected code that > impacted the builds of other packages. > Would it be better if this happened in stg.fedoraproject.org environment to triply make sure it didn't affect production? -- 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 Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote:
> However, we lack concepts on how to proceed after removing java-maint-sig.
> What consequences do we draw from the analyses?
The java-maint-sig formal group ceased to exist. Java SIG continues to
exist as an informal group, in the shape it existed before
java-maint-sig was formed. Anyone who wants to improve Java in Fedora
can simply do so. Eg. If you want to package something, you can do it.
If you need help, you can ask on IRC or mailing list. If you want to
test existing packages, feel free to do it and open bugs. If you want
to improve docs, just do it. And so on. Java SIG has resources in form
of communication channels that can be used by members to help each
other. There is a mailing list and an IRC channel. We can even
schedule an IRC meeting if anyone has a particular topic to discuss
during a meeting.
> Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts on
> those?
I'm for removing java-maint-sig group and documenting the current
state of affairs. But I don't think there is a need to "restart Java
SIG" or to plan editing the wiki. Whoever wants to clean up some wiki
pages can simply do so, without asking.
> I posted on the java list some ideas some time ago ('Empowering Fedora
> Java’). Any comments on those?
These were about java-maint-sig, IIRC, which basically does not exist
any longer.
--
Mikolaj Izdebski
>
>
>
> Peter
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36
Hi everyone, Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild of previously shared failed packages on 15th, and report FTBFS bugs. Thank you, Regards, Sahana Prasad On Thu, Sep 30, 2021 at 4:31 PM Sahana Prasad wrote: > > > On Wed, Sep 29, 2021 at 3:26 PM Stephen Gallagher > wrote: > >> On Wed, Sep 29, 2021 at 6:00 AM Miro Hrončok wrote: >> > >> > On 29. 09. 21 9:11, Sahana Prasad wrote: >> > > Hi everyone, >> > > >> > > Reminder to kindly think about porting your packages to >> > > avoid build failures with OpenSSL 3.0.0. >> > > We will try a rebuild in the next 2 weeks, and report FTBFS bugs. >> > >> > I also see that we have openssl1.1 in the default build root >> >> How long (how many Fedora releases) do we expect to have >> openssl1.1-devel available in the buildroot? I maintain modules of >> Node.js 12 and 14 that will likely never be updated to support OpenSSL >> 3.0 and I'd prefer to keep them alive until their upstream EOLs >> (2022-04-30 and 2023-04-30, respectively). >> > > Hi Stephen, > I can keep it in Fedora until then, sure. > 1.1.1 upstream EOL is in 2023. After that we would not support CVE fixes. > > Thank you, > Regards, > Sahana Prasad > ___ 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, Oct 4, 2021 at 3:08 PM Mat Booth wrote:
>
> On Mon, 4 Oct 2021 at 13:07, Peter Boy wrote:
> >
> > We had a spirited and detailed discussion so far. But nevertheless, I
> > think we are none the wiser at the moment. We have many informative
> > contributions to the discussion and analyses of the situation.
> >
> > However, we lack concepts on how to proceed after removing java-maint-sig.
> > What consequences do we draw from the analyses?
> >
> > Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts
> > on those? I posted on the java list some ideas some time ago ('Empowering
> > Fedora Java’). Any comments on those?
> >
> >
> >
>
> Like many Open Source projects, Fedora is a "do-ocracy" -- those who
> step up to do the work win the responsibility of getting it done. If
> you have a clear goal in mind, just go for it.
>
> As I said before there's always a lot of discussion from people who,
> in the end, never get involved. And then there are people who are
> quietly working away and Getting Things Done™ without the need for
> endless discussion. A good example is Nicolas De Amicis who recently
> stepped up to revive SWT because he really cares about openjfx in
> Fedora and SWT was a dependency. And that is awesome; it is the
> do-ocracy in action! Picking a goal you care about and setting about
> achieving it doesn't require a SIG, it requires you to "do."
>
> So, do you have any specific, concrete goal you want to achieve? If
> the removal of a Java package has affected you directly or a Java
> application you care about is in danger of being removed that would be
> a excellent place to start.
I totally agree with Mat.
If you want to contribute, just do it. If you need help, feel free to
ask around.
--
Mikolaj Izdebski
>
>
>
>
>
>
>
>
> --
> 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
___
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: Onboarding package
Dne 04. 10. 21 v 11:34 Zbigniew Jędrzejewski-Szmek napsal(a): On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ;) 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. Forgot to mention these could be rewarded by appropriate badges ;) +1. We already have some test-only packages (for ci testing?), and one more wouldn't really matter. It'd be nice to match the naming pattern. https://fedoraproject.org/wiki/DummyTestPackages I assume that 1) above would be be done with the sponsor/mentor doing the merge and actual build, and 2) would be done with no direct sponsor/mentor interaction. The question always is how far we would go. E.g. would be some or mutliple of those scenarios enough to be sponsored? There could also be Copr scenarios, or it could be incorporated in the (1). This package should have multiple release branches, to exercise multi-release updates. Good idea, right. Vít This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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: 20211004.n.0 changes
OLD: Fedora-35-20211003.n.0 NEW: Fedora-35-20211004.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 2 Dropped packages:0 Upgraded packages: 46 Downgraded packages: 0 Size of added packages: 12.70 MiB Size of dropped packages:0 B Size of upgraded packages: 2.12 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -4.04 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-35-20211004.n.0.ppc64le.tar.xz = DROPPED IMAGES = Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20211003.n.0.x86_64.vagrant-libvirt.box Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20211003.n.0.x86_64.vagrant-virtualbox.box = ADDED PACKAGES = Package: eclipse-swt-1:4.21-1.fc35 Summary: Eclipse SWT: The Standard Widget Toolkit for GTK+ RPMs:eclipse-swt eclipse-swt-javadoc Size:12.33 MiB Package: qcoro-0.2.0-1.fc35 Summary: C++ Coroutines for Qt RPMs:qcoro qcoro-devel Size:378.13 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Field3D-1.7.3-15.fc35 Old package: Field3D-1.7.3-14.fc35 Summary: Library for storing voxel data RPMs: Field3D Field3D-devel Size: 9.70 MiB Size change: 818 B Changelog: * Fri Aug 20 2021 Richard Shaw - 1.7.3-15 - Rebuild for OpenEXR/Imath 3.1. Package: ImageMagick-1:6.9.11.27-7.fc35 Old package: ImageMagick-1:6.9.11.27-6.fc35 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 40.87 MiB Size change: 4.93 KiB Changelog: * Sun Aug 22 2021 Richard Shaw - 1:6.9.11.27-7 - Rebuild for OpenEXR/Imath 3.1. Package: OpenColorIO-2.1.0-2.fc35 Old package: OpenColorIO-2.0.1-1.fc35 Summary: Enables color transforms and image display across graphics apps RPMs: OpenColorIO OpenColorIO-devel OpenColorIO-doc OpenColorIO-tools Size: 12.57 MiB Size change: -685.48 KiB Changelog: * Wed Sep 01 2021 Richard Shaw - 2.1.0-1 - Update to 2.1.0. * Sat Oct 02 2021 Zbigniew J??drzejewski-Szmek - 2.1.0-2 - Rebuild for OpenEXR/Imath 3.1 Package: OpenImageIO-2.2.17.0-9.fc35 Old package: OpenImageIO-2.2.17.0-7.fc35 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 21.28 MiB Size change: -4.33 KiB Changelog: * Mon Aug 23 2021 Richard Shaw - 2.2.17.0-8 - Rebuild for OpenColorIO 2. * Sat Oct 02 2021 Mattia Verga - 2.2.17.0-9 - Rebuild for OpenEXR/Imath 3.1. Package: OpenSceneGraph-3.4.1-32.fc35 Old package: OpenSceneGraph-3.4.1-31.fc35 Summary: High performance real-time graphics toolkit RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk OpenSceneGraph-examples-qt OpenSceneGraph-gdal OpenSceneGraph-gstreamer OpenSceneGraph-libs OpenSceneGraph-qt OpenSceneGraph-qt-devel OpenThreads OpenThreads-devel Size: 57.00 MiB Size change: -8.29 KiB Changelog: * Sun Aug 22 2021 Richard Shaw - 3.4.1-32 - Rebuild for OpenEXR/Imath 3.1. Package: alembic-1.8.3-1.fc35.1 Old package: alembic-1.8.2-1.fc35.3 Summary: Open framework for storing and sharing scene data RPMs: alembic alembic-devel alembic-libs Size: 5.45 MiB Size change: 5.85 KiB Changelog: * Sat Aug 21 2021 Richard Shaw - 1.8.2-1.4 - Rebuild for OpenEXR/Imath 3.1. * Sun Sep 12 2021 Luya Tshimbalanga - 1.8.3-1 - Update to 1.8.3 * Tue Sep 28 2021 Mattia Verga - 1.8.3-1.1 - Rebuild for OpenEXR/Imath 3.1. Package: blender-1:2.93.4-3.fc35 Old package: blender-1:2.93.4-1.fc35 Summary: 3D modeling, animation, rendering and post-production RPMs: blender blender-rpm-macros Size: 124.03 MiB Size change: -10.09 MiB Changelog: * Sun Sep 12 2021 Luya Tshimbalanga 1:2.93.4-2 - Rebuild for alembic 1.8.3 * Wed Sep 29 2021 Zbigniew J??drzejewski-Szmek 1:2.93.4-3 - Rebuild again for alembic 1.8.3 Package: ceph-2:16.2.6-2.fc35 Old package: ceph-2:16.2.6-1.fc35 Summary: User space components of the Ceph file system RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts ceph-radosgw ceph-resource-agents ceph-selinux ceph-test cephadm cephfs-java cephfs
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Hi, > > Recently, there have been a lot of discussions on this list as well > as we have internally about onboarding. During our internal > brainstorming, we were initially discussing that it could be useful > to have some package one can experiment with without being too much > worried about the result. > > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) > > 2) Second step could be something similar, but that would require > the packager to be already sponsored and they could go through the > whole process themeselves just with some light guidance if needed. > > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines could be refreshed suggesting/requesting to take these > steps at some point. > > Thoughts? It's a good idea, but it's probably also a good idea to block it from installation at the dnf level. If it was open to everyone even non-sponsored then someone could anonymously put something nasty in it, like a %post script. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
This is a great idea. I've been reading through the new packager documentation this weekend and attempting to get my first package submitted. It would be really nice if there was a way to go all the way through the process with a "real" package, but without effecting anything, to help those who "learn by doing". ___ 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: Onboarding package
On 04/10/2021 10:57, Vít Ondruch wrote: Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. I like this idea, but such packages shouldn't be pushed to the official Fedora repositories. 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. We have COPR. It doesn't require anything other than the FAS account. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: co/lead-maintainer sought: python-mailmerge (python)
On Sun, Oct 3, 2021 at 6:48 PM TItouan Bénard wrote: > Hi, > > I want to help you > Sweet. Onuralp replied via direct mail and I have added them to the repo as well. Can you work with them (or agree on any other organization) around the upgrades indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1937525 also, send me your FAS id so I can add you to the repo. Once the upgrades are good I can hand off the repo to one of you all as main maintainer :) Thank you. regards, bex > > Thanks > > Titouan > > Le dimanche 03 octobre 2021 à 13:34 +0300, Onuralp SEZER a écrit : > > Hello Brian, I would like to step-up. > > Thank you > Regards > > > Onuralp S. > > On Sun, Oct 3, 2021 at 11:36 AM Brian (bex) Exelbierd > wrote: > > Hi, > > Want to play with python packaging? I am still looking for some > assistance here :) > > Thank you. > > regards, > > bex > > On Wed, May 5, 2021 at 12:01 PM Brian (bex) Exelbierd > wrote: > > Hi, > > I added python-mailmerge to Fedora Linux as it was super important to > large parts of my work as FCAIC. In my current $dayjob I use it less > frequently, though I know of colleagues who still depend on it. > > I'd love to find a maintainer to help me with it. There is a new > release pending, which I suspect will just be "build the rpm with new > code; test it; ship it" level effort. I am happy to hand the whole > thing off to someone or to work with you. > > Thank you. > > regards, > > bex > -- > Did this email arrive after work for you? Stop reading it and enjoy > some work/life balance. > > Brian "bex" Exelbierd (he/him/his) > Community Business Owner, RHEL Product Management > @bexelbie | http://www.winglemeyer.org > bexel...@redhat.com > > > > -- > Did this email arrive after work for you? Stop reading it and enjoy some > work/life balance. > > Brian "bex" Exelbierd (he/him/his) > Community Business Owner, RHEL Product Management > @bexelbie | http://www.winglemeyer.org > bexel...@redhat.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > > ___ > 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 > -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
Hello, I see this failure in dnf in Copr and Koji: https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf dnf-4.9.0 + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd dnf-4.9.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) I am perplexed with the error. Could it be some problem with updated coreutils? -- 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-20211004.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211003.0): ID: 1011918 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1011918 ID: 1011926 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1011926 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
[Test-Announce] Fedora 35 Upgrade Test Day 2021-10-07
Hey All, As we come closer to Fedora 35 release dates, it's time to test upgrades. Fedora 35 has a lot of changesets [0] and it becomes essential that we test the graphical upgrade methods as well as the command line. As a part of this test day[1], we will test upgrading from a full updated, F33 and F34 to the F35 for all architectures(x86_64,ARM,aarch64) and variants(WS,cloud,server,silverblue,IoT and newly added Kinoite). The results can be submitted here[2] As usual, we hang out on the #fedora-test-day, should you have questions. [0] https://fedoraproject.org/wiki/Releases/35/ChangeSet [1 ]http://fedoraproject.org/wiki/Test_Day:2021-10-07_F35_Upgrade_Test_Day [2] https://testdays.fedorainfracloud.org/events/121 Happy Upgrading! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Hi, > > Recently, there have been a lot of discussions on this list as well > as we have internally about onboarding. During our internal > brainstorming, we were initially discussing that it could be useful > to have some package one can experiment with without being too much > worried about the result. > > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) > > 2) Second step could be something similar, but that would require > the packager to be already sponsored and they could go through the > whole process themeselves just with some light guidance if needed. +1. We already have some test-only packages (for ci testing?), and one more wouldn't really matter. It'd be nice to match the naming pattern. I assume that 1) above would be be done with the sponsor/mentor doing the merge and actual build, and 2) would be done with no direct sponsor/mentor interaction. This package should have multiple release branches, to exercise multi-release updates. > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines could be refreshed suggesting/requesting to take these > steps at some point. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Strange soversion checks in rpmlint 2.x
Hello. Rpmlint on Fedora 35 includes strange E: shlib-policy-name-error and E: invalid-ldconfig-symlink checks. It complains about most of the built RPM packages. Upstream bug report: https://github.com/rpm-software-management/rpmlint/issues/718 Example RPM: https://kojipkgs.fedoraproject.org/packages/kimageannotator/0.5.2/1.fc35/x86_64/kimageannotator-0.5.2-1.fc35.x86_64.rpm Fedora 34 with rpmlint 1.11-19.fc34: $ rpmlint kimageannotator-0.5.2-1.fc35.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Fedora 35 with rpmlint 2.1.0-4.fc35: $ rpmlint kimageannotator-0.5.2-1.fc35.x86_64.rpm === rpmlint session starts === rpmlint: 2.1.0 configuration: /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/licenses.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 31, packages: 1 kimageannotator.x86_64: E: shlib-policy-name-error 0 kimageannotator.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libkImageAnnotator.so.0.5.2 libkImageAnnotator.so.0.5.2 === 1 packages and 0 specfiles checked; 2 errors, 0 warnings, 2 badness; has taken 21.4 s Let's unpack RPM and test this manually: $ objdump -p libkImageAnnotator.so.0.5.2 | grep SONAME SONAME libkImageAnnotator.so.0 SOVERSION is 0 and 0.5.2 is just a symbolic link. By the way, SOVERSION can consist of more than one digit. It can be 0.5.2 and this is not an error: https://autotools.io/libtool/version.html I think these checks are bogus and should be removed. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)
I just noticed that as well in our systemd Packit runs, but so far only on i386, because the repos for x86_64, ppc64le, and aarch64 are still on coreutils-8.32-32.fc36 (whereas i386 has coreutils-9.0-1.fc36): https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-20923/build/2873236/ https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-20926/build/2873203/ On 10/4/21 11:57, Miro Hrončok wrote: Hello, I see this failure in dnf in Copr and Koji: https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf dnf-4.9.0 + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd dnf-4.9.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) I am perplexed with the error. Could it be some problem with updated coreutils? -- PGP Key ID: 0xFB738CE27B634E4B 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: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller wrote: > > Hi all! I just got back from Open Source Summit, several of the talks I > found interesting were on RISC-V -- a high-level one about the > organizational structure, and Drew Fustini's more technical talk. > > In that, he noted that there's a Fedora build *, but it isn't an official > Fedora arch. As I understand it, the major infrastructure blocker is simply > that there isn't server-class hardware (let alone hardware that will build > fast enough that it isn't a frustrating bottleneck). > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > as builders, could we build fast enough under QEMU emulation to work? We > have a nice early advantage, but if we don't keep moving, we'll lose that. > > But beyond that: What other things might be limits? Are there key bits of > the distro which don't build yet? Is there a big enough risc-v team to > respond to arch-specific build failures? And, do we have enough people to do > QA around release time? I think the primary problem here is that koji does support neither external builders nor building on top of qemu emulation. However, COPR *does* support building on emulated architectures (that's how its armv7 and s390x support works there). So, maybe adding a mock configuration for building RISC-V packages in qemu emulation, with the fedora repositories from http://fedora.riscv.rocks/koji/ as a base, could work until koji supports it? (I think that would involve either adding RISC-V hardware to Fedora Infrastructure, or adding support for emulated architectures to koji, or adding support for external builders to koji.) 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: Onboarding package
On Mon, Oct 04, 2021 at 10:10:35AM -0700, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Thoughts? > > I like the idea! > > We can block such a package from ever appearing in a compose in pungi. Is this really necessary? The package will not be open to anyone, but only for approved contributors. Malicious behaviour is not more likely then in any other package (and would be immediately caught). I think we're thinking up technical solutions to something that is not a problem. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 4, 2021 at 1:35 PM Fabio Valentini wrote: > > On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller > wrote: > > > > Hi all! I just got back from Open Source Summit, several of the talks I > > found interesting were on RISC-V -- a high-level one about the > > organizational structure, and Drew Fustini's more technical talk. > > > > In that, he noted that there's a Fedora build *, but it isn't an official > > Fedora arch. As I understand it, the major infrastructure blocker is simply > > that there isn't server-class hardware (let alone hardware that will build > > fast enough that it isn't a frustrating bottleneck). > > > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > > as builders, could we build fast enough under QEMU emulation to work? We > > have a nice early advantage, but if we don't keep moving, we'll lose that. > > > > But beyond that: What other things might be limits? Are there key bits of > > the distro which don't build yet? Is there a big enough risc-v team to > > respond to arch-specific build failures? And, do we have enough people to do > > QA around release time? > > I think the primary problem here is that koji does support neither > external builders nor building on top of qemu emulation. > However, COPR *does* support building on emulated architectures > (that's how its armv7 and s390x support works there). > > So, maybe adding a mock configuration for building RISC-V packages in > qemu emulation, with the fedora repositories from > http://fedora.riscv.rocks/koji/ as a base, could work until koji > supports it? > (I think that would involve either adding RISC-V hardware to Fedora > Infrastructure, or adding support for emulated architectures to koji, > or adding support for external builders to koji.) > Perhaps kojivmd could be extended to support foreign architecture VMs? I think libvirt already can set up VMs with foreign architecture emulation, and kojivmd already calls libvirt for creating builder VMs. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: > > I like the idea! > > We can block such a package from ever appearing in a compose in pungi. > Is this really necessary? The package will not be open to anyone, > but only for approved contributors. Malicious behaviour is not more > likely then in any other package (and would be immediately caught). > I think we're thinking up technical solutions to something that is > not a problem. Yeah, I think making it a real package is a good idea. Maybe even a little packaged script that runs xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ ? The package itself can even be a gateway to onboarding for the curious, but more importantly, it'd act more like a real package. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 03:15:24PM +0100, Richard W.M. Jones wrote: > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Hi, > > > > Recently, there have been a lot of discussions on this list as well > > as we have internally about onboarding. During our internal > > brainstorming, we were initially discussing that it could be useful > > to have some package one can experiment with without being too much > > worried about the result. > > > > However, discussing this back and forth, we figured that it might > > also be good idea to actually have something such as "onboarding" > > package, where new coming package maintainer could gradually gain > > experience with the packaging workflows. So the simplest tasks could > > be: > > > > 1) Add changelog entry into onboarding package and open PR with the > > change. This would not require too many privileges. Alternatively > > this could include change to "CONTRIBUTORS" file. I suspect that > > also some current Fedora contributors might be interested to send > > such PR ;) > > > > 2) Second step could be something similar, but that would require > > the packager to be already sponsored and they could go through the > > whole process themeselves just with some light guidance if needed. > > > > This could be extended in the future. E.g. next step could be: > > > > 3) Submit module update. > > > > Apart from gaining experience, this could also help with the common > > question "where should I start". And of course our sponsoring > > guidelines could be refreshed suggesting/requesting to take these > > steps at some point. > > > > Thoughts? > > It's a good idea, but it's probably also a good idea to block it from > installation at the dnf level. If it was open to everyone even > non-sponsored then someone could anonymously put something nasty in it, > like a %post script. I don't think it'll be "open to anyone". In the described workflow, non-approved packagers can only open PRs (like they already can against any package). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > I'm not sure what's the best solution, but I guess the number one > reason to have packages within the Fedora distribution is for a matter > of trust, if this is the case I would argue that a curated list of > maven packages served via a Fedora managed repository would be a > better investment. I'd love to see someone interested in this pursue this idea! I know we talked about it as long ago as... Flock Prague... and probably before. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
I have nothing to add to this conversation other than: 1) I'd love to see RISC-V become a serious contender to X86-64. I'm tired of being controlled by the Intel/AMD oligopoly. 2) I love seeing Fedora people discuss supporting RISC-V. 3) Linux rocks. Fedora rocks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages
On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson wrote: > I was going to ask people if they > were interested in them but I decided to straight up orphan them so > they#ll can go through the usual garbage collection process unless > someone claims them. > libcec > platform I'll volunteer to take these two, as they are useful for a couple of projects I am involved with (unless, of course, someone else wants them more than I do). ___ 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
Polymake soname bump
Polymake 4.5 is out and bumps soname. I will soon build the new version and rebuild its dependencies, namely: - python-jupymake - sagemath There are a couple of packages that I want to unbundle from sagemath first, so these builds will not take place until I can get through the package reviews. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages
On Tue, Oct 5, 2021 at 12:21 AM Sérgio Basto wrote: > I wonder if kodi shouldn't use cec from kernel [1] instead libcec Perhaps, perhaps not. The recent libcec for Linux uses the kernel functionality, but (mostly) maintains the existing API. So for an application which is trying to be cross platform, using one API for Linux or Windows or macOS may have some advantages for their team. ___ 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: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: > > Hi all! I just got back from Open Source Summit, several of the talks I > > found interesting were on RISC-V -- a high-level one about the > > organizational structure, and Drew Fustini's more technical talk. > > > > In that, he noted that there's a Fedora build *, but it isn't an official > > Fedora arch. As I understand it, the major infrastructure blocker is simply > > that there isn't server-class hardware (let alone hardware that will build > > fast enough that it isn't a frustrating bottleneck). > > We have avoided using emulation in the past because we would be chasing > bugs in our emulation that aren't in real hardware and vice versa. > How good is the emulation support? Do we know/have people who can fix > things in it when we hit them? Tools folks: is emulation an option here? > Or do we still forbid it? Qemu support for RISC-V is very good, it's actually used to develop some features (virtualization and SBI). We do know people who can fix it. If you have the money real hardware is also available now. Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project. Rich. > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > > as builders, could we build fast enough under QEMU emulation to work? We > > have a nice early advantage, but if we don't keep moving, we'll lose that. > > > > But beyond that: What other things might be limits? Are there key bits of > > the distro which don't build yet? Is there a big enough risc-v team to > > respond to arch-specific build failures? And, do we have enough people to do > > QA around release time? > > Well, one big thing is that it's been a while since we had any secondary > arches and it's unclear how they would work today. In the distant past > secondary arches had their own koji and builders and composes and > releases and used koji-shadow to try and match up with primary koji. > This was basically more than a full time job for someone and I am sure > koji-shadow has atrophied in recent years, but perhaps at least some > subset could be made to work again. > > On the other hand we could just add it into primary koji, but then it > really really has to keep up or it's going to block everything else. > > So, probibly a 'secondary' koji and builders to start with to bootstrap > and to gather info on how hard it is to keep up and good emulation is > would be worthwhile, but it's gonna need some dedicated work. > > Perhaps we could get a up to date status report from folks working on > this, answering such questions as: > > * How good is emulation support > * What would it take to keep up with the other arches? Is that possible? > * What device(s) would we want to target and could we get sufficent > numbers of them for QA and devel folks to debug problems and test? > * Are there folks who can bootstrap/shepard the koji shadowing process? > > I think RISC-V is pretty exciting, and I am happy to help as much as I > can with adding it in. I think there's likely to be a lot of > interest/growth in coming years for it. > > kevin > ___ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: [...] > Personally speaking I think the real barrier is someone with a large > colourful hat putting up the money to hire a full time developer to > work on the project. Also, I think one of the pre-requisites to enabling it in koji would be making at least one machine available to package maintainers. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: > Hi all! I just got back from Open Source Summit, several of the talks I > found interesting were on RISC-V -- a high-level one about the > organizational structure, and Drew Fustini's more technical talk. > > In that, he noted that there's a Fedora build *, but it isn't an official > Fedora arch. As I understand it, the major infrastructure blocker is simply > that there isn't server-class hardware (let alone hardware that will build > fast enough that it isn't a frustrating bottleneck). The hardware situation is actually not terrible now (albeit still very expensive). HiFive Unmatched is a very solid platform that supports mini ITX, a decent amount of RAM, M.2 SSD, AMD Radeon GPU. You can build a reasonable desktop-style machine with one of the boards. For servers there are several missing components: - Any kind of BMC or remote management. You can add a Raspberry Pi-based KVM hat (assuming you're happy with that incongruity) - UEFI, although it's coming and u-boot works OK. Qemu also works very well if you don't want or more likely can't afford the hardware. > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > as builders, could we build fast enough under QEMU emulation to work? We > have a nice early advantage, but if we don't keep moving, we'll lose that. > > But beyond that: What other things might be limits? Are there key bits of > the distro which don't build yet? Is there a big enough risc-v team to > respond to arch-specific build failures? And, do we have enough people to do > QA around release time? I think we have most things covered. Hardware doesn't support virtualization but Qemu does. Hardware doesn't support various desirable features like the vector extension. Also it'd be nice to have a JDK port. 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
Orphaned packages
Looking through the packages I own there's a bunch I no longer use. I've tried to group these, from memory, where I own something because it's a dependency of something else. I was going to ask people if they were interested in them but I decided to straight up orphan them so they#ll can go through the usual garbage collection process unless someone claims them. The top two groups of packages need to be maintained together as the key package, at the top, depends on the rest. The bottom group are independent. speech-dispatcher dotconf festival-freebsoft-utils flite libcec platform crcimg csound libsoc python-webthing zram libfakekey ptpd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages
On Mon, 2021-10-04 at 23:08 +, Gary Buhrmaster wrote: > On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson > wrote: > > > I was going to ask people if they > > were interested in them but I decided to straight up orphan them so > > they#ll can go through the usual garbage collection process unless > > someone claims them. > > > libcec > > platform I wonder if kodi shouldn't use cec from kernel [1] instead libcec [1] https://www.kernel.org/doc/html/v4.11/media/kapi/cec-core.html https://cateee.net/lkddb/web-lkddb/USB_PULSE8_CEC.html > I'll volunteer to take these two, as they are > useful for a couple of projects I am involved with > (unless, of course, someone else wants them > more than I do). > ___ > 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: RISC-V -- are we ready for more, and what do we need to do it?
https://www.opensourcevoices.org/20 On Mon, Oct 4, 2021 at 10:47 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: > [...] > > Personally speaking I think the real barrier is someone with a large > > colourful hat putting up the money to hire a full time developer to > > work on the project. > > Also, I think one of the pre-requisites to enabling it in koji would be > making at least one machine available to package maintainers. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller wrote: > > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > > I'm not sure what's the best solution, but I guess the number one > > reason to have packages within the Fedora distribution is for a matter > > of trust, if this is the case I would argue that a curated list of > > maven packages served via a Fedora managed repository would be a > > better investment. > > I'd love to see someone interested in this pursue this idea! I know we > talked about it as long ago as... Flock Prague... and probably before. This approach will buy you *literally nothing* compared to how things already work, assuming you don't advocate just redistributing binary artifacts / JARs from Maven Central. Given that assumption, JARs would still need to be built 1) from source, in a 2) trusted environment, 3) against trusted dependencies, as I don't think any other approach should be acceptable for content distributed by the Fedora Project. But then you're back to *exactly how Fedora packages for Java projects already work* - only with the added complication that distributing those build artifacts as plain JARs instead of RPMs now makes them impossible to consume as dependencies from other RPM builds. 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: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: > Hi all! I just got back from Open Source Summit, several of the talks I > found interesting were on RISC-V -- a high-level one about the > organizational structure, and Drew Fustini's more technical talk. > > In that, he noted that there's a Fedora build *, but it isn't an official > Fedora arch. As I understand it, the major infrastructure blocker is simply > that there isn't server-class hardware (let alone hardware that will build > fast enough that it isn't a frustrating bottleneck). We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it? > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > as builders, could we build fast enough under QEMU emulation to work? We > have a nice early advantage, but if we don't keep moving, we'll lose that. > > But beyond that: What other things might be limits? Are there key bits of > the distro which don't build yet? Is there a big enough risc-v team to > respond to arch-specific build failures? And, do we have enough people to do > QA around release time? Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again. On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else. So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work. Perhaps we could get a up to date status report from folks working on this, answering such questions as: * How good is emulation support * What would it take to keep up with the other arches? Is that possible? * What device(s) would we want to target and could we get sufficent numbers of them for QA and devel folks to debug problems and test? * Are there folks who can bootstrap/shepard the koji shadowing process? I think RISC-V is pretty exciting, and I am happy to help as much as I can with adding it in. I think there's likely to be a lot of interest/growth in coming years for it. 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: Onboarding package
On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote: > On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > I like the idea! > > > We can block such a package from ever appearing in a compose in pungi. > > Is this really necessary? The package will not be open to anyone, > > but only for approved contributors. Malicious behaviour is not more > > likely then in any other package (and would be immediately caught). > > I think we're thinking up technical solutions to something that is > > not a problem. > > Yeah, I think making it a real package is a good idea. Maybe even a little > packaged script that runs > > xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ > > ? > > The package itself can even be a gateway to onboarding for the curious, but > more importantly, it'd act more like a real package. True. As long as there's a group of experenced folks watching it, that should be ok. 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: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi wrote: > > On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: > > Hi all! I just got back from Open Source Summit, several of the talks I > > found interesting were on RISC-V -- a high-level one about the > > organizational structure, and Drew Fustini's more technical talk. > > > > In that, he noted that there's a Fedora build *, but it isn't an official > > Fedora arch. As I understand it, the major infrastructure blocker is simply > > that there isn't server-class hardware (let alone hardware that will build > > fast enough that it isn't a frustrating bottleneck). > > We have avoided using emulation in the past because we would be chasing > bugs in our emulation that aren't in real hardware and vice versa. > How good is the emulation support? Do we know/have people who can fix > things in it when we hit them? Tools folks: is emulation an option here? > Or do we still forbid it? > > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > > as builders, could we build fast enough under QEMU emulation to work? We > > have a nice early advantage, but if we don't keep moving, we'll lose that. > > > > But beyond that: What other things might be limits? Are there key bits of > > the distro which don't build yet? Is there a big enough risc-v team to > > respond to arch-specific build failures? And, do we have enough people to do > > QA around release time? > > Well, one big thing is that it's been a while since we had any secondary > arches and it's unclear how they would work today. In the distant past > secondary arches had their own koji and builders and composes and > releases and used koji-shadow to try and match up with primary koji. > This was basically more than a full time job for someone and I am sure > koji-shadow has atrophied in recent years, but perhaps at least some > subset could be made to work again. > > On the other hand we could just add it into primary koji, but then it > really really has to keep up or it's going to block everything else. > > So, probibly a 'secondary' koji and builders to start with to bootstrap > and to gather info on how hard it is to keep up and good emulation is > would be worthwhile, but it's gonna need some dedicated work. > > Perhaps we could get a up to date status report from folks working on > this, answering such questions as: > > * How good is emulation support The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware. > * What would it take to keep up with the other arches? Is that possible? The real hardware options do not have the performance to keep up with the other architectures. > * What device(s) would we want to target and could we get sufficent > numbers of them for QA and devel folks to debug problems and test? This is probably more of a question for Fedora RISC-V folks like Richard W.M. Jones... > * Are there folks who can bootstrap/shepard the koji shadowing process? > We already have the other Koji instance that could be converted into a shadow Koji, couldn't it? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote: Is this really necessary? Yes. Because anyone can add something like this: %post rm -rf / And it will destroy the installed system or even the hardware. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 4, 2021 at 8:58 AM Vít Ondruch wrote: > Thoughts? Anything that improves the onboarding process can only be a good thing. I would recommend that before going too deep into weeds that you need a small group of "non-packagers"(*) to see if this is the right approach from their perspective, and whether they can successfully navigate it with the resources that will be available to help. If so declare success, and if not iterate based on the feedback. (*) The problem is that the people that tend to be part of this discussion have mostly completely forgotten about the details and lessons they learned along the way and that are now part of muscle memory. ___ 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: Onboarding package
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote: > >Is this really necessary? > > Yes. Because anyone can add something like this: > %post > rm -rf / > > And it will destroy the installed system or even the hardware. Eh, please don't overtrim the message you are replying to. > The package will not be open to anyone, but only for approved contributors. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Summary/Minutes from today's FESCo Meeting (2021-10-04)
=== #fedora-meeting: FESCO (2021-10-04) === Meeting started by Eighth_Doctor at 19:03:26 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2021-10-04/fesco.2021-10-04-19.03.log.html . Meeting summary --- * init process (King_InuYasha, 19:09:10) * #2670 Consider triggering contingency plan for F35 WirePlumber change (King_InuYasha, 19:09:41) * LINK: https://web.libera.chat/?channels=#fedora-meeting (mhroncok, 19:13:09) * AGREED: QA will meet on Friday to decide if WirePlumber is in good enough shape. If not, King_InuYasha will revert after the end of that meeting (+9, 0, -0) (King_InuYasha, 19:38:30) * #2671 [DNS over TLS] following connection to a wifi AP, internet is not available for ~30s (King_InuYasha, 19:38:45) * AGREED: FESCo agrees that this is a Final Blocker. QA will add criterion for this for F36. (+8, 0, -0) (King_InuYasha, 19:39:43) * Next week's chair (King_InuYasha, 19:40:07) * ACTION: zbyszek will chair next meeting (King_InuYasha, 19:40:48) * Open Floor (King_InuYasha, 19:41:02) Meeting ended at 19:47:04 UTC. Action Items * zbyszek will chair next meeting Action Items, by person --- * zbyszek * zbyszek will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * King_InuYasha (86) * StephenGallagher (39) * mhroncok (29) * adamw (28) * zodbot (26) * nirik (21) * zbyszek (21) * wtay (16) * defolos (11) * mboddu (10) * dcantrell (9) * Eighth_Doctor (7) * decathorpe (5) * bcotton (4) * zbyszek_ (1) * King_In7 (1) * bcotton_ (1) * dustymabe (1) * sgallagh (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * Son_Goku (0) * Sir_Gallantmon (0) Generated by `MeetBot`_ 0.3 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-10-08 @ 16:00 UTC - Special Fedora QA Meeting: Wireplumber Decision
# Special Fedora Quality Assurance Meeting # Date: 2021-10-08 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! Well, this is exciting. I've been doing this job for approximately eleventy billion years, but I think this is the first time I'm going to run a special meeting! Today FESCo considered[0] a proposal[1] to trigger the contingency plan on the Fedora 35 Wireplumber change[2], which would mean going back to pipewire's own simple session manager. The decision they reached was that they'd give the maintainers until Friday to make improvements to Wireplumber, and on Friday, we (QA) get to decide if we think it's good enough to be shipped for Final. If by Friday we think it's not going to be in good enough shape for release, we'll immediately revert to the simple session manager - the changes to do so will be prepared and ready to go if necessary. This meeting will be at 16:00 UTC, which is 9am timezone, to give me enough time to check in on the status of all the bugs before we get started. Anyone interested is welcome to attend, and I expect we'll make the decision by rough consensus without worrying too hard about bureaucracy or who's allowed to have an opinion. If it somehow turns out to be especially controversial I'll try and come up with a voting system on the fly, if it gets really bad we can bounce it back to FESCo. == Proposed Agenda Topics == 1. Should we revert to the simple session manager, or stick with Wireplumber? [0] https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2021-10-04-19.03.html [1] https://pagure.io/fesco/issue/2670 [2] https://fedoraproject.org/wiki/Changes/WirePlumber -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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
[Test-Announce] ** UPDATE ** 2021-10-08 @ 16:00 UTC - Special Fedora QA Meeting: Wireplumber Decision
UPDATE: first time in eleventy billion years, and I messed it up...this meeting will be in #fedora-meeting-1, not #fedora-meeting, because ELN is using #fedora-meeting at that time. Apologies. # Special Fedora Quality Assurance Meeting # Date: 2021-10-08 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting-1 ** on irc.libera.chat Greetings testers! Well, this is exciting. I've been doing this job for approximately eleventy billion years, but I think this is the first time I'm going to run a special meeting! Today FESCo considered[0] a proposal[1] to trigger the contingency plan on the Fedora 35 Wireplumber change[2], which would mean going back to pipewire's own simple session manager. The decision they reached was that they'd give the maintainers until Friday to make improvements to Wireplumber, and on Friday, we (QA) get to decide if we think it's good enough to be shipped for Final. If by Friday we think it's not going to be in good enough shape for release, we'll immediately revert to the simple session manager - the changes to do so will be prepared and ready to go if necessary. This meeting will be at 16:00 UTC, which is 9am timezone, to give me enough time to check in on the status of all the bugs before we get started. Anyone interested is welcome to attend, and I expect we'll make the decision by rough consensus without worrying too hard about bureaucracy or who's allowed to have an opinion. If it somehow turns out to be especially controversial I'll try and come up with a voting system on the fly, if it gets really bad we can bounce it back to FESCo. == Proposed Agenda Topics == 1. Should we revert to the simple session manager, or stick with Wireplumber? [0] https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2021-10-04-19.03.html [1] https://pagure.io/fesco/issue/2670 [2] https://fedoraproject.org/wiki/Changes/WirePlumber -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-10-04.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change dnstracer orphan 4 weeks ago fedmodnphilipp, orphan 1 weeks ago golang-github-hanwen-fuse orphan 0 weeks ago golang-github-jacobsa-crypto orphan 0 weeks ago golang-github-jacobsa-oglemockorphan 0 weeks ago golang-github-jacobsa-ogletestorphan 0 weeks ago golang-github-jacobsa-reqtraceorphan 0 weeks ago golang-github-rfjakob-gocryptfs orphan 0 weeks ago golang-github-sabhiram- orphan 0 weeks ago gitignore jakarta-commons-httpclientjava-maint-sig, mizdebsk,6 weeks ago orphan kdevelop-python dvratil, jgrulich, kde-sig, 1 weeks ago orphan kdocker kde-sig, orphan, rdieter 1 weeks ago mingw-brotli etrunko, orphan 1 weeks ago mingw-libpsl etrunko, orphan 1 weeks ago mingw-libunistringetrunko, orphan 1 weeks ago perl-WebService-Dropbox mathstuf, orphan 1 weeks ago python-email_reply_parser orphan, python-sig 1 weeks ago python-first orphan, python-sig 1 weeks ago python-graphene-sqlalchemyorphan 1 weeks ago python-graphql-server orphan 1 weeks ago python-opencensus orphan 5 weeks ago python-parallel-ssh orphan 1 weeks ago python-pipreqsorphan, python-sig 1 weeks ago python-plette orphan, pkopkan, python-sig 1 weeks ago python-power orphan, python-sig 1 weeks ago python-ssh2-pythonorphan 1 weeks ago python-yarg orphan, python-sig 1 weeks ago rubygem-ancestry jaruga, orphan 1 weeks ago rubygem-cliverorphan 3 weeks ago rubygem-gem-patch orphan 3 weeks ago rubygem-scoped_search orphan 3 weeks ago trac-customfieldadmin-plugin orphan 1 weeks ago trac-watchlist-plugin orphan 1 weeks ago waiverdb lholecek, lucarval, orphan, 1 weeks ago ralph, vmaljulin yarockkde-sig, martinkg, orphan1 weeks ago The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2021-10-04.txt See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan Affected (co)maintainers (either directly or via packages' dependencies): berrange: mingw-libpsl, mingw-brotli, mingw-libunistring dcavalca: golang-github-hanwen-fuse dvratil: kdevelop-python eclipseo: golang-github-hanwen-fuse elmarco: mingw-libpsl, mingw-brotli, mingw-libunistring eparis: golang-github-hanwen-fuse etrunko: mingw-libpsl, mingw-brotli, mingw-libunistring fidencio: mingw-libpsl, mingw-brotli, mingw-libunistring fpokorny: golang-github-hanwen-fuse go-sig: golang-github-hanwen-fuse infra-sig: golang-github-hanwen-fuse jaruga: rubygem-ancestry
[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2021-f2e6978f90 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f2e6978f90 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008958 ___ 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 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 --- Comment #3 from Fedora Update System --- FEDORA-2021-e4daf49855 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e4daf49855 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008958 ___ 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 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 --- Comment #4 from Fedora Update System --- FEDORA-2021-0f9b1e3ac3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0f9b1e3ac3 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2008958 ___ 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 2009792] perl-Math-BigRat-0.2620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2009792 Jitka Plesnikova changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2009792 ___ 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 2009792] perl-Math-BigRat-0.2620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2009792 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Math-BigRat-0.2620-1.f ||c36 Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2021-10-04 10:31:35 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2009792 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL package and Java 11 requirement.
On Mon, Oct 4, 2021 at 3:50 PM Stefan Bluhm wrote: > > it provides "java-11-headless". Not "java-headless". At least not on my > machine Doing my own checks on CentOS Stream 8 and RHEL 8.4, this sounds like a Fedora change that didn't make its way back to RHEL. Worth opening a Bugzilla report on? For posterity, only java-1.8.0 returns when checking for java-headless on EL8 (latest versions on RHEL for 1.8 and 11 as of writing). $ rpm -qp --provides java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64.rpm /usr/bin/jjs config(java-1.8.0-openjdk-headless) = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.302.b08-0.el8_4 java-headless = 1:1.8.0 java-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-headless = 1:1.8.0 jre-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 libjava.so()(64bit) libjava.so(SUNWprivate_1.1)(64bit) libjsig.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libverify.so()(64bit) libverify.so(SUNWprivate_1.1)(64bit) $ rpm -qp --provides java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64.rpm config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4 java-11-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4 jre-11-headless = 1:11.0.12.0.7-0.el8_4 jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 -- Mike ___ 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 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 --- Comment #6 from Fedora Update System --- FEDORA-2021-f2e6978f90 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f2e6978f90` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f2e6978f90 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=2008958 ___ 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 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2008958 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2021-e4daf49855 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e4daf49855` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e4daf49855 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=2008958 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL package and Java 11 requirement.
Hello,
can you please give me a direction on how to handle a Java 11 package build on
RHEL8 for EPEL8?
My issue: I am trying to build jaxb-api. The build works fine:
https://src.fedoraproject.org/rpms/jaxb-api/blob/rawhide/f/jaxb-api.spec
In addition to the original file, I added:
BuildRequires: java-11-openjdk-devel
and
%if 0%{?rhel}
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
%endif
Now the generated rpm adds this requirement line:
Requires: java-headless >= 1:9
This is something that RHEL cannot fulfill as it would be called
java-11-headless (adding the next higher available version).
How do I remove/omit the generation of the 1:9 requirement?
I tried:
- adding a manual requires: java-11-headless
- removing the maven-compiler-plugin and manually setting the mvn compile to 11
(which adds the same line as abnove just with 11 instead of 9).
What would be the right way of doing this?
Thank you and best wishes,
Stefan
___
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: EPEL package and Java 11 requirement.
On Mon, Oct 4, 2021 at 3:06 PM Stefan Bluhm
wrote:
>
> Hello,
>
> can you please give me a direction on how to handle a Java 11 package build
> on RHEL8 for EPEL8?
>
> My issue: I am trying to build jaxb-api. The build works fine:
> https://src.fedoraproject.org/rpms/jaxb-api/blob/rawhide/f/jaxb-api.spec
> In addition to the original file, I added:
>
> BuildRequires: java-11-openjdk-devel
>
> and
>
> %if 0%{?rhel}
> export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
> %endif
>
> Now the generated rpm adds this requirement line:
>
> Requires: java-headless >= 1:9
>
> This is something that RHEL cannot fulfill as it would be called
> java-11-headless (adding the next higher available version).
>
> How do I remove/omit the generation of the 1:9 requirement?
>
java-11-openjdk-headless provides "java-headless = 1:11", so it should
work anyway. And that's in RHEL 8.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL package and Java 11 requirement.
Thanks Neal,
it provides "java-11-headless". Not "java-headless". At least not on my machine:
$ dnf repoquery --provides java-11-openjdk-headless
config(java-11-openjdk-headless) = 1:11.0.11.0.9-2.el8_4
config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4
java-11-headless = 1:11.0.11.0.9-2.el8_4
java-11-headless = 1:11.0.12.0.7-0.el8_4
java-11-openjdk-headless = 1:11.0.11.0.9-2.el8_4
java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4
java-11-openjdk-headless(x86-64) = 1:11.0.11.0.9-2.el8_4
java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4
jre-11-headless = 1:11.0.11.0.9-2.el8_4
jre-11-headless = 1:11.0.12.0.7-0.el8_4
jre-11-openjdk-headless = 1:11.0.11.0.9-2.el8_4
jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4
Best wishes,
Stefan
- Ursprüngliche Mail -
Von: "Neal Gompa"
An: "epel-devel"
Gesendet: Montag, 4. Oktober 2021 21:45:41
Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement.
On Mon, Oct 4, 2021 at 3:06 PM Stefan Bluhm
wrote:
>
> Hello,
>
> can you please give me a direction on how to handle a Java 11 package build
> on RHEL8 for EPEL8?
>
> My issue: I am trying to build jaxb-api. The build works fine:
> https://src.fedoraproject.org/rpms/jaxb-api/blob/rawhide/f/jaxb-api.spec
> In addition to the original file, I added:
>
> BuildRequires: java-11-openjdk-devel
>
> and
>
> %if 0%{?rhel}
> export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
> %endif
>
> Now the generated rpm adds this requirement line:
>
> Requires: java-headless >= 1:9
>
> This is something that RHEL cannot fulfill as it would be called
> java-11-headless (adding the next higher available version).
>
> How do I remove/omit the generation of the 1:9 requirement?
>
java-11-openjdk-headless provides "java-headless = 1:11", so it should
work anyway. And that's in RHEL 8.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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
