Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote: > On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote: > > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit : > > > > > Please do not drop mod_php. It is NOT the case that "php-fpm is > > > already > > > used but most users of httpd and nginx without any issue." > > > > php-fpm is the default configuration for httpd and nginx for few > > versions > > > > nginx ONLY uses php-fpm > > > > mod_php is httpd only and prefork mode only > > so without threaded MPM and without http2 support > > > > Please describe issues, I don't have any bug report about this. > > > > Remi > > Yes, nginx only uses php-fpm. But that has nothing to do with > mod_php. > > The default doesn't matter, there's absolutely no reason to take away > the > sysadmin's choice here. There are at least 40 servers I personally > am > responsible for where I see no reason to move from mod_php to php- > fpm, for > example. If you don't want to maintain it, I'd be happy to do so. > Many third > party packages expect mod_php, and nearly all documentation for > configuring > httpd for Fedora, CentOS and RHEL goes through the use of mod_php. > There is > just no reason to break this. People who want php-fpm will stick with > it, and > others will continue to use mod_php as we have for the last decade+. > Many > servers do not need http2, or other new features. Many of us have > something > that works, and we'd like to keep it working. That's what CentOS / RHEL is for. > -- > John M. Harris, Jr. > Splentity > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Qxr4ACgkQEV1auJxc Hh6GIRAAt5sV7J4E6W5vzHCc3iy+IGXYyMtl/RqewhkcHChT5ZuiCLnOqmBw0vbF Mrmn+6hyJUoP4Vfw1uRjbqvt5b3/0V+43ZibIwDNwi7jGSPVazgHUTdhvgqEiqhK +tWfLrwaoLMQZoCvMNFqoRnKvmDN/go1IhmHj7HAhhb6VLmGeJ2RJCqQH9hgMUwv 9P+aUGoqO5XDFApCGtU55dtIIecPiN5Sd+lHvFRxI5cTJafsU1cLjtqvmayVaPH2 jeS5nOEFauCuZztCrYBgwgB1OKKudfj9skkb3KlH5VzoH4uSxli4xUccYFnu3Nnq uz3J7L4W4sVc5cuhOZuQ+0GmKImY1bfrEj8FFhaVfLPU7qIXPe2zXVWrMC0FaBuD Vtkb3d+++Pfmz2Hbs8O9ufo8ahya751f55BQrJOkLq9ncyDjyUCXgmV6Uef+VSJM BuHRJjLTmH2i14z4hLNaila0QqOzPEg4ZpjlSOe4U1hG0UMkWqU/U3WGhTBw3dki 4sDGon85M1VOw3kDf9wyLzq0fUOvyFLOnDDewwxprWzB0W5J1j30reF9mnAiTzdJ mOOas+n8tLNYfCpMkClmg1YB8gO6AFdvD+45GTseYOzGo4hkBcsQcCbj1uQCi7rf 0W2MVWh5ioeluvA47/x9WbSEJ6sBrVMSoBp9lW7bDEb+WBm85cA= =oY/3 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Rawhide broken: crypto-policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-05-29 at 10:08 -0600, Jerry James wrote: > Trying to build a package just now failed > (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531): > > Running transaction check > Transaction check succeeded. > Running transaction test > Transaction test succeeded. > Running transaction > error: lua script failed: [string > "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19: > attempt to call a nil value > > Error in PREIN scriptlet in rpm package crypto-policies > error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install > failed This is fixed now. https://bugzilla.redhat.com/show_bug.cgi?id=1841851 > > -- > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7RNzUACgkQEV1auJxc Hh63xg/9EbBPd1jZ/0T8Dz3/te4VtBYFwV6Z/8WuRmnuINADIoFw18bd3VsFur7z e1tyuEZUxHVpvg0WJA43ktJxYeG8cVQoyXeTdD4wIAW7DWIuFIE9IKSyGLpajxXQ /TNlIjyR52zcUsltrbra64NB0+WP8I25HzjVbumzB4jWEl8/XIqFBja9Qaco1Z06 6odCLzdpuKVzJDqHXubhVI1ZnKX61tDPlDsGp/BH/+wb48/sos31dRAHoR22dhwl uzlyBsbfvcvZrLr/RmBQtZCXHyXbrtI5S3aPMNX1GcQkG5UOc4WxZWHhJb09AA2B Rs5PmU+O8MNk3t5VX3Ra6FhbsrG+tk+eRzZ2voxYBiWbFBNDbhmoGqAFgvxgNCRj dfQc0V5rMUxpoM1KglNUAKDJuZP2lW3K3KvQyXchnaG/uwNPxneJxsmgavRFB0yC 2HAL2f16TQbfABGw8kFy9Vc1lghbTZu2cTgaVjwYLd0IOVqntzQ0iSpFK5P5D/8B F+TBknkYwcfp2WotNLAAtd1dBkEy9Z6CWAHUKcMfUgdWt0FDvL3syJa4GQSe+/++ GgUcR8/SqX3Gszv8RnhYk2ziq3quEj8pcaUNEk+7Aia/8Xj60O6uou0zGBxU29EO i1b4h98ftK2rmdet+OJTbBeikLmnRSyTghgLpWF6mmwED6SM5W0= =OETP -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Adding Obsoletes to generated -debuginfo packages ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote: > Other possibility is to modify DNF to not touch such packages. Not > sure > if that would be better. Or is there already some functionality which > would exclude the package from dnf transaction, something like: > > ~~~ > # This package won't be installed, but will obsolete other packages > Provides: libsolv-self-destruct-pkg() > > ~~~ > > we use in fedora-obsolete-packages? Since they do not block the upgrades, does it really matter? However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically. > > Vít > > > > Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a): > > Because was bitten by this and there is not clear guideline, I have > > tried to draft something here: > > > > https://pagure.io/packaging-committee/pull-request/988 > > > > > > Vít > > > > > > Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a): > > > In libvirt we recently deleted a driver for the legacy Xen > > > toolstack. > > > > > > This was shipped in a libvirt-daemon-driver-xen RPM. > > > > > > I am able to add an "Obsoletes: libvirt-daemon-driver-xen < > > > 4.3.0" > > > line to the libvirt-daemon-driver-libxl RPM, which gives clean > > > upgrade path for users. > > > > > > If they have the libvirt-daemon-driver-xen-debuginfo RPM > > > installed > > > though that still breaks the upgrade. > > > > > > How can I get the auto-generated libvirt-daemon-driver-libxl- > > > debuginfo > > > RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < > > > 4.3.0" > > > statement ? It seems impossible, meaning users with debuginfo > > > have a > > > broken upgrade path. An unfortunate consequence of switching to > > > seprate > > > -debuginfo per sub-RPM. > > > > > > Regards, > > > Daniel > > ___ > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7X3hIACgkQEV1auJxc Hh4/SBAAta3Au3oyBA72koUfKaMhvw8/XcT4FHMcJNiInpyobYFNSMmAvjJPj2/L tIefm2tPmtqSv03OjnIaeENVNT+eNiCcHljDvnT4x8fFySRn+r9Qvs+A7PU7zAIc 11q2WD+wzinFeSuf62Y+tvIVb1TPPdBrJqSsh+f/v97YK94ZhTpzfBa1C7ysZOds JXSZo5Sh0OqLDmi876YdpCZnYn3DAbqmkCfMJJ5RNWDGu5KbN35s4utBZSTfqt73 bEh/TPZ22RkNYpPQU/70CJkBcJXVJMS6JzZIOUhvSE5ITvYTg/E26vL4AmZS0rY+ eWbaR2N7V7GDhVe5MM8wpHStF8KxGajROeqllR3OF0w8lKlxIPItj9DI7DHuBEtI IFJUq8L1OLnFP3PR3pkn6a8wNwLTVWmAy44lR4NCMn7J9SbvRcjmAuFx9O2IprIH wG9vmVo4Q2Olvh8HJYr09xAFGKzmqlZnBTgiPGwcHl5O4EkygPAEdHD1EcEtkeRv Ony/fi4HX2f3B1YKdlEoqs7sDsMvLPEJzw32MftMIdBBo8q/0Xba/EQMya76ihrh ai5AFAOiqpoNzN6FjceIEGm3G0n2YquLMW++uVPIB0VJLYmoXBuGZD02LLxUfTzm VFnSjqnyVMkNaavxJf2SyCPkRY8xqN3exymh0vQUOVPmWPAbywI= =hJ35 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: %configure broken in Rawhide
Uh, this is my fault. Ive tested it, but seems I have tested something else. Not near the computer now, so if somebody can untag it - would be much appreciated. Sorry again. On Thu, Jun 4, 2020, 02:07 Orion Poplawski wrote: > On 6/3/20 5:36 PM, Jerry James wrote: > > If koschei is telling you that your packages are failing to build in > > Rawhide, it may be because the %configure macro is currently broken: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1843714 > > > > Just a heads up. > > > > Thanks. Hopefully this gets cleaned up quickly. Seems like this would > have shown up pretty quickly with local testing before building for > rawhide. > > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.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 > ___ 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: %configure broken in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-04 at 02:58 +0200, Igor Raits wrote: > Uh, this is my fault. Ive tested it, but seems I have tested > something else. > > Not near the computer now, so if somebody can untag it - would be > much > appreciated. I got to my laptop faster than I thought. This should be fixed with redhat-rpm-config-160-1.fc33. There were actually 2 issues with the same thing, too many semicolons, one is from my commit and one from the PR that I have merged. Seems like a common problem when writing macros :/ At least it did not break anything than %configure, so the world did not explode :) > Sorry again. > > On Thu, Jun 4, 2020, 02:07 Orion Poplawski wrote: > > > On 6/3/20 5:36 PM, Jerry James wrote: > > > If koschei is telling you that your packages are failing to build > > > in > > > Rawhide, it may be because the %configure macro is currently > > > broken: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1843714 > > > > > > Just a heads up. > > > > > > > Thanks. Hopefully this gets cleaned up quickly. Seems like this > > would > > have shown up pretty quickly with local testing before building for > > rawhide. > > > > > > -- > > Orion Poplawski > > Manager of NWRA Technical Systems 720-772-5637 > > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > > 3380 Mitchell Lane or...@nwra.com > > Boulder, CO 80301 https://www.nwra.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 > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7YTRAACgkQEV1auJxc Hh6gtg//dzoZX2h6BRoP/whPJBEKl8QtojmyrjqYUpCNBQAdeDHuZyPKjclJhGmZ nE/CqffmFbUNeebF2D+aICUvrf6xHSRWzAs9I75wsA2bPN+Xg9fmfSs+ZxzwH6Vt Z6/zqg0zu/xZpSUUEtNWh9DwnG+dIBN4hAua+0qThlRU8uUXJPVXtbXRJtqKvmVL AwaC39E5LRCew+FxiderFpRN1+L40UjdfJkHYoezkwszjOX0AZV+SZXQaoYEb9zB m5Fan5uz5uzqHd1JzPXi62yuFu1dHOziHZnc/0YvkS3F9/qeNLE2Z++KE7SwR6d0 dPB8wHseVGy0M5XkgDQ1N83lVDOnRJ30F/DyonDYX6NbKcmoYiM1OGRn/i8g9MuA np/0ixs/Vwj1vgKnST9yMlu7mHNQGOvuTudMr39JjPc1DYZEQ2JrbgEY1C0Ypc43 TlHEsLpDfFvyZ5icBCXKoCDN1z7xJOnhVVX6ow3LgpAe56svs52UQ3hMAC8TM9UQ dQNuIxS3+0KAmX/wH0SnbnMONAUk9JwRcBvh28jPv6mu46bZ0tjXUxLLFOsdZnqm WIKN7N842BHusCK2VxF7TrA4oD+Q3DWWRESEBi7o1emycUTqTlb7PBNeYR3UL219 3uyri+f91DWgRjYlyF8Th7bzfXC/hf+YIEuWfDpfy7XyuxJ2xnE= =Ps+B -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Adding Obsoletes to generated -debuginfo packages ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-04 at 10:56 +0200, Vít Ondruch wrote: > Dne 03. 06. 20 v 19:29 Igor Raits napsal(a): > > On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote: > > > Other possibility is to modify DNF to not touch such packages. > > > Not > > > sure > > > if that would be better. Or is there already some functionality > > > which > > > would exclude the package from dnf transaction, something like: > > > > > ~~~ > > > # This package won't be installed, but will obsolete other > > > packages > > > Provides: libsolv-self-destruct-pkg() > > > > > ~~~ > > > > > we use in fedora-obsolete-packages? > > > > Since they do not block the upgrades, does it really matter? > > > They block updates. The subpackage -debuginfo requires the main > package. I don't think that it is true anymore, starting with Fedora 27. https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo ❯ sudo dnf repoquery --repo=rawhide-debuginfo --requires gnome-shell- debuginfo --quiet | wc -l 0 > While there is update for the main package, there is obviously not > update for the subpackages. Therefore the subpackage -debuginfo > packages > will block the upgrade forever. This is the same issue why we have > fedora-obsolete-packages. However the difference is that we typically > don't care about -debuginfos, because they are magically generated > and > they are always parallel installable. > > > > However, I > > agree that DNF removing packages that are not present in upgrade > > repo > > and blocking the upgrade, should be removed automatically. > > > Actually, the -debuginfo package could be possibly treated as > installonly packages. But even install only packages are updated, if > I > am not mistaken. So it would be probably better if DNF completely > ignored them. > > > Vít > > > > > > > > > Vít > > > > > > > > > Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a): > > > > Because was bitten by this and there is not clear guideline, I > > > > have > > > > tried to draft something here: > > > > > > > > https://pagure.io/packaging-committee/pull-request/988 > > > > > > > > > > > > Vít > > > > > > > > > > > > Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a): > > > > > In libvirt we recently deleted a driver for the legacy Xen > > > > > toolstack. > > > > > > > > > > This was shipped in a libvirt-daemon-driver-xen RPM. > > > > > > > > > > I am able to add an "Obsoletes: libvirt-daemon-driver-xen < > > > > > 4.3.0" > > > > > line to the libvirt-daemon-driver-libxl RPM, which gives > > > > > clean > > > > > upgrade path for users. > > > > > > > > > > If they have the libvirt-daemon-driver-xen-debuginfo RPM > > > > > installed > > > > > though that still breaks the upgrade. > > > > > > > > > > How can I get the auto-generated libvirt-daemon-driver-libxl- > > > > > debuginfo > > > > > RPM to have an "Obsoletes: libvirt-daemon-driver-xen- > > > > > debuginfo < > > > > > 4.3.0" > > > > > statement ? It seems impossible, meaning users with debuginfo > > > > > have a > > > > > broken upgrade path. An unfortunate consequence of switching > > > > > to > > > > > seprate > > > > > -debuginfo per sub-RPM. > > > > > > > > > > Regards, > > > > > Daniel > > > > ___ > > > > 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.fedora
Re: Rebuilt for OpenCV 4.3.0 in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-05-29 at 14:02 +0200, Nicolas Chauvet wrote: > Hello there, > > There is an update to opencv 4.3.0 in preparation for rawhide. > This will be handled in a side tag along with the rebuild of the all > dependencies. > (fedpkg build --target=f33-build-side-24026) > > This was evaluated ahead,so it should lead to issue. > https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/ > (failures are random issue on copr builders, should be all green on > koji). > > We will merge the side tag next week and once everything have been > rebuilt. Seems that some packages are broken in rawhide now: * os-autoinst * qimgv > Thanks > > -- > - > > Nicolas (kwizart) > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z64QACgkQEV1auJxc Hh4Dmw/+LuAOtCLcYUhtzRIEe3zA2aw5QiOTGNnbl08t245nIDUR0Pag1qSLXkU6 mz8eaK8bDND5yIyTOXdNCjFV38L3z3B2l+P3Vzv2R+csMBomav7R2z/eH1i9yhym S3XDkK1BFyxxjYn+2fq7vdTVQewIoxgpShNZcCI12ClejZUo2P+mYVJfmtOpVUyQ zhTD2LSBxn0UxkDwPZv3bYXy+hiOB0/jKurxuxCyt/ds/Fyx7gzfXy2UF1gnjfwk NHkHjpxYIJz9BKqlFyp/L9VLDUT9yA68BJ9cXyE2sC0U1KX4VtL9EokCZIXd+akJ pjdFu5yMb6E6oJ2JkxYgGFf7T5wJ1ZXrl7A0ZR82+VJhqoe4KsmShVxucSzVZ8qP rXwPkVnWVbIzCJnmj/L/kAEgcmcgwEegAGFblSwc0LuShUXKfNCWEdMA63pxADAT onlVMwawpFdlLC3YRMZhhqeI2jXHF5TCAZepSTC0IQMiYd+eYaKME/Sxh55zXJYr f7Xp50CmbhvvMmcqeHw02rm6H1CKlsK9ZMiFnV1SThS8SLmPwkhSjFEHSKTPs6Z7 FiWb7iFxkgEVf7I1X2/OGKuwSsT24C3uXx77AzfUarq27jV+0svnZnMnq6/ErINX T4ws8VOuJV9H+YjPpgz+AgAxKgCzVkk69cF93p5QumGFQcDI1GY= =St6t -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: subtle issue with systemd, dnf 'greedy' obsoletes behaviour, and multiple repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 08:38 +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > > On 01. 06. 20 23:10, Adam Williamson wrote: > > > It was actually a bit tricky to come up with a solution for this. > > > I > > > hacked up a minimal reproducer with empty packages, and > > > experimented a > > > bit, and the solution I was able to find that works is to have > > > systemd- > > > udev Obsoletes: systemd < 245.6-1. This seems to correctly clue > > > DNF in > > > to the situation and cause it to leave out anything from 245.4- > > > 1.fc32 > > > in the upgrade. > > > > IMO this is the "correct" solution to the problem. Thanks. > > The correct solution is to actually fix DNF. It MUST NOT take > Obsoletes from > outdated versions of packages (i.e., when there is a newer version in > the > repository which removes the Obsoletes) into account. https://github.com/openSUSE/libsolv/issues/146 > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z7FMACgkQEV1auJxc Hh7BvQ//UQxGN/Cvn0yab5qqBCDnKgtOLB55YnSY1tfqY2moUv+TndNSkbIHHnSw JlIPSBgVcuThDG2NYtX9t9hhYwlEve2se4TBTlI8fg4O8sYsfjbdvD2wpwBPf1cP nHn54izfGDerEbnY6Zo8NRg13ABIKbMYzqlA9r9zh9FeiY34EDK3TR1TzRJg8wnP OV+0bWI8xkyfb8MrSRKc9zo7Jq203OiVFb59G60507i3QyV0y8epg8Fq6+yMxwsZ vjUtaUZBNO+wkWqM1qiY8NQh8rbsgptZuc7vbc78LMsoUvFLWLvs+q8JtKYBYw6l iYXb8w1m6uSRvODnz3kzZnTii0uBf2uwGYuS7+ZPEWagE3mGl50gWqLgMZxT0gQL mrguNJa9nHViKVLgC2MAj2/tffaX6T4/JzAsKLfpaP9HJTqERy3h128j9S/Mqw1q e7kKVOZmpBJSCmRYfz1pYHCJJNCzxbIhs1uD4Guh0BFpFDANCCSg3uu/KzuzJQQZ VlvNGPjY1L8oDhdRFG0E0IgfJdCrsEegtopWFnZ/q0Pw65BjM/hZss0SKpUn5PZO bAyvMn8qQUvjHWGnXVAu7Dy2Y5A2eStbhNrKRnP5hUKDC/NU9s3DPcNOecjqvvsw HXPr+A9XJ03ICk6MiewrbwRSlu4PcWMQHSHI6QjUsAIyVt5Elj8= =Dk2S -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
; compiler for Fedora. > The default > is whatever the upstream project supports/recommends. However, there > are > probably many packages with upstreams that are ambivalent about their > compiler > choice. For those packages I would recommend we keep the status quo > at the > current time. For a package with a dead upstream, the Fedora > packager should be > able to select the compiler they want to use for the package. > > == Release Notes == > This change should not have any end user impacts nor does it strictly > require a release note. However, a short release note could be > written if FESCo or the development community thinks it would be > useful. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z78YACgkQEV1auJxc Hh5bAw/+M26mjEsJNxTeHPw/1jyqX7QC5tGYz0+Ourvy5NLsAvrbay9uaxtYT0Vr bB5T0cjPPYX0EXJBT0Xp3G4JPHBWnzwr6OiE3O0kR+kODySY/uVUp/i8K4Xng4wM wtgTDM/5QtvoRSQB625jeTl0W7HEMSH6WRBhpbHvf6hm3WhOso9Sq/R/rzqfYgNb T4eFDYVfHx1/VYtWPWI3sJOL670n4rzcrsg5t78GaAh9MoXWrPL5YX46nwGOW0sd C3tmiI+tM3qQXV1NUq55+agK3fFZpelL+FjSdkOt9xoH7EuAIxbuY/ibehDlFfGo 9IPB5IF12u377WgLtgIk5Tk2jceDhu/DoH/lzAt9YZIIBGLoWWkBNtCMPsdfDx3/ P65gRFcRqWHKfDMMrFDdBAGo8d3PUK5tz9snrVX6dWwqoZ4rjedHs/XulqOZOQFu NCfEHm0BfgILHjIRgJFBXX2tzGCY5J+x0SuAqSbEzhsHTg4kW7PCF0KWMSCeyzm+ ckV9Mp/99gWY8O88npOtrPQiB9V+jgxQwyAMfuypEz7ZvJpn3eFkO4svpC1D017Y VlsR4AoH+BLC05pscL0yIjlM9pYsOV1BH2MnY+aLH5pQ+dsgoJV3CHxwQr+5Km/H Vp+slBZH8oQC7PGTOm83D7zTuUUUBslUlL6vb7nsCzVdEmLemp0= =5Noz -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
out zram being > used). > > Also, you can see the actual compression ratio achieved with the > following command: > zramctl I would appreciate here how to get to the state from swap-on-disk (default workstation) to the new swap-on-zram (new default workstation). So that people can see better how they would be affected by this change. > > Test Day > > [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to > discover edge cases, and tweak the default configuration if necessary > to establish a good one-size-fits all approach. > > > == User Experience == > > The user won't notice anything displeasing. If their usual workload > causes them to dread swap thrashing, they'll be surprised that > thrashing doesn't happen. The user might get curious if they don't > find a swap entry in /etc/fstab. Or if they 'swapon' and see swap > pointing to /dev/zram0 instead of a > drive partition or LV. > > > == Dependencies == > > N/A > > > == Contingency Plan == > > * Contingency mechanism: Don't ship the generator = big hammer, but > easy. Preferable to ship the generator, but only selectively ship > configuration files = scalpel, pretty easy. > * Contingency deadline: Beta freeze > * Blocks release? No. > * Blocks product? No. > > > == Documentation == > > Consider adding a hint in an /etc/fstab comment? There is no man page > for this, and the documentation is also minimal, besides what's in > this feature proposal. It's an open question how the user should get > more information on how to configure and tweak it. But then, they > don't have that for swap today either. There's just institutional > knowledge. > > Hence, a strong test day, with a lot of people and press coverage of > the feature, might help spread the word for institutional knowledge > changes coming. > > Ideas welcome. > > > == Release Notes == > Pending feedback and test day. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z86UACgkQEV1auJxc Hh6FVw//ZPNbzWgiCAUalQk4Ih5Zn7Z8HrpReej00arKuu+DhtsOWaUXr5iEwIIB ZVWgpEPn40DKLn0OiAzDCFM+DRpReGXIlmUnnz3fV+NCE23snQ1gG4ucu/97mExo heFl8ndBpJj3BF9oXrHhSumX3hHhQu3Kq6xWMj3Wr33Ao+v+/+vQpPqPGFGM+XV+ tAN7ljf1MVDSJxbTyXsykzxAwfq66hUFY+8/t7H0/OWzbq6uplsRXgeN5/wvW9NX wjWldQPes3kpuzMAnWwWb5dfVW+zhRoUnc2cyp3ZMrkc25re7Wf7gveZE4t0p3X3 ku5SjHj+MTzeWTvFg8YqygdVUpliprvOeewStAd9fpUZt8BRl4MD1g80NDVpXCO1 mz9v/zUNnTGNmosth/EBOIfm66uzJQuWOru+I4oTezwuP6YZIxIONULj4XPMSjlI CGt9gC+Jpl4/IDSI0Vk+zEFGywpcxnqHidwZOdi8fgjyE4E2GWLwOwRpqL1T1CCe gPyqPGhBlhayvA4yx2ixAtjn6v56bTPNADtyD10hw71XmC19uEW337asPYNrVMyu aRvgLX2n/Lwr/n6URysLbb7APTaFZANhbiVnDJBIzEIU5hI3Vzp7GLGXojr2gRvH bPIxYvsJr2xFMJ1tAIQwreHaxTFlO2wODUgSz0sVZQaQch71KWc= =Hce9 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 09:16 +0200, Frantisek Zatloukal wrote: > On Fri, Jun 5, 2020 at 9:11 AM Igor Raits < > ignatenkobr...@fedoraproject.org> > wrote: > > > Also we probably should mention that -fstack-clash-protection is > > not > > available in clang, so in theory binaries can be less secure due to > > that. > > > > This seems to be worked on as per > https://reviews.llvm.org/D68720?id=224102 (on > x86, I am not sure on what arches GCC supports -fstack-clash- > protection ). Yeah, I think this was mentioned in the https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/89#comment-45723 - From what I see, GCC supports it on x86, x86_64, s390x, riscv64, ppc64le. So this just does not include ARM / AArch64 from Fedora architectures. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z9LUACgkQEV1auJxc Hh7Erg/+ISu0CkAn1Qy7ZhrxeqCa3orhXRCZga08dPrqHabZTtxnAaB9xog3ETu0 1RgmpOYzCEzZAlJfBull4V81r8n1JB/e+Edg9/a+fGL1UQafJoStbiEw24kQVZyH bCP9OVfPplrrIYQebb51CKm3sQ29wUyBilS1kBwG3cawLjFgzmT1P4B2KLoqwwOo 3TYgPq7tK12V3n8UlyRsmaszxydP5tmB8WWTv6o6DOUkXYAZmNTktVmRwUleklYy TX/Ifcdxr47XhrcsuQc3g0x4jtzGfvRbzZ6o45HFVic2EVN0sQdweiXd5F4ywyBF 1w7CsV+sJu1lQT7fVpkL1n2eyuS/gOF1c1n15WaD89FFMZvXjBAfvPN71lsgqBNi SVNJXsdgAajdgWRbeln4GcVgkXyN45nwwgux/AD4E5AjPW/FA7xpocA7S9J1Ys/X VR7Zcb45WjFZKas3vBMbK+Yc45xPQOR/SLQ6T24yRgNvLn2L7+BNMQ+ZXJ6YOAkI rJTovrQUN6TvU9YWp39GWwdBru+6Xo3LWa0JrAafgKCbNw/pyGMaokpESqHQhOFu CTAVE1VLBFaEWciwCFkwhIt+Wt5Cn9NkHAfPnm4eJbp7/E3Y7TtDvPzmUKPWTFvy TPEE2M9WsRfbpYNkWYMBGBynVfPyyEGZgAh1JRjIKNneVsu7STc= =kJ/i -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > Ben Cotton wrote: > > Swap is useful, except when it's slow. zram is a RAM drive that > > uses > > compression. Create a swap-on-zram during start-up. And no longer > > use > > swap partitions by default. > > > > == Owner == > > * Name: [[User:chrismurphy| Chris Murphy]] > > * Email: chrismur...@fedoraproject.org > > I do not think it is safe to assume that zram is sufficient to > completely > replace disk swap. We do not know how much RAM is actually available > on all > users' machines, and the compressibility of RAM contents depends on > the > individual user's workloads. The change says it will use 50% of user’s RAM size, but not more than 4G. I did not have chance to test how compression ratio depends on workloads, but I believew that it will be far more better than 1:1. Probably there should be some presets in Anaconda with "profiles" that may default to different swap / zram configurations. But I think as long as typical use-cases of users are covered (that's how I understand these settings were chosen), it seems to be better than status quo. > So, I am opposed to this change as is. > > > # Install systemd rust-zram-generator† package. This does not > > enable > > swap-on-zram, it only makes the generator available. > > Also -1 to adding something to the core system that is written in a > language > for which we do not even have dynamic linking support. Or even real > static > linking support, as opposed to packaging libraries as source code. This is not fair. It is a programming language that is safer than C and is already used by some projects that we ship. rpm-ostree, firefox, librsvg2 and others. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z+wkACgkQEV1auJxc Hh6TxRAAscjHaFs/BWxFAy2bwBeSjO+zJ8s2ZxjULiA8iyUmHooDX9JeRaL6i3/u hNEavH6+6uvl9NsOw/YkCoCCbZ8SlgU9rbXi9kbaVf15MdS4ROVJbTTuNzbSY6gB kzZEtjQRNmG3PKR8khxRbM2LJX4GzMUV5ZuWQfLnv0BsIouHo4wArZPLo6IrSVXv RIwkGmblRq+q9qHjxAeohvosiL3UbSKq0Rch1L+t6jf6Fn92dAtKdRgm+sYr4Dfq d5FvI/tCCc4qbOLCa6pNGGZ/KOzl/qExRbXieVgOU1ZdxZZlLctIV3NwNUPLSQX2 Zq1DVHeajCdA69KNwO7F6uJhX/LYOg6/Ovng8em1yC30U4HzF0Sxj+cIpm4wMOVR eAVF90yKK/1F2UQ0FhN0q6SDHNRztG0xPNKHnp+nuelQzpv0zN6pfNX4pvh0dOdD R+39XHx1/93hJfg+4uNNBX+pJeaZCFtWjr62BNTcmFBliyAVGuAB0pu4a8EhQdGz G9bE3UbmNRfPl5yxNpqM5gXaDlDhKoY/JRwDh6iXGu4PC9OKeWFZxm7+kh4pX+/J +1KeIER8soWem/uOL5BzXydjckbSF67zIOlmRN1EyZmF9/+latvTo6tp+PJ3bzt5 ORDwcLsY4a9P6nNYUkm5rgAT0atN1k5ev4McOIqduhNesER7ck4= =Dg2z -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 09:52 +0200, Kevin Kofler wrote: > Ben Cotton wrote: > > == Summary == > > Fedora has historically forced packages to build with GCC unless > > the > > upstream project for the package only supported Clang/LLVM. This > > change proposal replaces that policy with one where compiler > > selection > > for Fedora follows the package's upstream preferences. > > > > == Owner == > > * Name: Jeff Law > > * Email: l...@redhat.com > > I am opposed to this change. Chromium and Firefox build fine with > GCC. I > think that a distribution should be built with a consistent toolchain > wherever possible. > > Last I checked, there were several reasons why GCC is preferred over > Clang/LLVM in Fedora. And if that should ever change (or have changed > already), then switching the systemwide default (reversing the rules, > i.e., > using GCC only for those packages that do not build with Clang) > should be > envisioned. But as far as I know, that is not the case at this time, > considering runtime performance, security features, etc. Since I was not sure if clang is supported by Red Hat Toolchain team in the same way as GCC, I've asked this in my reply. If they are supported in the same manner (maintainers are as well developers in upstream and work full-time on this, development versions are being tested in rawhide early, etc…) I do not see a reason to disallow that. - From the security features, do you have some specifics in mind? I saw only from our CFLAGS/LDFLAGS, only the -fstack-clash-protection is not yet supported, but it is being worked on (already in trunk, though only for x86). > I do not see why we should allow yet another special case for > Firefox, nor > why we should let random packages make their own choice of compiler > and risk > running into hidden binary incompatibilities. We have a system > compiler for > a reason. Well, if they are supported in the same way as GCC (in the sense as it is not just being packaged in Fedora, but developed and properly tested in Fedora), why not to declare that we have 2 system compilers? Regarding hidden binary incompatibilities, those are the bugs that needs to be fixed so I assume if maintainers of clang make commitment, they will have to fix it because Clang will be 2nd system compiler. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z/oQACgkQEV1auJxc Hh6eZg//QsO9aE7sAXDqJwRee/QkG2uJ9kbxFVd96hugDh/HMXqxEoEdQuhxxVA3 jUWlcd94zxqrY9B7oAp2eJIiaCbo3sXv9iHaJUNdPvueNASoLSLJZ2juwAb7tDzp dy2joMNieLbr5z4v73Ri7KOhLQ+LSJv228OAuYzcw7rxMYV0QpKcG9Qc8rSIhXyi VA131keQ+B3Kfphqek0EvPGWNxyWmAFI+fyOmpTKVQHgixmbrKYsApRUzz0tYZtz VYQZS1XPnxEjk09dwgguXWwarnNMiZ1J5irwjR0OmqIVQAnGGhrBPYg9j6rCBc1n rwRhyBEo+jFFqrZ+ue/OKDYxlBd8aTlXndzShhqeHEeE0ihZrP1z4TNkjSb2hIpL lxPVAH7v3bfcY45SMvgZpxHcQTs9wZ6ggPaAEgi873oOTHgEA8Dd93lbdCSzE4uP yQWF9UxU0mVAojyp1PtSU3atECUAYJPWnfeUKme+2UP67P05spUNs6oU1MRB/JwB nEsPA+fVjrNGupTKijN2bkI4qXcSdX82lEgYLKL5jTtXbgCF+wewgpobOsnHWNqf zMCcODDzfgDMiaZQntfZxUXzVrW4zv6WezsE5fAbLAtpZXKGyg6kDj8IrfdyJJ9L TVrwRYMpPdUGEJUkrB+te3CZY1VRPO/aqA0vvQlEyv5/0bQVEX4= =LA6Q -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 02:03 -0600, Chris Murphy wrote: > On Fri, Jun 5, 2020 at 1:33 AM Igor Raits > wrote: > > > > > == Upgrade/compatibility impact == > > > > > > Add Supplements:fedora-release-common to zram-generator to pull > > > it in > > > on upgrades. > > > > I would do it other way around just to keep logic sane. > > Hmmm. The fedora-release package is a "dummy" one, so there is no reason to "Supplement" it because it is meaningless, but having it other way around should be better. > > > > > > Existing systems without swap will have swap-on-zram enabled. > > > > > > Existing systems with swap-on-drive, will also have swap-on-zram > > > enabled (two swap devices), with higher priority for the zram > > > device. > > > Existing swap-on-drive will not be removed. > > > > It would be nice to see this in action, what kind of issues this > > might > > bring. > > A future feature might be zswap for this case. I've done a lot of > testing with that too but I think it needs some synthetic or > contrived > cases to expose the hypothetically better LRU basis efficiency for > what to evict from the cache to the swap-on-disk device. But making > it > easier for people to do these experiments with real workloads is a > big > part of the feature, while keeping the defaults conservative for > starters. > > > > I would appreciate here how to get to the state from swap-on-disk > > (default workstation) to the new swap-on-zram (new default > > workstation). So that people can see better how they would be > > affected > > by this change. > > Good point. The feature for priority is not yet in zram-generator. A > work around is to swapoff /dev/zram0 and then swapon -p 3000 > /dev/zram0. Now it has higher priority than swap-on-disk. I mean to convert existing installation to the new way that would be installed from scratch, so have only zram and not have physical swap. I understand that we do not want to automagically remove physical swap on upgrade, but it would be nice to have howto that describes how to enable zram together with removal of physical swap. > > > > -- > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z/5gACgkQEV1auJxc Hh4wuxAAqGsG3tdWdSEQl3VxEzL474KvKZMWjJ4JMRt4LPjvvr6U5zexeL+V8iPj vKRPfV6DGZy/cKmn4LlKK/t+C4ITYyTCK2x96CsL0qtNKC1xp5UoxBvgr/dKj4ao bBHjzQqubjW21FedOHfblECx8uGL+1taKENb2oNr+s0AOVAxXW9U88/GSf/bwJbC 8QDqeEuW4Ea3Lmr/3z19QchCH7EzQJqgpOrkPw5Q1b/aLcTdcqeO9jKOzBMUxyJe czuOGkFELcKRECJwvPTF7nkXBG48kIVGe/JJ57l66+RzF6djd4//IW58Qtj9aI8q HjN/LwdsgxcknSeF/tCXDkTk/STYLJ7C6WqdHJGEf+nHId54GrkYyXjRgIXFuy+P gM3TPtX8RJ5dFBpmOubGgMeQBos6doFWxKGCnER7s2qDBUOwv+EZUSx6IP7PdYA/ C9NF4vBb/qhhbR3zfBcdPYfbEmA+CUxabop81mmOIv1Q/xs0xsIkbMqg/nO0ya4q K2VmFmR3SMBVcXGWiY7G6MHk1rGIn1TWOtAlVYPgUoFS55e/ES5LG8SvCw2Vf7jP IBBEqoiphchhCUR7h/V0k4nT5TLXsdIkZHxKZVccHqGdUY7sPea09eX2Pv+jtKv4 OqqDEKD+XO+cXh5CHRZeLnJrKJfNkdRJ9Ur5pBq+/b4ZG5tjjH4= =ocnt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 10:17 +0200, Igor Raits wrote: > On Fri, 2020-06-05 at 02:03 -0600, Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:33 AM Igor Raits > > wrote: > > > > > > > == Upgrade/compatibility impact == > > > > > > > > Add Supplements:fedora-release-common to zram-generator to pull > > > > it in > > > > on upgrades. > > > > > > I would do it other way around just to keep logic sane. > > > > Hmmm. > > The fedora-release package is a "dummy" one, so there is no reason to > "Supplement" it because it is meaningless, but having it other way > around should be better. > > > > > > > > > > Existing systems without swap will have swap-on-zram enabled. > > > > > > > > Existing systems with swap-on-drive, will also have swap-on- > > > > zram > > > > enabled (two swap devices), with higher priority for the zram > > > > device. > > > > Existing swap-on-drive will not be removed. > > > > > > It would be nice to see this in action, what kind of issues this > > > might > > > bring. > > > > A future feature might be zswap for this case. I've done a lot of > > testing with that too but I think it needs some synthetic or > > contrived > > cases to expose the hypothetically better LRU basis efficiency for > > what to evict from the cache to the swap-on-disk device. But making > > it > > easier for people to do these experiments with real workloads is a > > big > > part of the feature, while keeping the defaults conservative for > > starters. > > > > > > > I would appreciate here how to get to the state from swap-on-disk > > > (default workstation) to the new swap-on-zram (new default > > > workstation). So that people can see better how they would be > > > affected > > > by this change. > > > > Good point. The feature for priority is not yet in zram-generator. > > A > > work around is to swapoff /dev/zram0 and then swapon -p 3000 > > /dev/zram0. Now it has higher priority than swap-on-disk. > > I mean to convert existing installation to the new way that would be > installed from scratch, so have only zram and not have physical swap. > I > understand that we do not want to automagically remove physical swap > on > upgrade, but it would be nice to have howto that describes how to > enable zram together with removal of physical swap. That should also include how to modify resume= parameter and regenerate BLS / grub configuration. > > > > > > > > -- > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aAKsACgkQEV1auJxc Hh73qA//eWFYtpO8V8Ro3TuJemzRRYs8LHMFUfzSM/adiEWhaAJdd02i1Dy0tqmm xJXgV8GazWPuOpiOoixhhNd4ekk/85JB+Eo6AQGtXDcTKkVl3SP9QSt2JnzL+6wR i3lCYDsgTHSmZdPFJVhHtbad6eTgZYRGQz92PacpTin6Z5N6laZEv/TykgVLLb97 Z8pfqw3rdiW5IFwoCqkPUrTvdioyKaqchc6N67T3nMo68cwocA9Yre1iFOKcCJlG 4+cGjSS0oCqWcHOdkM06pJS8Uwv4Kq5luG/XofD0L0TNkvxbAkP/VXtV6an2CBTy EAtv3CffvkmUjW1G5i04Z1BZ+dGDeQ7NPTFrRhhnTU8H4VGEr0WGIGhlWEM+HF1r 29c+ymZlHiGEwi0eEHRhNwqHbH6qS3bNuEl8P74e79uoB6gTivuQ3Vk724r/NmZI WoUb3QdZPyT32r9bzcDKqv90nLQLOWxpF89YWGlTPoKNpccQl+8sHu88zbKADFQC oz0vNSODM403f5giiaxSRLVlV2q6szR7hXljrZ933ySRtxGkAlhEIPTZDdwPe9Wy zVfN8Ky4F+VVAwT2EErdpBRA9LifHVRxHklzwTgXx8AUxN0WbbhBAzGbXtJqM5tL 3KCTK+lRzztudtB3Xzj9uGATeuBPEaX+pIIqk7cNQ3G9K91seGc= =05Jh -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 10:15 +0200, Frantisek Zatloukal wrote: > On Fri, Jun 5, 2020 at 9:57 AM Kevin Kofler > wrote: > > > Ben Cotton wrote: > > > == Summary == > > > Fedora has historically forced packages to build with GCC unless > > > the > > > upstream project for the package only supported Clang/LLVM. This > > > change proposal replaces that policy with one where compiler > > > selection > > > for Fedora follows the package's upstream preferences. > > > > > > == Owner == > > > * Name: Jeff Law > > > * Email: l...@redhat.com > > > > I am opposed to this change. Chromium and Firefox build fine with > > GCC. I > > think that a distribution should be built with a consistent > > toolchain > > wherever possible. > > > > Last I checked, there were several reasons why GCC is preferred > > over > > Clang/LLVM in Fedora. And if that should ever change (or have > > changed > > already), then switching the systemwide default (reversing the > > rules, > > i.e., > > using GCC only for those packages that do not build with Clang) > > should be > > envisioned. But as far as I know, that is not the case at this > > time, > > considering runtime performance, security features, etc. > > > > I do not see why we should allow yet another special case for > > Firefox, nor > > why we should let random packages make their own choice of compiler > > and > > risk > > running into hidden binary incompatibilities. We have a system > > compiler > > for > > a reason. > > > > I don't think we should force Fedora Contributors (Packagers) to > change/fix > their packages to compile with GCC if upstream decides, supports and > tests > GCC. There are tons of gcc specific patches in chromium [0], there > were > some issues in Firefox [1]. Apart from browsers, LibreOffice is going > to > use LLVM/Clang from Release 7.0 too, so that would potentially be > another > added work to LibreOffice packagers in the future. > > I believe we should make packaging as easy as possible and allowing > packagers to work with compilers that have upstream support is a > great way > to make their lives easier. I would emphasize here that we should do that as long as performance does not degrade. Even though it is not really easy to measure it, many upstreams have some benchmarks so we possibly run those somewhere in Fedora to see performance changes over time. But I would not block the change on this. > > I don't know how much of an issue is currently > missing -fstack-clash-protection support LLVM, but if Mozilla > distributes > official Firefox binaries without that flag, Google distributes > Chrome > without it, I feel it's not a big deal. Well, upstreams are not necessarily enabling many security features or optimizations. So you are effectively saying "upstream knows better" where I would have to disagree with you. > [0] > https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_205 > # To line 250 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1601707 > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aAbMACgkQEV1auJxc Hh4+1Q//elj3a2geCtuEdJa4/vTl5/zV53JhlESibS98tEC6W+RzuUhkvkKCgX8e tSMSQk6VS0B8ZBxquwPdWVpncT5vJquTi9yi8ChnnwcY87knNoF3p7qraJIc5E+x mWkVWY0a/AUie9J9JXxzSKENhBmRZ/rB2WQ7E8BKmyZ379pEBgUirgHjpPYYdyqV aNB8zZKkmQuaDTzyYsMdMl0E3WMY2t73ZoM2EJhKfb/wgWhibma72riUQHKQiNDw U7sggoJZoVUwwOJRpSC/VXxTnjYiS/9PY6MhCw1Q2YRgsHLd3ra6DKjRzbg7ZSgw FrcWjIEB0qXxd9/HflZi3ITz4H/NlV2TfdupGvcWlJPurK2LkNv2rTQS4Ua3Y2wm wayTZAanj+669Tz88OkK4BdXmcWkMU9VA7xA9GMpPO73W3ycQDacTW/tVKtb2jm4 gOtiwe4cnl1v+ML3QfHbll466/F5QXBgFbWJAUd6CAR5ftYDdavpntcjP6h2Q639 tuhSE+KtKm1lzDxTeivSuRR40SMKxf2sFlUTCdqvCTfOk82yFa6n7JcC5Yimy3qe kj5DAUKPvNtdDCPIbF1o9abBBfi2LUYFw71grdsmMNTPmby+PO4BL3xaEXq+LrYC UgMsHi2b/ge/tSDuXdTsYjpotwYKF26OYu8egSuVBpqojFJYFu4= =ud8C -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:34 +0200, Vitaly Zaitsev via devel wrote: > On 04.06.2020 22:30, Ben Cotton wrote: > > Swap is useful, except when it's slow. zram is a RAM drive that > > uses > > compression. Create a swap-on-zram during start-up. And no longer > > use > > swap partitions by default. > > I'm strongly against this, because zram will replace disk swap and > disable hibernation, which is very useful on laptops. It does not work in some cases even today anyway. For those who still want to use hibernation, whether it is some checkbox in anaconda or magic that guesses if that actually works on your machine (whether it is laptop and Secure Boot is disabled). > I suggest zswap instead (with zswap-cli[1] implementation). > > [1]: https://github.com/xvitaly/zswap-cli > > -- > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aI2kACgkQEV1auJxc Hh7qdhAAmnCP6a7ZPtTi/P+KFvmn8CeqtjAJFDapRe5M5cGLbam4gDaQD7ZnkeiD p2Fo5C3W/QkhCv+4X7caXEtLJjWlFQWEUPlnZraI7lOLXGIfbsGJHzIKkycSWjZb sJb/ql7te3n+H7KecYC9elZFJhh5Fz5Xlbgv7Pig1n3d+jqa6aHW22+8wzmX0eTI HaBeXuvu4a0ICL49+QZooWJIdb4hVdqyJOoNX93QtkgP4DdMJrmKPQaXuzawn8VA vy5yL5IvCTj4DcDaFIZ3Dc0nidu+fTzq6GCKQg55zelqXqsXax0+S1fIABbacXlv Q2ljmHaaz/ZEohsNwfXZ0mAWVMmyldeMiJrLiFd3wVRLL3XIxSUff7+bGEVZByhw QQLZ1nmcGEG3X0e4Vdz3xwuhulADMDqeKQ50ANdJt+a8XzaslR2IXdx9wJtx5dK9 SM3MF6lil7fQAyEF0zumAvUAdf/EztXaype9WsjUOi5It1wuhgKSsaV8F/u7+xFU b0Kzlo/AD9AS/tqg0sOfQ4kfHgEZg7X6xgwELzYav/fdBq/4cQLQzkHziIPGsUu+ wMQM9fvKUsvN7LVWCUMizifoDtqxtpnOkGmvDaISMPkdLGNI25KDvcAzNZKxVICg 0ULVTE439MRVEeB3cVLWRLEsPIRUN9o0HgxsZ5ZgJdGPZTXGkDY= =+rta -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
oblems that upstream don't > care about" is a good reason to use Clang. > > "I've heard the cool kids use Clang, so I changed my package to use > it, but I don't know what these compiler errors mean" is not a good > reason to switch if it just makes work for other people. > > When there is a real advantage to using a particular compiler, I do > think it's good that packagers should be able to make an informed > choice. Fully agree here, we should be still preferring GCC and not allow changing compilers just because it seems cool. > Ideally we'd have CI building (nearly) everything with *both* GCC and > Clang, and finding and fixing problems in packages and in both > compilers. But that's probably not realistic (yet?). Well, building itself is not that interesting but running some benchmarks periodically with clang / gcc compiled binaries would be interesting. Though this definitely is huge amount of work and we should not block this change on this. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aNw8ACgkQEV1auJxc Hh5q1xAAs2zy7F/XnKRoAU6461WLo//0MF1sbzwsTesn6+ZHDgG/S12QHQw6U2du qvdKjBc3MKLTSnOZk1okhVrP2jQUJTSvxjBMnWBc/nsvmZCCrE5juZaMtPAJgxXx JZPVywdtccMv9PcHtmaG6fCoCSi+HiEOlLRfbwobZPpmG+9WiIDvOV+sErLFRYbW 7CJeRqOu9c1Nf8TuZgiRemw1xAK1FcKWM+PCvxZi/ZjL1lmuasY0dJL89YOeaWfL NIFo8zOFigCiQatjMIS0yFwcFJGRNIml3/u+/WuNJE8y8FCMohsmUHVcoHVe1PZv 1JHJS34xWOhLoi/PhDfzlFD+awWQiap+Sy35uwsVFBydGLVArYD7BFSz6X5mrbNq dP2RW1xF5LjPNA42rcddF199SxfEZCkK+ADlCG9/fjxbBk15T11h+q/F+9itWuIU 1T/PGl4h/wOQdgr/eU/SlmvBf++lMRQV2el0l92tbsJ5SogyXZEC/x5S6qAyqrkv Y6wFW84V0qK1wBvFlG9xkRHhWil31CPaOe08pUUzkxp5RYFDah+gxE9p4DcbY6jE zkETeJw23nHEJeR+9GIVsy7OxZHRNFNMW6bZgenDCKdYhHSr9ZjKrwgKjZvsmW+A VE9jh5oMMISgBBOJj0OxpMikZK+TXRabifr2KqSXlAC7kQ59hT0= =SpbG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 07:42 -0500, Michael Catanzaro wrote: > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > wrote: > > That is the plan, otherwise the swap-on-zram device probably never > > gets used. And then its overhead, which is small but not zero, is > > just > > a waste. > > I thought the plan was to get rid of the disk-based swap partition, > since it has an unacceptable impact on system responsiveness? If I understand correctly, this is only for upgradepath. The clean install should have only zram, but I might be wrong. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aRK8ACgkQEV1auJxc Hh7pFA//XJ1FjBF8d3GrEBFIZ+ML1tR3Nr5hbo2cFD6p0dokYocrH8Xz2V9GvDla MAuKSNBXa4AohzaQ1w6JHSNJVlQya9FlqWk61+I8uWA+y9/vJGc7mV7AaJKzbEsa 4DvGEFFgpwnWcWl0K0W4Y6JZrw0o5mpZZrXumF0I86tOb/w72Bg5DZBvUjGRk1i9 uZvupNNiFdMaBOwz/26v8r/0qzZG1xmEv+YXw+wDnXXX1hAENl0/ZxlEc23IVWt4 8fvpiwOTrex9CKvFVIDFsAW3k9Cjn+gYUZF3K23toZPN4dPlUle9UpVezX0YrtdD pBeX4zzt68N8ofoz/uQzHKAuxvQ/EtO1lKP1M7SXylev5ZPTWZfbCWfjQc6/cBmd 2wNsKastLVnLGEPipFu4phYLIs0eqRGqzK3wuia7IRd0abLV0TPq98F2iGbME1OC hixrJtgP8zZoE7d0SPgdzy+7ne0k8AXsrwemOnloIcWMfwl8yezWutQzrHJ0A+Va wFFRyASld7KZ8BY8lbWmCxG4pWoUeMX0FRg0bW/p14Xa8Vcom/THJw+Q/D7F4su0 7nRihJpcx597xhfwaz88RAG4KF1IveIK659p9jKuEc6SAtJOAnLH63gUFObvGaOt wp5RBHGBMnbAqV7cR0LYrEzktQf8hVOF35kNtc8ozLt5ib0Em/E= =58Nc -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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-packaging] Let's standardize the way to disable tests during RPM build?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 16:10 +0200, Tomas Orsava wrote: > Hi, > I think it would be useful to have a standard way of disabling the > running of tests during RPM build (in the %check section of a spec > file). > > I see a lot of packages already having %bcond's or other macro > definitions to archieve this, but each package has their own way, > there's no real standard. Thus you have to first look into the spec, > locate the appropriate %bcond or macro name and only then you can > disable the tests. > > I would like to propose two approaches: > > (a) Add a *SHOULD* rule to the guidelines that specifies what is the > preferred way to conditionalize the tests. > > (b) Or, if that's too strong, mention in the guidelines the common > methods that are being used (e.g. %bcond tests and %bcond check) so > that > new packagers have something to use. > > What do you think? I'd like to have this finally be implemented in https://github.com/rpm-software-management/rpm/issues/316. That way it would be simply rpmbuild --nocheck or define %_without_check 1 which would skip %check section entirely. For now, all Rust crates just have `%bcond_without check` so using `-- without check` works just fine there. Since this would be more generic thing to the RPM ecosystem, adding rpm-ecosystem@ to the copy. > Tomas > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-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/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aWQwACgkQEV1auJxc Hh6dyBAAmbJSCU0wtuET7vuXVVIeg7BeosaQF25/VoMwTSYGH3h36S9Gci9BRBgs yuque1uGnBaUQ74fsxBIMgGzapd73TvEY1M8PNnzHF3Miz0i0FgVhwnw3S9jvrTT aGqln2rE3L5jH0alII6pNOIqA67yPlYfb5+JtRazeO0KTarZuGOdemJsp6ONEKQS 5doQid6yrQvaUj90Xl2VpRY6goXx5FOQLDPb9DlaWlQDvBcVBJz5oaJ/VyxqCnC2 ObyLjMB9AXq+pBiot/50QDLTUCxKOkro1siBPxfswNCjpwRy6vDp6dyczHyQkhJ8 zFAHJQPWAr870WU3FMO/FirTv9yAqY6Je8jB+3EdxjzNuyBMTOT6Iq6r8Su/yxeq FcvDvUhlJ0OtWM8PfiIkaKpiSB9rzpuuM5hagPYqznLbqu5AeuTqAKojSyLbkK7Z 7fS+qABernfYqAVOlq7DkTaETh/0sAuIxhtwWXbbhz7vFPpbnsPdnyfUUGzFoIdT LBFnMOBQF0q4woTAhQRHez+VEH4ndiqZQGdYL8AJ9FtKeMZwwWmvl/r3ki/Hr5Yf bqETizKe4XBu5DxPRNN3+0RSi+TIXX11VeHtxIWeuGGErgdqq4EZkBfnmZlTb3/N gA8/3DUl9B4XRzGjnzq0AahOfIW1wNObh4pzlmoGN2jrG5odKPM= =JCw+ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 08:07 -0700, Tom Stellard wrote: > On 06/05/2020 03:42 AM, Vitaly Zaitsev via devel wrote: > > On 04.06.2020 22:30, Ben Cotton wrote: > > > Fedora has historically forced packages to build with GCC unless > > > the > > > upstream project for the package only supported Clang/LLVM. This > > > change proposal replaces that policy with one where compiler > > > selection > > > for Fedora follows the package's upstream preferences. > > > > +1 for this change. > > > > Also RHBZ#1559007 need to be fixed as well. I'm very tired of > > patching > > Fedora build flags in order to remove unsupported by Clang options. > > > > redhat-rpm-config-160-1.fc33 has a %toolchain_clang macro that you > can put > in your spec file that will only add clang supported CC flags. It is slightly different, you need to use `%global toolchain clang`, but otherwise yes. > -Tom > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aZacACgkQEV1auJxc Hh5vmg/9Frgul4qmIBy9kbYd57y76gZT+KLYyDAv9ozyd7KIzt7n1KO15ME+2kd5 10+66uO7zBiPDPp6qOdSUdJNvTNgNZFr7HBVYVpWmxBVbgKQhEgLpfverWo7BTx7 vAQnvPj3tB6WStNT3bzb0Z4cqogyF3+J61xY93PxJED5hwVfKjDdRyMI8EmyygxF 6U8EmXB2Sjiis7RJtTx6EzSIDfWlErnIeK0BRJNlaGJwrYKnl09XyWGCN9FAuedL rloUG1ofHZ4Dx1bF3CXbJd/J1DiSfamratuLYV5b1ahLfBCFGnSL67gT4/pFs8Dp hDOUmyRf7sUEkHEUPSDmVWDnDGN05u8WDcDy/47RlWh4d7SVD7p2vV9KqZvoNGbv CZ0P5s8fnhEo5or1nZYpAhou4TBoWg1B3e62SbWWvaFxL/XZhRLqihj+5IdG1V7J WMJUZxxVum9TjLUdMEsV/f526D5+RY8Fr6KV7jiA1j9SDyO7Q7yoDRkQZxp8B/Lz ryrlhjeEPUfz5FpHhGkOiI5Y6+QoVXAkEkPtDsG2KsUImmL9aA+zAUn7TRDeYtcW Qxr/jWN6mTpB4nsmTwP3/c98q3lIu3zQapcAZX/kkfZVyF3LHHB7zjgr7ECd6uOj 2VCdjGpMj9rkdhmP4HKnfqgRxxoiBKIwziTgZXJyppmkss+/3kc= =NfxN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 15:11 +0100, Richard W.M. Jones wrote: > On Fri, Jun 05, 2020 at 01:50:29AM -0600, Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 12:33 AM Milan Crha > > wrote: > > > > > > On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote: > > > > ... The memory used is not preallocated. It's > > > > dynamically allocated and deallocated, on demand. ... > > > > > > > > The system will use RAM normally up until it's full, and then > > > > start > > > > paging out to swap-on-zram, same as a conventional swap-on- > > > > drive > > > > > > Hi, > > > I confess I've absolutely no idea about this, I mean how that > > > works in > > > practice, but when you tell me "we do not allocate on start, we > > > allocate on demand, when the memory is full", then, I hope a > > > logic > > > question is, where do you allocate, when the memory is already > > > full? If > > > there's some threshold, then it's quite the same as preallocate > > > the > > > memory. > > > > Yes, it's an oversimplification. There isn't a case when the memory > > is > > truly completely full. The kernel starts to swap before that, and > > it > > can move things around from buffers, cached, and even do reclaim, > > in > > order to start allocating memory to the zram device. And at that > > point > > the compression permits a greater rate of freed memory due to > > eviction, than loss due to the allocation to the zram device. > > > > This is taken just now from a laptop with 2+ days uptime > > > > ]$ free -m > > totalusedfree shared buff/cache > > available > > Mem: 78453292 699 5323852 > > 3714 > > Swap: 3921 1923729 > > $ swapon > > NAME TYPE SIZE USED PRIO > > /dev/zram0 partition 3.8G 193M -2 > > $ zramctl > > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > > /dev/zram0 lzo-rle 3.9G 187.3M 50M 52.7M 4 [SWAP] > > $ > > > > This is a small amount of swap in use right now. In this case, > > ~190M > > has been paged out to swap, and the zram device has compressed that > > to > > ~50M. That's pretty good, so it suggests highly compressible data. > > The > > savings is ~140M. That 140M can be used to avoid reclaim of file > > pages > > (programs can stay in RAM instead of being pushed out and read back > > in > > later) or for more active user data, etc. Anything really. > > I'm unclear: that ~50M is still in RAM? Or it's compressed on a disk > somewhere? IIUC, it takes some part of the RAM and just compresses it on the fly. For example, I have 32G memory on my laptop and when I enable zram device, I basically have 23G listed in free as memory and 11G as the swap. And that 11G is supposed to be compressed memory (in avg cases with 2:1 ration). Of course, as part of this change, it will be made that it can't take more than 4G no matter what by default. > Also does the swap partition on disk contain compressed pages, or > uncompressed pages, or a mix of both? With zram there is no partition on disk, or was this question about something else? > Also what is the compression algorithm? zlib or zstd or something > else? zramctl shows ALGORITHM NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 11.7G 4K 74B 12K 8 [SWAP] So it is lzo-rle by default, but it should be possible to override this algorithm. There is an RFE for this already at zram-generator github. > The description (I think copied from the kernel documentation) was > really unclear about how this works. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: > http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/l
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 11:15 -0500, Steven Munroe wrote: > I would also add that Clang/LLVM is missing some of the newer C > language revisions at least for the pppc64le target. > > Both IEEE/ISO _Float128 and _Decimalxx support is missing. Ie the > type is not supported or if supported basic arithmetic and math.h > support is missing. Also finding bugs for in-line assembly and > missing > constraints needed to work around the missing language features. > > Also Clang's poor support for constant folding makes using __int128 > (and vector __int128) harder than it needs to be. > > This is a significant impact for enabling my project (PVECLIB) for > Clang. As-is a number of project features have been disabled for > Clang. But this is not what is being proposed. If your project does not work with clang, everyone is happy to use GCC. If it does, but there is no reason to use clang - we will keep using GCC. Where change comes to play if upstream prefers clang for some really good reason - we will allow it to be built with clang instead of GCC. > I think Clang needs more time to cook. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7acnkACgkQEV1auJxc Hh6TfA//aX7H+M12kJHJlr8T9HC0FEgkVfGYmmcG7xSKxV81drKB242uan9ALIeC YqnYjPS8HubMpMFQQ6b1PhLHURnwsi/xZukPdwlQMHeYPTN/tiJqOKXJ4fLGvFC5 0p9R3PNG4aAYM86ZP2gawDafG9BsktSc1Z7Rwz8OxBPZ11jprUNINlhsxVgdREPD 5JPd0q0LxneMLpB6yjQH846bTme3cKSoRoY+JHiMVFfB9zyNepxBIt+HtNHZYG8t x5UConS0ikwhwt4vYT6Ekz1ZqpVRsTbVwA3Hg7yPueeO3P7hhbCibIfsNgy1iitw nkHY2NsiA4d3C6SG6ik/RFAAopekmvFLjOJzQfYin/ZoZlhBZ0IbthvSbQCcZG49 Nqwe7q9F05t9dfD2MAlqmXWIk4KRYeS3gKDFmpyr/9TL7ks/OZpcgI/2ch0ZvUm3 GRbzadIUDY/CT1VsRIEDBvPwKn1gfnOgx++wReZbf2QsMhGt13wtNuko2BLw5YFK JAr6GoU65gGxtXD2zwF36uxxBJ5DZ/dIrB00BIRjcmEniFw1IK8bjAshsVn2JWgt 1KwhhzSQohrS966boBiZkIbRP7S8makkTaY0WuJN6wDUKXFLvfJ5saNS8PMi8UdN kDUJRwu5WetkSt1UCJCflqiUQIsw9mIF+cIv39dwJvSoYg4GIXI= =EWd6 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:36 -0500, Richard Shaw wrote: > On Fri, Jun 5, 2020 at 10:33 AM Igor Raits < > ignatenkobr...@fedoraproject.org> > wrote: > > > It is slightly different, you need to use `%global toolchain > > clang`, > > but otherwise yes. > > > > Is this documented somewhere? I've been manually sed'ing out the > incompatible flags for PySide2 since it uses some clang only > features. Not yet. Since the change is not approved, it is not something what you should be «officially» using. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ahT8ACgkQEV1auJxc Hh7imw/+PCmGIYID+pCOPqSmmC6tf0i+TWUCwLK19Vo5elh4kEUQZLeYY5/i9kD4 pQtYuppLWO2Qrj4TGrYftvyWM5dJmCXVBnIK4QK3LM/k+cbNtr3yCWvC2ojh+0TA uqgVl7xVnUIwlkH44+PwkthUNNzowF8Nj6PGKLZY1d6u2VSg2Cu5tqw8m4sUST3j +dPtlckHxpA3obNRr6z778PVI2+r9t1T258zoUDoCeulgxBKcU66LLFfZsb0m211 umedfE2Ii60BSLFMB5fMg2diYpkDnjIXLtR/uTXKpOndADfjZb6EPB6WG8MkJqrX XfR0OCGXio3NXOUU8JNAtW3E3LROf72xjjsHDQdSB9TIk9/AAP9wpSPggSGsXE3h rmIdEu+wGHxjxlNhOCK6WPsaHqayYt0uizJWhmiwk0ChPmjZWjAu9W9Ck6chlgv+ flqB578ZNiFtj/9S2w+qbTsYiLlcOSXXwpmd7lK9+/iVeCKstNDMsE7Ya2MXfjGI wZnyhDtGAodMUN5OWqcMWnTIc5SQMS2lvW9mmgsdwBJqnitOJW9e2kf0DjJB78hI IaQaJiyRXz4rM6sjNN/qjL2t5rSwBhGGK9pzHph3yQNySt/puLoI3x62Cri0cTHy R/k2m1h2mxxlmwVSRVjr5u0EUBZFp7zsOzTIfOwCr+qd7IwoM6Y= =3IR+ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 11:08 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel > > wrote: > > > > > > > > > > > On 04.06.2020 22:30, Ben Cotton wrote: > > > > > > > Swap is useful, except when it's slow. zram is a RAM drive that > > > > uses > > > > compression. Create a swap-on-zram during start-up. And no > > > > longer use > > > > swap partitions by default. > > > > > > > > > > > > I'm strongly against this, because zram will replace disk swap > > > and > > > disable hibernation, which is very useful on laptops. > > > > > > Already discussed in the 'support hibernation' thread. > > > > Most laptops today have UEFI Secure Boot enabled by default and > > therefore hibernation isn't possible. And even when the laptop > > doesn't > > have Secure Boot enabled, there's a forest of bugs. It works for > > some > > people and not others. It was working for me on one laptop in > > February, consistently doesn't work now and I haven't gotten a > > reply > > yet from upstream about the problem. > > It may be true that most laptops have "Secure Boot" enabled, but not > those > running Fedora. We don't have numbers to support that claim, and most > devices > require "Secure Boot" to be disabled, or to have the mode changed so > that it > accepts new keys, to install Fedora. They don't require disablement. Fedora shim loader is signed by Microsoft that means it is installed in most (all?) laptops. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ajmAACgkQEV1auJxc Hh7Nzg//UYaFPMpfVM6CwQ9wlfAAUrz444Lbvn6CrutshqIDylXsBigD6uAC0mAP K9Z1U46FPkBjQRBIVuckAS5kK4ZAkg43QeUNAZJwlqDTJigdvwHDGpgGcRTWwA/f cg2bzcTxvZ+bBpHo6R8yZEzjMydavvZYMBFOnXcfkUUhDSsyctou8BDNo43K/wOD iexpV0tYgz8fq14aAvJrI2/0jZbvW3Mi4H1bHrdC0/7Odtghuo3Erp+H5IF7+A+9 QdlbOSJVJUm/8aKwpzeHgkAqY3wSZtg1AXhJp+OEUDkt9MzpvjQw/Zpny8B5+G68 /+chMP/Fq7jIbLoqNKyzNpgVUiYNm+Yl2J3ro0nQbXzG0Bo7VH3+SVso5kE1pMEC do7XGxWziXEGfQcRZVfdoH6GDzE4yO0TiSFmd3i2GrH3BeMrDa6KboBvPBHHSs89 iSeUgce8Can+IHjPkv8Kb4UoMVl9pEwNOQe4WJIHy4TNVQKq1TJm8Z/nU04zehsZ lhVVhIMyP+qUF5/RieYqHxM1OkkDMA2z8dohHFsP7u+YhBiyVu6zcSl4wfD3Y3CX 2tpbTAMO6hGJ3HwqQeVgdJC+Jy3gdrAKmpFtAioKa8cdx87UaszB3Sov+H7tD2JC 6X7s7Q4Cm5ROL2FfdGEzXcPjQ4FGvdiG5WRtKau9yGO8Avf1OTs= =nTKL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 13:25 -0400, Robert Marcano via devel wrote: > On 6/5/20 12:31 PM, Jeff Law wrote: > > On Fri, 2020-06-05 at 16:23 +, > > devel-requ...@lists.fedoraproject.org wrote: > > > Date: Fri, 5 Jun 2020 11:15:39 -0500 > > > From: Steven Munroe > > > Subject: Re: Fedora 33 System-Wide Change proposal: > > > CompilerPolicy > > > Change > > > To: devel@lists.fedoraproject.org > > > Message-ID: > > > < > > > CAPrKuAohVppTu_B4GDoxSMW=kzxtq_m13utpozoccok0xoz...@mail.gmail.com > > > > > > > Content-Type: text/plain; charset="UTF-8" > > > > > > I would also add that Clang/LLVM is missing some of the newer C > > > language revisions at least for the pppc64le target. > > > > > > Both IEEE/ISO _Float128 and _Decimalxx support is missing. Ie > > > the > > > type is not supported or if supported basic arithmetic and math.h > > > support is missing. Also finding bugs for in-line assembly and > > > missing > > > constraints needed to work around the missing language features. > > > > > > Also Clang's poor support for constant folding makes using > > > __int128 > > > (and vector __int128) harder than it needs to be. > > > > > > This is a significant impact for enabling my project (PVECLIB) > > > for > > > Clang. As-is a number of project features have been disabled for > > > Clang. > > Clearly your upstream project is still using GCC then and as such > > the Fedora > > package would continue to use GCC. > > > > We're not changing the default here. We're just removing the anti > > Clang/LLVM > > policy and allowing upstreams to select the compiler that best > > suits their needs. > > Clearly Clang/LLVM is not the right choice for your project. > > This looks fine, but why not add to the policy that for upstream > projects that have no defined preference of compiler, the package > have > to use GCC in order to have at least some standard and not let the > packager bias be the rule, unless some measurable advantage is found > to > use LLVM This has been discussed in this thread, Jeff wants to keep GCC a default choice for packages. Just to have an option to select Clang in some cases. > > > > > > > > > > I think Clang needs more time to cook. > > I'd respectfully disagree. There are certain features that GCC > > supports that > > Clang does not and vice-versa. But broadly they are comparable. > > What this means > > is some projects that are using bleeding edge features may have a > > hard need for > > one toolchain or the other. And the proposal I've made accounts > > for that by > > allowing the upstream project to select the compiler. In your case > > it would be > > GCC. For others it could well be Clang/LLVM. > > > > jeff > > > > > > > > ___ > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ajyoACgkQEV1auJxc Hh6ATg/+ImOPA1iIt0LVohfZA25Ljv7HPkN6I/jOqQiAXsnqJFWSwv/CSKE3kt+r Bbs0CcVvqUOFjOuK/jfHtZJP0RdvCpgnHmyddY896bYZaJvLeVZrhPw5a5IWbSbS Nd4SZaWwzkJVJJM/kXnAJfil2LpINNF2hS9usjFtc8ZgEheXzBLwmLqReS7Ikp7S 1oLLSROqHVMm0WNp1k/1uRRTFi38KkEdDGfZwvp7BHEOv0h99tuNaDqmnUi4wDSQ ke9xWXosSbfjOboJPY3LXZrl3vWam4+WEt7+OEPW8z44ClPAs5+guX059O41OVR9 SwDxYzM3Z8yqWjTVsYs9W5joCCR6CjtyrkR2l4LkEUIxUp6Q5X/YbYBJrhd1UIXi YBQ9iYV1MdZUdU23w0aez44py8xUWSMRVXhtcahd4eM6KToJ8t4AF0hInz7jDrzD NiAACAXr/aiJZ95LvALrSlBXfzXxDz+9Itmv7h43QoSET6NAHcFgJfCe5V1GhgNh ztJy2U2ORBN2bL3qL/lB/vjBFg5s1tpziwIRMlmw9aHlrDVL5vMzpfDFM2JDtLbv lsNwzDaO+RyEkwELi6d1+clO9aoVYLrL8PrYHXBOPw4SXy3gGWoS45Rrk+gChMn1 zls7UgiHBp3FhdA1xRfCKVP2+rhvAMgkiQcfTNmCTG+GzZVUSfc= =tSW7 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro < > > > > mcatanz...@gnome.org> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > That is the plan, otherwise the swap-on-zram device > > > > > > probably never > > > > > > gets used. And then its overhead, which is small but not > > > > > > zero, is > > > > > > just > > > > > > a waste. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap > > > > > partition, > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > swap-on-drive. And the installer will still permit swap-on- > > > > drive being > > > > added in custom partitioning. Both of these paths results in > > > > two swap > > > > devices. > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap- > > > > on-disk, > > > > to remove /etc/systemd/zram-generator.conf. And in that case, > > > > users > > > > will not get swap-on-zram. And we could also forgo the change > > > > being > > > > applied on upgrades. > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram > > > device > > > on upgraded systems. This would lead to less unexpected behavior. > > > I'd > > > support that, for sure :) > > > > > > Contra argument: It also leads to fragmentation of the user base. > > Most > > users use a distribution because they trust the decisions. And > > while > > it is only a preference, not a policy the Workstation Product > > Requirements Document says "Upgrading the system multiple times > > through the upgrade process should give a result that is the same > > as > > an original install of Fedora Workstation." > > > > There is a balancing act here that should be considered because a > > large percent of Fedora users upgrade rather than reprovision. It > > might even be the majority case. > > Well, that's for the GNOME stuff. This is a system-wide change > proposal, is it > not? Additionally, you could still be meeting that requirement here, > as a new > install with the same options selected, that is, to have a swap > partition, > would disable the zram device. That'd be a nice middleground for > users like > myself that don't have enough RAM to waste on a zram device. I'm > writing this > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where > giving half of > my RAM to zram would kill my system's performance, if not quickly > cause OOM. Either you did not read the page or I misunderstand how zram works. It will take 3G of your memory and call it a SWAP. With a compression. So essentially, if the starts will be aligned you will end up with 9G of memory. Of course, if that is not enough, you can add on top of that swap on the disk. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Ra
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > > > > > In discussions with both cloud and server folks, their use > > > > cases often > > > > do not even create disk-based swap at all. A small swap-on-zram > > > > provides all the benefits of inactive anonymous page eviction, > > > > including reducing reclaim of file pages, without the black > > > > hole > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > So yes it's well suited for these cases and the proposal does > > > > include > > > > them. If they wish to be left out, that's up to those working > > > > groups. > > > > It's possible to make sure /etc/systemd/zram-generator is not > > > > present. > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the Server > > > image > > > right now, and go with its automatic partitioning scheme > > > generation, > > > it'll give you a swap partition on LVM. This is correct for most > > > servers, > > > not necessarily the LVM part, but having swap on disk. > > > > > > The proposal recommends changing this. Cloud and Server folks will > > decide what's best for their use cases, not me. > > In that case, would you be open to changing this proposal to only > affect > Workstation? I think it is fine to have the proposal as it is. Those groups will chime in if they do not like this approach. Having things consistent across editions (in this regard) makes more sense to me tbh. > -- > John M. Harris, Jr. > > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7an1kACgkQEV1auJxc Hh5Ezg/+PrFUmkHOc46SKgDIMa5x3w/SCHOF3VKhpvN4bQ6WWY+HpJhmsh92dvle ogYnseXIl2wuOyCr75vIMXpuyvBGoZMBlFJmQZG5+2jABJ1/DZ+MyyYgpBWZtkPs QUoNs03pJ70DHuLjakv4mX9nbXqHPBwOzlQuk07ivdVoj6qTXDhkSpJCBULlBm/N QsHCIPOoP7Hmu5AZuNopjgzvlr9Ezt3ra/SM65hSxJDNl2Pn/Piex4A35i8+WHgs iWCvH04iF/+iLt6V09Rya2d+9xWary05DtZdmIRbsR2IjgoYIWtOwC1rp8DsRcL/ nsRODfQuMbP7HB2IihpWIF4A9PATcVP1r+DE7NtlLdSERqrSbTvKcycbsbGww/7b 9IZhhNSRJ0CH4xyRW7R9E6mRHR8K9uYykD8t0eWS7dIlw7mIbDZnwjHYRu1qlQzK OdgPZkpY9aZkAWWA5iFE3pWIYYmCkRwPPytxFVH4adEqSo0i5xJs0bmbHowthVZ0 zjLQRv/LNxZJTedKgCyLtEt9fb0Gza/8+zrlcmYC1Ahq9+NSWYalFMwRJunRL95b L9NlTQ8qYUZEAQM9zIL4ULjniUL9lNuq5GIH9OE3JdCvtNY78Ml4u9GjRRX+HwjX 22MQqgNdXQ5tWvcJo2gRDSaUzpIENVvPwY8mUwoEuN4ceYVgnvw= =RlRQ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote: > > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: > > ... > > > > Sadly some upstreams insist on clang just because they like it > > more, > > without any technical reason. The question that comes to my mind: > > Should we still try to convince upstreams to use GCC in such cases > > or > > not? > It happens (choosing Clang because they like it) and while we can > (and have) > engaged upstreams on this topic and I suspect we will continue to do > so in some > cases. > > But in the end I think we still have to respect the upstream > project's choices, > even if it's just because they like Clang/LLVM more than GCC. > > > > > > > Also does this mean that Clang is now fully supported compiler by > > full- > > time working people @ Red Hat in toolchains team that are also > > contributing to upstream? Just curious if we will be able to "fully > > support" people when we find bugs in the compiler. > Yes. Absolutely. Tom S & Serge G directly. Others in a more > indirect capacity. > > > > > And also, does it mean that we will be following same pattern as > > with > > GCC to test pre-release versions in rawhide, do the mass rebuild > > and so > > on? > Some of that is already happening internally. Tom's got a tester > which spins > Fedora packages with Clang/LLVM. I'm not sure if he's trying to > cover the whole > distro, but it is running regularly (it shares a jenkins instance > with my > tester). > > > > > ... > > > > I think this is not fully true because clang / gcc produce > > different > > binaries in terms of size / performance. So just switching compiler > > in > > some package may result in significat (hopefully not) performance > > gain > > / drop. > Certainly switching compilers can result in performance changes. > Having been > through this kind of disruptive change on the other side (GCC vs > various vendor > compilers through the 90s), what tends to happen is the compilers get > to a point > where they're typically +-5% of each other on the vast majority of > codes. That's > where Clang/LLVM and GCC are today based on the data I've seen. > > > > > Also we probably should mention that -fstack-clash-protection is > > not > > available in clang, so in theory binaries can be less secure due to > > that. > Clang/LLVM is closing that gap rapidly. I fully expect stack clash > protection to > be at parity on the relevant platforms except aarch64 by LLVM 11 and > a reasonable > chance to reach parity on aarch64 by LLVM 12. Sure thing! I just asked to have it documented that as of F33 it is not yet implemented, but is planned to be worked on. So that users do not expect it to have all security features built-in as on F33. > > > > > ... > > > > I think this should mention that annobin plugin should be prepared > > for > > clang. > Nick Clifton is already working on that :-) > > Jeff > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aol8ACgkQEV1auJxc Hh5p+w//XQ32GF4YUnJUXbzQzquqogtmnr+wPcfsY9ZsjTR2PRQUhq+C0JV2ipf3 esitrJQlLPsBfU1pyxRT3ISFQZp4/RR6OtUddMPGS0TDj1UMyyBfuuRC+LKpm4wV MoYsOByMlKEZxeqHe2fKvWvxtcXhe1ocFaqpA3lJAPIxAg3UhjiZzqW7UjqqWQVI wC/Ap5BPSyNUH1QAtkfC98q58YNkMtm3YzUGHfebpp608gNgUzk/R8iE/Is+pHC0 laqiGpnhj8y2jwjqkBSc2sZhgwqYOYYPYy61YhouyNLNin5PqDA1dSBcnrNFXmHv gai1a9uHvN/jYUfDmpgE8TaO4EvWIncnlQV7E7SuH8X48nXNzYjqZl1CRj3bkAm6 kE/ZASmTE9p9aNrq5c7YnQy16zgX/jFVZuge4yKvJFfCZSSwMOPizVAMS2eVjBUG ToJE7q2YmGIwwqjX4W59HElCQXTwK4Yrscr5j9F5mJH+IOzOXuu3tW+XyeX6cjs6 OnyeXGJ1lojO5jBIC6PPJ5KtSFUBjOFyQqJb8ydYGdtwFXgjGDYxiBwJEASo00yE Gx1wpkIhQYGdglbDhVk8qd01S4c2IVpsb0ezGL2Irr0TKAtkFw9N6KM04hNf6zyH RdfTNrdJvNwR2QfyOdhWIRsdjI8/EnacZzORKOQ1pouldEuHQv4= =shcY -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 13:53 -0600, Jeff Law wrote: > > On 05/06/20 10:26 +0200, Igor Raits wrote: > > ... > > > Well, upstreams are not necessarily enabling many security > > > features > > > or > > > optimizations. So you are effectively saying "upstream knows > > > better" > > > where I would have to disagree with you. > > > > Yes, this is a very good point. > > > > Many of Fedora's packages have upstreams that are not using the > > latest > > compilers, libraries, security features etc. > > > > Just because upstream hasn't been updated to work with compiler > > hardening features doesn't mean we should disable those features. > > Just > > because upstream's code is not portable to more than one compiler > > doesn't mean we shouldn't send them bugs (or better still, > > patches).<> > Right. Though I think the security side of this largely belongs in > redhat-rpm- > config and moving annobin/annocheck into an enforcement role (like > we've done > with RHEL). > > We did this for RHEL and while painful, getting the vast majority of > packages to > honor the flags injection and verification via annobin/annocheck > before the > resultant packages can be included in the distro has been a big win > and enables > us to do a lot of useful things knowing that the flags injection > works well. > > Fedora is behind on this. While most packages honor flags injection, > we don't > actually know which do not (either by accident or design) and we > don't have a way > to easily find them. So things like CET in enforcing mode by > default are going > to be harder to achieve in Fedora than in RHEL. But like so many > things, I don't > have the time to push on something like this for Fedora. Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or? > Jeff > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7apgkACgkQEV1auJxc Hh5dhxAAk6g0ayGwzp9gg0P7LiNv1bfk9yFKMI/cI9ToFi2D3bzOCMomvorDui15 EbRZ+YeBB0aMt8OFMKDFwrLpL6dz9rfjxUi5XLuuUzvhpWpgfi4hDJSM8wY3vT5q vEKLCUi/pSGTIRkAYWnxmrJh7XaUIhuQS4FOWId0rzx++7ywPXKCcimMEmR5PnfU qVA1ulPsWrMZVQIiAM4EecJtHTlBKS8kVv5LecZmx0kqNeiiXFnBhThpTiM5LJJX xLhDGYWRKLPHCCKTBbi1nmN+AC71rEikQykry6XruiHFJUrimKdRytP3wdio89ox cbMbinZolYyHUo9aqN/Mqz1diIAoJsQhZ47RQY78lVnR5D78hUYzFCxg4dYQJp2r U0eOwe8Pd4lZxnpEt3Cegyn/2BlEViQPZvBLZa1yzJ5wpMapcqwNTYsv/H5h8Cj5 UpVzBT6/wbsJA528cpqpb3xZuR97M39dHJac1gs9UWXQlu4oM32A59nuHQKhVYxn ZCmiyLg7yl96tgvE/ilDZrsVA84CC2GY9yZY7FHEFEO+WAAIVUUwTCIsyJXAmMzR VWxuCv00ho78wT+UROaFBhYbjaSQJyrTgITpKBRD/Pcim7rO1PIisOg1bVZgTlZd xPcHCzjMGJ6idrROlGlgmj0Mqj7x9fUqEsxqlNSd3QO8NF/GPNY= =S+0b -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:58 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote: > > On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote: > > > > > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > > > joh...@splentity.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > In discussions with both cloud and server folks, their use > > > > > > cases often > > > > > > do not even create disk-based swap at all. A small swap-on- > > > > > > zram > > > > > > provides all the benefits of inactive anonymous page > > > > > > eviction, > > > > > > including reducing reclaim of file pages, without the black > > > > > > hole > > > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So yes it's well suited for these cases and the proposal > > > > > > does > > > > > > include > > > > > > them. If they wish to be left out, that's up to those > > > > > > working > > > > > > groups. > > > > > > It's possible to make sure /etc/systemd/zram-generator is > > > > > > not > > > > > > present. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the > > > > > Server > > > > > image > > > > > right now, and go with its automatic partitioning scheme > > > > > generation, > > > > > it'll give you a swap partition on LVM. This is correct for > > > > > most > > > > > servers, > > > > > not necessarily the LVM part, but having swap on disk. > > > > > > > > > > > > > > > > > > > > The proposal recommends changing this. Cloud and Server folks > > > > will > > > > decide what's best for their use cases, not me. > > > > > > > > > > > > In that case, would you be open to changing this proposal to only > > > affect > > > Workstation? > > > > > > I think it is fine to have the proposal as it is. Those groups will > > chime in if they do not like this approach. Having things > > consistent > > across editions (in this regard) makes more sense to me tbh. > > What makes sense for desktops doesn't necessarily make sense for > servers, or > other environments. Fedora isn't just a desktop distro. Additionally, > what > GNOME folks believe to be best is normally not the best for other > desktop > environments. Can you be more specific about potential problems you see in other use- cases like server? > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7appIACgkQEV1auJxc Hh5Dqw/+MbNqLrRDJb+cYb61f9+M/lvvDIV2OOoYDggchn+gQfUZbW5oEuMUzJY1 zBCqGUzm0nQovKXZtVigBTcLIW2rl7x9PNrDkF1yI6YpeZ52lQFeC+WlETaOs7f9 KaF6MRfjKY+w1qEX8zDnvA0lCjZJUkreoPI6YanQ6/GvX6bCABF3QjEEGjQNNcKL R6BKFdBKTvI1YHb2lPwNNlK8bDi+IBuEZ466WhaT/tDfGtnvHU6XVYzSwle8W5br W0W13xwH/K/40rgff32TFUoczDgB0XzwtEJ6UkJBUjQJV/mSHRuIa7Bwev8BbuNX Lik1lEQHAWvAyxCAuVrq45d0dzxHpYHwSp1tKaDZgbn8T0NDIZOJNn1q8T9OFhnM ZnnX3TOX2Ey9CaDFCnI6aca4LrRrkdSbcuwwtfefl+zlFqdfMHaBFS+6afMvYLDk JfYGVVwg2wKxX9a8YYFAMFshFjbDRT0lKDg+yhvxCdKjzvAxi0bR+7cEbw/NamR6 NTxsDwG8HNNYMHD8JOM3230uSK22bX1x9c4xzaAgOTtmG6StnekS8nLXs/kZBr1I hXyJ58+dCsh0podC7Sanz+XeFdMtxqQN+8Y0KDDY18sA+wYQwt/5GpkWEk4JPrF4 H2mT7hqm7gNAscXdxAl4b6/yjHR57B5sV2/AU+/XBLIH5JTDuMc= =bmkv -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote: > On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote: > > > > Just curious, how is it done in RHEL? Just some kind of CI that > > analyses all builds or? > So we have a step that sits between the build phase and when the > resultant > packages land in the distro which runs annocheck to validate options > used, CET > coverage across the binary, PIE, etc etc. If that annocheck run > fails, then the > packages are not allowed into the distribution, buildroots, etc. > > We flipped it on a couple years ago in the run up to RHEL 8 and it > proved to be > quite valuable. Seems like a thing we should do in Fedora CI for each update! Thanks again for all the work on making distribution better! > Jeff > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aqYQACgkQEV1auJxc Hh5xuBAAiW2mcJsidegXZcnsI5BQanOsVlawmBi6wvZUs5oMb6QpxSrDlMGPQhBr rW+fLdcC8sHyj4sKeC3Rvc//nURiPXLEtB9MDTZVYbdnglt2dNszDIxxxYtL4ktq fd1EvFNvVtB0mdymErgv0zDIDmkJFlsjkageQ/JZBTrFozHTERQadst8QvEoXZRR EmF1WWIy4ERMKSqX3gP1QE4M0pNjwZVNT72lXjf5oUhIcYvfCwsZCacml7GT8mnt Z+2T9GX/k3DRV568LIbuO3thW+hd4GHQa3eL0l3k/NKOy7US4eDET3At64MQgox3 S+pRSNqHlerRSrrlgDkWUY5gojumN2SwESsXdgw91K53Kvw1zOdppBfp93Q1jBJm sHJQR6yQZzh+9Ucn9ayFHE4pX9Zuvmi/93FiQ1sXSJXAvCEbKkCnMfeYVPCHkM6P d7jFvtbjq0Psl7qjV8ydYtUnNKrSzc/TnnrHbYwCxJ15rdVRKJ/TVV5P+M28+jh+ L+EW1niJpHN5ixgBy4N8OOUwzNi7Y9F9mhF7dLQHUN2rHharVikPfath/KoQ1L6D RYwPkpinn3ffw7FQX/9h3BdhxAF9M0W6/9NUoJwT5TB7v3yRtXbKNakT2BTJN/2z 9GK7szXrO35wHpebpQgjVTY96wZK6ieYiOVzIIyk1O6msBwKpB8= =miEX -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CompilerPolicy Change
Firefox > or Chromium. > I'm less familiar with the LibreOffice situation, so I won't try to > give an > opinion there. > > Perhaps in this case we leave it up to the Fedora packager? > > > > > > In some ways this means there is no "default" compiler for > > > Fedora. The default > > > is whatever the upstream project supports/recommends. However, > > > there are > > > probably many packages with upstreams that are ambivalent about > > > their compiler > > > choice. For those packages I would recommend we keep the status > > > quo at the > > > current time. For a package with a dead upstream, the Fedora > > > packager should be > > > able to select the compiler they want to use for the package. > > > > I would prefer the policy to have a stronger preference for GCC > > when > > there is no good reason to change. Currently it's worded like > > keeping > > the status quo is Jeff's personal opinion. I would like it to be > > policy. > So that text was literally copy and pasted from internal discussions. > So, yea, > it's my opinion and I think it's one of the option questions this > body needs to > hammer out to more precisely define any updated policy. > > My preference would be to stick with GCC when upstream has no > recommendations/support policy around supported compilers to avoid > unnecessary > churn. > > I would also be willing to support the Fedora packager's discretion > if they can > make a case for it and upstream has no strong preference. For > example a packager > may simply be more familiar with Clang/LLVM and thus more adept at > understanding > what a particular diagnostic means and how to fix it properly. > > Changing, but then expecting you, Tom, Jason or someone else to fix > or interpret > diagnostics for them no longer working code isn't reasonable IMHO. > > > > > i.e. where the current policy is that you *must* use GCC, unless > > granted a specific exception, I would like it to be that you > > *should* > > use GCC unless there's a good reason not to. > I could live with this so long as we define "good reason" to include > upstream > preferring one toolchain over the other. > > > > > "Upstream only builds+tests with Clang and using GCC requires lots > > of > > work from the Fedora maintainer to fix problems that upstream don't > > care about" is a good reason to use Clang. > > > > "I've heard the cool kids use Clang, so I changed my package to use > > it, but I don't know what these compiler errors mean" is not a good > > reason to switch if it just makes work for other people. > > > > When there is a real advantage to using a particular compiler, I do > > think it's good that packagers should be able to make an informed > > choice. > I think we're actually largely in agreement. I don't want change for > change's > sake or because the cool developers use X Y or Z. I want the change > to have a > real technical reason behind it. > > > > > Ideally we'd have CI building (nearly) everything with *both* GCC > > and > > Clang, and finding and fixing problems in packages and in both > > compilers. But that's probably not realistic (yet?). > You may remember me advocating for this in our meeting in Montreal :- > ) So, yea, > I'd be totally on board with something like this. I think Tillman > was also > interested and even floated the idea of finding additional Fedora > builder > resources to facilitate this kind of scheme. > > The big problem then becomes getting packagers to address the > diagnostics. I've > been disappointed at how many packages are ignoring diagnostics > (particularly > those with security implications) and I'm actively looking at schemes > to improve > this situation :-) Just make them error by default and people will have to deal with it :) > Jeff > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bMH8ACgkQEV1auJxc Hh5bGw//RlZibAdAUs6xXOk0A/6Xudz/GdVdf23qeO+BWyPHjQWpFfRsFEuUu6y2 P+RQ/tqdBwccACX1+H39f1mBfvx3GQfRiWbtf2aZTZ305Pc/1psh9nSvMOisa6dP LV8PnS5/tptVmjqOdALupkwA2A6XHp8VDy/EbLJ8dcV7Aag5ygEMttOdzfqg9bPJ +nha9VanxPWOsirfxpv6gb824LFFqjqZnWoOJuDqNIYnAmb/b6IbJdkqGcDcIrni 1Rz5w5Pmc4/B7SIYvmXu9BAW4rLmFPEPRmc6S+kWERLNMm03dtsYfo8D3JQo6a7W cTqa2fwoG9fy4pH6MG4/CSAbaAjxYK41lMloUCOtBVIsRjkUFt6m/snyPZd1m2mC en2292Am0dkk3H9ZcCra7/sDyerb2WrwUwgLOpUqpklmXB+r+ILTyaxRH5p/oolS T5xd1aLMJ9utBLMIINDaHnNiI/jqoO/7OEesjb3Qxu65PiLWCzYTfpEX6zlxCG+m 9yQi18QrwA5Cd9uGug+cTZlH6CeVGPIqMR6F+pNvqdkxz+yXlTkCQsQFGkuCWcpC 0wewgBpf7OXf5XcEgXM5ZbewgNrdWq8PQ5RlAuovOkAGe214gQtSt8gwESfJ2D5c aefXybm8ef+NWpHufw2DAIzqc8zXAc7AqaDPSy11tOoDtfsRSJw= =DYhd -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:19 +0200, Kevin Kofler wrote: > Chris Murphy wrote: > > So yes it's well suited for these cases and the proposal does > > include > > them. If they wish to be left out, that's up to those working > > groups. > > It's possible to make sure /etc/systemd/zram-generator is not > > present. > > Also, why does this have to be a systemd generator? As a user > administrating > his own systems, I find those to be extremely annoying, because they > do > stuff behind my back that I never asked to happen and I have to mask > them > (and/or uninstall them completely) to get rid of the unwanted > behavior. > > E.g., the systemd generator that tries to automount partitions not > listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap > partition > I have on my SSD in case I ever need it, which is normally NOT > mounted to > avoid wearing out the SSD). So why does systemd want to second-guess > me and > mount that partition behind my back unless I go out of my way to mask > the > magic generator? > > So why can this zram feature not be a line in fstab, a parameter > passed > through the kernel CLI, or some other solution that is easily > tweakable and > that will definitely not affect upgrades of existing installations > (unlike > yet another systemd generator, if it happens to get installed for > whatever > reason)? > > IMHO, the only systemd generator that should ever mount partitions of > any > kind (including virtual ones such as zram) is the systemd-fstab- > generator. > If you want more stuff mounted, it should be added to /etc/fstab, > that's > what that file is for! Well, with systemd.mount it is already possible to mount things that are not in /etc/fstab. That file has same disadvantages as any other configuration files in «unstructured» format. You can't override some specific setting of it, disable some mount by simple command (that is not sed) and so on. Also if AIUI, it is not trivial to make it work with just fstab because something has to create a swap during the boot and fstab entry clearly can't do that. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcA8ACgkQEV1auJxc Hh5VGA//SNQOQdLoTvqZKdfS9DpPSsvh/Lii/FMe38viOmy6hcAjQJ6Z3PlJX9cb e/4i8af/OTzYkoYLQLlRwOfXszcZvKCEtjAJz3yfOTOxwxuItucsC7HeuMXiDlpG 3RuV2yLoZFOo+BwlfjFLxvNZRag+w8GLuSLFO0Nes1xjZMNwoI31PVyIykZ60YsH LX7vPZ80QOKAQHpPuxChyOIH0uXelGN8Mnl7lVu9jPPaDQaCzbUpcSBTeiNK0MGK oUFMXB0zfTZqk0iLI3VVdf3MZl2hro9R4c3AkbDsitcFwlWoMuM07U8jdNvuf0pP Zlm5hnZ/Xks3RzC+6wsIqB//ubS5f6WYLt4B/tH4zhAyW2CIxcWx3n9eonLshFX+ QqS92HuS/KBfcVG5GCpAMVwBdZwikjxbnf0CQ0az34iae2FmKwyVc2jKOwwdwCke eGnMeo623p4uuLC+R9LwjQCAK8BHi6dQqRgY+Ybp6ymzPpffqaWzENxRmGeG/0M3 cNjrsHQlKvxnXhbbungeJIEPVFXn4Y/V1sXOrj5JMW/M9Dk44M3lrATiiiojZDxA tRsKgtGKzT4WTp67N4/dnK61ByCDAew39IG8JFUr/2dUDoDkEpXk4mSxcU3K7kln +yagnUD6UTTeWWtq76nKer9ydjrN/tdi9yVfHGFXqbKboFKQ/ok= =rfaN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > The change says it will use 50% of user’s RAM size, but not more > > than > > 4G. > > But if the machine has only, say, 4 GiB of RAM, then the amount of > extra RAM > you get that way might not be sufficient to avoid OOM. > > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > > > Also -1 to adding something to the core system that is written in > > > a > > > language > > > for which we do not even have dynamic linking support. Or even > > > real > > > static > > > linking support, as opposed to packaging libraries as source > > > code. > > > > This is not fair. It is a programming language that is safer than C > > and > > is already used by some projects that we ship. rpm-ostree, firefox, > > librsvg2 and others. > > 1. librsvg2 and firefox are not really core system components. They > are > UI-related packages (an image processing library and a web > browser), > which is at least one layer higher. > 2. rpm-ostree is only a core system component if you use an ostree- > based > installation. In the default Fedora system, it is not. > 3. I think that it is a bad enough precedent that even these packages > are > using Rust. We do not have a reasonable way to package software > written > in Rust. Packaging libraries as source code is not reasonable in a > binary > distribution. (And yes, I was opposed to the Go packaging > guidelines from > day 1, and the Rust packaging guidelines copy the same broken > concepts, > so I am opposed to those as well.) As a result, shipping Rust > software in > Fedora is very painful, because everything is essentially > statically > linked (actually compiled on demand at application compile time > and then > statically linked into the application). Why is it painful? You have all dependencies packaged that follow semver (not like Go) and it is quite easy to build those packages. Another example here could be nodejs, even though it does not link statically it is just PITA to package since ecosystem is just full of very small libraries that do not really like to cooperate so you need to have tens of different versions of a lib in a repo. I consider this much bigger problem than the Rust has in Fedora. > 4. The Rust toolchain is also inherently foreign on Fedora because it > is not > based on GCC (but on LLVM). That way you can say that mesa is foreign because it uses LLVM. If there is ever alternative compiler to Rust that is based on GCC and has feature parity, we can definitely consider trying it out. But the referene compiler works just well. > > Core system components should be written in C. The higher layers (UI, > extra > CLI tools, etc.) can use C++ as well. IMHO, any other programming > language > is just a pain. We also have Fedora CoreOS that uses https://github.com/coreos/afterburn and https://github.com/coreos/zincati that are written in Rust as well and those are core system utilities. I don't think saying "Ditch Python, Ruby, Perl, … from the system components" is useful for anyone since you know that it is not going to happen. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcdkACgkQEV1auJxc Hh6Aqg//bbeyDzTLPVhN41P7TU5LeA2d1c/Ya2tjbpvWf3VaWsJ26UDdLUyIXw2c r4/C3Kkda7qGHmOSjLRlBvzEMe3e7wO+Xi+16ZyTex6+2M1bxifAXZHTz1wtkhIW AmdMvyjJbCrzc3jUG3dj3FfE4PWjS58tZYIvG8XEcRxoyvWOsMRqdaxP0V9Frhr7 9hxULUenGpVzvXz+z8/s7rosN4yqTotv1HCFRCworHhXXErVzEy8ha7EjZpGwnyL zDssJ0jB+5eMYk94J2NG5ZwBkOSxBfYMEO4dDLQdMPk6jBEfpZg1jS5wIkbUx3UR fZpitoOs5snIyh46bjL5ldod9lgJ+j7txSle0tpTbeGsPRqVIq+k7NhRI7s24q+R uaJwHDsGRtBaWeTzzykCPlj7kRh/y/fV3TIBzpi5apK1aXxmAZw/RuMXzZK65yFb cGQ79jKanOzRMCD97T+ExiBNpk5Oj0dEF3dWlbHAxoHDc5UFRxyizUPPUNGHooTg qmnssso/a4MoS0/IdTsHpJP62Xm7tGBm9VfIDkK9GFxBZ+L5nj/43yuBxKUMA2s/ pWBZ2FiqzLQ0RyD1IqXsUVyoxm3X66FRywkTgUdg56MQAvZQkppdeoBwoP4kBOdS Yqnt/GC3iq0bt+7Rt7TQudB5fXOKnFL7oGyrx6zAoct3n+F+HNk= =H4dJ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Some services are failing to start with mount namespace errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On fully updated rawhide, ● systemd-hostnamed.service - Hostname Service Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service; static; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/systemd-hostnamed.service.d └─disable-privatedevices.conf Active: failed (Result: exit-code) since Sun 2020-06-07 07:56:50 CEST; 2min 19s ago Docs: man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5) https://www.freedesktop.org/wiki/Software/systemd/hostnamed Process: 4654 ExecStart=/usr/lib/systemd/systemd-hostnamed (code=exited, status=226/NAMESPACE) Main PID: 4654 (code=exited, status=226/NAMESPACE) CPU: 7ms Jun 07 07:56:50 igors-t480s systemd[1]: Starting Hostname Service... Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Permission denied Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-hostnamed: Permission denied Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=226/NAMESPACE Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'. Jun 07 07:56:50 igors-t480s systemd[1]: Failed to start Hostname Service. Also seen this with fprintd and systemd-timedated. fprintd.service: Failed to set up mount namespacing: /run/systemd/unit- root/: Permission denied fprintd.service: Failed at step NAMESPACE spawning /usr/libexec/fprintd: Permission denied Restarting those services make them work fine sometimes, but not always. Any ideas where to report this bug? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7cg3YACgkQEV1auJxc Hh6Cxg/5ATwHWnT63B1c2dgmOTWbBiB8oZyoQ7YeWsFwNFiUOsF8ap4Ndx3idpuU 1Xesq4MPLhfOlCdBwT8QPxP2vqMfmc3Fxe+jwxBjN/u9yBOqUbaDGWkq6c2d7+rB AZ0pfJLCEodn86UrXkZJ6RhAS/8pXSS60Y13+UgVZhzI/1y9HSfKhjhi6GFDTxDS WRHR7rqeij3XAjM8HQ+bYTjLmxkFIJx0EjfE3sO8va9HSxvnSbSIUuKQnzBtDb5D N92NUkKLfNx6gjL5mcKaKbdwIyazBzxSIgGN9Bz53H30xQCYV86RA9iyvvRQcqQY gLlD8gsnDJJHpcW9Jad5qX44Jqa1dyp4i/2WXozskv387GAAAJ9L00hZuJmHKVjJ 1MT321/A8iEI6DXukkGRdsXtQ5QJRYW2bg6N5PsW/BetHEwWd2+y55zlAbsuzSth Qfhasw/9u8NptuFINrSaZ0RB/OiRHld7OFh7G0tX3ShrjNjF8c9SLUI6eETtLOeP jv8ArHDg7mebjCsHGmCeEqCcNi0CRRl7fCbd0j9J0h9g2jtuE0bjqfrrNHRUhdAk AL9s1xK4Blk0XA+x4nOqnzRZpn5YnlCC4kpmiihKX3i5bH3O6q0qDueDG371qmj1 YaAD6KmRza/+nOPxYUoYtZ4orLFG1VnobJloBzpNmPMPb+Wqzrs= =vw+H -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Inactive maintainer - dmsimard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Anybody knows new contact of David Moreau Simard ? Seems that email is not active anymore. https://bugzilla.redhat.com/show_bug.cgi?id=1841624 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7d4tQACgkQEV1auJxc Hh5gow//UM5WlL+yOcd5uANoVqbQpD6/FxzxFirFQ89J6LYhzDU88pj0YkD35dT1 3/+tHN7VrBfNPmYAAXyQitpCKvPmhnRE1sFIk+zxh+GkcN/e2AvXTAh1U5MW75+X zMP5hjHedmSvWGvT/IH+qvGdS8ZlMOA4Bgc65dAlHV0x8m3jhb6ue1xxDL94ZftN 18k6K+LMstNiW6ypXpis/Awx1P6On+dgrfHLxqgj+C+4ADqs14Gd9UztvE3ytf8E Emm78SDUKzRraNoA4tk0u26soqhFS+y4tjNQA1mfgo2Pkz8hNfKgd4ThrsDxthcy CBs8hFQ1RequjKHoTyWMAQJo6cWNvsFBr+qrSaMJWaPmS5AuiNUDVvNn6tMQUQT2 GNVMH+DHye8WzSugVQc8nlWCapXSV4Jx4GApauznjLWkzHKE7XQwkOWdLgN+MAix g/GGp3n9v2K1cjb1JSnLx0crVELie9XQyFx7tYY3VbO9sd0avge4dHmcvfWtrY7A QrdLqJQhmfBzO7JvG9uLhb4YE6wtYCRwN0fxIJJU9QjEm32vatHk8MrNZYII/R4G hKKylUoBoLaHHx8dulVXCxvUcXkX7TFJNVFm0bBYv8q/dPXe4748JPtIRd2siTTH chQKRohPbmkAaZFIwRpVMxo/4LOnBGdRwjahVdDzHPD69E5v6e0= =qtWT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Datacenter move days 3 and 4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-11 at 21:24 -0700, John M. Harris Jr wrote: > On Thursday, June 11, 2020 9:09:53 PM MST Kevin Fenzi wrote: > > We are working on getting this install moved over to recent > > fedora or rhel, but for now it's rhel7 and python34. > > RHEL7 is better than RHEL8 anyway. ;) > > I'm planning to skip RHEL8 entirely, it's totally b0rked. Good to know. Please avoid posting such messages to the mailing lists. Thanks. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7jSlMACgkQEV1auJxc Hh6tpBAAjNN6Hl71RlZ1sAugggpQBJt0/rZ7KpL86L5a/rT8qkSqDIyGCF8MpoFd xBkDQrz2oHd2sSbjTtORlHYuxtrmuju7FijudyphhJVTAWvfdrKfv80f/+zRYwcV gNpgvReqWR2woMSs0TnJnodjnc5adpO+UDR83U2DSI7enJlsUA/HQg4h9O3eDb7t Hupt37/SInUlKkrAe/Rq6967AEIsu+C4VNo3O0kb9wSqCMaWEyyKr0o6M+dqMzQL kZ4gmIwNz2EzDAJaSP1GDDMfrJosUZ3ApsnjcE02UuTcK0+kjT4dp+/bNioUVO4+ FVnka7MhIs4DTqT6lxqLnPCl5CTkXA0t0MqJOMcRtW/OFSYpB6l1d5SRcgu4vlMl G2LmnZ2pEhgTWvIJlv49dDeZOi3IlF2i1XAydKSMKOTHR4kekFy5Wz76UXh2EMRR 0FV6Z3BGNsXD2X9/T5wRKjfaC/+rs9zMZ3Zc3zrT/UgXYSLaYyOHun+geIiz5GJp 5qx/pVoIp0a4wl0u6WVRjqLrtpfQDOorw0Ng1foea3AqMJzHaB0Yep1Rwuq1eGdK Or/yybv1Ud52Jt8rid/zFluPPvJZz3oXeSzL+O5jzdvT5QZsz6z17y9yVVnqDLjm 2TtnU76QEy87Iv/fCWOF/cVEw0XJK3zs0zomXkWti2pKY9cXySY= =wm6E -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Is there way to include some sensitive credentials in builds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I am packaging one nice GUI application (newsflash) that is working with API of some services like feedly. Those require some API key, but I think it is against their rules to have it included in the plain-text format in git. I am curious if there is a way how to get those passed during the build. The key can be passed as an environment variable on the user's system, but there is no way everybody will be getting their own keys and I think this is non-trivial process. I think shim does that by building unsigned copy, then signing it outside of Fedora infrastructure and making signed build with prebuilt, signed binaries. This would not help in my case. Any ideas? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7k5lUACgkQEV1auJxc Hh4DJhAAr8lkzSGSZipWQA70K57+bLCQDv7M7igmQYo9vUVz3QH004aShKOZ7tmy XWvkx/T/lNQ7V0ND1jvs74/NwskYYojPgTHNNTUtYOK1krmBtTGjcZcaR66CJXay YZpUiYGouvFmHn15X9VDGO0uoMM4kAPWhdkZ1/Ruw5cSfwSZMW7j48WPaeu6iYNj zujO3hyIfkv5TY323Wx1x8MfPyH5IgwOmZ/OiCyW6mmJaXBj+P+qgMuWZnmkrxea prfK6/Amb8HOm8AbbSN6Cg+jszcRGSAdkSNEPG7ryGbOtWI1SnuzbIqMv3ffE2Rm 5eO9Ycgo9HGDFNLuEMOCT8CkNdl4kf/wYvd3TjktfFQxyqJIJXFlnAWuZJa4i+6Z fq5XIAsmu9aPftKjmF7kYusN0UZQ3Z7Fq0wphdOgPd9wXnGjdeqy/7tkopHSgTJ6 9mxYkXUPmD8kI9LyCVCZOltGsArB1X0GmRaiGnTsfd2H33JQY38+kv2OO1kP6pkG F+osagb3E3rW8cAxWuKWLgx5ElCbLTbe1gdPwNi2gvYEtExxkMqdJAnujkkGXoQk zkKi/KsQrcEj69M83t19GxaaxMc4Ns8ccin9vYe09ffCJKsUUTgvxvCFBtmpSim6 NHx7y8h2VezuF2D4hmR6Q0Vw3Y/EXRPU/7euBl6/Gc6z3+5OzmM= =9tek -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: New protobuf blocked by old protobuf from module [f32]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 11:31 +0100, Daniel P. Berrangé wrote: > I'm trying to install gmic on my Fedora 32 system, which requries > opencv, > which requires protobuf 3.11 > > DNF refuses to install any of them though, because protobuf 3.11 is > blocked > by modularity: > > - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular > filtering > - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular > filtering > > All I can see with "dnf list" is a seriously outdated version from > an unknown > module: > > protobuf.x86_64 > 3.6.1-6.module_f32+6163+c0e6dcb2 > fedora-modular > protobuf.x86_64 > 3.6.1-6.module_f32+6163+c0e6dcb2 > updates-modular > > What is the right way to fix this ? dnf module list shows me loads > of > modules, but I'm not seing how to determine which of them are enabled > vs > disabled, and more importantly which is providing this bogus outdated > protobuf ? dnf module reset eclipse > > Regards, > Daniel > -- > > : https://berrange.com -o- > > https://www.flickr.com/photos/dberrange :| > > : https://libvirt.org -o- > > https://fstop138.berrange.com :| > > : https://entangle-photo.org-o- > > https://www.instagram.com/dberrange :| > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nUNkACgkQEV1auJxc Hh4Ijw/+LN9prD1aH0AiNQGExJA1wtq2AMK1rCUGDgUwuC0AbGf0Iw6gf03DgvDL 636ncSbApXlmxR+LhAhyCriAaa7CpMciB3YJvlLrGR7NLGkNLj7zMvETpueXTq7d D/Qj6gnTL90asfHNip8EiXRj4zIRhexf6kVNXnmthfnlU8+44RQcOc5bGztJ633D u8cMo2ksKLWni2n+Or7Oh6LO0Pob0LxH/iaSOVg+TIoQ84/6nHWZFIarrmzC8D+H d0xuSBGcQFDw+5gXA4dVXz0FhYPIYDBtV7ZzCEgn9uNyY4BpMrfIlxF1DGiLMSIz NCiLtpiUEvukWzmKWkUDHk5//NawtNPRzOT7WaKdvbcHr43fouZrPKw1mNU3AmgJ zAgkvMSTpKzGOG328y9XEx/mYcHC/rw/+ct+1m2ctCp8NR3/oPRUUQ5CIt0Y0Vbk oOPnFghGF8wbSd+jdqgRyTsKBI0OSwQCaVBsNM9lx81J6zVfWTCaNiOgrRy/jWrd w2btjd/TagDMKgj2PBcPTPrLjU1BAXZWbT58XFMsM8AGfUrUryE894o2eW+qPeNv f2ruwOsG4uh1qnJh7KKUQCnmpqbWPK1ACwqHdcGdAnqXtqmlCF9PyyVynZ9R3KlH sF1B0oY1/FofziAClw88zyvqBEc6vsEfPGbJo6N5h/UoAtcSqNk= =d4WE -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: New protobuf blocked by old protobuf from module [f32]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 13:52 +0200, Tomasz Torcz wrote: > On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote: > > > - package protobuf-3.11.2-2.fc32.i686 is filtered out by > > > modular > > > filtering > > > - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by > > > modular > > > filtering > > > > > > What is the right way to fix this ? dnf module list shows me > > > loads > > > of > > > modules, but I'm not seing how to determine which of them are > > > enabled > > > vs > > > disabled, and more importantly which is providing this bogus > > > outdated > > > protobuf ? > > > > dnf module reset eclipse > > Could you please explain the steps how to arrive to this "magic" > invocation? dnf list on Daniel's system shows only one protobuf build - protobuf- 3.6.1-6.module_f32+6163+c0e6dcb2. Doing koji list-tags --build protobuf-3.6.1-6.module_f32+6163+c0e6dcb2 shows: module-eclipse-2019-06-3220190902131726-a48fff9b module-eclipse-2019-06-3220190902131726-a48fff9b-build - From where it is easy to figure out which module it is coming from :) > -- > Tomasz Torcz “God, root, what's the difference?” > to...@pipebreaker.pl “God is more forgiving.” > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nc1MACgkQEV1auJxc Hh6v0w//ZbRTLiJQJl664pTAPB4WMHhVtYqfCtnOVuA98oxo6VZRgVxK8VK6Lnv7 RQtVcljb11ObQs1Fbr0JijdTERqcRww9W//kYYXOGgs+PI7sZB/y2SnQ3jVybnXm cXDOHUvROjHPW9vhCM3N0wbDFSq/VWPoXHlUuejEZzt9m7OXGfqP4f/APbt2xyGX cttvLve7yg5EdjNwMqEDiaipThpFrqd/RCy2qWb8qBauHVm0AHDruGEcjL3oknoF CtzexxXXgs6eaoNnBpSkAer+iCRdhFhEmkBVk9kPYhNmUelKc8eYKTFDE1gVmpsB 4gHoxZMkTsc6MaAtlhbzPIYwx7Yfwa/spuQZdkp6Shew1fxjlEj4vq9kHZyuSFmW ir8SneTaqW+Aohv8Xs6E/hBIwm/LfrW+5yWXCeNP9uOwZCi1S+v1IaoxMj0q1o9q MbLLtXGjdjv9iHiEm5enr0FM/4Z/ls/ob9IQ2boWbqWHuNSTngR26BRKAFbcNcGG htj5VR6JDu14gsxA1bgQxZQtm90f0UPD+T44VIFR4G1IqGIp82Q5DuZrqbBUCaNZ B4WuFrooORL/mwwDKIleuWailAyeLQo5bQ8PTSH0EBwUM+sYdHigNYcO6tBQP5Kx JoDlkYuoXH2/ShRc2zqUg95IHRCslQan4YpUo834p+sUA6XPYCY= =MuWT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora-Retired-Packages
ny other package. > > == Contingency Plan == > * Contingency mechanism: Drop `fedora-retired-package`. Or remove > `Obsoletes` from this sub-package. > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > == Release Notes == > TBD > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n0oQACgkQEV1auJxc Hh5v4BAAmjdMeYnF5GMjdH30EweQAz1Wsjex/QN/yUP3GOt50EPfy4jbU2RIwije RvwKkJF6JAgEY+Q+mKvRWRlTIu3cBA/Kh4qQS/LDzRSuRba6ZUBeZ3aG4Pe1fn4L XubI8pBHWPfO7W4w3nsF8ivSQoLighQm3/Ee/FqdAUmeD+ZyCqWZLV+hWMX45fMY LSlBLp+Lx7m0INWNBB5lxiXtvx66pBicyAp3YbWmfWGls8TdSMqpIEhSAizPM+Mn Kg09SkQqNtEydSAOS+TZi1fe5mQJKWGdaxTXEfUUO5pRSmIt/JR6uDltgru4ltWe 1eeN3Agp8xltChY8oadlK1SdPL5msjxguKVe1vMjoSXsQKzT53gzVAmeN2lCCnyT 122O2qklsG0RV4lx19aIAKpvq43gUnUAKXT6dZVbLIzh5UBfK2qGRuT6KNNVrRb8 N+fnkYqJ4XDPLdvoaAWdAAFn/WohV3/IXdX5jbN1XahJo5kxO7ePc1TVh0u2A4UW 9qdpAU8P0M5zKoreRWwvTkLKSWdz9wRnPJA0iZgxIWFbOBytmYxlKJzNGlGPKt1N r1dYid3q2QGX5OXNJvwnARQThRTtC+Q295/AF4EPKb4LsV0w7qUYKSe8kjYBRHxv yezHkTo2EUt4JKB6R64m7e05tDRP7wLMTdzLaxxPem+32Ap3cFM= =fm7+ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Self-Contained Change proposal: NSS dbm support removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NSSDBMRemoval > > == Summary == > Network Security Services (NSS) historically supports 2 different > database backends, based on SQLite and dbm. Since Fedora 28, the > SQLite backend has been used by default and the dbm backend has been > deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format > SQL]]). This Change is about removing the support for the dbm backend > entirely. > > == Owner == > * Name: [[User:ueno| Daiki Ueno]] > * Email: du...@redhat.com > > == Detailed Description == > Applications that use the NSS library often use a database for > storage > of keys, certificates and trust. NSS supports two different storage > formats, one is based on SQLite and another one is based on dbm > files. > > Today's default file format used by NSS, used when applications omit > the type parameter, is the SQLite file format, and the older dbm > format has been considered as deprecated since Fedora 28, because it > has several drawbacks such as lack of support for parallel access to > the storage. > > As the default change was made 2 years ago, and NSS provides a > transparent migration mechanism from the dbm format to the SQLite > format, the suggestion is to completely disable the dbm backend. > > == Benefit to Fedora == > There are a few benefits: > * By disabling the dbm database, the size of the library binary will > be slightly smaller > * The NSS developers will be able to focus on the new file format > > == Scope == > * Proposal owners: > A build time environment variable (NSS_DISABLE_DBM) needs to be set. > > * Other developers: N/A > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > The impact should be limited, as long as the users always update from > the previous version. That would ensure the existing databases on the > system are properly migrated. Therefore, we propose this as a Self > Contained Change, rather than a System Wide Change. Does it mean that people who upgrade from F31 to F33 will work just fine? > In the discussion on the fedora-devel list, it was pointed that > pesign > package embedded the dbm format database. It has now been resolved in > [https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902]. > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > No user visible changes. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Revert the shipped configuration > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? No > > > > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n12oACgkQEV1auJxc Hh69AhAAqMcmdCbus8WJVDLeNcLl2o9jIMWGgcIzPcz0wrC70yGG46mkrlD47h/s c3ZuzhiCWi3xZ9NHOwkWpF46DJE9ac5/4bJjxv6doJNfRCoUIgdTYQpmXoYzWXqq mfQK8f2qD2PHaBkK+0Cq2z9TJ/7xigsPKxHPDbzwfjOV4IodTk/0RO6SxsdF6Y2V rOeaPVp+Lf+QRMKVGwpkRidMxwKxEsYN09MJc8yj9M+LL+lqepSzqB4oG1IevOlt 3xb1FG53W5WGe7SOEz4Gej3MVRt/YnZwsiIQD8ztEH8udp9+VBEEtyfVeNkcel0A t5Uq5sJccmWGARmua++4HC9lSPI92MbEITzePfBi8yPquXfhz7pBypKQ4922HarL 0Y4hj1D2hPCySXeFQ9sD0iccgcyew9a2Z/S//aCUIaMY2TTaqgPN2lo9MdD1MbFY r1YD24RA/ogSc+dyK01u354hsPvg0u/hfaZwmyBlXNLWmLu2nPHywhwrKbkPDppC G0dVqgHYSVVnFHuXmviuhWMyrUjiJJY7LDccXGrQEUoIAvU1nYw6HgWB7e/O8dwV OS+XOJDxlzdHolNxOXI+FUaL1r7MlbsAOAkFdS5lFBHSK81yU6BGn1KNPZ9K9z/T uFBZLsIr/T+/iT3pn+1N3DlLLXdAdw67N7MNh2mzwHWWIMv/6m4= =nJVu -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Self-Contained Change proposal: Default animated background for Fedora Workstation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground > > == Summary == > Fedora Workstation 33 uses animate background as default. > > == Owner == > * Name: [[User:luya| Luya Tshimbalanga]] > * Email: luyaATfedoraproject.org > * Product: Workstation > > > == Detailed Description == > > Starting from Release 33, Fedora Workstation uses default animated > background as a visual showcase. Spins and lab maintainers running on > desktop environment unable to support animated wallpaper will be able > to select a different frame from the default (and variant) > background. I was actually surprised that we don't do that already! > == Benefit to Fedora == > > Fedora Workstation will showcase its animated background seamlessly > as default. I am not sure if the Change Proposal is actually needed for this, but thanks for working on it. > Does this improve specific Spins or Editions? > Design Suite Labs, which is based from Workstation, and > Fedora Silverblue will take advantage of its change. Other Spins and > Labs will remains unaffected unless their respective maintainers wish > to use the default animated background. > > > == Scope == > * Proposal owners: > Fedora Workstation may need a slight increase of its ISO file size in > order to implement the animated backgrounds which are in PNG format. > Each frame from animation will be selectable from the Background > Settings. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: Possibly a slight increase of ISO file. > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > Users will notice an animation of the default background related to > the time of the day. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Revert to the default static background > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) > > == Release Notes == > N/A > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n2A8ACgkQEV1auJxc Hh5RFg//Sl5dAmadTFxJipPKtYbNdXINFBwjdqO0Ww2GjrJo7STOLhbGkGTS+hVH 4phJxONNml8PW9RbNBEzMJwhR+U8Ma5ghD8bslMYanmpjCwoTAVkSlttu9AvdFNp VZcEE3p4TNIKiygELl22EsIj2APm//cDoq7bY/Ltx9tIdJDob4G9aur7g631rzQm p0f60HznSHQdLE/5MmBfgWPu9TAh9IzFvXxXarmmDzg3njYlurfFhNUaBh3ZrwwR upAgjSgyL5YDqCE6PTuj1pAR/ZLlajXgdSiVKQmO5UTI4svC06iuMlBUFOIl2f11 +dhLWv4o13GWACEWnM+TD88vVYEwRGWLgbOn+wpz2GHPYBDyavtIhOZXUPHY4+lV GivFrdzstW6U1nC4VOwin2FpX3uJGSFw9XUgiRhEWbVngco9mR9/zSSXqyS06DFH ojvHO81FZiObZsuTkhaPKB9aNaZ9AtXWsRZ8ykYoJZNo7pL1K1y81hy0lRmGr6nE T3jq/c8mn/w8zKYSOvO+0OcyA17fTlnxwHtQKycZH2xRcikPlkUtXuBME4W2TDFH yNDQJj/B9+cBO6LsY6XyPQf+8NZpadTHvqhOKM1QWWhLMtMf3bwEFA1Q16ozrKKr pfqz3WEncKAF4/9wqOAJz1YoKP4jXMag7yLM10D8He787YMF20Q= =9nHC -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
>
> How does this affect the many packages that already build in a
> separate
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.
If they assume that builddir will be in `.`, they will break. And we
will fix them.
To prevent breaking, it is enough to specify `-B .` or setting
`%{_vpath_builddir}` to `.`.
> And why is it worth making a potentially incompatible change to the
> %cmake
> macro when it can already be done with the existing one?
Not sure if I follow, what means "can already be done with the existing
one"? Does it mean that you can already specify a build dir via CLI and
some packages already do (e.g. libsolv)?
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oVDMACgkQEV1auJxc
Hh6eAA//Zcu6swqz5QBUW/Tof+UrTZrYYSVomGuqp7ramJFlDjEOT2Vi8turzz+a
WUkFp3ITGml9W324Y75+TMq9nAnoAwiuEjhnknEQ1aO+U5n9wiCRQx+t0Gtw8sHT
BsP+vu1FbXVN9NgQxmVXfKlD4yB6JAzU1XvVF8szXpHpiJEA3fstMf4wtCJkWRNa
3jHpByUsLijgYoddTO/DCdqIBOtXUhoEHfm98ZmLI4rBvF85vAA67ylcKuWjXHNw
OKtVnTOYBxP16XLEQuP4MyjeZDcBbWxJgAWfaEE4ozhV+D8zRKYAuiRVi29ANJN/
D3QxwZVjMIOyPciT7yrurApP+njMsf58MNs5jVdW2PZX2Kx2unU0ojv+01jBz5qs
hYDlKTmk+zvYrLtG30HXSSoe+WuO2pzeQPAKrCODm89fteyzOfj0ZHW7j02vB/7O
d3WIw9KpKbvBdxTVlfL4aEBxvm3WXfjW2zcXCSCmxUHCX9Hs5pDqOK5KOHpdxWj5
n3msgjAJrF8Vap2cqPwWcbX0plyrKiTHspQuD5mj9j1jG9VjPK6ynNvmrzXJMn0D
wxrkJBA3FpLtNhI7XOdlHPKWVuiwVV369NKkavgKY3ea2QzHGJsnPOaaVoXCtMNl
90pSjpLh1jTntN0VlMMXN3pJaoC+QZw7i76WQJ6wIYp0VKN9j5E=
=SoZw
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
> %cmake?
I forgot that it does not use %cmake, so I think we should change it
too. In that case, we should also update change page.
> 2. If a construct like this is used, I guess we will end up with a
> VPATH
> inside %{_target_platform}? So the -debugsource package will have
> a
> nested structure like Russian matrioshka puppets or Chinese boxes?
Example above will stop working, but we definitely do not want to have
build tree in x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/.
> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are
> doing
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit
> from disallowing in-source builds, it is just a simple special case
> and
> normally requires no extra code to support.
With this change, everyone will be more happier. Essentially we will
always do out-of-source build that is recommended by upstreams and you
won't have to think whether you need to build in-source or out-of-
source because it will just work.
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oV0MACgkQEV1auJxc
Hh7dxg//bGpoju+h0HS+ZqVUQxnHreOZeGM+/OoGwaut3M/tbHYqoSCHHFVGuCPe
e3SwVpdeFxnAvGpa6w5KAuVYTz1bwje8wSDDAmdAF7mUQCgCofZOwVwaqTkCIAVj
UCsZP4K+khwLNSZtrlvqHzp1qvweOk33MykqepG3IrwzX+QtaMkyciAZmxqewE1P
yqpVYtHJeeu4JSg2rcBWswTC08NOPImc/uMfwqSfB9kXUuzoF55iEvWSaYYSHVRa
J2J1MIC+COaj2TODb6F5kbjjasM3sX2QC4e0P6S/R1r+1Kh5Nt8lCYhiCBR86t6S
rTbMMMch+mkOjRdphmbF6NtJBE4q0YlDQfZDB2jhXk/4/PD9wMqOJwk62oobLIv8
qFFNmI62ROzdr44fOG/MsobgKeDI9Xn/VgMsPdeXFMa3hDVvAOKSDrRuHXwUTCX9
/+G1kXhnhhO5uxHtWdHlCGJOFplixELz371lOC8sLVkxYGNpX0vtLtfdMwK6bqLB
RFyJzqBDn0UWMGw+2OIAUw7lAydMXWvLUu781PfW87MIZotM1cu/b23mC4kbMKdT
Cn1vgFLE9VlKh9olB8dCcVBB55Oxk2JbtYNlffT2lZ6U618icoG5XRgqv5WauM6Y
oMpOw0OISRjteYNPNjx2FiIW92Elt8UCs84za27KXyQSDZORvCY=
=ZOqQ
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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
undefined symbol: pthread_getattr_np, version GLIBC_2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I built gitui in koji (f33) yesterday and tried to run it on my laptop with Fedora Rawhide today and it does not work: gitui: symbol lookup error: gitui: undefined symbol: pthread_getattr_np, version GLIBC_2.32 Did anybody see something similar in other applications? Any ideas what's broken? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1 nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI= =tZrU -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 12:16 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > Example above will stop working, > > So your change breaks hundreds of packages, exactly those that > already do > what you think is the right thing. The correct way of doing out-of-source builds is to use `cmake -S . -B builddir` and not cd/pushd and other things. Sadly we can't implement this enforcement without breaking packages that do `cd/pushd` but we will fix them. > Hence, sorry, but I am opposed to this change. > > > but we definitely do not want to have build tree in > > x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/. > > That was my point, yes (and what will happen if it does not error). As I said it will error out. And we will fix it. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxDQACgkQEV1auJxc Hh6ueg//SDqWyj2LAhdrwLS9yp/0pJrrfZ0NqFuhfEBKdG4uhxR0dwULeHZ257iq uQAHo92e6SAgnDEhTl+EoAcWqoM74Bf9ladXOckY/3WaHPV4QHGKIeQhzCrlaBt0 79vNaQ02Bss7lkr6a33tqem45DNLl80vMLk66otToKSAKce5sUT/mOx6KmEkJDHu iZykEVERRqSnAJtzgYhhpcT9T1nUVQCO0/0uJUUt1sq0Pr5S5hZPI1I/FTCod7YT OeMOvryRaPgEMu7iuxQ9gLC1ZkwPnUQX3t8rVs4XxAzydFTIxh7iVQpN1JKvCcBp jzkY/zY3TPNkKRIIc2oHeoSUDUQ03IT/pAAlv5zDKBpmAoN/E1ZxlYCFD92y2GsD /VgFCYU8wJeIykWVeFuDpLKmjD1z5d9RFcd8a8tUfswglbMdSEQHNSaI8HIPcAU3 fCiXn9dAjTsujA5qcnZZXcrfGFzJTcxvhlqAjz1cJLyy8y4ogvQ8iQrW2KviF/Tc 06EJ9edPTIaLKk3JN2rq2phOzr99z//PZT/ez7Om6Jh0Ov9CR1x0y+d2DhvToOfZ St+IjKrghPFPNTojQdMkXT5hNYJ92hn0NAGj90WmvnNvIYowGXMAZR7oDhcWcoOw N7Ab715wgy426BtvjwzVKg/kBNmGGX4wMDbQ20M7LdJaBcCT7KM= =lS8S -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 08:37 -0400, Neal Gompa wrote: > On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar > wrote: > > > > On Tue, 16 Jun 2020 at 03:09, Neal Gompa > > wrote: > > > > > > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler < > > > kevin.kof...@chello.at> wrote: > > > > > > > > How does this affect the many packages that already build in a > > > > separate > > > > build folder manually? There are even several specfile > > > > templates that > > > > contain the boilerplate for that. > > > > > > > > > > If they build a separate folder manually and are already using > > > the > > > VPATH macros, then there's no change. If they're using a > > > different > > > structure, we can adapt them to the standard VPATH macros, and do > > > other adjustments as needed. > > > > What if you need several builds with several flags? E.g., something > > like > > > > %build > > %cmake -B flag1 -DFLAG=1 > > %make_build -C flag1 > > %cmake -B flag2 -DFLAG=2 > > %make_build -C flag2 > > > > %install > > %make_install -C flag1 > > %make_install -C flag2 > > > > That still works, CMake processes the _last_ -B set, just like Meson. > So if you redefine it later, then everything still works. Yeah, also you should consider switching from %make_build / %make_install to the %cmake_build / %cmake_install that have -B option, so it is consistent across all your cmake code in the spec. > > > -- > 真実はいつも一つ！/ 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxI0ACgkQEV1auJxc Hh7Y8A/+Pcf+MMN79+wDAx7UymW2f5/fxq1gW7f/2KdXSpDBMNcV5xgn8V6b1Z1A nodEQ9PoCOLv7V/q2LZlk2QGs62eQxFWIbTSpCkzCGK1EXLgh3WZ8L1fVH09KYHl NA+eg8FjeQp4eq2wXzY4v3NYhmnJJke4W/WiiaUDZkDQIBRpJ0Wz3ivSQ7R76sH6 lwcNoaN8bGKgetv1WhyWw3BreybCQxigfDzdDHAwt22HGBo5DEkoiw5cx41gLqUO wewpxclacLEMfy4VXkdDQqAuLdSOfwmFFBold3XSyMUm63bMSQx8lDn9bQW21y4a etD0PuW/QnMbWiWQNZIgtNWpj1yD+igSDabDxzRQxHNRJ2Klft32JREhf49vxbha IG0tkzfHpeVy3p7SF6VDvkeCXoqfQTKvBO0ciJA9EZF2LleufSoYOgh16Ip3ZSCU mU6uhyPTg07dXijo0cgdEVzteLHR1+oDbxdbVldL3AKqJI+Tq9O/PQU/WcJulEtw iBNoCQLJWaqeZyMheYtTEMq4No5zHBXnsV8Hs2l/gz5DNr7k+yugP07ne3XSPG4U vRBMGoWNa7DcD9PNcSasQuHvlWoWNfz8/nrO7L5ec0/ss0FmIg5oIWoep/oSKZ7J apnQ4Xqq5ktibkpyQvX811Fsy+z2ITLN144lsOqOjLF2v1ByLWQ= =mBUP -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
> %cmake?
I've just updated the change page that clarifies this question. I'm
also surprised that %cmake_kf5 does not use %cmake, but we are not
going to change this as part of this proposal and leave it for anybody
else who might want to work on that.
> 2. If a construct like this is used, I guess we will end up with a
> VPATH
> inside %{_target_platform}? So the -debugsource package will have
> a
> nested structure like Russian matrioshka puppets or Chinese boxes?
>
> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are
> doing
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit
> from disallowing in-source builds, it is just a simple special case
> and
> normally requires no extra code to support.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxS4ACgkQEV1auJxc
Hh6VGA/8DTF4GLhj8yAJVQNn3JA7UyrYKlx89aHpxCQVtJg3SqbnwvZVHwrl2LHx
cDhnbYt7KmzGkVkG3iapdROBXFED80zXaGm4BAOZF9YXUQyphpaker4NkIyjfksx
GE2bD77ZlzP+5bBnSWSkJ6zJtdxVf7KK81V7jOV0tD2DkDJp6VjBvJJZ009PKZha
Exe5cr1bbALT6+j4IQTjTZOAiqxpQPZasb9/5VXz7G+J79ATv3kBpueoJpShba/t
BcTzdUVihBll5jS6BJQkFUhdfjb1kjZ4YndZ7aPSPnpNJFumYEyfkKrm+yIjlkA2
aaSL5Yy0RjHB8k+Sixftvc2sCjbtU6QhRYOOyxYpXXiHnHrev09YD+H2CzR8/FMf
e829Epm2eUDmKA4JEuCWNTwpRS+KZ+ga35GhVWsBzFecSQT8pGaz2Bu9teKZevR0
pnAzlxKt6VnXBHRWj1DtcoNUQbkDNI3/Nu25XwY3GsR/jjYNUl7Z6/UgtJmuodLL
1AZ3P9okMFofcevkD5rI+QPAG2SfEOGZd4ONZBZ9PP3w1gDWM0T0BojFGXYhZ19d
GGxlYvYKf0pmcAiKuoERJ8JFKC8HFYR6Nj2MzLX4odGHAkwAdaeht1LvZVkgNeDb
Ptt0GmxIUt0i6swjXgVvvIQH1G4fTsupXd6ZTgPwQzWNvXosoc4=
=qwEu
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: undefined symbol: pthread_getattr_np, version GLIBC_2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote: > Could please check what version of glibc has been installed during > mock build? I can;t find the logs or the build artifacts. > But by checking other build yesterday I can found that glibc in koji > build is newer than the one on my computer (fedora rawhide x86_64) > I think the problem is because koji is using > glibc-common-2.31.9000-14.fc33 for f33 and we can only get a > 2.31.9000-13.fc33 now. > Maybe wait for mirrors to update (and install new glibc) and retry? That's true, but I am surprised that this is not handled by symbol versioning. This function seems to exist for long long time, so why did it break just now? > > Igor Raits 于2020年6月16日周二 下午6:11写道： > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Hello, > > > > I built gitui in koji (f33) yesterday and tried to run it on my > > laptop > > with Fedora Rawhide today and it does not work: > > > > gitui: symbol lookup error: gitui: undefined symbol: > > pthread_getattr_np, version GLIBC_2.32 > > > > Did anybody see something similar in other applications? Any ideas > > what's broken? > > - -- > > Igor Raits > > -BEGIN PGP SIGNATURE- > > > > iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc > > Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY > > QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv > > MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p > > NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn > > faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In > > h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1 > > nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn > > +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU > > bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS > > a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII > > mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI= > > =tZrU > > -END PGP SIGNATURE- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxZIACgkQEV1auJxc Hh6raw/+JA4UnrNHd3x/adWXtrpJis3eQTy8pzFiyLIxzFZlUGS/RjVeuK77ESsO DiphTp+9KXZ9QsWJqGlQuO1Epa1WnAYQGXZ3QEBuHgGIdphjEUePAj1+BFoAVVmK VkRsLEvySJnyMrppWsODYMVfMt5+sHrBtCvT3HSqjoc0CfKK20WVZ8Sf3tNSm44W twTswCRCR0B0G9oF0m99ql9AktwIKs1SbilGclpx05jGGTm1pwSS7G4RbMzEcO9i oElH8vRrT9OifESPIIHYxnvP/2zXt3ltBNmR+1jMB8qeISeK1CKqF41q7VCHtcS8 DSPGG7kXJUQxHMlA01VAl3+kcKetPv+0y9R9g4Ymzb3vaTm3b1MlJwrfZtA3/8jv BzeQhjFR2ANWV4tEHUvA06FJQV4kPfy7Y1adxeXD0me5VxMOvEPNmB0oCNrNDn5V IJlHMpqWX0Bbpa34NUu744LQcM7GyaircD4whLbG4uWHqbHJ3i8rgx7XGsPeKrAj kjhsFErKUk+R7/7/7+BFnOU29w63ZjTWxf0hhxVJ3KVrSmUQ0Xh0Fsv1flR8KzFa lvkCMC9Wd3+uG+dFla9X2B6BDGAKkgQdmlXNeKoulz57TCP3Ai43buYzFEpFGJrD 2HUuJp+qUAlK0/0Fh/0PEzhBwtIYUZv7iwADo5EcV1UUkaWLWYg= =tvmS -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 18:54 +0200, Dan Čermák wrote:
> Kevin Kofler writes:
>
> > Michael Catanzaro wrote:
> > > Kevin, the goal is to *simply* these packages:
> > >
> > > mkdir -p %{_target_platform}
> > > pushd %{_target_platform}
> > > %cmake
> > > popd
> > >
> > > It's four lines. We get to simplify it down to one line. Proposal
> > > owners are provenpackagers and say they will try to fix affected
> > > packages. Fine by me?
> >
> > In the real world, it will end up as:
> >
> > %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> > %cmake
> > %else
> > mkdir %{_target_platform}
> > pushd %{_target_platform}
> > %cmake ..
> > popd
> > %endif
>
> Or you use the new %cmake macro only in the f32, epel8 and master
> branch and leave the other branches as they are?
Also note that %cmake_build and %cmake_install will be backported to
f32 and f31 so you won't have to care much whether it is in-source or
out-of-source. You can use those with `-B %{_vpath_builddir}` to ensure
that it will do out-of-source even on older Fedora versions, otherwise
it will behave slightly differently but this should not be a big
problem.
> >
> > i.e. 8 lines instead of 4, and much less readable. Most specfiles
> > need to
> > work on older distributions too.
> >
> > Kevin Kofler
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7o/DQACgkQEV1auJxc
Hh65YhAAl2Ym9ht9817hcXRiN1cIMqRceUITnG0TYZNco0ipKbWGIEeF44g/kHw1
coQmthh4J24a5vj6/CgXGozm/InpSkwiitPfsdrZ5rjtdafk83DGeVbEpNvKPu4/
5DngvInCe3K1/W0JyyI9uA2PtXrbnW7QtZfqu7SrKarCReQSwiCFfpAwEpKgq7Ma
xK2/Sidwtz6/wohrEYMs+FEtmzq+8YbkunGza3IKmFOolGGsZNyTmHya5LFu+AuM
VOgmM6LbJdCtgHFYgV0Ag/fvK3ftkIuXPRCiGriO/VRXY1QGnrnLcJXAgdycF5Th
L9HMPKQsLXWD/CLo0dOAZSRw8ls9JQgwste3qMZuE1RimpIyO1UsbFpbEpOJsjb6
ZrYoKPfrVSYhIndfGhTthujkrwAY6lGd33D6YMN8vpZXMCqiYwRS9iJp3tREejFO
dmMsc24BiXCU3pusINakVDc8pAM1tUmP7OEIAFJkl7jLAv4sDXh1tJRyOr6RkS70
fQmvBE7UPs6zJ8wHwGmwbcOoPjemnbZUltmiXM5nIQ1o/Mqx6uP0QwCnOhOd+9tX
4w9fkxecunk0sAWFscaHWoE+wIiDMfM48FWJRKQXdRYdN5g/jeKrBqanK0N9RiI/
46xgJZyGTXmhKjAkINyEo1uw0wFHr7imKLZgmJKDTrhFQGwBReQ=
=9at0
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 01:38 +0200, Kevin Kofler wrote:
> James Cassell wrote:
> > If you're doing this, might I suggest reversing the condition so
> > the new
> > way is in the "else" part, hence "default"?
>
> The problem is that this results in a counterintuitive &&, as in:
> %if 0%{?fedora} <= 32 && 0%{?rhel} <= 8
> (by de Morgan's law, or if you want to analyze it directly, because
> 0%{?rhel} <= 8 will always be true on Fedora).
%if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
> > I've run into issues rebuilding packages because there was such a
> > condition from a decade ago and I didn't have %fedora defined
> > because I
> > was trying to build it for another distro. (Common issue amongst
> > the ruby
> > packages.)
>
> Then you will always get the conditional for the oldest Fedora (no
> matter
> what is the %if and what the %else part) because 0%{?fedora} will be
> 0, by
> design.
>
> The specfiles in Fedora dist-git are either only for Fedora or for
> Fedora
> and RHEL/CentOS. They are not expected to work on any other distro.
While this is true, I know that some spec files are taken as-is to
openSUSE and Mageia. So it would be nice to have same and simple spec
files that work across multiple distributions.
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prRMACgkQEV1auJxc
Hh4Hqw/+P6sboNTE3HXfqaPGiG06rzG69crm4LcDaDP2iwOHbXE43wY2+/gTNIaW
pl4hjIcoVH9ANJMQK56bvqHZYgl2z2PZ1MrlYOlAWVOi9CgDRqAX5toS6ivXiBWA
FbcDVWrYtbM/AL+Md0FFnEjjEZvAbXMBfDwAYcQc1Z/tjFHVYW0sCLg1H3XkZe21
3x3av3RH6TTrd7BQWa7DalRv5DJVbrrIqwpRwZmeiK9L2w2vJXGfkLKBQ/Tm0v87
SUZQ2OE+MrgGkF9CxW9z4rmSPzeQyNSAycL11SoyIBxXMIqnUeL/GdezK7mJaofS
PSlSz4hljSZqI+4kRbH4FMB0CSJz4xIJzGL1DAw0X8W2SzWoM69n3r7z4TQtX9Tv
jAf7MxSmY7mhDBnP6ePS5ecTOdvIQ5T0fdqUy8ATqLjnb3gq+2TVQJeF1eezHuMx
/E7OfLXczqpeg/vs0So4T91b2/lW/7zJicG+81Vw7efDHBJPMpp0YxXpQr8MOwwz
ALVG8OZU2KuYQnZ6OyJi3xB/3P2MDkPjq0G5revzmzirq6IkrB4d8CuuK8jq4gI7
wS81Re+Z0jU9oUKnT+5nUsRu6dC8iTM+j6qrCMGvhif1wgKlOM6FtR7MysZCwH34
ll+OXRvryP7QnRwacpDneh1OGxBz6JzBLXVdtsz5jWdErOFb4TQ=
=QAkM
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 15:18 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > The correct way of doing out-of-source builds is to use `cmake -S . > > -B > > builddir` and not cd/pushd and other things. Sadly we can't > > implement > > this enforcement without breaking packages that do `cd/pushd` but > > we > > will fix them. > > The pushd approach has been working since forever, which is why it is > used > in all templates. -S and -B are more recent (and redundant) > introductions. Right, they have existed before -S/-B were introduced, but it does not mean we should use old method forever just because we've used it before. Also they are not redundant. cmake [options] cmake [options] cmake [options] -S -B The former options are trying to guess whether you specify source dir or build dir while with these options you get a consistent way of telling them to cmake. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prksACgkQEV1auJxc Hh7sKg/+O8f1OiUT14JlBcJQabX864VfxfnFfzv4jnS22WiXdxlZ9pv3GP6sQQed vU+Vo0Hmq3v0Qf45qaNLx5pN8foYFD3zgTeSfTaDyCeAWvmebsiXbGEqmSXaddP5 Jdl89aAWg2UzwetYv3FrNqZkl9iVhEWLmFRBdoJ5DeVrpr3iovXM3Falu7GCsFMa zQ8CJNB4E/r4cLQCXzUFkfQMH3hqcg/v5XmWJvLmNm3lFhw4smrbI2f7g5MydXFH 0d+3MNpE+QjqLKXpLGqtKMkq/uFhmREOakwBDwJoJ5mQz0lw5JltVOnF0T/nbJIv T2Aqg1FK0sQF7CtsJP+dKfVfTeIRJ0VPtloF6UUiQAGgUh4/m85zgscV6UKETSoH H7CsN26yU064wVsYG/t3N3DM40/o/H/fweA3Be8UEhb8OrrLcwt9jvbMSVOSvsjQ UKwaBiaV7hXdC3pYrTvG2XZ/X//+jTM70yY1dV/GkBgUEvmt3CHvRtqqNAJrQEdR //JdXbzTZkLMamRFE0CBQ5uTG5zCj2u7boG4ZFg18Y+uO/DKBjT7AVMnKE2YtfuX c//lRTlbTgaeEGPPlqVzZo2lNKYthvyIk3Yq28Oi3mOAtmk8i3+E5lwkFP8JwYHa X2V1qMh+yOvvZDXR0pHJY3mXKMLLzggUStNxIzUk1toxt8/2uT8= =dOuo -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 23:52 +0200, Kevin Kofler wrote: > Dan Čermák wrote: > > Or you use the new %cmake macro only in the f32, epel8 and master > > branch and leave the other branches as they are? > > That requires maintaining the branches separately and not fast- > forwarding > them, but fast-forwarding is the most convenient way to maintain > several > leaf packages. > > We have had the discussion of whether to maintain separate specfiles > on > separate branches or use conditionals many times. Both are allowed, > and > different maintainers have different preferences. So trying to force > maintainers to do things one way rather than the other is not going > to fly. > > So I think pointing out that a specfile "simplification" can actually > be a > complication in the presence of conditionals is a valid point, and > "don't do > that then" is not a satisfactory answer. As it's written in change proposal, we are going to backport %cmake_build and %cmake_install into older Fedora so you can have same spec file across all Fedora releases. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7pr6AACgkQEV1auJxc Hh7REA/8D+CczSJ+Pv4f6ph8lqYIH7Fh2AH7//2JwFD3gA7/AEZrL5+Eig5ZBFQq MzEz1Q8UPn5qDGrH7/69WBrCiOigg5jjs6L2sAVmkRyXIvycueOVZtW6DQMWgmfw Gp86SO+EHFF6csAq7bTqHFfFypyShVz9DgBZw2KqbvAhUxHx/M5ubS/WqGKEmFIs Ro5y0gEzEp3P7fjevDG/H3J/5s11jo/zFCrO3snNtZqc3aLPR0BQqre2JOUWLjYl YcFqKaaQXVKhSEiX3GKe9MsPqARI4b2Y/RhyCJ7SxkfgywpNAWVY9Iy+eCV6jaPe ZGZvpa0vxaOduLkvOO7h3hYgTdtAd95uPrJHWFKJrpjCpYAC81nGnuLEXZRuKBvl 04wwPUFxlXUQALPEQvX+HQeY+XKkecjEuUpmyd5HtsYQ2oMWdB+hfa/Kc975F1Iz 2RC9uGNsnAuGQ7STMG7Gvcxx0Ik51/cdvH0DV+jjaUbBBb1WqxNaPJ79n0YTXnt0 2GYMHzC5UE9Mj05PJzfUZSwh2+hHyi4vQ7aW5z/m1fUwP+AfaenOf/8HkP2CKmUO 6wlgcQO4m2SB8mwjiVRwKmbORyBzu5G8aXs40sFXfEKOlEv6hZFsv8D6Mqry9qfy vvdRrOx2Qn60s1Kw9TKUdhAafdzfRhL3CXIWm6etqfSsAf2sqh8= =pqxm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 23:45 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > You can also do "%cmake -B %{_vpath_builddir}" and that will work
> > on
> > old and new distro releases alike.
>
> Not on really old distros, because it requires CMake 3.13 (2018-11-
> 20):
> https://cgold.readthedocs.io/en/latest/glossary/-B.html
It has been there since F29, and now oldest supported is F31.
> (The undocumented variant "%cmake -H. -B%{_vpath_builddir}" should
> work with
> some older versions of CMake, not sure how far back, but it is not
> documented and may break in newer CMake versions.)
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7psAsACgkQEV1auJxc
Hh7QLA/+IjUXol0e9378X5q+tAMoZZnvXJDEeEeCp5TtT4SUY2kKCs5gKneCK8Gc
bQTrw2opo+pTn4TxFz/oo1RzRcP5wZ3LdmKp8w2e924tmzQAsE3LXlaS5m61zC06
S9K7kg8ANMgwBe6um5ARhgMR4F19l+nb3jvfhbn/wWCxlAK8O7mWJa01f6HLFh1z
S49JZXCd+Ivn2CqE3gDViFDU4pPsrraWU3h36ttEvYj9T7cZZnLFWdLI2dAxh5xO
GVNBkGShodo0+qCaGBzl3Ky5IJPOBZvLyekfYN3jZz0hqav/0UYMtdFzBmAlHBCv
bfz9PzTBiA+LA8M3TF1VMPaGFZO/BuGgRhJ4/tIn9f2iea9RRjK0O5kLNMxCy9Y9
7++Hvh5s0fyccnxrYI67Hop8Jwt/O1dBIVfxpdiAR0NCuwWq27Kwn1oFMLV66V4x
ISrUeGyQXhcoDmbN19CywyhklTBilu+KNo0o4D7gUcsyczrfzeGa9fBulMWZfoUa
gx9uTtsybaYtGx3L/O2Fh9XC1zkvMTBNFsXPKjHo/9u4SAwGuE91JT4OEaUhdQVq
9pmNSIy3hUgJwUr1BpiqJ+hWVGNFsjiq8cWuhmdKezUQiu9jR7gMJ7uAhcYH8Pfu
jjFSI3Kjd4g/r9RUMxNws+jI39v8IgEQU3tLjlA9l0Jb+QJU34w=
=CMj5
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: Regression in build_make macro?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 20:38 +0200, Andy Mender wrote:
> Howdy everyone!
>
> Some time ago we discussed the misuse of the make %{?_smp_mflags}
> construct
> and that one should switch to %build_make. I tried that and all of my
> COPR
> builds failed completely. Here's a log from one of them:
> https://download.copr.fedorainfracloud.org/results/andymenderunix/7kaa/fedora-32-x86_64/01475167-7kaa/builder-live.log.gz
>
> Is there anything I'm missing?
Yes, the macro is named %make_build :)
> Cheers,
> Andy
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7qZRwACgkQEV1auJxc
Hh6/lw//Uv0vPPdZTVJHLoihzMytEGX1TLcot4kY5+Oa4Eq0VXrmFbXfVAWWCApG
iGCEnVYRiowTAFpwZBzQlyOk7HqAwcO15BrTawDz+acwmF3TvcqM6ugBTVLhad27
ys/Q7BmFic2IGBRB/jBiYHK/jLMqcGc75ekk0a0TSfduj3si5SxvU5o9HcdDUnHr
oH9vEYjapk3RoDPekxFu70B2nd19aOKEJyQoo885HkuxKC+KTHpWqz6ol4Y9cWED
qq8Vp44VbV422q6xpjP6aaDM2xKvyaoPMj5R99+Y5E4nTY9lwKMHy0Vr3kIEun7j
XhzDJjvdkOR9jX4njflZKVf8nPNbG8loBczoL2ZuSUXkfmKb+vS1mw3E3vMkyq5z
beYtF8bYk5/N+HJw79EWJXxE8OlqP/a8ToZXF5CvdFxvJEXrhRe63THvZSr0wYYd
64HeECzbkkkOxf1vrf4wm4SIgAjYZZ6fezbXnWDp+UqR1qgtkbt1ifwKJW7Kj4Hf
cZ7B+1dfjBdve4PU4CtUXU8/hPVw31Sr7ab4+peauVDkjuFjzPzDcuKkJdZFnwoe
2Mdzskz4fW9MefvHODKMq1iNZKbcVF95MerHFKqVWwaioZlgWh14R9ewLv/+naTU
NYgGnQFTfYtOmIoJhWqbshBcGD/MkeyUxeorb89lSmSyd81EuDI=
=nh0b
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote: > Hello Fedora Community! Hi Josh, > I am a long-time Fedora Community member, and may be familiar to many > through previous FESCo or devel list discussions and passionate > debates. However I write to you today with a different community hat > on, as a lead Architect for Red Hat Enterprise Linux. The RHEL > organization has been following the modularity discussions within > Fedora, particularly around ELN, and often the question of what plans > we have for modularity in RHEL 9 has come up. Our Fedora Project > Lead > and a number of FESCo members have reached out and asked if we can > provide some perspective here, and I am both happy and excited to > have > that opportunity. > > As the Fedora Council has pointed out [1], we certainly acknowledge > there are improvements to be made and have a team already working on > them. They recently outlined their plans in conjunction with our > Product Management team in a Fedora Council call as well [2]. We’re > continuing to invest time and effort in this packaging solution and > are confident that the team can deliver against their plan. It is > somewhat of a new experience for all of us when Red Hat is direct > with > our product intentions, but we discussed the larger gaps we see with > usage in RHEL and are putting our efforts towards solving those gaps > with this plan. > > Modularity is important to RHEL and those efforts are already > underway. We will be leveraging modularity in RHEL 9 where it most > makes sense. This is primarily centered around our Application > Streams concept, which has been well received by our customer base. > Providing a consistent but improved experience is the base > requirement, which allows us to have continuity from RHEL 8 to RHEL 9 > and lowers the hurdle for our customers when upgrading from one major > version to another. It is nice to hear that it is helping to solve problems in RHEL (even though I've heard many people saying that it is nightmare now). Is there a list of requirements that you have so that we could potentially develop something that would be useful to Fedora same as for RHEL 10+? > It is always good to push the boundaries and search for better ideas > and improvements, and that is part of what makes Fedora great. We > are > doing this in the context of the RHEL 9 release as well, so our near > term timeline and requirements mean we are working on evolving > modularity, not a revolution or a replacement. We are excited by > ELN, > as it presents a possible space to allow those that want to continue > to iterate on modules a place to do so without necessarily impacting > the broader Fedora distribution in its entirety. It is my personal > hope that we can use that opportunity to improve modules and > modularity in the open source, Fedora-first way we’d prefer. Our > near > term effort to improve the existing modularity implementation ahead > of > RHEL 9 needs to occur, and we’d like to do that work in Fedora, > rather > than in closed product development. Longer term, we are open to > contributing to a better replacement that meets many of the same > goals. This is what makes our distribution ecosystem work well, and > not having that upstream lessens the value we all get from such > experimentation in the open. While I support you that we should do it in Fedora, does this essentially mean that this technology is useful only for RHEL and you do not plan to develop it *for Fedora*, but rather *for RHEL in Fedora*? > Hopefully that provides some context and helps FESCo and the wider > community understand where Red Hat is headed with modularity on the > Enterprise side. Sadly no. It helps to understand your plans, however it does not help to understand the reasons behind, whether you can't change UX in the RHEL 9, or you think that technology is good enough for your use-cases or any other reasons. Basically this email just says "We decided for Modularity in RHEL 9 and we would like to do it in Fedora Infrastructure first". > josh > > [1] > https://communityblog.fedoraproject.org/fedora-council-and-the-future-of-modularity/ > [2] https://bluejeans.com/s/W_P0D > ___ > 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 - -- Igor Raits --
Re: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-18 at 09:24 -0400, Josh Boyer wrote: > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote: > > > Hello Fedora Community! > > > > Hi Josh, > > > > > I am a long-time Fedora Community member, and may be familiar to > > > many > > > through previous FESCo or devel list discussions and passionate > > > debates. However I write to you today with a different community > > > hat > > > on, as a lead Architect for Red Hat Enterprise Linux. The RHEL > > > organization has been following the modularity discussions within > > > Fedora, particularly around ELN, and often the question of what > > > plans > > > we have for modularity in RHEL 9 has come up. Our Fedora Project > > > Lead > > > and a number of FESCo members have reached out and asked if we > > > can > > > provide some perspective here, and I am both happy and excited to > > > have > > > that opportunity. > > > > > > As the Fedora Council has pointed out [1], we certainly > > > acknowledge > > > there are improvements to be made and have a team already working > > > on > > > them. They recently outlined their plans in conjunction with our > > > Product Management team in a Fedora Council call as well [2]. > > > We’re > > > continuing to invest time and effort in this packaging solution > > > and > > > are confident that the team can deliver against their plan. It > > > is > > > somewhat of a new experience for all of us when Red Hat is direct > > > with > > > our product intentions, but we discussed the larger gaps we see > > > with > > > usage in RHEL and are putting our efforts towards solving those > > > gaps > > > with this plan. > > > > > > Modularity is important to RHEL and those efforts are already > > > underway. We will be leveraging modularity in RHEL 9 where it > > > most > > > makes sense. This is primarily centered around our Application > > > Streams concept, which has been well received by our customer > > > base. > > > Providing a consistent but improved experience is the base > > > requirement, which allows us to have continuity from RHEL 8 to > > > RHEL 9 > > > and lowers the hurdle for our customers when upgrading from one > > > major > > > version to another. > > > > It is nice to hear that it is helping to solve problems in RHEL > > (even > > though I've heard many people saying that it is nightmare now). Is > > there a list of requirements that you have so that we could > > potentially > > develop something that would be useful to Fedora same as for RHEL > > 10+? > > The dnf team is working to gather those internally. RHEL 10+ is > still > ~5 years away, and while we're working hard to develop our product > roadmap, that's still far enough off that we haven't put much down in > terms of requirements :) > > > > It is always good to push the boundaries and search for better > > > ideas > > > and improvements, and that is part of what makes Fedora great. > > > We > > > are > > > doing this in the context of the RHEL 9 release as well, so our > > > near > > > term timeline and requirements mean we are working on evolving > > > modularity, not a revolution or a replacement. We are excited by > > > ELN, > > > as it presents a possible space to allow those that want to > > > continue > > > to iterate on modules a place to do so without necessarily > > > impacting > > > the broader Fedora distribution in its entirety. It is my > > > personal > > > hope that we can use that opportunity to improve modules and > > > modularity in the open source, Fedora-first way we’d prefer. Our > > > near > > > term effort to improve the existing modularity implementation > > > ahead > > > of > > > RHEL 9 needs to occur, and we’d like to do that work in Fedora, > > > rather > > > than in closed product development. Longer term, we are open to > > > contributing to a better replacement that meets many of the same > > > goals. This is what makes our distribution ecosystem work well, > > > and > > > not having that upstre
Re: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-22 at 09:19 +0200, Petr Pisar wrote: > On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote: > > Around the idea and concept of modularity... what are the benefits > > to Fedora, > > Fedora developers, and Fedora contributors? Through the various > > discussions > > on modularity, nothing solid in this regard has been presented. If > > I am > > Fedora contributor now, what can modularity do for me? > > > It can define a build order among packages of a module. For that you don't actually have to design some special format. The buildsystem should figure this out on its own. And there are such buildsystems that do that - Open Build Service. > It can change RPM macros in a build root (including SRPM build root). I think this is not really good idea, but again - you don't have to invent new format for this. Open Build Service allows you to do that in a project configuration. > It can use transient build dependencies (a package is built, only > used as a build > dependency of a consquitive package, and then dropped and never > shipped). Same here. > It can build and deliver a package against multiple exclusive > dependencies > (e.g. for different Fedora releases). The same thing. > It can build a package from dist-git sources that do not depend on a > Fedora > release. Again, same. > (Teoretically you can build a module from non-RPM components; I've > never tried > it.) > > -- Petr > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7wdP4ACgkQEV1auJxc Hh5iiBAAsdv3yWu6y+Un2LIGFcAomRmwijA3C3aajdNXDHWO3mco/MYDukjPVMIl FHO7xDg13ZCvxQ+AsKyVjJwRXI8ugyLatLBTO9sXLUw8LBtl36RfH/P2wXYCA6kM kB1aWYxxBlBLuZ2cJmyYJHfXEtOFDQHz1gORIX5HyXnL/asXOPwgeh+VjYGnNMPn FHSGCelFrW+aRU8E6vxxuqNrqFwZwXbv3ccHEJIihRMeFKoGFqfDRy/KMQFQ7zZm NagszNoFpfAhRLEqRYaHg3GR0Kl8DYlcJCNJrXmoBdlu/nlDy2soOOzs7PiiFtuN izdZeASITvpcBvR5h/wt52IZCAGP/G/YmSZE73LWteBZhiUBimuAzl1cAEQWfPBc /y8/mdMXaGAKtQcWZ8ZZNMXYqpyR2Ahrl13fK2XwFBcyi6/mnCsX27KAlczhdnlS siBzxyQW8PBvcbZdWF2XlR4W39RHH+EHdIHeeHdGauc+Oent6xObXVW9HIp/Vvkh VH87cdSBPGiJDmZMXBWs1QqViTHzxSlyX8PI3bFxFoYA+7ZwrER75hQnKNN22Or+ Bfl5i6EHtReatUW1uxtmVODON5hZ8fcxi8v6prjDAGTUMWHHkb6f7tcR1dH42/Sf 1OLXojU8gYMuuY/ooace7zto5ByfIJT0ViUFi0eV0qvG5w053D8= =iMXG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Schedule for Wednesday's FESCo Meeting (2020-06-24)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-06-24 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F33 System-Wide Change: Aarch64 Pointer Authentication & Branch Target Enablement https://pagure.io/fesco/issue/2403 APPROVED (+6, 0, -0) New FESCo rep to Fedora Council needed https://pagure.io/fesco/issue/2405 dcantrell willl be a new representative (+9, 0, -0) F33 System-Wide Change: swap on zram https://pagure.io/fesco/issue/2408 APPROVED (+7, 0, -0) = Followups = #topic #2390 Request to permit module default streams in ELN https://pagure.io/fesco/issue/2390 #topic #2407 Find a new meeting time slot https://pagure.io/fesco/issue/2407 = New business = #topic #2409 F33 System-Wide Change: CompilerPolicy Change https://pagure.io/fesco/issue/2409 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7yPJgACgkQEV1auJxc Hh4sPA//em6sOv4mugq2qEcya409mXHp6Q19yWMp44rYjyeAgVv/TZzQceol2IxG mEMfLpI8qsE1COyP7+IOBVqmfHhpBNVN0Fjy7hCnpcWfRiiRqgN4ZYva5eZIQdI3 YJKQe1Uh2/wrJZcplaP8aa7tDL4KlV7zDd3IvULRle1TBtYGU3byTCYxHeXmj3ou ldKL86tpcc6Vyk3eh1qb4iiwEvKDOvQT1WRLYq7wUxlj6DIofvrNxwsNcs8JEr9x kv2JhRxtwyI2qxgc+mHshYNg+DD/pZiotkNjJSUeRzfNUxo+jP8VV9V4TogfMMR/ d8XKx64QfpkGFggeHPU5vOJMc3VL1hVJUu7QPbqh+eDXt7/H9IpGxlAzipYHdf1X blwFYttl0ng8RqrVuzFONGcic0UF+SSW5cSC88mGd/VxIUZ7UwXmSSh8E0LV9fNF dvGo5cY4IFUsssxuI/gGvPE2y6XlNH/Fptb+TZKaC/xPNB8F6qUUBqAVFxDUCrC8 KTr301JqK5rgVzF+dlJalOI62uj1hLyIcfFjSQLUM63KbLvo/FXfBenu9efG5FIm Uh3g/9p9ungJvJX+BI/0LHVx0aBN/oRFfxcJ3NjfoeUESj9dOF5QujXXyNPFqKXV ssS6fnnuIGfO52ozB7396CxRfP7jUKEm7lsrHuraTiU2vFoBksU= =G87X -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Summary/Minutes from today's FESCo Meeting (2020-06-24)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = #fedora-meeting-2: FESCO (2020-06-24) = Meeting started by ignatenkobrain at 14:04:37 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-06-24/fesco.2020-06-24-14.04.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:04:50) * #2409 F33 System-Wide Change: CompilerPolicy Change (ignatenkobrain, 14:07:07) * LINK: https://fedoraproject.org/w/index.php?title=Changes/CompilerPolicy&action=history indicates the proposal was not updated (mhroncok, 14:08:44) * ACTION: law to propose PR for the Packaging Guidelines and we will vote again once that ready. (ignatenkobrain, 14:12:46) * #2390 Request to permit module default streams in ELN (ignatenkobrain, 14:12:56) * ACTION: everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo (ignatenkobrain, 14:18:02) * ACTION: sgallagh to submit Self-Contained Change Proposal once ready (ignatenkobrain, 14:20:36) * #2407 Find a new meeting time slot (ignatenkobrain, 14:20:45) * LINK: https://whenisgood.net/f2hzskx/results/gbhh7ba (zbyszek, 14:23:18) * LINK: https://framadate.org/ supports maybe (cverna, 14:39:25) * ACTION: bcotton to ask Council about moving their meeting to another time. (ignatenkobrain, 14:41:25) * Next week's chair (ignatenkobrain, 14:41:28) * ACTION: cverna will chair next meeting (ignatenkobrain, 14:42:12) * Open Floor (ignatenkobrain, 14:42:20) * LINK: https://fedoraproject.org/wiki/FESCo_meeting_process (ignatenkobrain, 14:43:07) Meeting ended at 14:52:17 UTC. Action Items - * law to propose PR for the Packaging Guidelines and we will vote again once that ready. * everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo * sgallagh to submit Self-Contained Change Proposal once ready * bcotton to ask Council about moving their meeting to another time. * cverna will chair next meeting Action Items, by person - --- * bcotton * bcotton to ask Council about moving their meeting to another time. * cverna * cverna will chair next meeting * sgallagh * everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo * sgallagh to submit Self-Contained Change Proposal once ready * **UNASSIGNED** * law to propose PR for the Packaging Guidelines and we will vote again once that ready. People Present (lines said) - --- * Son_Goku (60) * ignatenkobrain (51) * mhroncok (34) * sgallagh (30) * zodbot (24) * nirik (22) * dcantrell (15) * cverna (13) * zbyszek (13) * bcotton (9) * decathorpe (4) * Conan_Kudo (2) * law_ (2) * Eleventh_Doctor (1) * Eighth_Doctor (0) * Sir_Gallantmon (0) * King_InuYasha (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7zgyMACgkQEV1auJxc Hh79QA/+IVaJbzACBXQlfVYcjsnpAR3xsXAh+dKFg69nUi8ecml+8IdHJ+odJ2pa IC8uouqROHwhguhq1TmwYoBp0tWzCKRBmzQoSjNWIPR/UZrMumrX2B1dGktjYWxj nTOPtj+ZG+GemTPw6LyDwqkT35p8GOuwkp3m7s4ggSNi+63INf/EiJCT2f+hptRa u1GNo3dhALKzmu5/Q0HmDoJLD/4URO86Z33V+V7J2CB6UaN6WCFH0Pep07dTpVRW /aAVjmFwTCPD4jKI9PZOP3M6jFGDZ/0NAyDwsz+71/fNPVHk1UC/cApGp2OWtXAi PlwSqmg6s/w28UTDNqUnk/Tgz8FckItF/SrLAe9XflwN8oykGkx7Y6l6yKfiKBsh utFcuqPa8MIMNHLIOAVu0HVYoMbAVWJE/6ksftdpF0h0B0+tAGLHq+azewc3fGpk jDbqtL4Ai8z2xBHsgQJ2dzqTlPWX6r2WQyVaDdgJFU3AW2e4u+3+7dBYJwcuF/Av MsANV2ih5CTkxMLdSEnpZlCteMrRaDTlsjyScTZngysEajWAxCOQvozwPznPzEBX voT3CCUam+84795JnMtwutroIOYUL+1H2bDP2yU5dQTwcX0u7thkX9f+PI4Ift+b PJQfIMf7MVVLj4bg8HrsHL73IU++rFj0KZ2300yrog5UYt14GvA= =yN02 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Avoiding the automatic /usr/bin/python3 dep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-06-25 at 14:50 +0100, Richard Hughes wrote:
> Hi all,
>
> In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and
> other people working with low level firmware blobs. In
> https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was
> suggested we split them off as a subpackage to avoid the
> /usr/bin/python3 dep which is unwanted on CoreOS. It does seem a bit
> crazy to split off a subpackage when the rpm header will be bigger
> than the contents. Given these are such small files and certainly not
> warranting dragging python3 onto the image, I did hope I could use
> %{?python_disable_dependency_generator} to tell rpmbuild to basically
> ignore the .py files and not add a /usr/bin/python3 dep on my package
> automatically. Unfortunately that seems not to work. Ideas welcome,
> thanks!
I think removing that dependency is simply wrong. It essentially means
that one would not be able to use those scripts without dependency
being installed.
You should split that package and can use Recommends to pull it in by
default if desired, but definitely not removing a Requires.
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl70r2YACgkQEV1auJxc
Hh4O8A/9Hvo8dEqo0/yV2rdUr/v/OYwggwbWTVXHm4L8OhgRBGhhVPjI3vKYiumu
NsfgMmCNa5FE7MsYkFEg89CiJrbWT1+9JWxSDbtj1rFsh4OoDRM06Nddd6w3Kvuh
LPh0u7Rm2Jb1JD+V4U8GCinR2guIPsBHEDfdM87twt6UnuRBnZneURIXALIi7SBM
zO7BxcuxGGN9xn7V5UZA5771yfdIAoJNi0sndWTK7NehjITPTIwyESs/ReDwBs1D
ix58Ch7587kH7qslK6hWWppkYvyfxG/bMHlWuu/Os2bLKZtWmdAa1UlhPbxZokPf
U+UKZYSi31waUgN7o9aynRGt3Hj5ukrJ4HnJw+0Z7X6BHY/l5xAGlDhr1fS7he0T
th2Ta3EmT16taSlMhtn1EujnlW0e3DBf48WJyfUWLwntXu4uPxsZOef83ET+TCuA
Ch3UwD1XG31TgHI+8w7mlonh5wLxea+pEtUu0hMHa9RSejA3wEER9iYeGxz1c9Lg
k4UNTeeffTF+ryP3/zq2lbVE06ifrCkO20QQ/KR3YtjtI0HeAvCR7+hWNlPA+hnw
zcpJnkbo2COiwM6PsU7TFg5Dal8J+atbmIIOc81FMoj3fhi+BaiZnUSHkAqiU0te
2NMmPl4O2QFVfMPmmp+nmieu0sUNQP5QXiCUtxN5akqFsl0zbF0=
=fnbm
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-26 at 17:30 +0200, Lennart Poettering wrote: > On Fr, 26.06.20 10:42, Ben Cotton (bcot...@redhat.com) wrote: > > > https://fedoraproject.org/wiki/Changes/BtrfsByDefault > > If this is decided to be the way to go, please work with kernel > maintainers to make btrfs.ko a built-in kernel module, so that > initrd-less boots work... (it's kinda pointless anyway to have > something as module that is now gonna used by most people anyway, it > just slows things down for little benefit) Good point, we'll make sure to not forget about it. > Lennart > > -- > Lennart Poettering, Berlin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72F54ACgkQEV1auJxc Hh4GlBAAmKs/XoAYcj4+H8L1CAppzO4sK+4ubP7jRJ+f+VkSZ8jiDDzx/AgbDty3 byLFznYREKvqXWwTSm3cjvHl/8ZOoLCV5WGe7BMz6o6xqXfphDt0lVj1ZAbgXBoR 4BYOlMSqFI836nLMew1rR7ipOwpCdCVX60RJMPXurTptYOqIqp0Zoq0TRqqMOFTU zD2CYcMHkxUlWbFJUfUae2VylW3L9IWsBlOq4HpZl7HF/zeDgLUFlt8jaOyZBUwK plE22PaeZr5h0qULgJutlmeg7H2k8eF+Oa5a5ZAQQJzywoKtICJzm9NB9Ls1lvCC GAUYpE96cnimUZWa2zI8IhZ98x44hb5Yk5undGiw+7uDhBUFfdxbE9xteq8PL3X/ fk13RyG0YOMqn2HhS/F4xOgtENo4qmxpDZQEmnOd0mQ0IrIaYn9EI2FzWGNkYGlN Vpv5OZrVEFeWaFpeCSs/M2jQXyTLmPrO2pM8lHEPiw6p6n2Jq7izNOeEvU802tnQ /EFANvLm0toU2+eAaMLUQKMkIkUGfyCAuHrv2c2vZHfpkq+/9Q58P0DnL1A6F1UJ /kSTUbQEQJMKJxERGROC3JzIMJFKiVbmuKy8rQ4+OB4Un9I67jxoGpJmxQF1/RgM QHdlsDZEGXqsZh5bZXyv8aLW/s+8bByhmp+si0rT+HIQGbJNpnQ= =Yl5y -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-26 at 21:22 +0200, Markus Larsson wrote: > > On 26 June 2020 21:04:00 CEST, Michael Catanzaro < > mcatanz...@gnome.org> wrote: > > On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson > > > > wrote: > > > I strongly agree. BTRFS has been 5 years from production ready > > > for > > > almost a decade now, please don't force this on users that > > > doesn't > > > know any better. > > > > This is hard to square with the fact that it's already being used > > in > > production on millions of systems. It's also hard to square with > > the > > data presented by Josef -- the only hard evidence I've seen on the > > topic of filesystem reliability -- which shows btrfs is an order of > > magnitude more reliable than xfs (although we don't know how it > > compares to ext4). Surely if xfs is good enough for RHEL, and btrfs > > is > > at least 10x more reliable than xfs, that suggests btrfs should > > probably be good enough for Fedora? > > > > Do you have any real evidence for your claim that would be more > > convincing than what Josef has presented? > > Josef's server parks is a bit of a different use case than laptops as > other people has already pointed out. > If you want data on how it works in a desktop/laptop scenario talk to > openSUSE users about how many times the "btrfs randomly ate my > volume"-bug was "fixed". > > When I ran an environment of about 4500 SLES and about 5000 RHEL > servers btrfs failed about 3 times as often as xfs (this from our own > in-house statistics). That was 3 years ago but filesystems takes long > to mature and I have been keeping ear near openSUSE to see where it > goes. > Is this as big as Josef's environment? No but it is first hand data > to me (to you it is of course just anecdotal evidence) Keep in mind that SLES does backport btrfs patches because they support it. RHEL does not. And we are talking about Fedora here anyway. > BTRFS has the potential to become great, I just think it isn't there > yet and it'll take 5 years of smooth sailing to convince me. Probably you should try it with Fedora's kernel? > > > > ___ > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72TU8ACgkQEV1auJxc Hh759w//XHCXloEj6QAUNpVxCEljVwm1WQVl1jfH3p+mex1a5Dan242COXkVaEzy 6zR79EZf7ONg1dTU41fq1mg3gWkFAE/q+OD4cSJ/Jbwyt/L+L40MgD1h7UmNo0/P uytLZYC3BUIq9ARAH2DlYMHSQUcYZ8TOyrlxWUmkyqPnc99D9CkkqReRjWA/EtYi mVNOzCQwdMefSJu6+HZlFIhyYeyBbmfu/Q0v5uQE9CQbmN/AuyTHmWG3jRYTINxg 7w8vFPLwjUEmUno+i0Jvkdr4EqSZihV4ljoA0MO8OEADHamjnUOWX8HiFN6E6y+V cDXPvVTqdf7v+Hz6j6F2cUDbm6PQrbd5fODMeCVibuE5knDB587jRcrqXYfSp+wL 66VRnHXYrOAMHXKlcs+XpPxkqfy5AdgvkP63PUZTWb4yb4wElVVpFNsBf2wk7TXu kp9cKSf+1CSaIq0oD1uY9YB4Xm9elI3pRJJHuH8TrOKI4RsxnmjXdpXB+pzNf8BH 8PQex0mAwcvefiK0MfaJcl6cP9PgIvvAb75OoWulEsXGG9uPT1ZknYwgXPFN+eDs T5Wr/7957eiDDgYDtxPXQfliI58AtnCh1ysNcEf5vRLEARs3HLT8Mo+Z+o78ZvpG ZNYkixPYKGrGrUdLJzwXqlQAy6wlNXDzTIxPtrXy5DHMkuAAAqo= =2hBc -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 10:35 +0200, Roberto Ragusa wrote: > On 2020-06-26 22:13, Justin Forbes wrote: > > > Saying production on millions of systems is a bit misleading here, > > when you are talking about millions of systems at a single company. > > ...in a redundant configuration where losing a disk is tolerated by > design > and managing data that have very low vale (mostly pictures of cats > and random chats). > > Filesystem quality must be measured in other conditions: have a > Postgres > on it, financial transactions, random blackouts, etc. Do you run postgres, financial transactions and random blackouts on your laptop / workstation? If so, isn't it just for testing purposes? I'm not saying that it is not important to have filesystem stable and such, but just saying that typical workstation workloads is not utilizing disks that much (if at all?). > -- > Roberto Ragusamail at robertoragusa.it > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73B70ACgkQEV1auJxc Hh5sxxAAkRqwvcSoGHIK//W8rx3jlcpfWFQ6yVs16fDjWUB+Riv3YEcN8AuSkWAl OuW5ZcEu+kUJ2RZHpruqSFE69Z9IPIkjs9jbawkhFgU0f4F32I4NliLJj9+xHdpK p/KdzTf1tvKzy3hjxS7IDJEWJToPDAxjtdH8mD+XcXTFgTHiR1xS+sfPxPrMbIh3 jmySlx7ExSwixpJwqTljyK9xVK+1r8iA38vkr4DA2sKlm7cX3USQhQbFK3LsuOGz nWYy6oYkPWpcdGna8ETaZwfe3bwc/VMfJJtxFNZib3zsuRvsItuzhRle/OTB1r+K 6EXWbzpg8g7NzT3WwfpGlyC0G0K9VJkWFye7aBWSFNDi21Svr7565NyZFGXgJGnG 0mMZY68TAr8ybGxTf+1nPh8LK9alKJLmADgPhzenPUoRVlb6hMLGkwTNmgcEeD9g dhwao2eEx8TY4he+kVBXtTb+v2+AivTpV/iJT0gU9uRjtxuB4f+hqkuHnuS6fg7n YlOOqmexecc6kln008Xq5a8ayJoz/91XTR5fjslotesRT29FyLbkCJlvXRCvLxJW d0bVCtOdiKHZKamBzSlxWgr46R6J6eqyHlF2lelVJPmqKAY8QqxLOKF6hHM8KjGT 1RldNvsN7Muy5bd/s9uqqEeiMsdZ3EikVvMyOM0rurdIhIwxRMY= =TrQ7 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make nano the default editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote: > On Thursday, June 25, 2020 2:38:13 PM MST Jan Kratochvil wrote: > > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote: > > > > > I'm not sure why you think end-users can't use a free OS. > > > > > > First steps of end-users is to install Chrome, Spotify and > > VirtualBox. > > So there is left no advantage of a Free OS. > > > > > > > > > I've run with SELinux enabled for years, rarely if ever causes > > > problems > > > for typical stuff. > > > > > > Sooner or later something does not work. I do not want to open this > > can of > > worms whether SELinux yes or not, it may be a good idea but IMNSHO > > it is > > not for a development machine. > > I definitely agree on taking out "rhgb quiet", that's annoying as all > hell, > not knowing what's going on during the boot process. Why does the user need to know what's happening when system boots? > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73pqkACgkQEV1auJxc Hh5AUw/+I3C4LBRAV/JYGGg5TOVn/s4fNgl0ynNRcDDwOGeXJJsuA05o/gU1CWd2 WpnRYMWhMuGjunKs5/ZDxbLENlHsDgnkWrb82Lq9/bZnZwclqCTpWhJFMqDP0zQT FGjhvEDE5XyWoGanYjgI84MNoiTaBRzwaZnncUkfREx3n8RsF8sZWc2hdNynmJVR iZ2O+rsXzL5RfFDQwimyEFRjwlJC0J1baqxm+8XBXRf3/Y4X/YahyO2x6oDY8irO fYbbC1LOlaB9FsrC94uJB9BU8kY/cpZHA8D+CyNYakrCpqiciFwu1gnaqgj5mmtU JOtPbYOxyMb91JTfiyQnTP3MPMoSOQraMO7/VVefGS8LeW3r2dteH163gOSiNhCM bO7R1fusa4FZOUcKp9lbnv61GzbNZ6X1P63lVPLgd61YqcUUDwDdx2rMim+46j11 UxKXGLqlrQbW62EhQhhn3DILfMm37oj66GghE2Drln8l1PZ0LHH8v8I8WCwdJGZ3 hePvbDV7DMmMEt5g/HD1r/qaQSr30f4ZeIWGHFoH3sMepHGWr8uOBRDmccHoqyiE /uo4yPXiNOilcrTnb7db5aY3c0Ghxyh1LyQbqGC8BCUD79NBUo0BlTWgk2W5l19j uxrYusQH8GGv4i7Q1WUvVnAEjdMsgKaa8UwTlXnGEkvIoHU7ZX4= =c/Lb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 12:37 -0700, Gerald B. Cox wrote: > I was an early adopter and used BTRFS for many years, singing its > praises. > I was particularly interested in the RAID capabilities. Then in 2016 > the > bomb was dropped that: > > "It turns out the RAID5 and RAID6 code for the Btrfs file-system's > built-in > RAID support is faulty and users should not be making use of it if > you care > about your data. Well, the RAID5 and RAID6 in Btrfs is still not really working fine and there are some threads in linux-btrfs@ at kernel ML. Workstation users are not using RAID (even if they do, I am not even sure how it is configured today with Anaconda). Even for those that do, RAID0/1/10 seems to be working just fine with Btrfs. RAID5/6 is definitely not something that people run on their laptops. > There has been this mailing list thread > < > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55161.html > > > since the end of July about Btrfs scrub recalculating the wrong > parity in > RAID5. The wrong parity and unrecoverable errors has been confirmed > by > multiple parties. The Btrfs RAID 5/6 code has been called as much as > fatally > flawed > < > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55179.html > > -- > "more or less fatally flawed, and a full scrap and rewrite to an > entirely > different raid56 mode on-disk format may be necessary to fix it. And > what's > even clearer is that people /really/ shouldn't be using raid56 mode > for > anything but testing with throw-away data, at this point. Anything > else is > simply irresponsible." > > The current situation as I understand it is the problem is "mostly > fixed" - > whatever that means. > > So, BTRFS is great, ready for prime time... many people are using it, > etc. > etc. etc. until something goes wrong and then you get... well, it's > experimental and not intended for production. Sucks to be you. > > At some point you have to fish or cut bait. I was under the > impression > that Redhat had done exactly that with the announcement and direction > of > Stratis. > > Why are we not concentrating on Stratis and XFS? Seems to me after > waiting > for almost a decade for the promise of BTRFS to be fulfilled and then > having so many > people be burned, we should be turning the page rather than > continuing to > rehash the same old arguments. Well, because those have different use-cases? One of the problems with XFS is that you can't shrink it. With systemd-homed on the horizon, it will become a problem. It also does not like much when power goes down (even with battery on laptops it is not uncommon), two my colleagues got XFS destroyed (for one of them, twice) when they had to turn off their laptops using power button in last ~2years. Then they have switched to ext4 and nothing like that has happened again. But that one does not have features that are very useful on laptops. Stratis uses XFS under the hood, so it has same problem, but also it still can't be used as a root filesystem. And generally it is designed for different use-case than a workstation. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73qagACgkQEV1auJxc Hh7sthAAg+omUP71jyuAEXoy1/+B3m+OSikBEAxRS055en4JaKROLQ2UVJOSCzs+ KSJkg413ex8ORxH3l8vhnIlWCVXwV8de2duAt85DpknGe0XHpnLTtC45/xejUiln tjpz8RqyEYTXMEE7KhJpc3KCLgN1VHyVtr+6Y0P1WUOBQWj1iF5kfrB5J+VhYpVO qygMcjlSiFtJW4gfs8siukSebn1t3ILGX9eOvxjhNGgrsfZ4bboq5N4rhFb2+NWF sjBmjE9qIFJK21xgp1XPJHiF4SsfL8CQZqgvBGYcnfmcGb7wiXPZEvzVJ5VVSNh2 7l4VWrix+YDXKmhD7WccCLZOjEGJg7CSOHndm6FPQt6++OGMsWUdmZNAsB9Iw6Ia Y5oDYuVxRqH5VLPKwKfb4FIQJDr/RESJU7Xd9W0+RPwjLb73k6sPyn3eWBMbiWaa 5e8G/GlWJtT1GGQT3fBnUtKhRBrCJQ/tH/oDmWQ7BLgUWisiU2eOaMB3MCWDq13F uaKB63CU8EnvdDJGCbjy0U+D/e2ZRD8tKNcJAn1dl8+sBD28/vd5cO2aTv4AYSjG Jf9e7RHTy+giMx4jvKbPaQb6187Im92C/7J8rBuk7PhLhtZQU7RM5CPj9aiqYkWg 7OoNVWQSRbljS0V3J0qsUmvwXf5PngLjCKqBot2vbZIV7FM0sls= =Q/6i -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
3-4 days based on my experiences) > even on a relatively small SSDs (not to mention HDDs) and it also > will shorten SSD lifespan. > > If laptop is put into sleep mode without users noticing that btrfs is > running maintenance ops on background (and it often is), the > likelihood that file system will get corrupt goes up the roof. > Something users can do is use TLP and as a first aid set > SATA_LINKPWR_ON_BAT=max_performance for TLP which then will shorten > the amount of time laptop can be used without recharging. And this > has been a standing issue at least since 2015 with no real fix on > sight other than "lol, stop using btrfs" like one commentator at > Reddit wrote. Do you have some link to the bugreport about this? > The btrfs-check is also a massive can of worms and it cannot be > safely run. At least not without reading pages upon pages of manual > and becoming an expert in understanding how btrfs works. Expecting > every Fedora end-user to do this is unrealistic in many different > ways. Well, I hope people don't run random commands from the internet? Myself I did not even need to run anything like that. > The btrfs has no native encryption to my knowledge. However > alternatives such as zfs already has a trusted and reliable > encryption used in numerous FreeNAS installations around the world. Upstream is working on that. > And much of these issues and many more are straight up mentioned in > btrfs' own wiki pages at kernel.org where one of the most shocking > admissions is: "So, in general, it is impossible to give an accurate > estimate of the amount of free space on any btrfs filesystem. Yes, > this sucks." > > Source: > > https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complicated.3F > > And these are the brains before btrfs admitting this that there is no > solution for this. No amount of userspace tools developmen and UX/DE > integration is going to solve this for the end-users. > > Please, don't switch to btrfs. It is not mature. It is not well- > understood. It is not properly "battle-tested". It can still die on > its own. It's just a ridiculous meme file system. At this point it > would take me some decade of smooth sailing at OpenSUSE side to start > believing that btrfs is ready for prime time in my own personal > Fedora systems. Even 5 years of smooth sailing would give more faith > in it. But as it stands I have to strongly oppose btrfs. It's too > much of a headache with no relief in-sight. > > > -- > Antti (Hopeakoski) > > P.S. Sorry for this emotional nature of this message. But I really, > really like my Fedora and I really, really dislike btrfs due past > highly negative experiences with it (some of them happening to me as > recently as last year). > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl74lVoACgkQEV1auJxc Hh6LNhAAu6OC9A3PngNst6Ym9Bfq2TlNwfTiwk0nJrOMleAQwhmAySmfVtv8YeQF ozDYuPOqcLKDsSxrNKDzA+aaOegZpNnvTNB2UOFZgGQPdrTqGXv+kt3FCk9Vu0kF 6SW6DB83sgfuP93RJ7LDqktOw/EtCX4PWtRj1mSixTlpBqSQ3YPYHittgWnD/pWK Ka4h4WrQVvpY6tS7rfCCk+Vc4QLMBy5cw7Og/TtrBBJ9jFU2pZbbJ6wDKFMOC6l6 wr65un/9FuwKY9o8DGaqePTezVijTVumXfrAjtkfsvpxze2CJKCOC3r9+GQjWXmK WszsZ4tBJuoHrndINHTOronOsBrj3UoRkMqnCThu5JqMMqo0+9EsqewjbtCJYD7U gAYAT2neHzWKaNM3rl9hxOj1vkiwaLFiwYkDAmfwwaPJ5DH5FsjACevXj03E6zNn WwHZTHR1pi3SogU08wY0WszBrkemEBkwD7tbA5VZPtXSyAe/ae0qJsWfB4f/ebqf JDoTlbctYMAQ5HCTIE+d0n4U7XiBUcXGvN4Eb+mej+fqQwVdUKz0XYUdLFfDthef YCH+8WEz9ej9W2TGnB/1gjPK+1U6GllF5O2jJQmS/qYQgVk1oZsxnQg2e27HUswj UdLOtVuRDZu46LndelTke/SxQXrW6+C+C6UVgy0t6sPenUIVvIU= =MUeD -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote: > On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote: > > On 6/29/20 12:27 AM, John M. Harris Jr wrote: > > > > > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: > > > > > > > On 6/28/20 11:35 PM, John M. Harris Jr wrote: > > > > > > > > > > > > > > > > > For the best filesystem ever created, ZFS, I can't say that I > > > > > agree > > > > > with > > > > > your assessment of that value. Having ZFS in Fedora would > > > > > throw Fedora > > > > > over the top as being the best Linux distro, hands down. I > > > > > can count > > > > > the > > > > > number of times that having root on ZFS has led to me waiting > > > > > on kernel > > > > > updates over the past three years on one hand, and could > > > > > still do so if > > > > > I > > > > > had half as many fingers! > > > > > > > > > > > > > > > > How many times are you going to keep mentioning ZFS? It's > > > > completely > > > > off the table, not allowed, never happening. (I consider the > > > > chance of > > > > Oracle doing something reasonable to be immeasurably small.) > > > > > > > > > See the relevant section of Mark's email. I also don't see how > > > it'd > > > require Oracle to change anything in order to get OpenZFS into > > > Fedora. > > > > > > You were mentioning ZFS, not OpenZFS. However, it's still the same > > problem. OpenZFS is CDDL which won't be accepted. The only way > > that > > can be changed is if Oracle does something. And as long as OpenZFS > > is > > an out-of-tree module, it won't be in Fedora. > > ZFS, in terms of Linux support, is generally OpenZFS. You will note > that Mark > also simply said "ZFS". Yes, OpenZFS is under CDDL. That's not really > a > problem. See > https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html > . Ubuntu's solution is wouldn't work for us, and it is a GPL > violation > (https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/), but > it's also not necessary. The package for OpenZFS could be provided as > a kmod > package instead, which would *not* be a GPL violation. > > I don't understand the attitude against this particular out-of-tree > module, as > it's readily available for every kernel within days of release. The > longest > lulls have been around holidays, where it took up to 5 days to get > support for > the latest stable kernel. First of all, Fedora is packaging not only latest stable kernel. Fedora is building kernel from git in rawhide almost daily. Secondly, kmods in Fedora are not allowed. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl75nhoACgkQEV1auJxc Hh7u8g/+N/1Z9nEzFSzDLk6G5kOcfdeexDIv9EhtfLhmSuPDbwtt/t0JqHpWxxWx 8pf42bG85OkatyeMKE+Ycb9eW3ZSJ008i9Et2Nm9F9WS11KrfSWmVOjl1lJ7vQpD 9MJsvGgTQObcKriVxi6HEST/av9CStCzLyqjejMhyG/cXqTZ0sZuF9ZmdudiKGi+ gzDGxcJYeCnnagklomGB55mfz/+SrQphGNUc/yHbRJgrNpNmbUTIfl4mzSzu+12L 3kpPBLIaQYHp+Va8SV8C9jzWe3CXhN95pL5NqL6fcGouB9ciyds+1U0+xyPZF3kt Va+ziIKdbPJbBfgut4qa84QPCaUCb2gvCOUbL8IDV0ohlk05ss20NFDo26FxKEFQ QFqTGJGgrZZd3MK7HO0y/pZTtegv2dUxBy/xzqYo+5iLMczDTI3RJYWZoLDEP/wV 8fsF6jltCXXYvzWeQ9lk2aHODrP34PmqTTCvbwwzmQThB4ruG7h6Q4ec27MK+umz eW7di/U4cnB6JsJIII1ZJAy8E9vH98n1zUPFrpXsYhAq5AmepMMHtQB8A4CQoGkp 3F2csTTT1OR8f35RInt/IVZ0aLwB+vhdXmtWyZk35aRRTHZ1PIzcH4yd0mt1GObG LenIifmIdp/aQtgZAc3023517cg7zR+G4iABzu1yDf0tVsnA1g4= =ihOE -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-29 at 12:26 -0400, Matthew Miller wrote: > On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote: > > > We cannot include ZFS in Fedora for legal reasons. Additionally, > > > ZFS is not > > > really intended for the laptop use case. > > Has that actually been explored? How does Canonical get around the > > legal > > issues with OpenZFS' licensing? > > I can't really speculate on Canonical's legal stance and I encourage > everyone else to also not. > > I can point to Red Hat's, though: the knowledge base article here > https://access.redhat.com/solutions/79633 says: > > * ZFS is not included in the upstream Linux kernel due to licensing > reasons. > > * Red Hat applies the upstream first policy for kernel modules > (including > filesystems). Without upstream presence, kernel modules like ZFS > cannot be > supported by Red Hat. This is not fully true to my knowledge. Red Hat ships VDO and that is not even sent to upstream (yet?). > and "due to licensing reasons" links to > https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ which is > quite > interesting and quite long. If you have just time to read one > section, the > two paragraphs at the end under "Do Not Rely On This Document As > Legal > Advice" seem like the _most_ interesting to me. > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl76ONYACgkQEV1auJxc Hh5R7w//TvrXFDfvGwaKV0jSjy6OPKea+Y2urF8pjrH1lEBb2PpvW+I2jxqKy6BM lXeR0nShtlJJ6IHjq7IK8xUZiNBzbCbJQGURdRkh63ZENQrbJ52BPYJv190/Fh4g R/rHBbvja/Q0y/LRZK5heXknIELPZdWfD1N3hHvhc+J9uHlmozZBhlO3zk3kcZaL OwsrV5UzgccFfmWyOFTcx1VFLqoILJW6vo10m+qM47jwpdNlJQTBw9i1s8PDMsAI d045ZmX+u2ZTS7YJ3AJ+YaXQXlhI2DUUYc5R2hf8whUp7Fi68RJMseK8ar8kxLby HRSzTP55VYnApUBJ78KoVq7wvWdFCGq15YR39hVC/B1GgzjxYhzv53FJ2/Sy5Q2d jbWGvtpd8E5+29jhvGC+fDJ91XsTLdmkNOS8w+McQUkFiJdzqVzUIjzHz4bzK4wS agqsylZP+E79nxjKaQdE5vGdACN9cZnh/Za2sWLTGiVE1Rw7eDVhaDtpGjBVrwUr Y0sNSzbqVM2NE1pE6g43AisA533iD8b2XxplWhhoeHp1RRiASkp9yh6WibTDyFXW 9wnXmzIa3Swte3n+LvV9lSlILYoGdQKMljYNU/yr1zMsR9yBRx6fpijinzGWJ6oM /Ug7h+W7HPgWQk+sGJJs7mHXfYdAODzupSXhQml0hURMRQ/qaOs= =6vGj -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 11:04 +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > > On 29.06.2020 22:04, Ben Cotton wrote: > > > Fedora only support these RAID sets when they are already > > > configured in > > > the BIOS at installation time. So we can solve the problem of > > > dmraid.service still depending on the obsolete udev-settle > > > service by > > > making dmraid.service disable itself if no supported RAID sets > > > are found > > > on its first run. > > > > +1 for this change. > > > > Also the LVM monitor can be disabled too if LVM is not used in > > current > > Fedora installation. > > > > LVM monitor: -2.01 seconds. > > RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be > installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed > to > be there and enabled - it should not impact load time all that > much... ❯ systemd-analyze blame | grep lvm 4.103s lvm2-monitor.service Sadly you can't have lvm2 not installed: lvm2 is needed by (installed) libvirt-daemon-driver-storage- logical-6.4.0-1.fc33.x86_64 that is required by other libvirt stuff which ends up with gnome-boxes. > > Zdenek > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77BK0ACgkQEV1auJxc Hh4V8hAApS1m1x4gqE66qQZuf81bcHPU3wTYYgLvzqVr69eq25hzu1pIQDT1oXJH WgHuucYKCQjr2JO9dv2Amil0hNlnrRP6AONJ28f22xUnUHoM93vYi7Y6Ba5sbGh6 31DRf5FEgfcBODXmB4XVGm2vXxlWeMYVnR9ujKHvnl/8ODrI6jLrvIDl02rFq3eT Gym144modLy6cKVaUBRO8q6n26A8wHXKQ+9Gj7h95c5vHZzZd3QReITxsim+Lxee 3iVPI7sRPI6VYZFvtsG+sLJgQlUvrcD1pjkCUJDwIPQG8cnvmfUk8L1TtDOfeRZK Uzn/NQgx8WNAcpOJtE3PrqDLRQl7jVHwulwXP+181RYSAeuX5z69qXZZ+7kq2lVh OtTRKQbfed2VYdrd0emOizZH92zGNR8gtJ4PkCu3ThWEaYnH3eJ5r8FM/znoFOI1 P+rkllVce8AJ0+V+ZJOR3/hLQSN8bcOREm9shxWz7TixUPbkzsRUh4EAWamznyKL ZUHQbv9MZZ5HEvw2+7Ukb8tULsXNBWm1mSMVMhE92XueTaavAkY6E1iPmWaZ1R7y Tvmh1Gmq6Hk/DNb6qQtBPESKHGT9Y4T+8wbKDm8YilotwEZpQ0B1T7W/oTS+ZHKu 0woM7DnULdbtGaPcH1DM+3Q9XTkDWTbxVF3kG90f6oKezSpmntg= =hlFt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 09:25 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including > thermald in the default install. I have strong feeling that this has been already submitted before. https://fedoraproject.org/w/index.php?title=Changes%2FThermalManagementWS&type=revision&diff=580846&oldid=557200 Sadly the diff is so small that I don't think change owners really read feedback from the mailing list. Neither it incorporated "Feedback" section in the proposal. > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors > to monitor the temperature and use the best available method to keep > the > CPU in the right temperature envelop. On certain systems this is > needed to > reach the maximal performance. thermald will for example use the PPCC > power > table to set power limits (when available, see for example > > https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.html > ). > This is for example the case on Ice Lake, where thermald can increase > the > performance of the out-of-the-box behaviour of Fedora. > > Not strictly necessary, but *further* improvements can be achieved by > using > per-model thermald configurations. The most straight forward way of > using > those is for the user to install dptfxtract (available from > rpmfusion). At > least parts of what dptfxtract can already do may be integrated into > thermald in the future thanks to the reverse engineering work done by > Matthew Garret (see > https://github.com/intel/thermal_daemon/tree/mg_patches_test, > https://github.com/intel/thermal_daemon/pull/224). Should the reverse > engineering effort be merged, or if the user installs dptfxtract, > then they > can expect a performance boost on some machines. > > Theoretically one could ship appropriate per-machine configurations > as a > separate package (or inside thermald). However, this is not part of > the > proposal for a number of reasons: > 1. It is not clear how the configuration data can be collected > 2. We do not currently have an implementation to load such > configuration > data > 3. This may become obsolete with if the reverse-engineering effort > continues and is merged (or picked up by Fedora) > > For a more details explanation please consult Intel's [ > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. This affects many modern laptops (e.g. > the > Ice Lake platform). On affected machines, Fedora would continue to > have > poorer performance compared to other distributions. I think the change page is missing information what exactly this daemon does if it is installed. > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install I believe this won't do anything because the daemon won't be enabled. > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > Install the packages and use e.g. turbostat to monitor the > performance. > Improvements may only be visible if the non-free dptfxtract package > is also > installed. So if improvements are only visible when non-free software is installed - - what is the reason to ship it by default? > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Don't ship package by default > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://
Re: The future of legacy BIOS support in Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot > which > has been available on any common intel based x86 platform since > atleast > 2005. > > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class 3 > and above as in it would remove legacy BIOS support from its client > and > datacenter platforms by 2020 and one might expect AMD to follow Intel > in > this regard. > > So Intel platforms produced this year presumably will be unable > to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), > network > cards, and even graphics cards that lack UEFI-compatible vBIOS > (launched > before 2012 – 2013) etc. > > This post is just to gather feed back why Fedora should still > continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. > > Share your thoughts and comments on how such move might affect you so > feedback can be collected for the future on why such a change might > be > bad, how it might affect the distribution and scope of such change > can > be determined for potential system wide proposal. I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this configuration, develop tooling for them if possible for migration and do not allow upgrades that will simply break their system. > > Regards > > Jóhann B. > > > 1. > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77RJkACgkQEV1auJxc Hh4+4A//QC8EWxecyBbSWu8uo2dSlFgqcCJ4zn6fkpgsU1PPhcezTPNKBFYdXUag QMN5d6fawQE7LWRMY6y1Gq4oyANPQyJVshUeOcOBkyDpnZN13uCJSLDXpmHifpOJ Up27VxVjYRb4kkPyHZqiwOkJP8U/4NfKeWkfew5CFGufKjX1dQVS8CeNWgpl1YsM aTTLd5CvzDiMN4GBoaSRZmI9YDbrQbElqrk6BZD1wAIVnBbpvCq8wUJFRKIcx6O1 gMxpGV9txZ2HLKqmUYRtQUl5+CKTS45vJszGdlWPPqjiGpgGEDtsAqCPfWiyHUAc 0FZYdYHt3a1/jmNH0WRS2UOmeu5FP8VUOUvywVn3e4A5Dbi3Bdv2xuOGPD+xyti6 TAE3bWnYE1i7T1N6xoD90z2w+iQLFi12ftA7wkajNjf4e0MaawRBKuiG9VhL2xUA vCDFaL/tqSQDPkWlrQblUjpJEOZOrtxQl48iMTNWmo92AtmuuARNwSsXNxEeP3GP 2DVM69j3CrGPpEBCIt4PdymHTQ2AHalUZwSAxEiT0NjwZ11uS0dAK7ipzwbUr+gt Kwt202qSB5CZWSYe+VMDDxVyHJAIjpllzejaNBnVFrtpNmAXEjTJY+0sU/JW8o37 2HXm675cbN+X8AvNXMypoVJFcGRvqvaneKn4ywqhVhrRRzc5B38= =xrlO -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > == Summary == > > redhat-rpm-config will be updated so users of the auto framework get > automated release and changelog bumping. > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > * Email: > > == Detailed Description == > > This is a system-wide change because all packages build with > redhat-rpm-config, but it only concerns packages that opted to use > this part of redhat-rpm-config (auto framework). > > The change will make those packages auto-bump and auto-changelog at > the rpm level, in an infrastructure-independent way. So how exactly is this supposed to work? From where will it get old changelog, how packagers will migrate to this, how does it affect reproducibility? > == Benefit to Fedora == > > Autobumping removes a huge packager shore and makes timestamping in > changelogs more reliable. > > == Scope == > * Proposal owners: The feature is coded and works at the rpm level. > Unfortunately, mock filters away the srpms containing the bump state, > so it does not work in upper layers. > > * Other developers: The feature requires buy-in by mock developers > (and probably koji developers) to lift the restrictions that block it > above the rpm level. Also, it requires a mechanism to pass the user > name and email that will be used in bumped changelogs (defining two > variables in ~/.rpmmacros is sufficient at rpm level) So are you asking mock and koji people to implement something? Did you talk to them before submitting this proposal? > * Mock issue: > https://github.com/rpm-software-management/mock/issues/599 > > * Release engineering: https://pagure.io/releng/issue/9567 > * Policies and guidelines: maybe eventually if things work out on the > technical level > * FPC issue: https://pagure.io/packaging-committee/issue/998 > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > This is a pure build tooling update, it changes how things are built > not what is built. > > == How To Test == > > A redhat-rpm-config packages with the changes and some example > packages are available in > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > Since the mock/copr layer is currently blocking the feature, you need > to install the redhat-rpm-config and forge macro packages available > in > this repo locally. Afterwards you can take any of the example > packages > in the repo and rebuild them with rpmbuild -ba to your heart content, > and see the releases bump and the changelogs being updated > accordingly. > > To get beautiful changelogs, you also need to add > > > %buildsys_name Your name > %buildsys_email Your email > > > in ~/.rpmmacros > > == User Experience == > > N/A Packager experience change only > > == Dependencies == > > The change is a spin-off of > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > Therefore, it depends on the success of that other change and will > probably need rebasing if the code in this other change evolves > during > the redhat-rpm-config merge. > > It also depends on mock / copr/ koji buy-in and changes, that may add > their own requirements. > > == Contingency Plan == > > There is no contingency plan because the change will happen or not at > all. This is not true. If it will happen but then something will be entirely broken we need to revert it.. And we need to know when, how and who will do that. > == Documentation == > > There is as much documentation as the average redhat-rpm-config > change > (ie comments in the macro files themselves) > > == Release Notes == > > N/A Packager productivity change only > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-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/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77k5MA
Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
e devices > > * adding a centralized solution for delayed actions on storage > devices > and groups of devices (avoiding unnecessary work done within udev > context and hence avoiding frequent udev timeouts when processing > events for such devices) Is this purely about adding some package into the repositories and just to raise awarness that such tool exist? > == Scope == > * Proposal owners: > ** complete SID's infrastructure to fully support stabilized API for > other developers to start writing modules for SID; > ** document all of current SID's functionality, including the module > API and explain the difference (extension) to udev, write and > complete > man pages; > ** provide udev rules responsible for communication with SID and > possibly importing records which were marked for export to udev in > SID. > > * Other developers: > ** first version will make use of a module to handle > device-mapper-multipath devices (device-mapper-multipath package) > ** consult in more detail possibility of adding an LVM module even > for > this release (if not feasible at this moment, then postpone > development of this module to next release) > > * Release engineering: [https://pagure.io/releng/issue/9568 #9568] > * Policies and guidelines: no changes needed at this moment > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > We are introducing SID in this release and it will be disabled by > default so an upgrade has no impact here - all existing udev rules > for > various storage subsystems will still be installed as previously. > Subsystems for which a module will be already available in this > release will contain a switch in their udev rules to either use the > old udev rules (if SID is not active) or skip the rules appropriately > (if SID is active and related processing is handled within the SID > module instead). > > == How To Test == > * Basic testing involves (considering we have at least multipath > and/or LVM module present as well): > ** installing new 'sid' package > ** installing device-mapper-multipath and/or lvm module (presumably > named device-mapper-multipath-sid-module and lvm2-sid-module) > ** creating a device stack including device-mapper-multipath and/or > LVM volumes > ** booting with 'sid.enabled=1' kernel command line > ** checking device-mapper-multipath and/or LVM volumes are correctly > activated > > * More thorough testing: > ** (TBD) > > == User Experience == > Regular users shouldn't notice any change. SID is providing a > system-level infrastructure for convenient handling of > storage-device-related events through modules provided by other > developers. > > == Dependencies == > * a module to handle device-mapper-multipath is in cooperative > development with this change, the module will land in > device-mapper-multipath package (or its subpackage) > * the same applies for the LVM module (but that may be postponed as > described earlier) > > == Contingency Plan == > If SID is not complete in time, there's no need to execute any > special > backup plans. The distribution still contains all the original udev > rules to handle events for storage devices. If device-mapper- > multipath > and/or LVM provides the SID modules, these won't be built and > distributed. > > SID is not enabled by default so to start using it, one needs to > enable it explicitly. If enabling SID causes problems, it can be > disabled. For this purpose, there will be a kernel command line to > enable/disable SID so we avoid possible issues even at early boot > sequence if the device handled by SID is on critical path within boot > sequence. > > == Documentation == > * documentation (will be completed): https://sid-project.github.io/* > upstream repository: https://github.com/sid-project/sid-mvp > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lBMACgkQEV1auJxc Hh7VAQ/7B+6trAXJOJSusP7XzXfcjtyfk4rxriiyccfHsqEriHnVhbpipWJ2TrVe YnOdvDK0+iU+PNgyZueXV4OBZWaQLw76f+HC+0IbWlYuejIWKmEu/DRxnQS0Iz+6
Re: [Fedora-packaging] Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
rpm
> lua API without blowing up on the landmines it is littered with.
> Therefore, I abstracted landmine avoidance in a single place.
>
> === Drawbacks ===
>
> Nothing is free, and a higher level of automation required using
> rigid
> naming for control variables. Because software is a lot less tolerant
> of fuzzy naming than human beings.
>
> So, all forge control variables are renamed, fonts control variables
> have been renamed too, and go control variables will need renaming
> (in
> that last case, that’s not a problem because moving to go modules
> requires reworking variables anyway, so it will be done as part of
> the
> module effort in F34).
>
> To ease the transition a compatibility layer was added to forge
> macros
> so old variables and new variables are aliased both ways (this will
> eventually go away because it’s quite a lot of compatibility code to
> maintain). Mixing syntaxes (old and new) is not supported, you need
> to
> convert your spec file to new forge variables or not at all (if not
> at
> all, do not try to use new features like patching).
>
> == Benefit to Fedora ==
>
> Spec files that do more with less manual expensive to maintain spec
> code.
>
> Without this productivity win, complex efforts like converting Fedora
> Go packages to Go modules, or draining the Font packages swamp given
> that legacy formats are no longer supported by apps, are not possible
> with the current level of Fedora manpower.
So this came out of sudden, without any discussion with RPM upstream.
What about integration with Rust, Python, Ruby and Java ecosystems? Is
it planned for the future? Having something very generic,
unmaintainable and overcomplicated just for Go and Fonts does not make
much sense to me.
> == Scope ==
> * Proposal owners:
> The core of the feature is done and tested (and retested). It may
> evolve during the redhat-rpm-config merge process.
>
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95
>
> * Other developers:
>
> The way current forge macros call forge macros will need a little
> patching once the change lands. For other packagers, there should be
> no change except a warning in rpm build logs to switch to the new
> syntax before the compatibility layer is removed.
>
> * Release engineering: https://pagure.io/releng/issue/9565
>
> * FPC: https://pagure.io/packaging-committee/issue/997
>
> * Policies and guidelines:
> Forge guidelines will need some rework (mostly simplification,
> because the new syntax is both more powerful and more regular).
> For the average packager, the new syntax is the same old syntax
> with
> little naming adjustments (for example, %{forgeurl} becomes
> %{forge_url}, %forgemeta is subsumed into %auto_init, etc)
>
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
>
> This is a pure build tooling update, it changes how things are built
> not what is built.
This is not fully true, this will make those packages non-buildable on
older, supported, Fedora releases.
> == How To Test ==
>
> A redhat-rpm-config packages with the changes and some example
> packages are available in
>
>
> https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/
I think it would be useful to put concrete examples on the wiki page.
> == User Experience ==
>
> N/A Packager experience change only
>
> == Dependencies ==
>
> The change depends on a redhat-rpm-config merge by redhat-rpm-config
> maintainers
>
> == Contingency Plan ==
>
> There is no contingency plan because the redhat-rpm-config merge will
> happen or not. If it does not happen, i18n, fonts and Go Changes that
> are/were envisioned for F33 or F34 will be postponed indefinitely.
Again, if this blows up, we need to know what needs to be reverted,
when and who will do that.
> == Documentation ==
>
> There is as much documentation as the average redhat-rpm-config
> change
> (ie comments in the macro files themselves)
>
> == Release Notes ==
>
> N/A Packager productivity change only
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to
> packaging-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.
Re: IBus 1.5.23 - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:20 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/IBus_1.5.23 > > == Summary == > IBus 1.5.23 will replace the allowlist of XKB engines with the > blocklist of XKB ones. > > == Owner == > * Name: [[User:Fujiwara| Takao Fujiwara]] > * Email: fujiwara [at] redhat [dot] com > > == Detailed Description == > IBus currently provides the allowlist of XKB engines in > `/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can > show the XKB engines indicated in only that file in most desktops. > (gnome-control-center shows XKB list from gnome-desktop3 in GNOME > desktop instead.) The allowlist includes the limited XKB layouts and > variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the > allowlist has been supported to customize by sysadmin localy since > the > simple.xml is a simple text file and the default list has been > updated > upon the request. > > IBus 1.5.23 will replace the allowlist with the blocklist which > includes the disabled XKB engines and `ibus-setup` will shows all the > XKB engines which are '''not''' indicated in that file. The > blocklist > will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp' > layouts at the moment. > > I.e. the change won't effect GNOME desktop. So I do not fully understand this change. Is it actually breaking something or not? If so, I am surprised it happens when bumping micro version (.23). If not, does it have to be System-Wide change? > == Benefit to Fedora == > The users don't have to request the desired XKB layouts and variants > in IBus upstream and most XKB keymaps will be shown in ibus-setup. > > == Scope == > * Proposal owners: > * Other developers: N/A > * Release engineering: [https://pagure.io/releng/issue/9563 #9563] > * Policies and guidelines: N/A > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > If a keymap is shown in ibus-setup in the previous version, it will > be > shown in the new one. > > == How To Test == > # Log into XFCE desktop > # Run ibus-setup > > It will show 'English (UK)' keymap by default. > > == User Experience == > If a user customize `/usr/share/ibus/component/simple.xml` in the > previous version, the file will be replaced with new one. I think it is pretty much expected that if you modify something in /usr, it will be overriden by an update, no? > == Dependencies == > The change effects XKB engines only but does not input method engines > (E.g. libpinyin, hangul, and so on.) > > == Contingency Plan == > * Contingency mechanism: Drop the feature in Fedora 33 and postpone > it > to Fedora 34 > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lt4ACgkQEV1auJxc Hh7vKA//VigWO3Dx/Aj52Nb1zVUY6CluDKLwaYEJ1c3j6LYwNhH6LVYMLQUPRlw2 gNUHe5n7k2C1kiFP2s1+u/MEQXGxZwjzGgPxwVLNl9bOFfk8HnXrwHuTquucDC3T 0amg4G0x3LynbhCrzrzBxfOSy/GnlElUGKY66izaTMPnsHtGjrmHzb0eCOsaIYvl D4TxBJ7pTqJh6XG41UFHsyT82yuMAwjeS8mow7XsQY3a29wWN7A9cxyNBpv0Uhtb rXbN9ti5pk3qmc+XjSbbqNvS3ufVAOLGv9FOXmkOG3iY0uhSjLJXkSPesDkJdzYp EQR+W5nmFFsUEKKFUb4fwTJ5TEz1OjNtUYW09Ahuqq5S6xJv6IA7rMPkU05rxeMM Qac7q3LJ+cQM0vk9HKVIDfXmqX47tqCNpcrC5uDLb6MwBGvz7A9WJWdu71shuTAi Bmya4/yISh7C/5+pfpO4y2h+z7RYiA2visNdp3oYRWQ7o+8SMUjPHGzyIvX3TcF5 pZlmKrYsoyEiltyMoyhJTosOZ+wWpMhZQhjVNT3vq3nUYnSe3xAX7aGUoIF750O9 HOvjyDcpptCMjVr/b2pcQt7usLG+ISzta8LxZkm38RkFGSG3aewRTJGSTK+K7XQQ iUCRYGKePePPxtYZwNT212Hft1vBaN7hGzA7P3oXdYOblWuk9w4= =9bCf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote: > Le 2020-07-02 09:52, Florian Weimer a écrit : > > * Nicolas Mailhot via devel: > > > > > > How do I let rpm generate the changelog automatically? > > > > > > This feature is not changelog generation, just changelog bumping > > > on > > > build events. You still need some other method to put non-build > > > events > > > in the changelog. > > > > What is “changelog bumping”? Why is it needed? What about release > > bumping? > > Changelog bumping is the act of putting the actual release bump and > build time in the changelog. > > With the change, the spec is able to self-compute its next release if > the spec file evr is older or equal to the last build event. How does it know that "last build event"? > On build, it will both bump the release, without touching the spec > file > (that is release bumping) and commit the new build event timestamp in > the detached changelog file at %build time (that is changelog > bumping). > > > > The detached changelog is just one more file in SRPM sources, > > > which is > > > modified by rpmbuild at `%build` time with other files rpmbuild > > > modifies. The tricky part is to modify the source file as a > > > source > > > file > > > so rpmbuild adds the result to the produced SRPM (and, that does > > > not > > > work in mock right now, because mock serves the SRPM that existed > > > at > > > the start, not at the end of the build. Though it’s probably just > > > a > > > matter of getting mock to call again its SRPM creation method at > > > the > > > end of the build). > > > > > > The packager does not have to request the modification in his > > > spec, > > > it’s done as part of the various %auto_foo calls the change > > > introduced > > > > Can you list the relevant %auto macros explicitly somewhere? Is > > %autosetup included in the set of macros that trigger this > > behavior? > > %autosetup is not part of the new framework, all the new %auto entry > points have %auto_something name/ > > Auto release bumping and auto changelog bumping involve registering > some > processing in the preamble (to compute the next evr), in %sourcelist > (to > deal with the source files involved in saving state) in %build (to > commit the new data to disk once the build is ongoing) and in > %changelog > (to get rpmbuild to record the new changelog state in package > metadata) > > ie it registers processing in %auto_pkg, %auto_sources, %auto_build > and > %auto_changelog > > The bumping is done by the buildsys subsystem ie practically by > %new_package (called by %auto_pkg, directly or via %buildsys_pkg), by > %buildsys_sources (called by %auto_sources), %buildsys_build (called > by > %auto_build) and %buildsys_changelog (called by %auto_changelog). > > It’s done by the buildsys subsystem because the %buildsys subsystem > is > tasked with writing the SRPM header in the new %auto_call framework, > so > only it knows which of the various (sub)package epochs and versions > are > the ones that apply to the SRPM. > > This may seem a bit complex and convoluted, but that’s because > autobumping > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > is a small addition over the big %auto_macros change. > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > And it is small because the big change provides all the low-level > infra > to code such high level features easily. > > The big change was not done for autobumping. It’s only once I coded > it > for other packaging needs that I realized it made implementing > autobumping trivial (trivial to me after all the other changes, maybe > not so trivial for the average macro reviewer). > > Regards, > > -- > Nicolas Mailhot > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-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/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxc
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:27 +0200, Nicolas Mailhot via devel wrote: > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : > > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: > > > The detached changelog is just one more file in SRPM sources, > > > which is > > > modified by rpmbuild at `%build` time with other files rpmbuild > > > modifies. > > > > I don't like that. %changelog should be generated automatically on > > Koji > > side. > > Why? Koji schedules a build. The build registers its own build date > in > the produced packages. Koji decides to keep and commit the result, or > drop it (scratch build, failed side tag, whatever). Koji is still in > charge, the bumping is just integrated in the build process with the > rest of the package creation. I think Change Page does not mention that Koji will be committing anything to the dist-git. > And, unlike something done specifically by koji, the bumping will > import > and export across all build systems, ie all the bumps that occurred > in > rpmbuild, or mock, or copr, or obs, or whatever are imported in > fedpkg > with the rest of the srpm, and an srpm produced by koji can import in > rpmbuild, or mock, or copr, or obs, or whatever without loss of bump > information. > > And you no longer waste hours wondering why a package you just fixed > is > still failing on your test systems before realizing it is masked by > another build that did not share the same bump history. > > Regards, > > -- > Nicolas Mailhot > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79qyoACgkQEV1auJxc Hh7/uQ/+PU+KAwd+lCd4YMAEd41Caii7BBMSIOn7WQ5EJEJu9V4g7QvNFGi147Pw 95DH9jZNf6KIFbVNh32gi44fZ60Q2MCj4/H5Mq3PoGe+wa3ks4twbLox8rG2M1BG EWQVWXi8HWYZ5gR7QBUmVW0rpEYuyGNUMSFsavdAAv6hfq2LQMAA9lbSerWmOikK w+2SUuoo1D5l1ps8Bi7L91ZFH6Z7K9sdXxG8rhuK9EXuf63DwfXbraYCQdwOeCHP wXvyRkQ8D5w9MiFriN4e6zqp8SI8QvPnqhLWO9RoqYDr9FMc1tqKeaZN/yuIdu+Z zIQU1M1N4cfOm91TvNH/gAev9e9X9dvJMKPsVZF2K4yAE0MSy4EgjY0ixvv0KZWq RRTXqs/fYF/KLVfuwrI5ZVJTcthvuUi4YL+LDoC/TL7SfLJVTVv5t1ub8l0geTBc isFdIntggJEUxtovM/FG2/affYNJnxIW9diGJkQYYtqo7TpuHtW2yoYF2QJ3eKim yW0UQiyNZ81wpfHns0dzGm3EyUrqrWlazRCcgaxfH++MvVj2TSYnyiAmEF4YZg0r jFcjyMZ7ZXyekUvhjBBNMBow5dZ1F2178cEOeHhC8S4NFrX+UkuUkQE+UjMarr3p X6W2z2Gz/L/m3c1P+kLKYbMcpQCmzh2U6Or6F9zlUdwFLJTt4qw= =Y5uf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 12:20 +0200, Nicolas Mailhot via devel wrote: > Le 2020-07-02 11:59, Florian Weimer a écrit : > > * Nicolas Mailhot via devel: > > > > > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : > > > > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: > > > > > The detached changelog is just one more file in SRPM sources, > > > > > which > > > > > is > > > > > modified by rpmbuild at `%build` time with other files > > > > > rpmbuild > > > > > modifies. > > > > > > > > I don't like that. %changelog should be generated automatically > > > > on > > > > Koji > > > > side. > > > > > > Why? Koji schedules a build. > > > > No, Koji also builds the SRPM, via fedpkg-simple or a similar > > mechanism. > > Sure, by build I intended both the deployment packages and the SRPM. > > The main difference between the current workflow (the reason it fails > in > mock right now, but that should not be too hard to fix) is that the > SRPM > that includes the build info is itself a result of the rest of the > build. > > That seems the main point people misunderstand (thank you for making > me > clarify it), the proposal does not involve preparing a special SRPM > out > of band, that is then fed to koji, the SRPM containing the bumped > changelog and last build info is the result of the build process > alongside the binary packages. > > mock (and koji) just have to pick this SRPM at the end of the build > and > not use the SRPM as it existed before the build occurred. So who is going to implement necessary changes in mock and koji for this proposal to be complete? > And why is it that way? You do not consider a rpmbuild -bs a build > event > do you? We do it all the time to import packages from one system to > another. The only thing which is a real build that produces a bump > and > is stored in changelog history is a full rpmbuild -ba build. > > Regards, > > -- > Nicolas Mailhot > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79uiIACgkQEV1auJxc Hh6DWA//QXrE2wOef89QaKs/2KW9boWCZu3uapwHC+479iB2b1E3J7iw5c1JW03s 0BQ9sk+blA7WntICR2ebkq+wjv5A8upLDj7OGABxIag04MlMHXKD3HZtT67QoMUi vNEdxHr98oim7S/wI5ZizAAjxFApVoZmpsokaATc0r32wcyczVsWvBxEYmjw7Uo6 QqN38o/Z8Y9xaTDHf/S4d+FTUTbKmetpLmb5tLg25m62+0GaFMpfYo0lCuFID2on Ionk7+b0LH8DHaacxBwoV+6HiOno+qYLqDBLOKh5kJGFGr+o33uqqTfc3/7KouZh ui9F7TxeRpd+bbVhfQbAdQZEIWQCVaFSIza8YN8mXe6jcyyqqWjUOhWgGt6ihaSs h255wdI8VcZJXTSYt+qkXj5Z6fGvvDXjD+AoEtFyhP9sqm5qmFyEIm7xE/NGwFMj BO6xIumEFavP6lEylFtYH9j6q9LFvYBB5ITw33jI4Wq/lYbD4cB96ksuzz1FvDzp R76Y10H0naFmqN0IdLC7L8LV45uXFg/jZ0NCLQ/6d0kUm/FbggmhpePzJUZI/b3T phokAdf0RQ32NXXRj/unK8yMwaZfFd8ec+UK4VFb1+pECjgyvGxojp+vo7pVzEu8 QCTy+Cb5T96mwfO9ejFQMGV2VZBBoVPYsGc0hTmg4j7eA7fPiE8= =FeYg -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 18:00 -0700, PGNet Dev wrote: > (i'd been discussing this issue with praiskup @ copr-devel/buildsys; > he suggested that I bring it here ...) > > This spec > > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec > > which uses forgemeta to pull multiple SCM sources, and uses some > git/bash scripting in %defines, > > builds locally, on F32, via rpmbuild or mock build, from spec or > srpm, with NO error. resulting rpms are installable, usable & pass > testing. > > submitting the _same_ spec to COPR for online build FAILS @, > supposedly, similar Mock build By default COPR does not allow you to use internet though it can be enabled in the project settings. > Here's a diff > > https://www.diffchecker.com/izjQYkUF > > comparing the log output of > > SUCCESSFUL LOCAL BUILD > mock --buildsrpm --spec=~/rpmbuild/SPECS/nginx.spec -- > sources=~/rpmbuild/SOURCES > cat build.log > > and > > FAILED COPR BUILD > copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz > > The goal is to have the same spec generate the same Mock build, > regardless of environment. > > Why does the COPR build's Mock build stage fail? > > IIUC, mock builds _should_ be portable between mock envs, at least > for the same chroot. > > Do I need additional prep of the spec prior to submit? Something in > my foregemeta/scm usage that's env-dependent? Something else I've > missed? > > Or is there an issue with the Mock build env @ COPR? > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7+vesACgkQEV1auJxc Hh6few//fpCK/6V7F+7FWmo5l6e+kXJgtl3KZZfsusAo07ETto5meeOjZibjM13N 4adwQMY83uUJkD13jQwfWBzrcuK8ER6rhAGZ8SnTLKo7wrCWuvO2b2OBZxyXgaVW 1TcJzZsLLxEvBX1OPzYYlymyZSFfvePul6K1ByFLkYVpAn1xtYOCiB1QUT0BmX4m AQihgGJ7w0P8BY8f4crERM4U/pmxzBH6TeSMiTyq4JQSqfeloVvdFjzAiZ6MBp1Z rb+XtMhu6vu6ZYYYFf4bqPzYann5Bu8KGylhanuS+Tvvo9TmfKEQYz1Ec5XFkWwL wyw3QrlqcfllcX3zd3bgQYpPLuJST1PJho6Pv2lYyFVjhj8GC9kjXskm42CXeauz oF4D3m/Iz6kN+YQw/w+tg2BAnD+BOJVZaaI/T3dQIo2WE7fZVQ7fPCCtOkwiZYbc +eoBybumEFspShLKykoi5ENWbi3qA95qE69h+286btdgakKX+zv4RfMa2/k4jmMj r/Qohlph20mHJYJXf3VBO3Sng+pB2+fp2nhf46JE7OjcXefMMBuyja7ko7wBAMC1 vdfQc1ppCAQMvxxc+O17TNdP3f5sitzlf7J1XeiaPWHsPVv1XbZjnQTER7lYMYTy PqvDnoIEYfY2pVXHmvczYxeCGtbjA04bRPpmx1PLC1wZl2jcL/s= =KWRR -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest` is executed.
If it is set to anything, it will use `.` as a directory so that build
is done in-place.
* %cmake now always passes -S/-B options.
* %cmake_build/%cmake_install/%ctest macros have been created.
* %cmake_kf5 changes are in progress by Neal at this moment.
So far these changes are not breaking (it becomes breaking if you unset
`%__cmake_in_source_build` macro), so we plan to backport them in
stable Fedora releases so that spec files can stay compatible across
Fedora branches.
I've ran scratch rebuilds of ~2k packages that are affected (not
including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
will be lower once we get %cmake_kf5 changes are in). The ones that
failed are:
* 141 use `cd builddir; cmake ..; make` pattern
* 823 use `cmake; make` pattern
* 96 failed for irrelevant or overlooked problem
Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
of-affected-packages.
NOW: I've booked 4 hours session this Sunday with Neal to go and fix
broken packages. If you are interested to help - let me know and I'll
send you an invitation.
Will keep you updated :)
On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> == Summary ==
> %cmake macro will be adjusted (-B
> parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the
> older
> supported Fedora releases) to perform various operations that are
> commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> etc.) way.
>
> Packages that will stop building are trivial to fix and will be
> adjusted either by maintainers or change owners.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> Esser]], [[User:ngompa|Neal Gompa]]
> * Email: ignatenkobr...@fedoraproject.org,
> besse...@fedoraproject.org,
> ngomp...@gmail.com
>
> == Detailed Description ==
> Historically, software builds had a singular build configuration and
> required running the build within the project root. Nowadays, there
> are many build modes and options that can be configured in projects,
> different build settings (e.g. compiler flags) / types (release,
> debug) that can be applied and different tools that can be used to
> actually execute builds (compilers like gcc/clang, build job
> schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> discourages users of doing in-source builds and recommends doing
> out-of-source builds.
>
> From cmake.1:
>
>
> To maintain a pristine source tree, perform an out-of-source build by
> using a separate dedicated build tree. An in-source build in which
> the
> build tree is placed in the same directory as the source tree is also
> supported, but discouraged.
>
>
> The other part of the change is introduction of additional macros is
> creation of set of macro that can build, install and run tests in a
> backend-agnostic, vpath-aware (out-of-source, in-source) way.
>
> === Migration ===
>
> %cmake + %(make|ninja)_(build|install)
>
>
> There are multiple paths to complete the migration:
>
> * Add -C "%{_vpath_builddir}" to the
> %(make|ninja)_*
> * Replace %(make|ninja)_build and
> %(make|ninja)_install with %cmake_build and
> %cmake_install respectively
> * Redefine vpath builddir %global _vpath_builddir . to
> continue performing in-source builds (and optionally converting to
> the
> %cmake_*)
>
> Depending on the package, one of these options may be used to adapt
> to
> this change.
>
> %cmake -B builddir +
> %(make|ninja)_(build|install) -C builddir
>
> No changes are needed.
>
> == Benefit to Fedora ==
> * Follow CMake upstream recommendations when building packages
> * Brings Fedora package builds more in-line with how upstream
> projects
> expect them to be built
> * Improve compatibility with other RPM distributions that already do
> this
> * Support backend-agnostic way of building CMake projects
>
> == Scope ==
> * Proposal owners: Implement necessary macros, try to build packages
> that BuildRequires: cmake in a side tag, analyze
> failures
> and fix the relevant ones (introduced by this change).
> * Other developers: While proposal owners will try to fix all
> affected
> packages, there might be som
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 12:07 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing pa
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 11:57 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Ex
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote: > Richard Shaw 于 2020年7月8日周三 上午6:11写道： > > > Ok, so it appears this change was for F32+ only, so I can't merge > > master > > into f32 or earlier... > > > Maybe wait it to be backported into f31. The documents said this > will be > backported into older supported version. > > But now, merging master into older version is impossible, can cause > FTBTS. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6 Test them and leave karma please :) > > > > > This whole change is still broken AF. > > > > 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 > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8FjcEACgkQEV1auJxc Hh6+yxAAoJAojZ3en5ip2Lov+rciwDYKQaNW7231oYN2FsuG5EakUtu9CPjCAjRW 9n7W7Z2QmkrV/aPg3V304n4UFfNiKp01HHVF9vco8ljryrJObWSgwhzsv/8VO1k7 O+3rSieII8TcUyupAP5VfEqgJb0GFqdPeJpDNh3kovMbDAH6kdEH4ZGmwg/+xoPn 7gNBNl5r7FBik9i8nLhxm3sgglw0zjzAT1ac9PFrx8fx7eXo8clbuAD0i6bi8qJM 7i0NSTppf0KaeDRv88VZUwQMeZmjL2FrUvFIiWDlPvynjqZ6aGa4rNnJrEOLYbRy mpZTYa4qIWQ4+rgwwQbFfHoc168ZDenoWLR5YE+Qr/SzlyFN09WPmwffnFELHCX+ DJgv2vUHbwpAW7WTDrwjPLb2vmfK3wtI5StPGTh4Ntp8uy7j/B2hZipvub1TLeDb i26ouzKmHDOohizWrA/CQwlpxx7qFRPl5NuQveCp4oV7A8Xram/2h/J9UEA3skxr +3m5RJBtjUVWfdMGUkxqL88H/WN4Z6EkCQXhnZA9IAU043kORu3uImMArmv3ZkPT rhiSq443HNIpvUOd0nwtxx3O47YSv9uvQWY35PL27VqSznzuPnK1MiOxShF3w/iR MpYadfe/lruo6xwppPUhLRqilumQZDUUZuZptWwVwV5ykBkRxfw= =IeUt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote: > On 07.07.2020 19:57, Orion Poplawski wrote: > > What's the plan for EPEL8/7 compatibility? > > +1. The new Cmake macros behaviour must be backported to EPEL7/8. Feel free to submit patches to cmake3 and epel-rpm-macros. > Currently all fixed by proven packages SPEC files cannot be built on > EPEL branches. > > -- > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Fx9EACgkQEV1auJxc Hh7JzxAAtK8VXZz+jEdw1KICPRBOnsRvEcPBzpXbT7SLJd+84HRzxTFnWWJKqn3I 8hOKDl+lm00DKnplcIVPQXJ2g9CkV3a17bDWFGq9oW47eyH97lGRNUZifTKWcv7n OJNBB3OsU1jbhkKs0WtCX8NVmux2w9C/pCrSfcxCXxiWT7vz70NALqPX526sCDyb 6Unid5W/dZ35xl7tWmLm4WEwefpDOoCUF+khc9x8JPY6laczHmPk1RIdZ6g9a2FI Nwe6GNry1CWP22+wqxJlNQI0AEoev/olerIRD9hZ/TYiH+fRGqcOSefKDLE5TE3Y y9SF+5pEsELZgZm0hnI8b9QjIiNjf7m7RELn+Pdm/nS5eqJyIKuUUr/Zz+M4oDYW aZ2xToIyak769PmF6wr7x3oMAiT/OkvZRzwdpB6lC7cDslMAonsDisFIK8D7kE8x du/fHb/tIbbYuVVm4CnhxxY304U8NmBxCRsXZIYJNKdinG0nSAZUdy0Z5UqRk5VQ Tt2NMjSRBa2jV+AurM3thRCrJaVf6oPTKb6+pUsM6fBCF/HAoDN52AstxXNB97sS j/yOF4rPFg9N6i+ojDF7893n2ThkZXFERiqVTg2CWozLzK1g8AwfA66J38B5FQBJ QhL9vp8IO/aSrUa6pcfTbFTTozMncz7XZUDl4uStLFgUvkSzLxQ= =TyCb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora-
repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora-
repos (DEPENDENCY) and nothing depends on fedora-repos-modular so it is
not needed anymore (from the solver POV).
The fedora-repos is being pulled in by fedora-release-common (that is
brought by fedora-release-workstation or others). fedora-repos is not
part of the @core group in comps so its reason recorded in DNF DB is 1.
enum class TransactionItemReason : int {
UNKNOWN = 0,
DEPENDENCY = 1,
USER = 2,
CLEAN = 3, // hawkey compatibility
WEAK_DEPENDENCY = 4,
GROUP = 5
};
On my laptop:
❯ sqlite3 /var/lib/dnf/history.sqlite
sqlite> select trans_id,name,epoch,version,release,reason from
trans_item join rpm on rpm.item_id=trans_item.item_id where name like
'fedora-release%' or name like 'fedora-repos%';
1|fedora-release-common|0|33|0.8|1
1|fedora-release-identity-workstation|0|33|0.8|1
1|fedora-release-workstation|0|33|0.8|5
1|fedora-repos|0|33|0.6|1
1|fedora-repos-rawhide|0|33|0.6|1
21|fedora-release-common|0|33|0.9|1
21|fedora-release-common|0|33|0.8|1
21|fedora-release-identity-workstation|0|33|0.9|1
21|fedora-release-identity-workstation|0|33|0.8|1
21|fedora-release-workstation|0|33|0.9|5
21|fedora-release-workstation|0|33|0.8|5
143|fedora-repos-modular|0|33|0.8|1
143|fedora-repos-rawhide-modular|0|33|0.8|1
143|fedora-repos|0|33|0.8|1
143|fedora-repos|0|33|0.6|1
143|fedora-repos-rawhide|0|33|0.8|1
143|fedora-repos-rawhide|0|33|0.6|1
The packages that have been brought by the obsoletes inherit reason
(DEPENDENCY in this case) and since nothing depends on those they are
automatically cleaned up on the autoremove.
I don't know where / which the fix should be: DNF, comps or both.
Simply putting the fedora-repos-modular in comps won't help since DNF
is only using them when running `group install/update/remove`.
So sending this email just in case somebody will see this interesting
behavior.
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8G97AACgkQEV1auJxc
Hh6SkBAAo4iTvTmSImNbSRAZe6VzKfUJ1gBPjgMITEueM7pxa8zlZ7g2bOpl1UiI
TD+DKI953Qk2gZcN+WBvkQO13Cef/FD/lp6nGXvyo87mOs2ThSc+a6UgufEBceVY
Z5kGCoCQnfA6JkBtRtFdMbsCvVKtSRSOFJXlW7DCybLGKizUlFPqHdug0qxGpoO2
XWldoX0Bw0F11Pr2FqujZXlcfXe5G51lkfPFnChc0a4O0+d0/AsWZJ0dM0l1ff6l
GT43t+boiw9Dwp8KEBZTh7uTWQAeLAo9UxGIs2T2oZikHNwSSo13N6nwcS6x2XYd
AaHVET5dn4tITH9WjiknS9IHy06D5MZ8pWBRs46aav52Ro6GxNYeALYdhjaM2heG
mMGkjAWkXJ0qtaRR9qi68CfQiDfQjzYe0JXEHJTrLV+Pv42OrJJJoq7NWGOJbqV0
T9DYJoO63W74q/rttMNVMIBG8GtzbTBqoxuP9ooykpAzRv2LPn1Jc1L3eEBXSO0w
QW0SH5i6v6OgajCrc813TytboOua9zDZ55ENP0dJNXjqAiznZJjqrYG3RWUJH4cA
qx6xygK3OvZHm9vuL4VnXCp4wW/TDGf8MNGF0hoF75IbRN1+nrAAtGorx9BdV2g+
SvTV1Cs9CPyOKy0Q2brILtBZq6em6JNzkFAMg5h9xoce4brbyA8=
=UXSc
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" > > action on > > a system upgrade, because we want that package to be prensented on > > the > > system. However I worry that DNF does not possess a capability for > > doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually > installed > it, and opted into modularity, right? No, it should be installed by default. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HLXMACgkQEV1auJxc Hh5HOA/7Bf+x4zEaow3IVuBEbDgg97oe76kivIOyHnCySWp8xPVCgHPAo4NnBem1 534aECZMKZO6zRfSVPjkvxiImUy51TKkMy//OOUl8YJrb/wD6fuUEr3BrMkvDbdC ztIswL7wnnPLAQIE36JbmzvOLcyfZUp867rgbB7nDCwZ+3GAX1u4q8UZXCn/4FZl z624gtab1VGqddvN38nih+nGPMTOXLGEafhGaz5Y9tuFcZKA1nfSPn8HDNNieNNK 3lii2e9WHFgWJc7pbahDGbJGRC1YK8wDLDtfcr7FG9VBtkyWsErjI1VEhd5YUCld ex8aFRvA5SnxuvZriyDWr+DTITQXmGEPYxbXSpCM7Tufl42ZYccWr1EV0w5bWjf3 jKkM/zzb2P8CGomA6XWNkO43fVwjG6LTHpsq1h4q8EomXUfRNh4UfMYtOC5U3Nj1 5sHaMJJzzPHtzpBLEeYX2ns323bEr59Nc3qsbmfI7hiyBZffXYC1/LkJIaMxW7Dy Fufswm13S06330VGt1QEaa379opyUkLcFMs8SdGjGY5RCTA2CEyEL0VbZuwSC+ql B7bK0MvzuPtZpZ6CRgJnd0gMlMo29NQ9GOetYzLgHk52TkvTpj35vPtcv4/klRVI lKxwyizOi2aAWB+tMq3LTfs3N48/XTygMIZcavOp2p6b/EJc//o= =oXCM -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:35 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote: > > I don't know where / which the fix should be: DNF, comps or both. > > Simply putting the fedora-repos-modular in comps won't help since > > DNF > > is only using them when running `group install/update/remove`. > > What's to fix? Sounds like a feature, not a bug. It's well reasoned > above, > nothing depends on it. While it is behaving as it technically should, this is unexpected for the users. That's the only reason why I brought it here. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HMmoACgkQEV1auJxc Hh6K0g//b+BUTmjacqKE2nktWTdJGjmvqhVOuCvKp65i/EQV9CMtGidex3mEZnMN M/BT1eT8ZhLAh+4X1CVYxLzmknpOSKBbeK48kjBLzSXFvLRifgw7GXwnTkwp7TG7 jBlXI+k+qQZYx/Bsm09tgMNfiljHf0nsg7VpMkI4oVxmECx143LpNbZii8RI3dFc 0LX8vJ4KcEuE4Md3pORCOMGL6SDYrdBr/H0b9X2isY/JlsMWvIqMI1dZyodz5jMZ 2wCcscU7khpRNxmDI3xgnUgq9FwJnfKDciXG6EhUXTxA86kn1G7GvLaOw5zdZdDG 9mNjVaDLyL9Ik7fmbzY60/0mAYA4QK4L9s3yt/dVKDNP8LCCJR/ny+zMApimQ1jH Irgy4/XNJYWyhCARqGjoXGOLlguW3vjaTfA7+xZzvm1Hjk9D8fgAkvFQWwpzeFIm /Xj+nL4L35Zz5uOxYznUg/nmASV1jK+kvgGkf+RsGTx+MtYyURRekngNjVfT8BCb 3DRSmaE9EN9EH4A5ZBZNVATnhMGso6QB+B/HP5NUGBGKUlRtZ+uvGCV4c4omVZBE t5ep9yczF+uS5p+3YwzxT33AyVRnGYW2/uxuyXNEYz+yTCOAqCSk67/IpQe2wYfL 0oX7gu/1iNyZMYqdnnc+Crz7DbNKbmt/APbp2kP0Q5f4a7EYWCo= =j6pN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
; * Running mprime > (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); > choose local stress test, repeat by selecting 15 NOTE: mcatanzaro > has reported a huge impact, with both the session remaining mostly > responsive and EarlyOOM not kicking in (this makes sense, as overall > memory pressure is much lower, i.e. the session is waiting on memory > related IO less). The proposal owners have not been able to reproduce > this corner case so far. > * Log in two user A and B (same seat), run `stress-ng -c NCPUS` in > both. Switch between them and look at `top` to verify that the active > user gets a 5 times higher CPU share overall. > > == User Experience == > See other sections. > > == Dependencies == > There are no further dependencies. > > == Contingency Plan == > * Contingency mechanism: Remove uresourced from the default install > set and possibly also remove the preset again > * Contingency deadline: Final freeze > * Blocks release? No > > == Documentation == > Upstream is identical to the change owner. The upstream repository > has > a further README https://gitlab.freedesktop.org/benzea/uresourced > (which should not contain any more information than what is here). > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8JX4MACgkQEV1auJxc Hh69cw/9EUQU5YlPWl+yjOOLvMJ05Y27Eg2bg1INzde4iZIkuIydHS/ANXj9zIlF oMIbb7d1Gzh342Spdi7ANg7FdG23EnStJXWvDJb0XRVOcnbf6NIV0xttELMnSij+ NVMrdcmF5Vl2MI2HMBNfvLeyhCJAX6W/chf5lnyEwAWsEzRfagjs8I3WAMK6ZXr8 rMH+emU8xslhlTfON8tc30uvLWPAqkh85Md0X+Wl76lA+d09eCw0VsOQkI7hODKS l7L9s6mW1cpHv3wm9RmSJ3U3kq1IPCE4WvkjLcJIVtL1xX1qigrfBNnOXOjvdP+9 z9Ln4InzpmL/jsL6u715G9s0SE7MWelilN+K9juU8e2DZsqBBHY+S1j+YO1NZYXL K3jDH9Kr157jpyZnrBNcRzYJSt9wEL+jjNXtaErlfpwUsKCiIKeC7gaLFEbNS6Re iihGhJbHaRJB8O178s7WfUMD4Z/7EQoawBENKPLnxMsPdqkNcQC+1y9EGIs+PaQ5 I6L7FzhiSlqMrc8yQTXy8ebZKCMLZYy7bhLbrlhe3jYXHNHxCowyY2STBHiIYqkr LuqM5yo7+LUj7XIi4wTYFzXMhlkR8RZkDyzfe18tIq0Qvvrc2aOxPnjeUVZzPYkt NmKZIsQpw2ePGjNqWNSEk7tI5XeskrJEA4HRO26T2ydMBdgTMLE= =sFT5 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-07-11 at 10:33 +0200, Benjamin Berg wrote: > On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > > > == Summary == > > > This proposal adds cgroup based resource protections for the > > > active > > > graphical session. This is done by passing a memory protection of > > > 250MiB to active users (capped at 10% of system memory) and by > > > enabling other cgroup controllers (CPU, IO) to ensure important > > > session processes get the resources they need. > > > > Just curious, why 250MiB and not some other number? > > Initially, it was an educated guess (i.e. it seemed low enough to be > reasonable and high enough to be useful). > > I then continued to do a bit of experimentation and found that my > gnome-shell would stop page-faulting quite a lot if I gave the > session > processes >=350MiB of memory (measured by manually setting memory.max > and using "perf trace -F -p X"). > > Tejun suggests it is sufficient to protect around 50-75% of the > required memory, so 250MiB still seemed like a reasonable value after > those tests. > > Note that it is easy to change, simpliy modify /etc/uresourced.conf > (and, ideally reboot to ensure it is properly applied to your user > session). Thanks for detailed answer! > > > See: https://pagure.io/fedora-workstation/issue/154 > > > > > > == Owner == > > > * Name: [[User:benzea|Benjamin Berg]] > > > * Email: bb...@redhat.com > > > * Product: Workstation > > > * Responsible WG: Workstation > > > > > > > > > == Detailed Description == > > > Graphical sessions should always be responsive, even when the > > > machine > > > is doing a lot work or in the extreme case has started to thrash. > > > We > > > have started to ship EarlyOOM with F32, however, while it is a > > > good > > > solution to this date, it is shipped with the understanding of > > > being > > > superseded by other approaches in the future. > > > > Does it mean we do not ship earlyoom anymore or what is this > > sentence > > supposed to indicate? > > EarlyOOM is still very useful today. However, from my point of view, > EarlyOOM is just an intermediate measure until a more advanced > solution > is implemented and can be rolled out to users. This solution will be > based on oomd (or rather systemd-oomd) and will make heavy use of > cgroups to work well. My question was more targeted whether we are not going to ship anymore earlyoom by default with this change or will they be both shipped at thie moment until something better is ready? > This is a longer path, shipping uresourced puts us a step further > down > that road. > > > [SNIP] > > Benjamin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8JsGwACgkQEV1auJxc Hh4eYQ/9Fmqs5eP9swk+JlsIwS/KiUzx2IkPDeIsdu0bGdLFpm6/ElRtEWLQMAnP vHEX35MUNWwbnphNTMsFUqWUDQ7UyfaBRak8CPpggkNCCiDERJniyx9TEWaV6X9O cNdCDo5opOgfmjOf5Sn71ucf3Hg0IePE3W9BiwHne7CAqkXrPmouYa95GD6T/gFE WCbQIqPTFFYgU9igaU5gUcOLJS/TwJe9ABB8tH+gfolPBG+c+UaR1BepGJH8+9e8 3ixjEedcA4Hh5iLPxpPX5nmw91L81kENhLGWhWWAa8TbkImLQ2SC+Phb57lll3PW 0IaJuRMvTV/rD4fMqWpKgdwNHwIe3dqzAvjF1gsYjmPHaY0dFRcxYBI/E0WLna2q /IYEzehUDbFZggPN8L+y4s5xywDq6xvbHLCemrSwzW7zB7Q6cfgQkUUUk/MntAwQ PvcV5Mb5eQqia4aMMUPbtgnuhU56AiQoA95MNpH+xVTyMqcOUUlci73x0rcbNc1P B2QPydWeUaK6chsO5LIDnPhcRkf874MRMZfRgYfuEUSNRl8fa0bOPGYajjOu28hV tJXiXviWQNa2rJLhey3CJCbTRWyestLZCmR6oXcU2vX1EniNh9f7lvpjt4KxZ9pe L33Bj0znhpBg5YDni4bFgG+1eKQqSXS1E45dlqzg6XdfE/3noeU= =yzFL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: SwapOnZRAM and how it affects earlyoom thresholds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-07-14 at 01:28 +0900, Alexey A. wrote: > > The most > > common value I've found over a long period of time, for swap > > without > > hibernation is 50% of RAM. > > With low RAM (2G) it's easy to use swap on zram with disksize = 150% > MemTotal with opening browsers. > > 50% maybe OK with MemTotal=8G. > > > I'd like to hear from Alexey what he thinks about further reducing > > the > > values in earlyoom versus possibly raising the cap in > > zram-generator-defaults. > > It may be OK to reduce mem cap to 200 MiB. This threshold also can > work > well and may be sufficient to prevent freezing. > > I would suggest to increase zram disksize caps up to 75% and maybe to > 6GB. Please open ticket upstream with some more details, please. > пт, 10 июл. 2020 г. в 01:19, Chris Murphy : > > > On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter > > wrote: > > > > > > part of some irc discussions on > > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > > > > > raised my attention to related item, > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > > > As it stands currently with earlyoom, it's default thresholds are > > > 4% ram > > and > > > 10% swap before it acts. That's fine and dandy. > > > > > > Upon reading the SwapOnZRAM feature proposal, I see it is > > > advocating > > > allocating 50% of ram for swap. I'd like folks to consider and > > > evaluate > > how > > > this impacts earlyoom. It effectively makes the earlyoom memory > > threshold > > > double (right?). If so, at least think about lowering 4 to (2 or > > > 3), > > since > > > that will make earlyoom's behavior closer to before swaponzram > > > was > > > introduced. > > > > > > Thoughts? > > > > The net effect is that earlyoom is more likely to trigger than with > > a > > disk based swap because right now disk based swap is huge by > > default. > > It's huge by default to accommodate a hibernation image. The most > > common value I've found over a long period of time, for swap > > without > > hibernation is 50% of RAM. So this approximates those expectations. > > > > I'd like to hear from Alexey what he thinks about further reducing > > the > > values in earlyoom versus possibly raising the cap in > > zram-generator-defaults. I don't want to get too carried away > > there, > > because we are applying this to upgrades (wherever the to-be- > > obsoleted > > 'zram' package exists already even if not enabled). There is an > > opportunity, of course, right now and through beta testing, to keep > > on > > testing variations on both the size of the zram device used for > > swap > > and for earlyoom. But we also have another Fedora release, Fedora > > 34. > > So I'm more inclined to go conservative so long as that itself > > isn't > > causing problems. > > > > One thing I'm a bit skeptical of with reducing earlyoom's triggers > > is > > that free memory is needed for the recovery from an actual kill. > > Usually this is just sigterm. That's the first attempt. If that > > doesn't work then earlyoom issues sigkill, which is at a lower > > threshold already. > > > > > > -- > > 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 > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Mj3sACgkQEV1auJxc Hh4y9w/9GujtHWfY2C2QDcUfSaFwkGIgQgBP4oN4LC2QUlQyyQNAbMk7G
Re: make: *** No targets specified and no makefile found.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-22 at 07:24 +, Martin Gansser wrote: > Hi, > > cant't built guayadeque on rawhide [1] but on f32 [2] it works. > > [1] > https://kojipkgs.fedoraproject.org//work/tasks/4781/47574781/build.log > [2] > https://kojipkgs.fedoraproject.org//packages/guayadeque/0.4.7/0.16.20200717git3c54f64.fc32/data/logs/x86_64/build.log > > how can i solve this ? https://src.fedoraproject.org/rpms/guayadeque/c/00777277ceb0436439e0f670f3460e7bbe1c5984?branch=master > > Ragards > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8X9RAACgkQEV1auJxc Hh4KOA/+N/90Bik7hgxylmEzSYNMQWiDqd+9/BXP4qv0g/o0lfU0ukF5tjGn7IV7 jtfsWXzeuPKkpU8uHXqp4al36nSCCLIZ7m/jI9XJnFyP7IN7HP6Bqz/M/BcTmoRq 8l/5ruSrEnhtzCl8OeXYwKjPad+2E6r7HLGU9iwB52B7bRi/ZNZl8b7S2lgiiej9 L576W0WGhFR2Ez9CTlcopKZy9mWAN2xQaidNQwqJS5E9GYJuOx/GaeedFYWldEUU 0CDtAP/ZdxibM0kvbVt2VIGZa+i0ibIxmTVxoMql3mkAnEF2NEu2lN3+CqAsf8TP TjW4S4jVTLP/ucwOrdUQlKmVjzaRqZfIKadWbDKmBj47cMV8dw6fESGVdZx97kdG gPnnXiVuTu9Y9mc2+9tgd154S0vO9njzltCYmVglwwn6Dx9gGHusUnu5hLeWmsN7 35yoZNSNZ5JpFYm+TQFiPGUABrbtM57ScJ5kon+j2Z15l3peKezkjekPFDZep/Ao Qe2j8vg+oH0YRm4SyTOSFf39S1YByaXpn1ZSQnqWWx1DnnM5/vjznKjVPhiF6GFc SbfgZdTemTwO6aFr5/pqxg7jm+QmmMePOO0UusDpINrZf0DIa+I+voxU//l6eO26 iECFgerNP/s5HweOKmI2ZEZF6M5JBzGabTwmJguS3snmPHZLeHo= =M/JT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Schedule for Wednesday's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-07-22 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F33 System-Wide Change: Use %make_build and %make_install macros https://pagure.io/fesco/issue/2420 APPROVED (+5, 0, -0) F33 System-Wide Change: Golang 1.15 https://pagure.io/fesco/issue/2450 APPROVED (+7, 0, -0) = Followups = #topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs https://pagure.io/fesco/issue/2440 = New business = #topic #2448 F33 Self-Contained Change: PostgreSQL 13 https://pagure.io/fesco/issue/2448 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YHekACgkQEV1auJxc Hh7/mg/+J0LzJuhQv/nE0tR6pgZ96rACCx75GMLR4+xB0HAexYbMjCtcjml50Fxc WAIRw2gO+DMd5piH26tuUf69lHl86mZ1oP15o6K/Eb6fxsZcFlWdvD/f9+TFTFIW gApaKCl6WP4zo40h23o6w47QqxGX1FoWGbvZWlduvegb51Dv2MvMYq2SP0NACWCG U3T90kOM7BLZGv1cdgw4Zon7kF0sjYOi5bWWZBHgD+eMzgPYJnNh1Ee4gQzXiS9a Y5JretH0uIFyv7JM9hD1qLr0ti1HTx8ZiqyXEsCdS1iDowm+XhUlEzOYyxdtqAsi jHn6r6Aqdng9pXpqT49jhJOqVmO95Nwy45nu01iGJx3etlfDQNqcKtQ/KtLKvZBr n2SKZ7F2YA9aIgvVzPo63uNkl9QpUs+0HhBzP8uASN1TQREucqRKYMfdFQ0RDl87 6D3jGUzZeot58aWVdJ6kJl9Y+b0OObOU8ceDoQSttiWVirHD7MTSuohtXs6KKrvf Di7C20YlyRP8mSDAgeV8cDJ/qY+SkgWqa2igmqUA/g/ZEu1+eCVOqPggdWT2StIz GDdjFAxIXSqic9vWrh53sWE7rJODmfw+i0C177btQTCvMQ1E5wRPZ949/gye+8UA H9Is+iuGutFNf0ROSx5Doy3VtZYgOaP3juNmOqoYVdhQV+5Ie8s= =0cum -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Schedule for Wednesday's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = #fedora-meeting-2: FESCO (2020-07-22) = Meeting started by ignatenkobrain at 14:01:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-22/fesco.2020-07-22-14.01.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:01:13) * #2448 F33 Self-Contained Change: PostgreSQL 13 (ignatenkobrain, 14:06:06) * AGREED: Give one more week for the change owners to respond (+7, 0, -0) (ignatenkobrain, 14:10:27) * #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs (ignatenkobrain, 14:10:35) * LINK: https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs#Fully_automated_packaging (King_InuYasha, 14:15:49) * LINK: https://github.com/rpm-software-management/rpm/pull/1239 (King_InuYasha, 14:39:43) * AGREED: Ask @nim to clarify the proposal on those questions, revisit when we have the answers (+6, 1, -0) (ignatenkobrain, 14:44:08) * Next week's chair (ignatenkobrain, 14:44:20) * ACTION: decathorpe will chair next meeting (ignatenkobrain, 14:46:55) * Open Floor (ignatenkobrain, 14:46:59) * #2445 Proposal: Make the "shortcut" decision process require a specific request and assent (ignatenkobrain, 15:02:12) * AGREED: APPROVED (+8, 0, -0), bcotton will squash commits (ignatenkobrain, 15:06:01) * Open Floor (ignatenkobrain, 15:06:10) * LINK: https://pagure.io/flock (King_InuYasha, 15:07:11) * ACTION: ignatenkobrain to submit FESCo session for Flock (ignatenkobrain, 15:08:30) Meeting ended at 15:11:52 UTC. Action Items - * decathorpe will chair next meeting * ignatenkobrain to submit FESCo session for Flock Action Items, by person - --- * decathorpe * decathorpe will chair next meeting * ignatenkobrain * ignatenkobrain to submit FESCo session for Flock * **UNASSIGNED** * (none) People Present (lines said) - --- * King_InuYasha (87) * ignatenkobrain (54) * sgallagh (37) * zbyszek (34) * decathorpe (32) * nirik (25) * zodbot (25) * bcotton (13) * mhroncok (11) * cverna (10) * cmurf (5) * RaphGro (3) * pingou (1) * Conan_Kudo (0) * Eighth_Doctor (0) * dcantrell (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YWA0ACgkQEV1auJxc Hh4dRw//Saw76tSw4ERLwRoMCwfSioK+nkjLTrGO3+y6EZjez3LZWwbx8QDy3sAz ghunCu6KF8OXBPzxuZRY7euE7qkF9HYNjSQe9zNGSXJi9afyH0m4CrLIctTMFEDb m9cB7RyN1oez/Qeiw6U4jBRlWkLlyYghiml+Z91HbGZPTDWZwZFNmnAs+zB5Wqm4 v5HD6IcxvL7L6f7vX272frjrr2Scjq86Iao5yY6GsAsSA49iZIeVLGEu8KktYfLc lWrJjZMtNt19DZ7cXzqAwmdsUggx8WEp8Dabb1vQblb8Hw/DfU4atGopB+Ns1JEi NipA6gpmGGah7esnx4be45wFLpSE3NFQF7zqTBRcjE7Sl4dLYzE3zmSyKDDV6i/f Xv7X675INCmxWEYkyT1NcuqXKQg1ZcWM3tytOYx4KrVof7TQBT+ET00Db0T/HYfE uUrBu7VSmwPRb9zOaB70kXLGx+Bovuf34ATtn0CPJtFwxuNTjPJlsx/XJMtLVwSX 4oO1nQS/tR0Cd8ki31y+2f6MmoUWIHvI3aYBree2z3jB+5AiH6jAlDmRjIQT4Pow uvEwAhoFM02Yf9UIYv+pPRtAi6oLbQzCyVpfy61V1HQxs3pCPfnvGGaK8yVlBmF1 Ls/9+/h+xgDuzpIzho8m67s7mejHJsf36J6KJQnjOPkGrqn5iwk= =5+mx -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Summary/Minutes from today's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Re-sending with the proper subject.. = #fedora-meeting-2: FESCO (2020-07-22) = Meeting started by ignatenkobrain at 14:01:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-22/fesco.2020-07-22-14.01.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:01:13) * #2448 F33 Self-Contained Change: PostgreSQL 13 (ignatenkobrain, 14:06:06) * AGREED: Give one more week for the change owners to respond (+7, 0, -0) (ignatenkobrain, 14:10:27) * #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs (ignatenkobrain, 14:10:35) * LINK: https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs#Fully_automated_packaging (King_InuYasha, 14:15:49) * LINK: https://github.com/rpm-software-management/rpm/pull/1239 (King_InuYasha, 14:39:43) * AGREED: Ask @nim to clarify the proposal on those questions, revisit when we have the answers (+6, 1, -0) (ignatenkobrain, 14:44:08) * Next week's chair (ignatenkobrain, 14:44:20) * ACTION: decathorpe will chair next meeting (ignatenkobrain, 14:46:55) * Open Floor (ignatenkobrain, 14:46:59) * #2445 Proposal: Make the "shortcut" decision process require a specific request and assent (ignatenkobrain, 15:02:12) * AGREED: APPROVED (+8, 0, -0), bcotton will squash commits (ignatenkobrain, 15:06:01) * Open Floor (ignatenkobrain, 15:06:10) * LINK: https://pagure.io/flock (King_InuYasha, 15:07:11) * ACTION: ignatenkobrain to submit FESCo session for Flock (ignatenkobrain, 15:08:30) Meeting ended at 15:11:52 UTC. Action Items - * decathorpe will chair next meeting * ignatenkobrain to submit FESCo session for Flock Action Items, by person - --- * decathorpe * decathorpe will chair next meeting * ignatenkobrain * ignatenkobrain to submit FESCo session for Flock * **UNASSIGNED** * (none) People Present (lines said) - --- * King_InuYasha (87) * ignatenkobrain (54) * sgallagh (37) * zbyszek (34) * decathorpe (32) * nirik (25) * zodbot (25) * bcotton (13) * mhroncok (11) * cverna (10) * cmurf (5) * RaphGro (3) * pingou (1) * Conan_Kudo (0) * Eighth_Doctor (0) * dcantrell (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YWHMACgkQEV1auJxc Hh43+w/6A3xlVj4XSbz8CrUct5fpk5Svj/GxHmxBwSYnW8/G3rrRt1xxx/9xi5WU pzenY8OUTtDZ8c/27BaPQb2GF019q7WXuo0Y86Wb9m5cVYUjpvDxhSr0tZwRqIvJ Yw5voPtJgalFEMDvkxAr3VAXoryh957ZYvs9HsTDpmM6GLHdsRhlp9secTgTz0Z9 R/SRrKiE4qvlh922leTs+RkkhKEVwQ6EVvqC7o1q7gB0b0Kas+Pt4CBTjMs1XQ7e /Tv7mamYvxiKJ5FR4uMcDPNWff0qupq7otXRPBfZHXhpR0Oed9Iku7AQUIUgWgoA yfhflXAG9f5QsTEsryA/OgC0x491gdSJei2SrewNSZjGpceh0vHYqjv6gR4gLrD+ 3A0UAV8ZLf8Iup/HbHg0oGnMniRtwxBn7wh+mECrl32b7K3e3Y89Z179Kzhu9r60 k4igSpE/gbW6408YwqoNx4hgBOSNrA7e3rM6pynUdbobQV08ySp5AlzcCknZWFz+ WZ3Jh4gJGZOgwD5Hw5JLIVAuHvsCIaCjqCju0hUJ+UPRAZPbZo+kVyfQjcDwAA5e Afkh5kCEm1N0YGRIwdPs8GBclCc9ooNS8KN9GKGTtMf+9Djrb808oc+CtmP4PRto zXStH18CxqEiGwPynQGOwEzu0HSsOlOkEo9yReeO+2GpVIpWK8k= =oeeH -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: License change for rust-crossbeam-channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-22 at 11:41 -0700, Josh Stone wrote: > rust-crossbeam-channel-0.4.3-1.fc33 has changed its license from a > combined "(MIT or ASL 2.0) and BSD" to just "MIT or ASL 2.0". > See also: https://github.com/crossbeam-rs/crossbeam/issues/536 Cool! That means now we can remove `and BSD` from most of the binary crates. Though now there is some other dep now bringing up `zlib` license > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YkQQACgkQEV1auJxc Hh6VZg//V/rKB+YmP3oejChwllmhDQSziv4k/meAYVs00s+R5jgEeM3AfbYJRtoj AYZqiABSNhyGGUVNNZySrOLgjpomTYhFW1HGMW+4NB8FSTKO4PaHBVDP5oJkzlzH G0+PulqAxI3Xb74rYsTY5JA2TQMf77DTRzm1EfOCDHbwd1b20x86PQ5777qFVkfg EzuoaBaSaNVSzkAaMnx+EvioCbMZEACPgs4t8O0tDU6ewJHMDYamFcIhHPztEBin U+wP0rvdBssqrwCRayXd4fSWxG+MQRVVmpmSQm40GFc0yB960lX9kAikYHNGoXrI IyGcdyEIVVry9R1PQFjQ7DxyGfk7bh4FC1JfSMUVo9NMZgToNN42ou2hWu3YqlOk Tz1hbBPcURut0gsfVEzVYtIiee9M/QmY/plkFDluRkBikwkfRyTL1JcstXNLRwGf ZG8eaqrLeSEz1j5Cgkm9PIUmy00C1frCRg1v4K2ORZVDpwASr1u1quN1zLGRjT7u F1IBv/3AnLZhlUAJAEXVhYjcC0B8Ho1a33C6EkoeINZi3aZ2LNAhv9pq9v3pzgnY BSy6w75gFNEsl9yk17VIcPjA3kemubLRg3IpX7DS5fH7OWIgczXZ0oNonowV0EMj /MIYSnrRVthFOCC6BhbfpkQ5CFiCGzPsN/m33fbFkCjukfHq4k8= =pdiZ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > Hi. In rare cases building packages with LTO producing binaries or > > libraries which have bigger size then if they have built without > > LTO. For example 'kitty' package: > > > > * with LTO: > > - koji task > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > 1.79 MB glfw-wayland.so > > 1.99 MB glfw-x11.so > > 4.78 MB fast_data_types.so > > 8.56 MB total > > > > * no LTO > > - koji > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > 1.65 MB glfw-wayland.so > > 1.84 MB glfw-x11.so > > 4.51 MB fast_data_types.so > > 8.00 MB total > > > > Difference is 7%. What we should do in such case? Should we disable > > LTO for such packages? Or there is still could be gains from faster > > code execution speed? > I'd tend to leave LTO on, but it's totally your call. Without > looking at the > binaries, sources and compiler dumps I'd hazard a guess you're > getting a lot of > cross module inlining, but very little identical code folding. THe > former tends > to make things bigger, but faster. The latter tends to shrink code > with little > impact on runtime performance. - From what I see in this case, -ffat-lto-objects generates code that is bigger than without -flto. -flto alone generates smaller code than without -flto. > Unfortunately comparing this stuff in an LTO world is much harder > than in a non- > LTO world. You can't just bisect it to a .o or function that's > larger :( > > > jeff > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bQ2cACgkQEV1auJxc Hh4KkA/+LfGfZGjkZZcgJfgRYhVGdjpFpjdEjwTPQh/75IFnkd0q0BAJlHAxuvKA HQ0z/EQH5dfXIXtKYzg8+t+EHYjABPio+BSllNtv8OOAFW55TsRgxHCq/vDDjugU gM9urFXTvYnK8P52/EFMmZoIcg0PiLEMDArsoeUmHxzBDLSi4755HAsz/dz0VWxa BpJWWavTDHSFgkjMbqsrU/E9n/N0WdRdhaG1vuYEc80OLuQxGA9wSyT8fCOauGGZ 6qg2l93gHmQQys/V1PDOup2Dpjgr/GFEN3H0Q55UhdszXhfYKmipA0gS+rX7evyH jj9bYN+VMm8Qq9i7wmwPHsa88kYztozsx3vXYebpnuxgzG0uq1F+A2WoxkECtztc n5Ug0wUbYZSEBbpzxt7Tr9zaYoJ+TzdT8Ce+doub+P2fmnGO3Rhz87V0MGyiYcSG siBdnMBh26MwkQxRJkb5oR7WwCDmde2Rt7SmkVQuBI4sIUN418tif+bJUV+PMeMJ Q2hvqZryKeMHqGx7QmoUqSr5dMcZaY4zvMVbWggn2+qphNyI7gdc+QZMmtJ+5xeG ZpgKjMDofW8PWgD8Pn3ToeN/pyIzFFd17vvYY1sFD1ZpKE229T58eP6kWiMOnGyL j2/BI5UGjH0s+bhiUDLvfyVregBJRSxTptP975HLjjiP4GWUYN0= =taI4 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > Hi. In rare cases building packages with LTO producing binaries > > > > or > > > > libraries which have bigger size then if they have built > > > > without > > > > LTO. For example 'kitty' package: > > > > > > > > * with LTO: > > > > - koji task > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > 1.79 MB glfw-wayland.so > > > > 1.99 MB glfw-x11.so > > > > 4.78 MB fast_data_types.so > > > > 8.56 MB total > > > > > > > > * no LTO > > > > - koji > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > 1.65 MB glfw-wayland.so > > > > 1.84 MB glfw-x11.so > > > > 4.51 MB fast_data_types.so > > > > 8.00 MB total > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > disable > > > > LTO for such packages? Or there is still could be gains from > > > > faster > > > > code execution speed? > > > I'd tend to leave LTO on, but it's totally your call. Without > > > looking at the > > > binaries, sources and compiler dumps I'd hazard a guess you're > > > getting a lot of > > > cross module inlining, but very little identical code folding. > > > THe > > > former tends > > > to make things bigger, but faster. The latter tends to shrink > > > code > > > with little > > > impact on runtime performance. > > > > From what I see in this case, -ffat-lto-objects generates code that > > is > > bigger than without -flto. -flto alone generates smaller code than > > without -flto. > The fat-lto-objects bits are not used during an LTO link. They exist > solely to > cover the case where there's a .o/.a that ends up installed. Well, I tell what I see :) Compiling kitty with settings below produces this big /usr/lib64/kitty/kitty/fast_data_types.so: * Without any LTO-related flags: 4.52 MB * With -flto: 4.30 MB * With -flto -ffat-lto-objects: 4.79 MB Well, I did not run compilation multiple times but don't think it will change much. > jeff > > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bROYACgkQEV1auJxc Hh6dsBAApNegXihpiJ3SVr5IiD4pypEUDUNyBTY+Tp+HINNWdQHVivs2jYWwfVpU rNokkpq6Crgj68wznNGnwq+/eSP7DQwP3rN0TsAsfVydO1w0xBkz3zC47Y/7NPRR Ceeoalajz6/EqN89LDyYT/aQbfT4zbOV0ZTnUQrOe21URg2L1mUBSjeCoDortkC+ 1um7lyexAFroXmU4fQSdUMNTLrSolfFJPlkqeaaiJorqMvzex08xrv1D3vRrIyBD 6Z0NdPjB1nMbIWdCwTATYkbARzBH/88AUE3RZbjvRakr1BTBmsye3XaFts3Gn4Q8 ykINe/ImL+sDxm+cxKEAzafnr2GZQPvxYbwPjF+CEwDsBhqn92goOewgrrxNh+sq e9yf0vpJhmJBIq/hwPgvTihn9vB7oqxjT2/CFjIlNFCc5FyZfuSJPsyE/8EA4Vb6 9b8vj/q+gAlt9Ty/aJ+yhxQsO8zT0ZrVOi4L1/5RQna9HGca3YyKH4v9exHRMSpo HtbacKKg+7zYvVif7go6ERGBM680Pi5t6ypaH2cWOg4lRX50BVNn5NDpvatnOD/L VxJ1p+LmhRaoXT1Kzb4P5bNaSl+o7lPAjIjRk8osVll7m2jxFJxKfMLvnUBUaROj 5mVGA2JgdgGXKOdeFLHPsDmxs9B+EdR+PMzhMkcbww+MbhPXOiM= =gRTO -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
