RE: Nvidia binary drivers fail to install on Fedora 32
>Interesting. I’ve used Fedora 30 Silverblue before and it worked(yes, using >AKMod). Maybe this is a >regression? >Anyway, when I looked up the error I got a result from Nvidia’s forum wherein >a user pointed to a >kernel issue. Apologies if that isn’t the case. Wait, nevermind. It’s kmod, got them confused: rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 21 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0316f810ac python-twisted-19.10.0-2.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-79bd0a6b28 chromium-80.0.3987.149-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f16ad37b5e tor-0.4.2.7-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2cb1029c5a okular-18.12.2-2.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-913d6d1779 coturn-4.5.1.1-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing earlyoom-1.5-1.el8 python-blessed-1.17.4-1.el8 python-javaobj-0.4.0.1-1.el8 python-scramp-1.1.0-1.el8 python-wcwidth-0.1.9-1.el8 vim-gitgutter-0-3.20200328git7c48aa1.el8 vim-gv-0-4.20200328git72dc64d.el8 Details about builds: earlyoom-1.5-1.el8 (FEDORA-EPEL-2020-75d30f716e) Early OOM Daemon for Linux Update Information: Updated to version 1.5. ChangeLog: * Mon Mar 23 2020 Vitaly Zaitsev - 1.5-1 - Updated to version 1.5. python-blessed-1.17.4-1.el8 (FEDORA-EPEL-2020-a121af341b) A thin, practical wrapper around terminal capabilities in Python Update Information: Updated to 1.17.4 ChangeLog: * Sat Mar 28 2020 Avram Lubkin - 1.17.4-1 - Updated to 1.17.4 * Thu Jan 30 2020 Fedora Release Engineering - 1.16.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Tue Oct 29 2019 Avram Lubkin - 1.16.1-2 - Fix epel6 requirements patch python-javaobj-0.4.0.1-1.el8 (FEDORA-EPEL-2020-f4815ebc22) Python module for serializing and deserializing Java objects Update Information: Remove Python 2 support ChangeLog: python-scramp-1.1.0-1.el8 (FEDORA-EPEL-2020-a77bfc43c6) An implementation of the SCRAM protocol Update Information: Initial package for Fedora ChangeLog: References: [ 1 ] Bug #1817811 - Review Request: python-scramp - An implementation of the SCRAM protocol https://bugzilla.redhat.com/show_bug.cgi?id=1817811 python-wcwidth-0.1.9-1.el8 (FEDORA-EPEL-2020-838ec676ef) Measures number of Terminal column cells of wide-character codes Update Information: Update to 0.1.9 ChangeLog: * Sat Mar 28 2020 Avram Lubkin - 0.1.9-1 - Update to 0.1.9 vim-gitgutter-0-3.20200328git7c48aa1.el8 (FEDORA-EPEL-2020-e4c8dfd5da) Shows a git diff in the gutter and stages/undoes hunks and partial hunks Update Information: Update to latest version ChangeLog: * Sat Mar 28 2020 Artem Polishchuk - 0-3.20200328git7c48aa1 - Update to latest git snapshot * Fri Jan 31 2020 Fedora Release Engineering - 0-3.20191207git1c53af9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild vim-gv-0-4.20200328git72dc64d.el8
[Bug 1793917] perl-Test-mysqld-1.0012-4.fc32 FTBFS: DBI connect('dbname=mysql;mysql_socket=/tmp/B_Fm_kLtjo/tmp/mysql.sock;user=root','',...) failed: Access denied for user 'root'@'localhost' at /build
https://bugzilla.redhat.com/show_bug.cgi?id=1793917 --- Comment #6 from Fedora Release Engineering --- Dear Maintainer, your package has an open Fails To Build From Source bug for Fedora 32. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. If you have already fixed this issue, please close this Bugzilla report. Following the policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks (that's on 2020-03-18). A week before the mass branching of Fedora 33 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 31 will be retired regardless of the status of this bug. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32
https://bugzilla.redhat.com/show_bug.cgi?id=1799856 --- Comment #8 from Fedora Release Engineering --- Dear Maintainer, your package has an open Fails To Build From Source bug for Fedora 32. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. If you have already fixed this issue, please close this Bugzilla report. Following the policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks (that's on 2020-04-02). A week before the mass branching of Fedora 33 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 31 will be retired regardless of the status of this bug. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
RE: Nvidia binary drivers fail to install on Fedora 32
>Okay, no. This is actually a fundamental technical flaw with >RPM-OSTree. In fact, *zero* DKMS or AKMod based packages will work >with RPM-OSTree based systems, and has been known for at least three >years: https://github.com/coreos/rpm-ostree/issues/1091 >It has nothing to do with any ideological hatred for NVIDIA. It's just >the RPM-OSTree developers have so far been pushing to force containers >in every little nook and cranny, even when unneeded or unwanted, >instead of solving the problem to support akmods. >You can use regular kmod packages with Fedora Silverblue (rpm-ostree i>nstall kmod-nvidia). You can also use regular Fedora Workstation and >have akmods work perfectly. Interesting. I’ve used Fedora 30 Silverblue before and it worked(yes, using AKMod). Maybe this is a regression? Anyway, when I looked up the error I got a result from Nvidia’s forum wherein a user pointed to a kernel issue. Apologies if that isn’t the case. >-- >真実はいつも一つ！/ 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
Re: Nvidia binary drivers fail to install on Fedora 32
On Sat, Mar 28, 2020 at 11:57 PM Ty Young wrote: > > Either no one is testing Fedora 32 on Nvidia hardware or Fedora has > entered an entirely new level of salt. Attempting to install from > RPMFusion results in: > > [snip error spew from rpm-ostree] > > No issues with Arch Linux. The driver is being blocked from being > installed purely for ideological reasons. Okay, no. This is actually a fundamental technical flaw with RPM-OSTree. In fact, *zero* DKMS or AKMod based packages will work with RPM-OSTree based systems, and has been known for at least three years: https://github.com/coreos/rpm-ostree/issues/1091 It has nothing to do with any ideological hatred for NVIDIA. It's just the RPM-OSTree developers have so far been pushing to force containers in every little nook and cranny, even when unneeded or unwanted, instead of solving the problem to support akmods. You can use regular kmod packages with Fedora Silverblue (rpm-ostree install kmod-nvidia). You can also use regular Fedora Workstation and have akmods work perfectly. -- 真実はいつも一つ！/ 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
Nvidia binary drivers fail to install on Fedora 32
Either no one is testing Fedora 32 on Nvidia hardware or Fedora has
entered an entirely new level of salt. Attempting to install from
RPMFusion results in:
Mar 28 22:32:44 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[10990]: Building
/usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel
5.6.0-0.rc7.git1.1.fc33.x86_64
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: { echo
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-uvm/uvm_utils.o
/tmp/akmodsbuild.6qACAcgU/BUILD/nv>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ld -m elf_x86_64 -z
max-page-size=0x20 -r -o
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm.o
>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: { echo
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm/nvidia-drm.o
/tmp/akmodsbuild.6qACAcgU/BUILD/n>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make -f ./scripts/Makefile.modpost
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: sed 's/ko$/o/'
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/modules.order
| scripts/mod/modpost -i ./Module.>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: FATAL: modpost: GPL-incompatible
module nvidia-drm.ko uses GPL-only symbol 'mutex_lock_nested'
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[2]: ***
[scripts/Makefile.modpost:93: __modpost] Error 1
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: *** [Makefile:1596:
modules] Error 2
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: Leaving directory
'/usr/src/kernels/5.6.0-0.rc7.git1.1.fc33.x86_64'
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make:
[Bug 1818533] New: perl-Test-Compile-2.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818533 Bug ID: 1818533 Summary: perl-Test-Compile-2.4.0 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Compile Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 2.4.0 Current version/release in rawhide: 2.3.1-2.fc32 URL: http://search.cpan.org/dist/Test-Compile/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3388/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1818111] perl-Test-Simple-1.302173 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818111 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-7678909ab5 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7678909ab5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7678909ab5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Sunday, 29 March 2020, clime wrote: > You can make a separate namespace for this in dist-git. It doesn't need to > be a separate branch. That way, you won't be disturbing anyone elses space. or simply forks... > > clime > > On Friday, 27 March 2020, Stephen Gallagher wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> There has been a lot of (really good!) discussion on the original >> proposal thread, but as it has grown too large to follow anymore, I'm >> restarting it. I have made numerous changes to the Change Proposal >> page to improve the scope of the proposal as well as clarify some of >> the questions that have come up repeatedly in the original thread. >> >> Please see the newly-updated >> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose >> for more details[1]. >> >> == Summary == >> ELN is a new buildroot and compose process for Fedora that will take >> Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux >> compose. Feedback from this build, compose and integration testing >> will be provided to Fedora packagers so that they can see the >> potential impact of their changes on RHEL development. >> >> == Owner == >> >> * Name: [[User:Bookwar| Aleksandra Fedorova]] >> * Email: al...@bookwar.info >> * Name: [[User:Sgallagh | Stephen Gallagher]] >> * Email: sgall...@redhat.com >> >> >> >> [1] List of changes between the original and new versions: >> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Bu >> ildroot_and_Compose=revision=569655=569549 >> -BEGIN PGP SIGNATURE- >> >> iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo >> bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K >> jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ >> 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D >> 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z >> Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ >> mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg >> lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED >> pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q >> 6DnLPiZt >> =42JI >> -END PGP SIGNATURE- >> ___ >> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org >> To unsubscribe send an email to devel-announce-le...@lists.fed >> oraproject.org >> Fedora Code of Conduct: https://docs.fedoraproject.org >> /en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.or >> g/archives/list/devel-annou...@lists.fedoraproject.org >> > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
You can make a separate namespace for this in dist-git. It doesn't need to be a separate branch. That way, you won't be disturbing anyone elses space. clime On Friday, 27 March 2020, Stephen Gallagher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > There has been a lot of (really good!) discussion on the original > proposal thread, but as it has grown too large to follow anymore, I'm > restarting it. I have made numerous changes to the Change Proposal > page to improve the scope of the proposal as well as clarify some of > the questions that have come up repeatedly in the original thread. > > Please see the newly-updated > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > for more details[1]. > > == Summary == > ELN is a new buildroot and compose process for Fedora that will take > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux > compose. Feedback from this build, compose and integration testing > will be provided to Fedora packagers so that they can see the > potential impact of their changes on RHEL development. > > == Owner == > > * Name: [[User:Bookwar| Aleksandra Fedorova]] > * Email: al...@bookwar.info > * Name: [[User:Sgallagh | Stephen Gallagher]] > * Email: sgall...@redhat.com > > > > [1] List of changes between the original and new versions: > https://fedoraproject.org/w/index.php?title=Changes%2FELN_ > Buildroot_and_Compose=revision=569655=569549 > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q > 6DnLPiZt > =42JI > -END PGP SIGNATURE- > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-leave@lists. > fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject. > 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- > annou...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Sat, Mar 28, 2020 at 01:06:55PM -0700, Kevin Fenzi wrote: > On Sat, Mar 28, 2020 at 07:10:55AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > I think the question about priority was asked because: > > When installing eln by "upgrading" from rawhide, you hardly want to go > > package by package, but instead want to do a single command to install > > everything that can be installed. That's the first time where you want > > eln packages to have priority. > > ok. It's unclear to me if there is supposed to be such a path. > I know people in these threads have suggested it, but I don't know that > the change owners want it. > > > But then rawhide moves on, and some eln packages fail to build. Then > > you still want to keep the eln stuff (and not revert to to the rawhide > > versions of everything), but install the rawhide versions if that is > > the only way to satisfy dependencies. > > Sure, if the intent is for people to have long lived installs, but thats > not what I got at all. > > > So this question is how to set up inheritance and priorities to get a > > workable system like that. (Or maybe it's supposed to work in a > > different way?) > > My understanding so far is that if you want to test it, you do a install > from it's media, test and then destroy it until next time. Hm, I'm pretty certain that there were not installation media planned. In fact, there were supposed to be no deliverables... > Or if you want to test just a single or small group of packages you pull > them and load them into your rawhide install, test, and then a update > removes them so you are back at rawhide state for the next one. > > But I could be misunderstanding, or perhaps change owners do want to > allow for longer lived installs, in which case you are right that they > would want some way to make the eln packages 'newer' than rawhide > instead of older. > > Perhaps it's time for us to add some ugly hacks to rpm and make: > > f > fc > eln > f To do just that, we wouldn't need a hack. g > f, and + > anything. But without knowing what the intended way to consume this is, discussing technical details is just idle speculation. 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
From the proposal:
%if 0%{?fedora} < 32 && 0%{?rhel} <= 8
The fix will be done via a pull request that states a time limit. We
want the regular maintainers to see / comment / commit, but we also
don't want things to stall for months and get forgotten about.
---
What kind of pull request is that? It's like saying either merge or ...
In other words, great way to lose community members.
On Sat, 28 Mar 2020 at 21:07, Kevin Fenzi wrote:
>
> On Sat, Mar 28, 2020 at 07:10:55AM +, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > I think the question about priority was asked because:
> > When installing eln by "upgrading" from rawhide, you hardly want to go
> > package by package, but instead want to do a single command to install
> > everything that can be installed. That's the first time where you want
> > eln packages to have priority.
>
> ok. It's unclear to me if there is supposed to be such a path.
> I know people in these threads have suggested it, but I don't know that
> the change owners want it.
>
> > But then rawhide moves on, and some eln packages fail to build. Then
> > you still want to keep the eln stuff (and not revert to to the rawhide
> > versions of everything), but install the rawhide versions if that is
> > the only way to satisfy dependencies.
>
> Sure, if the intent is for people to have long lived installs, but thats
> not what I got at all.
>
> > So this question is how to set up inheritance and priorities to get a
> > workable system like that. (Or maybe it's supposed to work in a
> > different way?)
>
> My understanding so far is that if you want to test it, you do a install
> from it's media, test and then destroy it until next time.
> Or if you want to test just a single or small group of packages you pull
> them and load them into your rawhide install, test, and then a update
> removes them so you are back at rawhide state for the next one.
>
> But I could be misunderstanding, or perhaps change owners do want to
> allow for longer lived installs, in which case you are right that they
> would want some way to make the eln packages 'newer' than rawhide
> instead of older.
>
> Perhaps it's time for us to add some ugly hacks to rpm and make:
>
> f > fc
> eln > f
>
> :)
>
> 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
___
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
[Bug 1818509] perl-Tk-804.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818509 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Tk-804.035-1.fc30.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=42831482 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
CPE Weekly: 2020-03-28
--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-06 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Freeze is over! * New version of pagure (5.9.0) has been released and deployed in staging and on pagure.io * Document being worked on about how to onboard new CI systems in Fedora - this is a work in progress! https://hackmd.io/5gk_kHFhSR6sKa1huPA-4Q ### Request for Review * Fedora magazine: Article proposals about Silverblue rebase to F32 https://pagure.io/fedora-magazine-proposals/issue/59 * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync== * Covid-19 has seen restrictions added to the data centres we are moving from and to, however we are unaffected as of yet for the move. * If or when our timelines become affected, we will inform you immediately of any outages, downtimes, etc a delay could cause. * Thank you for your understanding at this particularly uncertain and worrying times. ### AAA Replacement * We are nearly complete in our phase one development! * Below are some of the features the team have developed since beginning the project in mid-Jan * UI where people register and login * Add groups function * Change personal details * Enroll OPT * Reset password * View group owner details * Use a search engine * Our next steps in this project is to demo to the team for feedback and then continue to develop CentOS authentication, more user focused features, request for more feedback and test, test test! ### CI/CD * Monitor-gating is now running in production and has already caught a couple of issues with bodhi (both in stg and in prod)! * Rpmautospec * This is in review as a Fedora package: https://bugzilla.redhat.com/show_bug.cgi?id=1816124 * Work progressing on Koji tagging plugin (post-build), full use case support for bumping releases * The team hope to deploy this in staging soon! ### Sustaining Team * Mbbox * Some progress on CRD for koji-builder and koji-hub components has been made this week * Bodhi 5.2.2 released * Some issues with celery tasks & rawhide monitoring has been super useful with this. * Compose Tracker enhancement * Tagging issues have been resolved * Ability to ping maintainers * Fedora Minimal Compose * Odcs-backend-releng01 has been provisioned to enable testing ## CentOS Updates ### CentOS * ppc64le and aarch64, 8 and 8-stream nodes now available in cico for tenants to checkout. -- Email sent to ci-user list * New signing for SIGs (through https://cbs.centos.org) live this week! ### CentOS Stream * Qt5.12 pushed in response to an internal request * NetworkManager re-imported ### Other Updates GitForge Decision * After evaluating over 300 user stories from multiple stakeholders we have aligned on a decision for the Gitforge that CPE will operate for the coming years. We are opting for Gitlab for our dist git and project hosting and will continue to run pagure.io with community assistance. * Check out our GitForge decision on the Fedora Community blog https://communityblog.fedoraproject.org/ * And at the CentOS blog page https://blog.centos.org/2020/03/git-forge-decision/ * Keep an eye out for mails in the coming months to the devel lists as we plan transitions and next steps with GitLab * We would like to express our sincere thank you to all who contributed requirements to us! As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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:
[Bug 1818509] perl-Tk-804.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818509 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1674356 --> https://bugzilla.redhat.com/attachment.cgi?id=1674356=edit [patch] Update to 804.035 (#1818509) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1818509] New: perl-Tk-804.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818509 Bug ID: 1818509 Summary: perl-Tk-804.035 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Tk Keywords: FutureFeature, Triaged Assignee: xav...@bachelot.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: andreas.bierf...@lowlatency.de, perl-devel@lists.fedoraproject.org, trem...@tremble.org.uk, xav...@bachelot.org Target Milestone: --- Classification: Fedora Latest upstream release: 804.035 Current version/release in rawhide: 804.034-8.fc32 URL: http://search.cpan.org/dist/Tk/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3471/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Sat, Mar 28, 2020 at 07:10:55AM +, Zbigniew Jędrzejewski-Szmek wrote: > > I think the question about priority was asked because: > When installing eln by "upgrading" from rawhide, you hardly want to go > package by package, but instead want to do a single command to install > everything that can be installed. That's the first time where you want > eln packages to have priority. ok. It's unclear to me if there is supposed to be such a path. I know people in these threads have suggested it, but I don't know that the change owners want it. > But then rawhide moves on, and some eln packages fail to build. Then > you still want to keep the eln stuff (and not revert to to the rawhide > versions of everything), but install the rawhide versions if that is > the only way to satisfy dependencies. Sure, if the intent is for people to have long lived installs, but thats not what I got at all. > So this question is how to set up inheritance and priorities to get a > workable system like that. (Or maybe it's supposed to work in a > different way?) My understanding so far is that if you want to test it, you do a install from it's media, test and then destroy it until next time. Or if you want to test just a single or small group of packages you pull them and load them into your rawhide install, test, and then a update removes them so you are back at rawhide state for the next one. But I could be misunderstanding, or perhaps change owners do want to allow for longer lived installs, in which case you are right that they would want some way to make the eln packages 'newer' than rawhide instead of older. Perhaps it's time for us to add some ugly hacks to rpm and make: f > fc eln > f :) 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
Re: Coronavirus: Fedora RTC solutions and YOU
On 28/03/2020 16:13, Sérgio Basto wrote: > On Sun, 2020-03-22 at 23:04 +0100, Daniel Pocock wrote: >> Helping to host >> any other solution is good too, for example, Jitsi Meet provides a >> Docker image[5] now. > > I will try packaging all Jitsi Meet suite [1] Great If you would like to run it on the fedrtc.org domain please feel free to ask. E.g. meet.fedrtc.org ? If it needs credentials for anything then it could share my FAS SSO script[2] > > [1] > https://community.jitsi.org/t/where-i-find-deb-src-or-src-rpm-of-the-packages/26195/2 > 2. https://github.com/opentelecoms-org/fedrtc-org/tree/master/accounts ___ 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
Fedora-IoT-32-20200328.0 compose check report
No missing expected images. Passed openQA tests: 8/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.21 to 0.06 Previous test data: https://openqa.fedoraproject.org/tests/556496#downloads Current test data: https://openqa.fedoraproject.org/tests/559721#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
[Bug 1818493] New: perl-PPIx-Regexp-0.071 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818493 Bug ID: 1818493 Summary: perl-PPIx-Regexp-0.071 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PPIx-Regexp Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.071 Current version/release in rawhide: 0.070-1.fc33 URL: http://search.cpan.org/dist/PPIx-Regexp/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3288/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Slow boot on F32 Workstation
Den tors 26 mars 2020 kl 05:56 skrev Przemek Klosowski via devel < devel@lists.fedoraproject.org>: > On 3/21/20 8:45 AM, Andreas Tunek wrote: > > I sidegraded my rawhide install to F32 a couple of weeks ago and from > > the start I noticed that booting F32 was really slow. I assumed this > > was some kind of bug or some devel stuff and would get solved. > > > What did you upgrade from? There were Radeon firmware deficiencies > introduced around February that cause about 10 1-sec timeouts on boot > and every time the driver is awakened ( [Bug 1802641] kernel 5.4 Bug > Radeon ). > I side-graded from rawhide. It is an fully Intel laptop. > ___ > 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 > ___ 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
Fedora-IoT-33-20200328.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Soft failed openQA tests: 2/8 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-IoT-33-20200325.0): ID: 559655 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/559655 ID: 559656 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/559656 Passed openQA tests: 6/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Mount /run contents changed to 67.99123905% of previous size Used mem changed from 145 MiB to 173 MiB 1 services(s) added since previous compose: getty@tty6.service Peak task count changed from 102 to 119 Previous test data: https://openqa.fedoraproject.org/tests/556107#downloads Current test data: https://openqa.fedoraproject.org/tests/559655#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 145 MiB to 172 MiB 1 services(s) added since previous compose: getty@tty6.service Peak task count changed from 102 to 126 Previous test data: https://openqa.fedoraproject.org/tests/556108#downloads Current test data: https://openqa.fedoraproject.org/tests/559656#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
Re: Coronavirus: Fedora RTC solutions and YOU
On Sun, 2020-03-22 at 23:04 +0100, Daniel Pocock wrote: > Helping to host > any other solution is good too, for example, Jitsi Meet provides a > Docker image[5] now. I will try packaging all Jitsi Meet suite [1] [1] https://community.jitsi.org/t/where-i-find-deb-src-or-src-rpm-of-the-packages/26195/2 -- 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
[Bug 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 --- Comment #7 from Fedora Update System --- FEDORA-2020-f85e3cdf82 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f85e3cdf82` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f85e3cdf82 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1817797] perl-App-cpm-0.990 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817797 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2020-2b35f0ffcf has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2b35f0ffcf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b35f0ffcf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 32 compose report: 20200328.n.0 changes
OLD: Fedora-32-20200327.n.0 NEW: Fedora-32-20200328.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 9 Dropped packages:0 Upgraded packages: 97 Downgraded packages: 1 Size of added packages: 85.33 MiB Size of dropped packages:0 B Size of upgraded packages: 3.25 GiB Size of downgraded packages: 30.31 MiB Size change of upgraded packages: 178.34 MiB Size change of downgraded packages: 48.14 KiB = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: c-ares-1.16.0-1.module_f32+8330+e40f9292 Summary: A library that performs asynchronous DNS operations RPMs:c-ares c-ares-devel Size:967.47 KiB Package: gnome-applets-3.36.1-1.fc32 Summary: Small applications for the GNOME Flashback panel RPMs:gnome-applets Size:40.19 MiB Package: gnome-flashback-3.36.0-1.fc32 Summary: GNOME Flashback session RPMs:gnome-flashback Size:2.76 MiB Package: gnome-panel-3.36.0-1.fc32 Summary: GNOME Flashback panel RPMs:gnome-panel gnome-panel-devel gnome-panel-doc gnome-panel-libs Size:8.44 MiB Package: libuv-1:1.34.2-1.module_f32+8199+88b63a05 Summary: Platform layer for node.js RPMs:libuv libuv-devel libuv-static Size:1.40 MiB Package: nghttp2-1.40.0-2.module_f32+8199+88b63a05 Summary: Experimental HTTP/2 client, server and proxy RPMs:libnghttp2 libnghttp2-devel nghttp2 Size:3.70 MiB Package: ocaml-ppx-deriving-4.4.1-1.fc32 Summary: Type-driven code generation for OCaml RPMs:ocaml-ppx-deriving ocaml-ppx-deriving-devel ocaml-ppx-deriving-doc Size:27.75 MiB Package: python-diskcache-4.1.0-2.fc32 Summary: Disk and file backed persistent cache RPMs:python3-diskcache Size:74.99 KiB Package: python-lunr-0.5.6-1.fc32 Summary: A Python implementation of Lunr.js RPMs:python3-lunr Size:70.11 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ModemManager-1.12.6-1.fc32 Old package: ModemManager-1.10.8-2.fc32 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 10.98 MiB Size change: 202.96 KiB Changelog: * Thu Mar 05 2020 Peter Robinson 1.12.6-1 - Update to 1.12.6 release Package: PyX-0.15-1.fc32 Old package: PyX-0.14.1-15.fc32 Summary: Python graphics package RPMs: PyX PyX-doc Size: 5.43 MiB Size change: 808.72 KiB Changelog: * Thu Mar 19 2020 Jos?? Matos - 0.15-1 - Update to 0.15 - Turn on the pdf generation - Add several patches from Debian Package: R-multcomp-1.4.12-1.fc32 Old package: R-multcomp-1.4.10-5.fc32 Summary: Simultaneous inference for general linear hypotheses R Package RPMs: R-multcomp Size: 714.66 KiB Size change: 6.11 KiB Changelog: * Thu Mar 19 2020 Jos?? Matos - 1.4.12-1 - update to 1.4-12 Package: R-systemfit-1.1.24-1.fc32 Old package: R-systemfit-1.1.22-7.fc32 Summary: Simultaneous Equation Estimation R Package RPMs: R-systemfit Size: 812.36 KiB Size change: 1.26 KiB Changelog: * Thu Mar 19 2020 Jos?? Matos - 1.1.24-1 - Update to 1.1-24 Package: R-zoo-1.8.7-1.fc32 Old package: R-zoo-1.8.6-5.fc32 Summary: Z's ordered observations for irregular time series RPMs: R-zoo R-zoo-devel Size: 6.44 MiB Size change: 23.65 KiB Changelog: * Wed Mar 18 2020 Jos?? Matos - 1.8.7-1 - update to 1.8-7 Package: Rex-1.8.2-1.fc32 Old package: Rex-1.5.0-8.fc31 Summary: The friendly automation framework on basis of Perl RPMs: Rex Size: 434.05 KiB Size change: 8.13 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 1.5.0-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Mar 07 2020 Dominic Hopf - 1.8.2-1 - Upgrade to Rex 1.8.2 Package: adcli-0.9.0-1.fc32 Old package: adcli-0.8.2-9.fc32 Summary: Active Directory enrollment RPMs: adcli adcli-doc Size: 482.67 KiB Size change: -92.08 KiB Changelog: * Wed Mar 18 2020 Sumit Bose - 0.9.0-1 - Update to upstream release 0.9.0 and latest patches Package: audit-3.0-0.19.20191104git1c2f876.fc32 Old package: audit-3.0-0.18.20191104git1c2f876.fc32 Summary: User space tools for kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel python3-audit Size: 3.15 MiB Size change: -6.99 KiB Changelog: * Thu Mar 12 2020 Steve Grubb 3.0-0.19.20191104git1c2f876 - Add Obsolete python2-audit (#1783061) Package: azove-2.0-19.fc32 Old package: azove-2.0-18.fc32 Summary: Another Zero-One Vertex Enumeration tool RPMs: azove Size: 233.46 KiB Size change: -9.84 KiB Changelog: * Wed Mar 18 2020 Jerry James - 2.0-19 - Add -memory and -map patches - Build with RPM_LD_FLAGS Package: beaker-27.3-1.fc32 Old package: beaker-27.2-1.fc32
Fedora-32-20200328.n.0 compose check report
No missing expected images. Failed openQA tests: 3/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200327.n.0): ID: 559477 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/559477 ID: 559485 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/559485 Old failures (same test failed in Fedora-32-20200327.n.0): ID: 559495 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/559495 ID: 559508 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/559508 Soft failed openQA tests: 21/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-32-20200327.n.0): ID: 559504 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/559504 ID: 559507 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/559507 Old soft failures (same test soft failed in Fedora-32-20200327.n.0): ID: 559429 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/559429 ID: 559430 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/559430 ID: 559434 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/559434 ID: 559438 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/559438 ID: 559441 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/559441 ID: 559442 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/559442 ID: 559464 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/559464 ID: 559487 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/559487 ID: 559489 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/559489 ID: 559521 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/559521 ID: 559543 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/559543 ID: 559553 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/559553 ID: 559562 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/559562 ID: 559571 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/559571 ID: 559587 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/559587 ID: 559595 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/559595 ID: 559596 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/559596 ID: 559599 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/559599 ID: 559601 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/559601 Passed openQA tests: 147/171 (x86_64) New passes (same test not passed in Fedora-32-20200327.n.0): ID: 559469 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/559469 ID: 559588 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/559588 Skipped non-gating openQA tests: 1 of 173 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.24 to 0.06 Previous test data: https://openqa.fedoraproject.org/tests/558828#downloads Current test data: https://openqa.fedoraproject.org/tests/559472#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Average CPU usage changed from 4.51428571 to 18.30476190 Previous test data: https://openqa.fedoraproject.org/tests/558830#downloads Current test data: https://openqa.fedoraproject.org/tests/559474#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 8 MiB to 0 MiB System load changed from 0.95 to 0.74 Previous test data: https://openqa.fedoraproject.org/tests/558831#downloads Current test data: https://openqa.fedoraproject.org/tests/559475#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.18 to 1.32 Previous test data: https://openqa.fedoraproject.org/tests/558847#downloads Current test data: https://openqa.fedoraproject.org/tests/559491#downloads Installed system changes in test x86_64 KDE-live-iso
Fedora rawhide compose report: 20200328.n.0 changes
OLD: Fedora-Rawhide-20200327.n.0 NEW: Fedora-Rawhide-20200328.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 18 Dropped packages:0 Upgraded packages: 118 Downgraded packages: 0 Size of added packages: 28.27 MiB Size of dropped packages:0 B Size of upgraded packages: 1.71 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -67.00 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20200328.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: adb-enhanced-2.5.2-1.fc33 Summary: Swiss-army knife for Android testing and development RPMs:adb-enhanced Size:17.11 KiB Package: feedbackd-0.0.0+git20200305-1.fc33 Summary: Feedback library for GNOME RPMs:feedbackd feedbackd-devel Size:518.00 KiB Package: ffuf-1.0.2-1.fc33 Summary: Fast web fuzzer written in Go RPMs:ffuf golang-github-ffuf-devel Size:13.44 MiB Package: gobuster-3.0.1-1.fc33 Summary: Directory/File, DNS and VHost busting tool written in Go RPMs:gobuster golang-github-oj-gobuster-devel Size:13.39 MiB Package: kerberoast-0.0.9-1.fc33 Summary: Kerberos security toolkit for Python RPMs:kerberoast python3-kerberoast Size:28.17 KiB Package: libevdevPlus-0.1.1-3.fc33 Summary: C++ wrapper around libevdev RPMs:libevdevPlus libevdevPlus-devel Size:225.69 KiB Package: protonvpn-cli-2.2.2-7.fc33 Summary: Linux command-line client for ProtonVPN written in Python RPMs:protonvpn-cli Size:62.70 KiB Package: python-adb-shell-0.1.3-1.fc33 Summary: Python implementation for ADB shell and file sync RPMs:python3-adb-shell Size:44.34 KiB Package: python-aiopg-1.0.0-2.fc33 Summary: Postgres integration with asyncio RPMs:python3-aiopg Size:64.50 KiB Package: python-aiostream-0.4.1-2.fc33 Summary: Generator-based operators for asynchronous iteration RPMs:python3-aiostream Size:57.24 KiB Package: python-boxsdk-2.7.1-1.fc33 Summary: Python wrapper for the Box API RPMs:python3-boxsdk Size:177.98 KiB Package: python-cloudant-2.12.0-2.fc33 Summary: Cloudant/CouchDB Client Python library RPMs:python3-cloudant Size:99.05 KiB Package: python-itanium_demangler-1.0-1.fc33 Summary: Pure Python parser for mangled itanium symbols RPMs:python3-itanium_demangler Size:22.49 KiB Package: python-javaobj-0.4.0.1-1.fc33 Summary: Python module for serializing and deserializing Java objects RPMs:python3-javaobj Size:78.50 KiB Package: python-magic-0.4.15-2.fc33 Summary: File type identification using libmagic RPMs:python3-magic Size:17.25 KiB Package: python-mulpyplexer-0.08-1.fc33 Summary: Module that multiplexes interactions with lists of Python objects RPMs:python3-mulpyplexer Size:13.19 KiB Package: python-nessus-file-reader-0.2.0-1.fc33 Summary: Python file reader for nessus files RPMs:python3-nessus-file-reader Size:29.66 KiB Package: python-xpath-expressions-1.0.2-1.fc33 Summary: Treat XPath expressions as Python objects RPMs:python3-xpath-expressions Size:14.74 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: annobin-9.16-1.fc33 Old package: annobin-9.14-1.fc33 Summary: Annotate and examine compiled binary files RPMs: annobin annobin-annocheck Size: 1.10 MiB Size change: 2.71 KiB Changelog: * Fri Mar 27 2020 Nick Clifton - 9.16-1 - Annobin: Fix access to the -flto and -fsanitize flags. Package: argbash-2.8.1-4.fc33 Old package: argbash-2.8.1-3.fc32 Summary: Bash argument parsing code generator RPMs: argbash Size: 53.44 KiB Size change: -2.23 KiB Package: awscli-1.18.31-1.fc33 Old package: awscli-1.18.29-1.fc33 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.70 MiB Size change: -146 B Changelog: * Fri Mar 27 2020 Gwyn Ciesla - 1.18.30-1 - 1.18.30 * Fri Mar 27 2020 Gwyn Ciesla - 1.18.31-1 - 1.18.31 Package: bout++-4.3.1-1.fc33 Old package: bout++-4.3.0-3.fc32 Summary: Library for the BOUndary Turbulence simulation framework RPMs: bout++-common bout++-doc bout++-mpich bout++-mpich-devel bout++-openmpi bout++-openmpi-devel python3-bout++ python3-bout++-mpich python3-bout++-openmpi Size: 19.18 MiB Size change: 8.04 KiB Changelog: * Fri Mar 27 2020 David Schw??rer - 4.3.1-1 - Update to 4.3.1 Package: buildah-1.15.0-0.19.dev.git17ceb60.fc33 Old package: buildah-1.14.0-0.31.dev.git82ff48a.fc32 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 87.24 MiB Size change: 551.99 KiB Changelog: * Thu Jan 30 2020 RH Container Bot - 1.14.0-0.32.dev.git4131dfa - autobuilt 4131dfa * Fri Jan 31 2020 RH Container Bot - 1.14.0-0.33.dev.git3177db5 - autobuilt
[Bug 1818483] New: perl-Mouse-2.5.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818483 Bug ID: 1818483 Summary: perl-Mouse-2.5.10 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mouse Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, trem...@tremble.org.uk Target Milestone: --- Classification: Fedora Latest upstream release: 2.5.10 Current version/release in rawhide: 2.5.9-3.fc32 URL: http://search.cpan.org/dist/Mouse/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/12781/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-Rawhide-20200328.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 7/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200327.n.0): ID: 559286 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/559286 ID: 559311 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/559311 ID: 559320 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/559320 ID: 559421 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/559421 ID: 559426 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/559426 Old failures (same test failed in Fedora-Rawhide-20200327.n.0): ID: 559284 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/559284 ID: 559298 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/559298 ID: 559333 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/559333 Soft failed openQA tests: 19/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200327.n.0): ID: 559254 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/559254 ID: 559255 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/559255 ID: 559259 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/559259 ID: 559263 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/559263 ID: 559266 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/559266 ID: 559289 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/559289 ID: 559312 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/559312 ID: 559314 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/559314 ID: 559346 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/559346 ID: 559351 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/559351 ID: 559368 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/559368 ID: 559377 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/559377 ID: 559378 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/559378 ID: 559387 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/559387 ID: 559396 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/559396 ID: 559412 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/559412 ID: 559420 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/559420 ID: 559424 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/559424 ID: 559428 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/559428 Passed openQA tests: 145/171 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200327.n.0): ID: 559281 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/559281 ID: 559283 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/559283 ID: 559317 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/559317 ID: 559319 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/559319 ID: 559321 Test: x86_64 KDE-live-iso base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/559321 ID: 559322 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/559322 ID: 559323 Test: x86_64 KDE-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/559323 ID: 559324 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/559324 ID: 559325 Test: x86_64 KDE-live-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/559325 ID: 559326 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/559326 ID: 559327 Test: x86_64 KDE-live-iso desktop_background URL:
Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
On 28. 03. 20 1:01, Kevin Fenzi wrote: Do you have any ideas when rpm 4.16 will be released? I don't see any dates on the change. Or perhaps I guess the question is when it will land in rawhide? From the ticket https://pagure.io/fesco/issue/2360 My understanding is that 4.16 could be shipped today: but lets please get 4.16 into rawhide for people to test, ASAP. For the backend: At any rate, even if sqlite was approved today we wouldn't be switching to that until at least a couple of weeks of shakedown for 4.16 first. -- 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On 27. 03. 20 17:02, Robbie Harwood wrote: What if I do not want to have %if's in my spec files? As long as your package builds in ELN then just maintain your package like normal. If there is a build failure, the ELN SIG may provide a PR as described above or will discuss alternative approaches on an individual basis with you. So... if we don't want %ifs in our spec files, the ELN SIG will provide us some? This is my understanding as well. Thanks Stephen for reworking the proposal. However it still looks like you heard the feedback but the response is "we are doing it our way anyway". Please, consider the feedback that many people provided here, do not outright reject it. -- 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
Re: RFC: Python minimization in Fedora
On 15. 01. 20 23:59, Zbigniew Jędrzejewski-Szmek wrote: ### Solution 5: Stop shipping mandatory bytecode cache This solution sounds simple: We do no longer ship the bytecode cache mandatorily. Technically, we move the `.pyc` files to a subpackage of `python3-libs` (or three different subpackages, that is not important here). And we only*Recommend* them from `python3-libs` -- by default, the users get them, but for space critical Fedora flavors (such as container images) the maintainers can opt-out and so can the powerusers. This would **save 18.6 MiB / 50%** -- quite a lot. However, as said earlier, if the bytecode cache files are not there, Python attempts to create them upon first import. That can result in several problems, here we will try to propose how to workaround them. Below using a flag file in each __pycache__ directory is suggested. What about a different route: having a flag file for all descendants of a directory? For example, /usr/lib/python3.8/.dont_write_bytecode would cover all modules under /usr/lib/python3.8/. If a .pyc file is present, python could still make use of it. This would be a nicer solution because it wouldn't require modifying individual packages, but would still avoid the selinux issues and slowdowns from failed attempts to write the optimized files. The __pycache__ files wouldn't need to exist at all. To follow up on this, I got an idea recently. If we add a reason to this marker file, Python can warn properly, without distro-specific patches. Something like: echo "Install python3-libs-bytecode-opt-0 or python3-libs-bytecode-opt-1 to get the cache." > /usr/lib64/python3.8/.dont_write_bytecode python -0 ... Warning: Bytecode cashe for the selected optimization level was not found and the /usr/lib64/python3.8/.dont_write_bytecode file prevents it to be created. Python startup and imports may be slower. Install python3-libs-bytecode-opt-0 or python3-libs-bytecode-opt-1 to get the cache. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: RFC: Python minimization in Fedora
On 15. 01. 20 23:59, Zbigniew Jędrzejewski-Szmek wrote: ### Solution 5: Stop shipping mandatory bytecode cache This solution sounds simple: We do no longer ship the bytecode cache mandatorily. Technically, we move the `.pyc` files to a subpackage of `python3-libs` (or three different subpackages, that is not important here). And we only*Recommend* them from `python3-libs` -- by default, the users get them, but for space critical Fedora flavors (such as container images) the maintainers can opt-out and so can the powerusers. This would **save 18.6 MiB / 50%** -- quite a lot. However, as said earlier, if the bytecode cache files are not there, Python attempts to create them upon first import. That can result in several problems, here we will try to propose how to workaround them. Below using a flag file in each __pycache__ directory is suggested. What about a different route: having a flag file for all descendants of a directory? For example, /usr/lib/python3.8/.dont_write_bytecode would cover all modules under /usr/lib/python3.8/. If a .pyc file is present, python could still make use of it. This would be a nicer solution because it wouldn't require modifying individual packages, but would still avoid the selinux issues and slowdowns from failed attempts to write the optimized files. The __pycache__ files wouldn't need to exist at all. To follow up on this, I got an idea recently. If we add a reason to this marker file, Python can warn properly, without distro-specific patches. Something like: echo "Install python3-libs-bytecode-opt-0 or python3-libs-bytecode-opt-1 to get the cache." > /usr/lib64/python3.8/.dont_write_bytecode python -0 ... Warning: Bytecode cashe for the selected optimization level was not found and the /usr/lib64/python3.8/.dont_write_bytecode file prevents it to be created. Python startup and imports may be slower. Install python3-libs-bytecode-opt-0 or python3-libs-bytecode-opt-1 to get the cache. -- 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
Non-responsive maintainer gilboa
https://bugzilla.redhat.com/show_bug.cgi?id=1818461 CC: gilb...@gmail.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
[Bug 1818111] perl-Test-Simple-1.302173 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818111 Paul Howarth changed: What|Removed |Added Fixed In Version||perl-Test-Simple-1.302173-1 ||.fc33 Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1818111] perl-Test-Simple-1.302173 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818111 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2020-7678909ab5 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7678909ab5 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 8:09 PM David Cantrell wrote:
>
> On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
> >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote:
> >>
> >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >> >As Ben is on PTO, I'd like to present the System-Wide Change
> >> >
> >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >> [snip]
> >>
> >> It has taken me some time, but I have read through the entire thread in
> >> addition to the change proposal. The idea sounds really interesting to me
> >> and
> >> a lot of points have come up on the thread. I decided to group my
> >> responses
> >> together as this single email after reading through the entire thread to
> >> make
> >> it a bit easier to read (and to write).
> >>
> >> TL;DR -- I think this proposal should be broken up in to 2 proposals
> >>
> >> The turning point for me in the change proposal was the discussion of the
> >> RPM
> >> spec file macros and getting in to the mechanics of how ELN will work. It
> >> looks like a lot of other people had the same reaction because many of the
> >> responses get in to the technical details and for some questions, there
> >> are no
> >> answers yet. After thinking about it for a while, it would make sense to
> >> me
> >> to have ELN come up in multiple phases/proposals.
> >>
> >> Suggested Proposals:
> >>
> >> 1) ELN buildroot and install media
> >>
> >> In this proposal, I'd like to see the ELN buildroot defined, the Koji
> >> changes implemented, the automated builds implemented, and install
> >> media
> >> composes happening.
> >>
> >> The expectation here should be that it is rough around the edges. But
> >> doing this gives the community something to see, use, and discuss
> >> further
> >> when reviewing the next change proposals.
> >>
> >> We should have some community goals with this proposal to capture a
> >> list of
> >> EL vs. Fedora differences and how to address those per package and in
> >> the
> >> context of ELN.
> >>
> >> 2) ELN lifecycle
> >>
> >> This gets in to more of the mechanics of how ELN builds can be handled
> >> by
> >> the community. I do not think there is a one size fits all and we
> >> should
> >> give developers control over how best to handle this for the packages
> >> they
> >> maintain.
> >>
> >> The spec file macros, git branch ideas, inheritance, pull request
> >> workflow,
> >> what builds block what composes, who is responsible for ELN failures,
> >> and
> >> other expectations of package maintainers (both Fedora and RHEL)
> >> should be
> >> discussed here. This proposal is definitely the policy side of
> >> things, but
> >> I think it would be easier to talk about after #1 is done.
> >>
> >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even
> >> called
> >> rhel-rawhide at one point), the ELN idea is one where the work is being
> >> targeted in the right place. As a Fedora contributor, I see RHEL as a
> >> customer and if we can make their work easier, I want to do that. As a
> >> RHEL
> >> package maintainer, I see Fedora as a place where I can make my job easier
> >> as
> >> a RHEL package maintainer. The more things we get right on the community
> >> side
> >> of things, the easier it is to produce RHEL.
> >>
> >> Various comments from reading the thread:
> >>
> >> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
> >>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el'
> >> macro
> >>that covers all three of those.
> >>
> >
> >The %{?rhel} macro name currently exists and is in use in some
> >packages as I recall.
>
> Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
> I would prefer a new macro for the ELN work to distinguish it from the
> existing macros.
>
> >> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
> >>major release. This should be ok in the community since Red Hat
> >> ultimately
> >>makes the decision to version RHEL. This is an engineering decision
> >> and I
> >>think it would help imply that ELN is _not_ meant for current RHEL.
> >> This
> >>also lets us entertain the idea of multiple ELN major versions
> >> concurrently
> >>should we ever want to do that.
> >>
Numbering by RHEL versions can not be done based on RHEL release
dates. Because RHEL stops consuming Fedora Rawhide code much earlier.
To implement such numbering properly we would need to have a
coordination with RHEL on a much deeper level. It will be additionally
confusing, as RHEL can have as many overrides and branches on top of
ELN packages as it wants and we can not say if ELN package built
during the times of RHEL 9 development lands in RHEL 9 and is not
consumed much later in RHEL 10 for example.
ELN is not RHEL, it is what RHEL could have been if we
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 05:55:42PM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 4:42 PM Jerry James wrote: > > Good idea. Thank you! > > I got a segfault on s390x on the second build attempt. I'd like to > investigate the ephemeron angle a bit, I think. No crashes here overnight, but I'll leave it running. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20200328.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 04:45:50PM -0700, Kevin Fenzi wrote: > On Fri, Mar 27, 2020 at 03:19:01PM -0500, Justin Forbes wrote: > > On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > > > Stephen Gallagher writes: > > > > > It is under discussion whether this snapshot will have its own > > > > > installation media. For now the preferred way to test ELN composes > > > > > would be to use standard Fedora Rawhide images and then include ELN as > > > > > an additional repository. > > > > > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > > > > > Yeah, that's something I was trying to figure out too. As discussed > > > before, for rpm '.eln < .fc33', so if the same package is available > > > from both sources, the rawhide one will win. > > > > > > > Can this be handled with the existing 'priority' directive in > > repository config files? > > I think this is a nice behavior and we should consider not messing with > it any. (ie, rawhide is always newer). I think the question about priority was asked because: When installing eln by "upgrading" from rawhide, you hardly want to go package by package, but instead want to do a single command to install everything that can be installed. That's the first time where you want eln packages to have priority. But then rawhide moves on, and some eln packages fail to build. Then you still want to keep the eln stuff (and not revert to to the rawhide versions of everything), but install the rawhide versions if that is the only way to satisfy dependencies. So this question is how to set up inheritance and priorities to get a workable system like that. (Or maybe it's supposed to work in a different way?) 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
Re: Upgrade tooling
On Fri, Mar 27, 2020 at 10:34:49AM +0200, Panu Matilainen wrote: > On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: > >>On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>>On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: > > previous-release-blocker(s) and previous-previous-release-blockers(s), > > since the changes would need to be deployed in F32 and F31. Also > > note that the last time when the upgrade plugins run code is in > > upgrade phase between two reboots, and the plugin is running > > pre-upgrade code. This code would then invoke post-upgrade rpm. It's > > certainly doable, but seems a bit funky. > > Right, requiring changes to previous versions is not okay. I seem to > be thinking our upgrade tooling had gotten fixed at some point to > perform the upgrade on the target distro packaging management stack > as it would really need to be, but guess that was just a dream. > >>> > >>>Relying on the target distro management stack sound nice, but is > >>>actually problematic: how do you run the next version before you > >>>install the next version? Sure, you can install stuff to some temporary > >>>location and run the tools from there, but then you are running in > >>>a very custom franken-environment. Such a mode of running would face > >>>the same issue as anaconda installer: it would only get tested during > >>>the upgrade season, languishing otherwise. > >> > >>Mock has this cool bootstrap image thing now. It seems to me we > >>could use that image to run the system upgrades too [*]. And if/when > >>we get koji to use that, it'll solve a number of ages old problems > >>on the build system, AND that image will get heavily tested 24/7 so > >>it wouldn't be any once in a full moon franken-thing. > >> > >>[*] Mount the host filesystem from mock and perform a dnf > >>--instalroot=... distro-upgrade on that, turning the whole landscape > >>inside out. > > > >Where would mock be executing from? The same filesystem it is modifying? > > Where is the offline upgrade executing from? How's this > fundamentally different? It's not — the point I was trying to make that IF we are running from the the host filesystem, it is easier to run directly from it. This subject has a long history of different approaches. Things that are more like what you describe than what we're currently using have been used in the past. And at least for Fedora, it seems that the simplicity of the current approach wins over the limitations. For RHEL the best solution may need to be different. > Oh come on. Running from a bootstrap image allows using full native > capabilities of rpm/dnf in any new version, without having to > consider what the previous versions support. How's that "not much"? Yes, that is an important hurdle that Fedora generally doesn't encounter at all. Fedora usually waits until the new rpm functionality is released in older versions of Fedora before allowing it to be used in rawhide. I think this should be a viable approach for RHEL too — after all, rpm is very good at keeping backwards compatibility. Another approach could be to perform the upgrade in two steps: have a rpm+dnf stack compiled for the old version, install it, and then do the upgrade to the real target version. Dunno, that's quickly getting complex. > >Let's consider a concrete example that came up recently: grub wants to > >rewrite something in the bootloader area on disk to help upgrades from > >very old installations. In current "offline upgrade" scheme, the upgrade > >tools are running on the real system, with udev active. They can query > >and touch hardware, can see all the disks as they are, etc. If we > >went through mock, it'd be running in an nspawn environment w/o access > >to hardware. > > And still that offline upgrade will be running on the old systems > kernel which will simply *prevent* certain types of actions to be > performed in an upgrade, just like using host system packaging stack > *prevents* use of native capabilities in the next version, just > because the old version doesn't support them, which is just totally > a** backwards. Really. > > Note that I'm talking about a high-level idea here. I haven't looked > at what a mock bootstrap image looks like, I haven't looked at what > offline upgrade looks like. Sure there would be technical details, > perhaps obstacles even to sort out. > > > > >(Something like os-tree's atomic replacement of things, that's of > >course a completely different story. But so far we're talking about > >traditional systems.) > > > >>>So nowadays we have a much simpler mechanism: reboot to a special > >>>system target without most daemons running (to avoid interference > >>>during the upgrade), run the update there, reboot into the new > >>>environment. The biggest advantage is that this way we reduce the > >>>amount of "custom": we're
Self Introduction: Weiping
Hi, I'm working on packaging cputil, and I'm interested in working on useful tools about benchmark or performance. Thanks Zbyszek's kindly help. Thanks Weiping ___ 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
