Fedora-Cloud-33-20210101.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201231.0): ID: 749262 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/749262 ID: 749269 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/749269 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1909426] perl-Graph-0.9716 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909426 --- Comment #7 from Upstream Release Monitoring --- Skipping the scratch build because an SRPM could not be built: ['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-2c0k324n/perl-Graph.spec'] returned 1: b'error: line 5: unclosed macro or bad line continuation\n' -- 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 1909426] perl-Graph-0.9716 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909426 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Graph-0.9715 is|perl-Graph-0.9716 is |available |available --- Comment #6 from Upstream Release Monitoring --- Latest upstream release: 0.9716 Current version/release in rawhide: 0.97.12-1.fc34 URL: http://search.cpan.org/dist/Graph/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7524/ -- 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
[389-devel] 389 DS nightly 2021-01-01 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/01/report-389-ds-base-1.4.4.9-1.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
License change: R-usethis GPLv3 -> MIT
As in subject; this will be in Rawhide only due to other breaking changes. -- Elliott ___ 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: Thoughts about packaging a standalone python-PyQt5-sip?
On Thu, 31 Dec 2020, Kevin Fenzi wrote:
I think fundamentally the version of PyQt5-sip probably needs to match (or
be very close to) the version of sip that PyQt5 itself was compiled with.
I think for calibre (which is currently failing with):
...
/usr/bin/python3 -c import os;
os.chdir('/builddir/build/BUILD/calibre-5.8.1/build/pyqt/pictureflow'); from
sipbuild.tools.build import main; main(); --verbose --no-make --qmake
/usr/bin/qmake-qt5
Querying qmake about your Qt installation...
/usr/bin/qmake-qt5 -query
These bindings will be built: pictureflow.
Generating the pictureflow bindings...
-c: Unable to find file "QtWidgets/QtWidgetsmod.sip"
...we need python-qt5 to be using sip5 also. I looked into it a bit, it
completely changes from using a configure.py to using sip-build and
PyQt-builder.
Or can we just add a subpackage there that uses sip5 and keep the sip4
ones for sip4 users? something like python3-qt5-sip5-devel ?
Or should we just convert everything to sip5 now?
I'd really like to get calibre building again... :)
It looks like technically you can still use configure.py to build PyQt5
with sip5, but it does seem more forward looking to switch to sip-build /
sip-install.
BTW, can you please build PyQt-builder for F33? Thanks.
Scott
___
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: Thoughts about packaging a standalone python-PyQt5-sip?
On Wed, 2020-12-30 at 20:40 -0500, Scott Talbert wrote: > On Wed, 30 Dec 2020, Scott Talbert wrote: > > > > Neal and I are looking at getting ButterManager packaged, and it > > > depends on sip and PyQt5-sip: > > > > > > > > > https://github.com/egara/buttermanager/blob/master/requirements.txt > > > > > > [snip] > > > Any idea what's the best way to handle this? and/or why PyQt5- > > > sip's > > > versioning get so far ahead of sip? > > > > I think fundamentally the version of PyQt5-sip probably needs to > > match (or be > > very close to) the version of sip that PyQt5 itself was compiled > > with. > > So it looks like with sip 5, PyQt5-sip is now published separately .. with sip 4, PyQt5-sip has a matching version number, but the package provides an API that is version 12.7. Confusing! > > Also, it seems a bit odd that ButterManager requires PyQt5- > > sip>=12.7.0, but > > only requires sip>=4.19.8 (ie, a MUCH older version of sip). You > > might want > > to just try patching that out and/or inquire with upstream about > > whether that > > version dependency is correct. > > Upstream clarified and it turns out they don't actually depend on sip. And they don't need to depend directly on PyQt5-sip either, PyQt5 automatically pulls it in. > > > Looking at the history...it almost looks like these dependencies were > added due to a packaging bug in PyQt5 in Arch Linux?? [1] > > [1] https://github.com/egara/buttermanager/issues/13 > Yup, thanks! > So it seems like the PyQt5-sip and sip dependencies really shouldn't > be > there as ButterManager doesn't use them itself (that I can tell). > We do need a strategy for how to eventually switch to the standalone PyQt5-sip, but that can wait for when we rebase PyQt5 and KDE to it I guess. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 12:53 PM Ben Cotton wrote: > > ** Update anaconda to perform the installation using mount -o > compress=zstd:1 > ** Set the proper option in fstab (alternatively: set the XATTR) I think the most discoverable is using 'compress=zstd:1" as the mount option, and any one who wants to opt out would remove this. Upon removal, the system will become not compressed basically by attrition, as files are replaced. The mount option method is per file system. Since we have 'subvol' mount options to mount '/' and '/home' it seems plausible that compression is a per subvolume option, but it's not (see below). It's file system wide. The per subvolume, per directory, per file method of compression has some pretty esoteric nuances: - chattr +c method uses the default compression, currently this is zlib - btrfs property method can't be unset https://github.com/kdave/btrfs-progs/issues/308 - btrfs property compression 'none' is not the same as unsetting it, and it inherits just like any other xattr; none means mount option "compress" does not apply; mount option "compress-force" will compress files set with compression 'none'. - btrfs property method isn't recursive https://github.com/kdave/btrfs-progs/issues/278 - both methods stop at subvolume boundaries; i.e. if you set compression on a subvolume or directory, it inherits as you add new directories or files, but stops at a subvolume - compression flags survive through btrfs send/receive - this is particularly confusing because it can make it a bit difficult to have a copy without compression, and not immediately obvious that it's continuing to tag along This might best be turned into a flowchart :P > This Change only applies to newly installed systems. Existing systems > on upgrade will be unaffected, but can be converted manually with > btrfs filesystem defrag -czstd -r, updating `/etc/fstab` > and remounting. Note that defragmenting to compress is an option. You can just add the mount option to fstab and remount, but only new files will be compressed, but again by attrition, eventually most of the file system will end up compressed. -- Chris Murphy ___ 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 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On 2020-12-30 1:48 p.m., Michel Alexandre Salim wrote: On Wed, 2020-12-30 at 16:28 -0500, Elliott Sales de Andrade wrote: On Wed, 30 Dec 2020 at 14:53, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression == How to test == Existing systems can be converted to use compression manually with btrfs filesystem defrag -czstd -r, updating `/etc/fstab` Update `/etc/fstab` how? Please be more explicit. Good point, thanks. Adding it now. Additionally, make sure to apply "systemctl daemon-reload" after editing /etc/fstab otherwise some services will fail to boot on existing installed system. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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 1909426] perl-Graph-0.9715 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909426 --- Comment #5 from Upstream Release Monitoring --- Skipping the scratch build because an SRPM could not be built: ['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-ezze96x5/perl-Graph.spec'] returned 1: b'error: line 5: unclosed macro or bad line continuation\n' -- 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 1909426] perl-Graph-0.9715 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909426 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Graph-0.9714 is|perl-Graph-0.9715 is |available |available --- Comment #4 from Upstream Release Monitoring --- Latest upstream release: 0.9715 Current version/release in rawhide: 0.97.12-1.fc34 URL: http://search.cpan.org/dist/Graph/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7524/ -- 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 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
On Thu, Dec 31, 2020 at 5:37 AM Zbigniew Jędrzejewski-Szmek wrote: > Is it really worth it to go through a separate deprecation step? > xemacs users can switch to emacs after xemacs is removed. I see that > you are concerned about the plugins, but maybe it's just better to > drop xemacs and the plugins in one go. If we notify the plugins' > maintainers now, they'll still have a few months to try to port them > to emacs (if suitable and porting is actually necessary). > Normally, I'd be in favour of "dragging out" the removal a bit, but > in this case I think we don't need to, because of the relatively > close replacement and the small number of users. I honestly have no idea how many users there are. I have gotten bug reports from time to time over the years, but it is possible that the number of users has shrunk down to near zero, in which case I might be worrying for nothing. My reasoning for this change proposal was two-fold. First, it prevents the scope of the work from creeping while I'm trying to remove all of the XEmacs-related bits from Fedora. Second, it may flush out anybody who will say, "You can pry my XEmacs from my cold dead fingers!" If anybody like that appears, then I get to say, "Well then, you get to maintain it!" and hand over the packages. :-) Does anybody else have an opinion on this? If the consensus is that deprecation is unnecessary, then I'll start contacting package maintainers about dropping XEmacs support from their packages. Thanks, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thoughts about packaging a standalone python-PyQt5-sip?
On Wed, Dec 30, 2020 at 08:26:42PM -0500, Scott Talbert wrote:
>
> I think fundamentally the version of PyQt5-sip probably needs to match (or
> be very close to) the version of sip that PyQt5 itself was compiled with.
I think for calibre (which is currently failing with):
...
/usr/bin/python3 -c import os;
os.chdir('/builddir/build/BUILD/calibre-5.8.1/build/pyqt/pictureflow'); from
sipbuild.tools.build import main; main(); --verbose --no-make --qmake
/usr/bin/qmake-qt5
Querying qmake about your Qt installation...
/usr/bin/qmake-qt5 -query
These bindings will be built: pictureflow.
Generating the pictureflow bindings...
-c: Unable to find file "QtWidgets/QtWidgetsmod.sip"
...we need python-qt5 to be using sip5 also. I looked into it a bit, it
completely changes from using a configure.py to using sip-build and
PyQt-builder.
Or can we just add a subpackage there that uses sip5 and keep the sip4
ones for sip4 users? something like python3-qt5-sip5-devel ?
Or should we just convert everything to sip5 now?
I'd really like to get calibre building again... :)
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: Chromium built in rawhide does not render most strings
I rebuilt chromium, but it did not resolve the issue. ~spot On Wed, Dec 30, 2020 at 5:35 PM Marius Schwarz wrote: > Am 30.12.20 um 14:07 schrieb Mattia Verga via devel: > > Il 30/12/20 10:14, Marius Schwarz ha scritto: > >> Don't you need to recompile stuff first to have an effect? :) > >> > >> > > I've just pushed a rebuild for qt5-qtwebengine, let's see if that's > enough. > > > > I had a chromium 85 build running instead of the 87er, that had no > problems rendering texts. My guerss is, that chromium needs a rebuild too. > > Best regards, > Marius > ___ > 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-01-01 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Deprecate_xemacs == Summary == Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages, all of which have dead upstreams. == Owner == * Name: [[User:jjames|Jerry James]] * Email: loganje...@gmail.com == Detailed Description == I have been part of XEmacs upstream for over 20 years, and have maintained the Fedora package for over 11 years. Upstream development had already slowed significantly when I became Fedora maintainer. The last release was over 7 years ago. Since that time, development has essentially come to a halt. Somebody will push a commit every now and then, but significant bugs are not being fixed. I see no future for the project. We should start moving towards dropping it from the distribution. The upstream sources have been spread across 3 packages in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra. In addition, the xemacs package uses an ancient, unmaintained 3D X library: neXtaw. It's last release was in 2003. Since xemacs is the only package in Fedora that uses neXtaw, I propose that it also be deprecated so we can eventually drop it. Deprecation is warranted because there are about a dozen XEmacs add-on packages in Fedora. This will prevent us from adding any more as we work to retire the existing add-ons. == Feedback == On December 7, 2020, I [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VDETPULZDBMXBXJKEFZX7DQ5R6W6FBXT/ communicated my intent to file this Change] on fedora-devel-list. There has been no community feedback. == Benefit to Fedora == This Change will open a path for us to eventually remove unmaintained software from the distribution. == Scope == * Proposal owners: The only required work is the addition of `Provides: deprecated()` to the 4 affected packages. * Other developers: No immediate work is required. Eventually, maintainers of XEmacs add-on packages will need to retire those packages so that XEmacs itself can be retired. * Release engineering: This change does not require coordination with or impact release engineering and does not require a mass rebuild. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: While this proposal does not match any of the [https://docs.fedoraproject.org/en-US/project/objectives current objectives], it is not opposed to any. == Upgrade/compatibility impact == Since the Change only deprecates packages, it has no immediate effect on upgrades or compatibility. Eventually, when the affected packages are retired, fedora-obsolete-packages will be updated to properly manage upgrades. == How To Test == N/A (not a System Wide Change) == User Experience == This change will not lead to any immediate changes in user experience. Eventually, we will retire the affected packages, which will impact users of those packages. We will seek to communicate the upcoming retirement as we work towards it. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? None == Documentation == N/A (not a System Wide Change) == Release Notes == The xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages have been deprecated. XEmacs users should prepare for the eventual removal of these packages from the Fedora distribution. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 34 Change: Xfce-4.16 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/xfce-4.16 == Summary == Xfce 4.16 is a stable release with proven components, provide features to both new and power users alike. This change proposal is submitted to sync fedora packages with the latest upstream release. == Owners == * Name: [[User:nonamedotc| Mukundan Ragavan]] * Email: nonamed...@fedoraproject.org * Name: [[User:kevin| Kevin Fenzi]] * Email: ke...@scrye.com == Detailed Description == This change migrates Xfce desktop environment (DE) to the latest version provided by upstream developers. This release brings, amongst others, the following features * client-side decorations * fractional scaling * new status tray plugins * Streamlined application chooser (i.e. merged "mime type editor" and "default applications") Full feature list can be viewed at [https://xfce.org/about/news Xfce news] == Benefit to Fedora == Updating Xfce to 4.16 will provide Fedora Xfce users stable but latest versions of upstream software. We will also be able to provide timely bug fixes. == Scope == * Proposal owners: ** Update core xfce packages to 4.16 ** Rebuild plugins once core packages are build * Other developers: N/A (not a System Wide Change) * Release engineering:
Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig == Summary == This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or `/boot` directory if no boot partition is used). == Owner == * Name: [[User:Javierm|Javier Martinez Canillas]] * Email: javi...@redhat.com * Name: [[User:Gicmo|Christian Kellner]] * Email: ckell...@redhat.com == Detailed Description == The GRUB configuration files layout on EFI platforms is not consistent with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le with Open Firmware). On platforms using EFI the GRUB configuration file (`grub.cfg`) and environment variables block (`grubenv`) are stored in the EFI System Partition (ESP) while for non-EFI platforms these are stored in the boot partition (or `/boot` directory if not boot partition is used). The reason for this is that the path where the GRUB bootloader searches for its configuration file varies depending on the firmware interface used. In most cases, GRUB searches for it in the path set in the `$prefix` variable. The device is not specified in that case, GRUB just searches for a configuration in this path for every detected device. But on EFI, a special `$fw_path` variable is used instead. This variable specifies both the device and path from where the GRUB bootloader was loaded and these are used to search for the configuration file. This is done for security reasons, to make sure that the correct GRUB configuration file is used and not just the first one found in one of the detected devices. Since the GRUB binary is located in the ESP, it expects to find the configuration file in that location as well. But this creates the mentioned inconsistency, because the GRUB configuration file has to be stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms it has to be stored in `/boot/grub2/grub.cfg`. This leads to a GRUB configuration layout that is confusing for users and error prone, since either the tools that are used to manage these files have to be aware of the differences or symbolic links used to hide the fact that the pats differ depending on the platform. Also, it creates artificial constraints on the OS installation due the differences in the configuration layout used. A system installed when using EFI won't be bootable if the firmware configuration is changed to boot using legacy BIOS instead, for example enabling the EFI Compatibility Support Module or moving the disk to a BIOS machine. The proposal is to always store the `grub.cfg` and `grubenv` files in the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg` to only be a small configuration file that sets a different `$prefix` variable and loads the configuration file stored in `/boot/grub2/grub.cfg`. The `$prefix` variable will be set to the device partition where `/boot/grub2/grub.cfg` is stored, using the partition filesystem's Universally Unique IDentifier (UUID). That way the correct GRUB configuration file will be loaded, making it as secure as the current approach where the configuration file in the ESP is used. A drawback of the new approach is that the GRUB configuration will now depend on the boot partition (or `/boot` directory if no boot partition is used). But since the kernel and initramfs images are stored there too, the bootloader configuration already has this dependency anyways. Note that the proposed configuration files layout is already used by the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this will make the systems installed with Anaconda to be consistent with the images generated by these. == Benefit to Fedora == This change will not only simplify and make less confusing the GRUB configuration but also allow the following improvements: * To have a consistent configuration across all the architectures using GRUB. * Allow the same installation to be booted with either EFI or legacy BIOS. * Use the same documentation and commands for all architectures instead of having EFI as a special case. * Make GRUB configuration tools more robust by not relying on symbolic links to be created and not having to handle platform specific cases. * Align with images generated by COSA and OSBuild on how the GRUB configuration files are used. * Align with other Linux distributions on how the GRUB configuration files are used. == Scope == * Proposal owners: ** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in `/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms. ** Make Anaconda to generate the minimal GRUB config file in the ESP that sets the `$prefix` variable and loads the configuration file located in `/boot/grub2/grub.cfg`. ** Modify the grub2 package scriptlets to not generate the `/boot/grub2/grubenv` and
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Summary == Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it. == Owner == * Name: [[User:law | Jeff Law]] * Email: l...@redhat.com == Detailed Description == -ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files. This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora. To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error. == Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders. == Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros. * Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems. I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives. == Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts. == How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues. == User Experience == Users should see no changes to the user experience. == Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro. == Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No == Documentation == No upstream documentation. Packaging guidelines will need a minor update. == Release Notes == I do not expect this change to require any release notes. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Fedora 34 Change: IBus 1.5.24 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IBus_1.5.24 == Summary == IBus will use the mmap(2) feature to show emoji and Unicode tables in order to reduce the physical memory usage. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == Currently IBus disables the emoji and Unicode features in some system users likes gdm, liveuser, gnome-initial-setup not to exhaust the limited memory usage with LiveDVD. The emoji data requires about 10MB and the Unicode data requires about 15MB and the total 25MB is required roughly to show the tables. The Fedora testers ask to test the emoji feature and Unicode feature in LiveDVD and the next IBus will use mmap to be available the emoji and Unicode data with liveuser. == Feedback == Fedora I18N testers asks to test the emoji and Unicode data without installing Fedora to disc. == Scope == * Proposal owners: * Other developers: N/A * Release engineering: (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == About 25MB free disc space will be needed. == How To Test == # Run Fedora LiveDVD and log into the Fedora desktop # Run `gnome-control-center region` and add both XKB and input method sources. E.g. "English (US)" and "Hangul" # Enable an XKB source with mouse or Super-space shortcut key. E.g. "English (US)" # Type Ctrl-Shift-e, "smile", space, and Enter key. U+1F603 is output. == User Experience == The physical memory usage will be reduced. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No * Blocks product? None == Documentation == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression == Summary == On variants using btrfs as the default filesystem, enable transparent compression using zstd. Compression saves space and can significantly increase the lifespan of flash-based media by reducing write amplification. It can also increase read and write performance. == Owners == * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide Cavalca]], [[User:josef|Josef Bacik]] * Email: mic...@michel-slm.name, dcava...@fb.com, jo...@toxicpanda.com == Detailed description == Transparent compression is a btrfs feature that allows a btrfs filesystem to apply compression on a per-file basis. Of the three supported algorithms, zstd is the one with the best compression speed and ratio. Enabling compression saves space, but it also reduces write amplification, which is important for SSDs. Depending on the workload and the hardware, compression can also result in an increase in read and write performance. See https://pagure.io/fedora-btrfs/project/issue/5 for details. This was originally scoped as an optimization for https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora 33. == Benefit to Fedora == Better disk space usage, reduction of write amplification, which in turn helps increase lifespan and performance on SSDs and other flash-based media. It can also increase read and write performance. == Scope == * Proposal owners: ** Update anaconda to perform the installation using mount -o compress=zstd:1 ** Set the proper option in fstab (alternatively: set the XATTR) ** Update disk image build tools to enable compression: *** lorax *** appliance-tools *** osbuild *** imagefactory ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/328 setting compression level when defragmenting] ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/329 setting compression level using `btrfs property`] * Other developers: ** anaconda: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9920 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == This Change only applies to newly installed systems. Existing systems on upgrade will be unaffected, but can be converted manually with btrfs filesystem defrag -czstd -r, updating `/etc/fstab` and remounting. == How to test == Existing systems can be converted to use compression manually with btrfs filesystem defrag -czstd -r, updating `/etc/fstab` and remounting. == User experience == Compression will result in file sizes (e.g. as reported by du) not matching the actual space occupied on disk. The [https://src.fedoraproject.org/rpms/compsize compsize] utility can be used to examine the compression type, effective compression ration and actual size. == Dependencies == Anaconda will need to be updated to perform the installation using mount -o compress=zstd:1 == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream and will not enable * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == https://btrfs.wiki.kernel.org/index.php/Compression == Release Notes == Transparent compression of the filesystem using zstd is now enabled by default. Use the compsize utility to find out the actual size on disk of a given file. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Planned Outage - taiga - 2021-01-05 07:00 UTC
There will be an outage starting at 2021-01-05 07:00 UTC which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-01-05 07:00UTC' Reason for outage: Upgrade to a more recent/patched taiga Affected Services: Only taiga (ie: teams.fedoraproject.org) Ticket Link: https://pagure.io/fedora-infrastructure/issue/9552 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-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
Planned Outage - taiga - 2021-01-05 07:00 UTC
There will be an outage starting at 2021-01-05 07:00 UTC which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-01-05 07:00UTC' Reason for outage: Upgrade to a more recent/patched taiga Affected Services: Only taiga (ie: teams.fedoraproject.org) Ticket Link: https://pagure.io/fedora-infrastructure/issue/9552 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora-IoT-34-20201231.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 1/16 (x86_64), 5/15 (aarch64) ID: 749232 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/749232 ID: 749241 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/749241 ID: 749243 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/749243 ID: 749244 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/749244 ID: 749246 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/749246 ID: 749250 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/749250 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 749225 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/749225 Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201231.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 9/180 (x86_64), 9/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201230.n.0): ID: 748925 Test: x86_64 Server-dvd-iso mediakit_fileconflicts URL: https://openqa.fedoraproject.org/tests/748925 ID: 748977 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/748977 ID: 749033 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/749033 ID: 749038 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/749038 ID: 749042 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/749042 ID: 749052 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/749052 ID: 749080 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/749080 Old failures (same test failed in Fedora-Rawhide-20201230.n.0): ID: 748975 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/748975 ID: 748982 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/748982 ID: 748992 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/748992 ID: 749001 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/749001 ID: 749003 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/749003 ID: 749015 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/749015 ID: 749155 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/749155 ID: 749182 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/749182 ID: 749209 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/749209 ID: 749214 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/749214 ID: 749218 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/749218 Soft failed openQA tests: 20/180 (x86_64), 13/122 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20201230.n.0): ID: 748921 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/748921 ID: 748922 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/748922 ID: 748929 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/748929 ID: 748933 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/748933 ID: 748937 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/748937 ID: 748938 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/748938 ID: 748951 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/748951 ID: 748960 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/748960 ID: 748980 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/748980 ID: 749023 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/749023 ID: 749032 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/749032 ID: 749041 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/749041 ID: 749058 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/749058 ID: 749072 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/749072 ID: 749076 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/749076 ID: 749099 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/749099 ID: 749100 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/749100 ID: 749115 Test: x86_64 universal upgrade_server_64bit URL:
Re: can't install package pipewire-jack-audio-connection-kit
On 31/12/2020 16:10, Martin Gansser wrote: this means that jack-audio-connection-kit has been replaced by pipewire-jack-audio-connection-kit ? - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 This messes with i686 and x86_64? Usually that means, something else is broken. Personally, I'd try to get rid of the 32bit binary as quickly as possible. Either by rpm -e --nodeps && dnf install to get the 64 bit version instead of 32 bit. Matthias ___ 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: can't install package pipewire-jack-audio-connection-kit
this means that jack-audio-connection-kit has been replaced by pipewire-jack-audio-connection-kit ? but then i get this message: # dnf swap jack-audio-connection-kit pipewire-jack-audio-connection-kit Last metadata expiration check: 1:57:23 ago on Thu Dec 31 14:10:39 2020. Error: Problem 1: problem with installed package libavdevice-4.3.1-11.fc33.x86_64 - package libavdevice-4.3.1-11.fc33.x86_64 requires libjack.so.0()(64bit), but none of the providers can be installed - conflicting requests Problem 2: problem with installed package vlc-1:3.0.12-1.fc33.x86_64 - package vlc-1:3.0.12-1.fc33.x86_64 requires libjack.so.0()(64bit), but none of the providers can be installed - package vlc-1:3.0.11.1-4.fc33.x86_64 requires libjack.so.0()(64bit), but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - conflicting requests - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Thu, Dec 31, 2020 at 9:54 AM Martin Gansser wrote: > > Hi, > > when trying to install pipewire-jack-audio-connection-kit i get this error > message: > > # dnf -y install pipewire-jack-audio-connection-kit > Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020. > Error: > Problem: problem with installed package > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts > with jack-audio-connection-kit provided by > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > - conflicting requests > - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts > with jack-audio-connection-kit provided by > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts > with jack-audio-connection-kit provided by > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts > with jack-audio-connection-kit provided by > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages) > > How can i fix this ? Use "--allowerasing" to make it swap. Alternatively, use the following command: > dnf swap jack-audio-connection-kit pipewire-jack-audio-connection-kit -- 真実はいつも一つ！/ 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
can't install package pipewire-jack-audio-connection-kit
Hi, when trying to install pipewire-jack-audio-connection-kit i get this error message: # dnf -y install pipewire-jack-audio-connection-kit Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020. Error: Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - conflicting requests - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) How can i fix this ? Regards Martin ___ 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
[Test-Announce] Fedora-IoT 34 RC 20201231.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 34 RC 20201231.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201231.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201231.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ 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: How to easily automate test builds in a COPR project
Hi, On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote: > 4. Build the packages in COPR. > > Easy enough using a bash script but is there a better way? packit allows to create test builds in COPR based on GitHub PRs and probably also releases. Maybe this can make it easier for you, too: https://packit.dev/ Cheers Till ___ 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
How to easily automate test builds in a COPR project
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a -testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20201231.n.0 changes
OLD: Fedora-Rawhide-20201230.n.0 NEW: Fedora-Rawhide-20201231.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 7 Dropped packages:4 Upgraded packages: 84 Downgraded packages: 0 Size of added packages: 876.62 KiB Size of dropped packages:1.90 MiB Size of upgraded packages: 1.51 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 11.93 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: d0_blind_id-1.0-1.fc34 Summary: Cryptographic library to perform identification RPMs:d0_blind_id d0_blind_id-devel Size:331.83 KiB Package: material-icons-fonts-4.0.0-1.fc34 Summary: Google material design system icons RPMs:material-icons-fonts Size:414.02 KiB Package: python-sgmllib3k-1.0.0-2.fc34 Summary: python3 copy of sgmllib RPMs:python3-sgmllib3k Size:18.59 KiB Package: rust-assign-1.1.0-1.fc34 Summary: Simple macro to allow mutating instance with declarative flavor RPMs:rust-assign+default-devel rust-assign-devel Size:19.23 KiB Package: rust-js_int-0.2.0-1.fc34 Summary: JavaScript-interoperable integer types RPMs:rust-js_int+default-devel rust-js_int+lax_deserialize-devel rust-js_int+serde-devel rust-js_int+std-devel rust-js_int-devel Size:46.14 KiB Package: rust-ruma-identifiers-macros-0.17.4-1.fc34 Summary: Procedural macros for creating Matrix identifiers RPMs:rust-ruma-identifiers-macros+default-devel rust-ruma-identifiers-macros-devel Size:17.73 KiB Package: rust-ruma-identifiers-validation-0.1.1-1.fc34 Summary: Validation logic for ruma-identifiers and ruma-identifiers-macros RPMs:rust-ruma-identifiers-validation+default-devel rust-ruma-identifiers-validation+serde-devel rust-ruma-identifiers-validation-devel Size:29.09 KiB = DROPPED PACKAGES = Package: jgraphx-3.6.0.0-12.fc33 Summary: Java Graph Drawing Component RPMs:jgraphx jgraphx-javadoc Size:1.33 MiB Package: pagila-0.10.1-12.fc33 Summary: A sample database for PostgreSQL RPMs:pagila Size:523.09 KiB Package: python-blindspin-2.0.1-11.fc34 Summary: Braille Spinner for Click RPMs:python3-blindspin Size:12.16 KiB Package: trac-git-plugin-0.12.0.5-19.2019git.fc33 Summary: GIT version control plugin for Trac RPMs:trac-git-plugin Size:49.75 KiB = UPGRADED PACKAGES = Package: GraphicsMagick-1.3.36-1.fc34 Old package: GraphicsMagick-1.3.35-3.fc33 Summary: An ImageMagick fork, offering faster image generation and better quality RPMs: GraphicsMagick GraphicsMagick-c++ GraphicsMagick-c++-devel GraphicsMagick-devel GraphicsMagick-doc GraphicsMagick-perl Size: 12.32 MiB Size change: 9.25 KiB Changelog: * Wed Dec 30 2020 Rex Dieter - 1.3.36-1 - 1.3.36 - fix urw font path, Requires: urw-base35-fonts-legacy (#1847187) Package: R-ggplot2-3.3.3-1.fc34 Old package: R-ggplot2-3.3.2-1.fc33 Summary: Create Elegant Data Visualisations Using the Grammar of Graphics RPMs: R-ggplot2 Size: 3.87 MiB Size change: 77 B Changelog: * Wed Dec 30 2020 Elliott Sales de Andrade - 3.3.3-1 - Update to latest version (#1911726) Package: ansible-collection-google-cloud-1.0.1-2.fc34 Old package: ansible-collection-google-cloud-1.0.1-1.fc34 Summary: Google Cloud Platform collection RPMs: ansible-collection-google-cloud Size: 277.01 KiB Size change: 36 B Changelog: * Wed Dec 30 2020 Igor Raits - 1.0.1-2 - Drop runtime dependencies Package: ansible-collection-netbox-netbox-1.2.0-2.fc34 Old package: ansible-collection-netbox-netbox-1.2.0-1.fc34 Summary: Netbox modules for Ansible RPMs: ansible-collection-netbox-netbox Size: 214.92 KiB Size change: 111 B Changelog: * Wed Dec 30 2020 Igor Raits - 1.2.0-2 - Drop runtime dependencies Package: ansifilter-2.17-1.fc34 Old package: ansifilter-2.16-3.fc33 Summary: ANSI terminal escape code converter RPMs: ansifilter ansifilter-gui Size: 1.29 MiB Size change: 920 B Changelog: * Wed Dec 30 2020 Filipe Rosset - 2.17-1 - Update to 2.17 fixes rhbz#1884414 Package: awscli-1.18.206-1.fc34 Old package: awscli-1.18.204-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 76 B Changelog: * Wed Dec 30 2020 Gwyn Ciesla - 1.18.205-1 - 1.18.205 * Wed Dec 30 2020 Gwyn Ciesla - 1.18.206-1 - 1.18.206 Package: awstats-7.8-2.fc34 Old package: awstats-7.8-1.fc33 Summary: Advanced Web Statistics RPMs: awstats Size: 2.24 MiB Size change: 75 B Changelog: * Wed Dec 30 2020 Tim Jackson - 7.8-2 - Fix CVE-2020-35176 Package: bindfs-1.14.8-1.fc34 Old package: bindfs-1.14.7-3.fc33 Summary: Fuse filesystem to mirror a directory RPMs: bindfs Size: 254.17 KiB Size change: -3.22
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Dec 31, 2020 at 12:54 PM Vitaly Zaitsev via devel wrote: > > On 31.12.2020 12:37, Peter Robinson wrote: > > Of course it could, who do you propose to do that work and support all > > the various options and code required? > It can be easily installed during Fedora installation by executing the > following: > > 1. Make sure the ESP partition has more than 512 MB of free space > (systemd-boot uses an ESP partition to store kernels; the separate /boot > is no longer needed). > 2. Add Fedora boot flags instead of the /etc/default/grub to the > /etc/kernel/cmdline. > 3. Install systemd-boot to the ESP partition: bootctl --path=/boot/efi > install. > 4. Execute kernel-install scripts (I think this stage will be the same > as under GRUB2): kernel-install add $(uname -r) /lib/modules/$(uname > -r)/vmlinuz. > 5. Installation completed. > As Peter said this was already discussed in the "The future of legacy BIOS support in Fedora" thread [0]. I mentioned there that Anaconda already supports an option to use extlinux, so the same could be done for sd-boot. It shouldn't be a lot of work as you mentioned but someone will have to propose the patches to Anaconda. [0]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ Best regards, Javier ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Hello Tomasz, On Thu, Dec 31, 2020 at 10:55 AM Tomasz Torcz wrote: [snip] > > I think either never fixing this, or never updating systems to the > > "new way" are both untenable. We saw with the BLS switch many users > > depend on doing in place upgrades. Many were pushing 4 or more years. > > I think conversion script would be needed for people doing upgrades. > But first of all - documentation! It should be clear what GRUB Agree. > expectations are, where the config file should be and so on. > BLS conversion was hard because it was undocumented. One of the crucial > scripts (grubby? install-kernel?) has been changing behaviour upon > existence of some file or directory in /boot (was is loader/?). It was > undocumented and so counter-intuitive that cannot recall details after > merely two years. > > Right now the best information about how Fedora boots and what happens > on kernel installation can be founds on AdamW's blog. This is not > perfect :( > Yes, we need to close the documentation gap. The process is still quite complex. I think the long term goal should be to align with the https://systemd.io/BOOT_LOADER_INTERFACE/ and https://systemd.io/BOOT_LOADER_SPECIFICATION/ (and extend those specs to cover all the missing bits for the bootloaders used by Fedora) in order to make the interface between the bootloader and OS well defined. That will make easy to mix and match bootloaders and OS, but there is still a lot of work to do in order to achieve that. > > -- > Tomasz Torcz 72->| > 80->| > to...@pipebreaker.pl 72->| > 80->| Best regards, Javier ___ 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: What is the most time consuming task for you as packager?
On Wed, Dec 30, 2020 at 11:42 PM Michel Alexandre Salim wrote: > > Howdy, > One observation (also in the post): > > The CLIs for fedpkg and koji is currently meant for human, not machine, > consumptions. Invoking them from Bash scripts and trying to use the > output (e.g. getting the name of that side tag) involves some brittle > parsing. I plan to rewrite this in Python anyway, but it might be > useful to add an output formatter to some commands where it makes sense > (e.g. request-side-tag or chain-build). +1000 It would be really really nice if some CLI tools (koji, fedpkg, etc.) had a switch to print machine-readable output instead of human-readable output. I'm also resorting to parsing human-readable stdout from some of those tools in my scripts ... Probably that machine-readable format would turn out to be JSON of some kind? It seems to be the standard for this interoperability stuff now, and there's good support for bash (jq), python (json from stdlib), and all kinds of other languages. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
On Wed, Dec 30, 2020 at 02:53:13PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Deprecate_xemacs > > I have been part of XEmacs upstream for over 20 years, and have > maintained the Fedora package for over 11 years. Upstream development Kudos! > == Summary == > Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and > neXtaw packages, all of which have dead upstreams. Is it really worth it to go through a separate deprecation step? xemacs users can switch to emacs after xemacs is removed. I see that you are concerned about the plugins, but maybe it's just better to drop xemacs and the plugins in one go. If we notify the plugins' maintainers now, they'll still have a few months to try to port them to emacs (if suitable and porting is actually necessary). Normally, I'd be in favour of "dragging out" the removal a bit, but in this case I think we don't need to, because of the relatively close replacement and the small number of users. 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Hello Chris, Thanks a lot for the comments. On Thu, Dec 31, 2020 at 1:02 AM Chris Murphy wrote: [snip] > > That problem was the result of quite old core.img in the MBR gap (or > BIOS Boot partition). As that change simultaneously depended on > shipping a new GRUB module without a way to update the core.img with > up-to-date GRUB modules, there was a known weak spot that we even knew > of in advance. > Correct. > Upgrades of customized configurations that deviate significantly from > defaults aren't supported. It's best effort. We can't be blocking on > people's customizations. > I agree with you but users have different expectations I think. If they deviated from the default and that didn't cause issues for them after a system wide upgrade, they expect that to be the case on the next update. > I think we can come pretty close to atomically renaming > > /EFI/fedora/grub.cfg /EFI/fedora/grub.cfg.old > /EFI/fedora/grub.cfg.new to /EFI/fedora/grub.cfg > > And at least ensure the user can boot the old one, but even this I > think is pretty unlikely. It's really a teeny tiny window of failure > opportunity. And based on my reading of rename() if the files are > already all present, and all we're doing is renaming them, there > shouldn't be a case where grub.cfg is either missing entirely or zero > bytes. > > But dm-log-writes can help confirm or deny this. What I don't know is > if this can be done with bash. The convert script probably needs to be > done in C. Or at least the rename and sync parts. > Yes, for me is less about this tiny window but more about users having modifications in their GRUB config file that will be overwritten when generating a new one. For example in the BLS conversation some users update their kernel cmdline in the grub.cfg and that didn't match the GRUB_CMDLINE_LINUX in /etc/default/grub. Maybe what we can do is to not generate a new /boot/grub2/grub.cfg but instead copy the one in the ESP to cover these corner cases ? I'll update the proposal based on the feedback. Best regards, Javier ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 31.12.2020 12:37, Peter Robinson wrote: Of course it could, who do you propose to do that work and support all the various options and code required? It can be easily installed during Fedora installation by executing the following: 1. Make sure the ESP partition has more than 512 MB of free space (systemd-boot uses an ESP partition to store kernels; the separate /boot is no longer needed). 2. Add Fedora boot flags instead of the /etc/default/grub to the /etc/kernel/cmdline. 3. Install systemd-boot to the ESP partition: bootctl --path=/boot/efi install. 4. Execute kernel-install scripts (I think this stage will be the same as under GRUB2): kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz. 5. Installation completed. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Dec 31, 2020 at 11:29 AM Vitaly Zaitsev via devel wrote: > > On 31.12.2020 11:50, Peter Robinson wrote: > > Because it doesn't support traditional BIOS boot, or the boot systems > > of POWER, Z-series and numerous other corner cases. Just look at the > > thread about BIOS support from a few months ago to see how > > controversial even considering that was. If we then move to it just > > for UEFI based platforms there needs to be a lot of logic to deal with > > different boot paths. > > An option can be added to the Fedora installer to choose between GRUB2 > and systemd-boot for the UEFI configurations. On legacy, this step can > be automatically skipped. Of course it could, who do you propose to do that work and support all the various options and code required? It's easy to say it "works for me" in your one machine use case, but supporting it acros 1000s of config options with users that are less capable and don't know what a boot loader is it hard, it takes a lot of work so people don't end up with unbootable machines. ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 31.12.2020 11:50, Peter Robinson wrote: Because it doesn't support traditional BIOS boot, or the boot systems of POWER, Z-series and numerous other corner cases. Just look at the thread about BIOS support from a few months ago to see how controversial even considering that was. If we then move to it just for UEFI based platforms there needs to be a lot of logic to deal with different boot paths. An option can be added to the Fedora installer to choose between GRUB2 and systemd-boot for the UEFI configurations. On legacy, this step can be automatically skipped. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Dec 31, 2020 at 10:10 AM Vitaly Zaitsev via devel wrote: > > On 30.12.2020 20:53, Ben Cotton wrote: > > This change makes the GRUB configuration files layout to be consistent > > across all the supported architectures. Currently EFI is a special > > case since the GRUB configuration file and environment variables block > > are stored in the EFI System Partition (ESP) instead of the boot > > partition (or `/boot` directory if no boot partition is used). > > Why not switch from the ancient GRUB2 to the modern systemd-boot? Because it doesn't support traditional BIOS boot, or the boot systems of POWER, Z-series and numerous other corner cases. Just look at the thread about BIOS support from a few months ago to see how controversial even considering that was. If we then move to it just for UEFI based platforms there needs to be a lot of logic to deal with different boot paths. ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 31.12.2020 11:28, Qiyu Yan wrote: iirc systemd-boot don't support legacy BIOS system. Yes of course. Systemd-boot is not a bootloader. It is an EFIStub kernel manager with a simple menu. I've been using systemd-boot for over 1.5 years and it works great. It can only be enabled for Fedora UEFI configurations. The deprecated legacy configurations should stay on GRUB2. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Vitaly Zaitsev via devel 于2020年12月31日周四 下午6:12写道： > > On 30.12.2020 20:53, Ben Cotton wrote: > > This change makes the GRUB configuration files layout to be consistent > > across all the supported architectures. Currently EFI is a special > > case since the GRUB configuration file and environment variables block > > are stored in the EFI System Partition (ESP) instead of the boot > > partition (or `/boot` directory if no boot partition is used). > > Why not switch from the ancient GRUB2 to the modern systemd-boot? iirc systemd-boot don't support legacy BIOS system. > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 30.12.2020 20:53, Ben Cotton wrote: The proposal is to always store the `grub.cfg` and `grubenv` files in the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg` to only be a small configuration file that sets a different `$prefix` variable and loads the configuration file stored in `/boot/grub2/grub.cfg`. And what about users, who use Fedora with other GNU/Linux distributions? These distributions can also switch to the same GRUB2 configuration. They will all start fighting for the same file. That's why a separate /boot/efi/EFI/$distro_name/grub.cfg configuration file was introduced. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On 30.12.2020 20:53, Ben Cotton wrote: This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or `/boot` directory if no boot partition is used). Why not switch from the ancient GRUB2 to the modern systemd-boot? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: runtime dependencies not in Requires spec section
On 30.12.2020 22:49, Germano Massullo wrote: My question is: how can keepassxc trigger the installation of such libraries if the spec file does not contain any Requires dependency that should be the attribute to identify runtime dependencies that are needed by the package? Yes, it must. Qt5Svg is a Qt runtime plugin, so it will not be added automatically by rpmbuild. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: runtime dependencies not in Requires spec section
On 30.12.2020 23:01, Jerry James wrote: RPM can query ELF objects (executables and shared libraries) to find DT_NEEDED fields. That gives it a list of libraries that are depended on directly. Except for Qt5Svg, because it is a Qt runtime plugin. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 05:08:03PM -0700, Chris Murphy wrote: > > Upgrades of customized configurations that deviate significantly from > > defaults aren't supported. It's best effort. We can't be blocking on > > people's customizations. > > > > I think we can come pretty close to atomically renaming > > > > /EFI/fedora/grub.cfg /EFI/fedora/grub.cfg.old > > /EFI/fedora/grub.cfg.new to /EFI/fedora/grub.cfg > > > > And at least ensure the user can boot the old one, but even this I > > think is pretty unlikely. It's really a teeny tiny window of failure > > opportunity. And based on my reading of rename() if the files are > > already all present, and all we're doing is renaming them, there > > shouldn't be a case where grub.cfg is either missing entirely or zero > > bytes. > > > > But dm-log-writes can help confirm or deny this. What I don't know is > > if this can be done with bash. The convert script probably needs to be > > done in C. Or at least the rename and sync parts. > > > Oh I forgot the part about the convert script testing for custom > grub.cfg. Maybe it's possible to parse it first, and if it's custom, > bail. If it's non-custom then convert it. > > And a variation where we have an opt-in for this convert script for > Fedora 34 cycle. And then ship it and do the conversion in Fedora 35. > > I think either never fixing this, or never updating systems to the > "new way" are both untenable. We saw with the BLS switch many users > depend on doing in place upgrades. Many were pushing 4 or more years. I think conversion script would be needed for people doing upgrades. But first of all - documentation! It should be clear what GRUB expectations are, where the config file should be and so on. BLS conversion was hard because it was undocumented. One of the crucial scripts (grubby? install-kernel?) has been changing behaviour upon existence of some file or directory in /boot (was is loader/?). It was undocumented and so counter-intuitive that cannot recall details after merely two years. Right now the best information about how Fedora boots and what happens on kernel installation can be founds on AdamW's blog. This is not perfect :( -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ 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-32-20201231.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 748913 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/748913 ID: 748920 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/748920 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
License field change in ocaml-ocamlbuild
The license field changed: -License: LGPLv2+ with exceptions +License: LGPLv2 with exceptions but this wasn't because of a change upstream, just we got the wrong license originally. Jerry James has been writing a tool to synch Fedora spec files with the opam (OCaml source distribution) files and that caught the discrepancy. https://bugzilla.redhat.com/1911667 https://pagure.io/opam2rpm Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
