Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Friday, December 20, 2019 5:48:17 PM MST Alexander Ploumistos wrote: > On Sat, Dec 21, 2019 at 1:43 AM John M. Harris Jr > wrote: > > > > > > On Friday, December 20, 2019 5:33:59 PM MST Rahul Sundaram wrote: > > > > > Hi > > > > > > > > > > > > On Fri, Dec 20, 2019 at 7:15 PM John M. Harris Jr > > > > > > > > > > > > > > > wrote: > > > > > > > > ...release notes are published on the docs site as they have always > > > > > been: > > > > > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ > > > > > > > > > > > > > > > > Where are the changes from the previous release there? > > > > > > > > > > > > Do you mean 30? > > > > > > > > > > > > https://docs.fedoraproject.org/en-US/docs/ click on 30 > > > > > > > > > > > > Rahul > > > > > > > > No, I mean the things that actually changed between the two. "What's new" > > or so on. This looks like it's just general documentation, and not > > release notes? Ah, yep that's what I'm looking for. Looks like we need to start pointing to the wiki in the "release notes" on the docs site, so that people can actually see what has changed, if we implement this Change. -- 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
Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]
On Friday, December 20, 2019 7:27:20 PM MST Chris Murphy wrote: > On Fri, Dec 20, 2019 at 5:42 PM John M. Harris Jr > wrote: > > > > > > On Friday, December 20, 2019 1:53:41 PM MST Chris Murphy wrote: > > > > > On Fri, Dec 20, 2019 at 1:37 PM Jan Kratochvil > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote: > > > > > > > > > > > > > > > > > == Summary == > > > > > Enabling fstrim.timer will cause fstrim.service to execute weekly, > > > > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > > > > > > > > > > > > > > > > > > > > > > > This is AFAIK not enough for LUKS drives, will it be supported for > > > > LUKS? > > > > > > > > > > > > > > > Good question. This change [1] happened in Fedora 27. But because > > > there's neither `discard` mount option, nor fstrim.timer enabled by > > > default, that feature doesn't really do anything for most users. This > > > feature proposal would build on that previous approval. > > > > > > > > > > > > If your LUKS drives are listed in fstab, they will have fstrim issued > > > and it will pass down to the physical drive. I've updated the proposal > > > how to modify fstrim.service unit to specify --all instead of --fstab, > > > so all mounted devices have fstrim passed to them. > > > > > > > > > > > > [1] > > > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt > > > > > > > > What do you mean about the `discard` option? If users wish to enable > > `discard`, they can do so. For LUKs devices, this is already the default, > > if one uses Anaconda to install. > > > "discard mount option" and "fstrim.timer" refer to the mounted file > system. The /etc/crypttab discard option only allows discards to > passthrough from the file system to the device, enabling it doesn't > cause discards to happen. I understand that. See my previous message... -- 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
[389-devel] 389 DS nightly 2019-12-21 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/21/report-389-ds-base-1.4.3.0-20191221git3022f46.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]
On Fri, Dec 20, 2019 at 5:42 PM John M. Harris Jr wrote: > > On Friday, December 20, 2019 1:53:41 PM MST Chris Murphy wrote: > > On Fri, Dec 20, 2019 at 1:37 PM Jan Kratochvil > > wrote: > > > > > > > > > > > On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote: > > > > > > > == Summary == > > > > Enabling fstrim.timer will cause fstrim.service to execute weekly, > > > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > > > > > > > > > > > This is AFAIK not enough for LUKS drives, will it be supported for LUKS? > > > > > > Good question. This change [1] happened in Fedora 27. But because > > there's neither `discard` mount option, nor fstrim.timer enabled by > > default, that feature doesn't really do anything for most users. This > > feature proposal would build on that previous approval. > > > > If your LUKS drives are listed in fstab, they will have fstrim issued > > and it will pass down to the physical drive. I've updated the proposal > > how to modify fstrim.service unit to specify --all instead of --fstab, > > so all mounted devices have fstrim passed to them. > > > > [1] > > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt > > What do you mean about the `discard` option? If users wish to enable > `discard`, they can do so. For LUKs devices, this is already the default, if > one uses Anaconda to install. "discard mount option" and "fstrim.timer" refer to the mounted file system. The /etc/crypttab discard option only allows discards to passthrough from the file system to the device, enabling it doesn't cause discards to happen. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Sat, Dec 21, 2019 at 1:43 AM John M. Harris Jr wrote: > > On Friday, December 20, 2019 5:33:59 PM MST Rahul Sundaram wrote: > > Hi > > > > On Fri, Dec 20, 2019 at 7:15 PM John M. Harris Jr > > > > wrote: > > > > ...release notes are published on the docs site as they have always > > > > been: > > > > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ > > > > > > Where are the changes from the previous release there? > > > > Do you mean 30? > > > > https://docs.fedoraproject.org/en-US/docs/ click on 30 > > > > Rahul > > No, I mean the things that actually changed between the two. "What's new" or > so on. This looks like it's just general documentation, and not release notes? https://fedoraproject.org/wiki/Releases/31/ChangeSet ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
Hi On Fri, Dec 20, 2019 at 7:43 PM John M. Harris Jr wrote: > On Friday, December 20, 2019 5:33:59 PM MST Rahul Sundaram wrote: > > No, I mean the things that actually changed between the two. "What's new" > or > so on. This looks like it's just general documentation, and not release > notes? > Nope. Those are release notes and every section covers what's new. Not general documentation Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Friday, December 20, 2019 5:33:59 PM MST Rahul Sundaram wrote: > Hi > > On Fri, Dec 20, 2019 at 7:15 PM John M. Harris Jr > > wrote: > > > ...release notes are published on the docs site as they have always > > > been: > > > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ > > > > Where are the changes from the previous release there? > > Do you mean 30? > > https://docs.fedoraproject.org/en-US/docs/ click on 30 > > Rahul No, I mean the things that actually changed between the two. "What's new" or so on. This looks like it's just general documentation, and not release notes? -- 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
Re: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]
On Friday, December 20, 2019 1:53:41 PM MST Chris Murphy wrote: > On Fri, Dec 20, 2019 at 1:37 PM Jan Kratochvil > wrote: > > > > > > > On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote: > > > > > == Summary == > > > Enabling fstrim.timer will cause fstrim.service to execute weekly, > > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > > > > > > > This is AFAIK not enough for LUKS drives, will it be supported for LUKS? > > > Good question. This change [1] happened in Fedora 27. But because > there's neither `discard` mount option, nor fstrim.timer enabled by > default, that feature doesn't really do anything for most users. This > feature proposal would build on that previous approval. > > If your LUKS drives are listed in fstab, they will have fstrim issued > and it will pass down to the physical drive. I've updated the proposal > how to modify fstrim.service unit to specify --all instead of --fstab, > so all mounted devices have fstrim passed to them. > > [1] > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt What do you mean about the `discard` option? If users wish to enable `discard`, they can do so. For LUKs devices, this is already the default, if one uses Anaconda to install. -- 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote: > Issuing the command once per week harms no one Based on what's actual in the Change proposal, this is not the case. Even if this goes through, in my opinion, it should only affect the GNOME Spin, or perhaps even "all graphical" spins at most. > It's reasonable to enable fstrim.timer now. *And* conduct parallel > development to create a kernel facility to do this automatically, if > it's even possible. I'm not convinced the drives report enough > information to do this properly automatically, rather than on a > schedule. What do you mean by that? It's the filesystem that would make the call, not the hardware itself. If the hardware was capable of figuring out when this call is useful, and wouldn't impact the user, it'd likely do the call itself, in the firmware. > And to be true, Windows and macOS have used their own white > listing method to do this, meaning quite a lot of devices aren't > getting these hints and are left out. I'm particularly concerned about the handling of the hardware that this will negatively affect, as I happen to have an SK Hynix part that is affected by momentary I/O freezes whenever TRIM is called, and I don't want users to have to deal with that. The correct time to call TRIM on these devices is when there aren't ongoing I/ O operations. -- 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
Hi On Fri, Dec 20, 2019 at 7:15 PM John M. Harris Jr wrote: > > > ...release notes are published on the docs site as they have always been: > > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ > > Where are the changes from the previous release there? > Do you mean 30? https://docs.fedoraproject.org/en-US/docs/ click on 30 Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Friday, December 20, 2019 8:07:50 AM MST Ben Cotton wrote: > On Fri, Dec 20, 2019 at 4:13 AM John M. Harris Jr > wrote: > > > > > > One, didn't we kill the release notes package recently? > > > Yes, but ... > > > > Are release notes even > > being written now, or do you have to go and check the wiki for the list > > of > > Changes? > > > > > > > ...release notes are published on the docs site as they have always been: > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ Where are the changes from the previous release there? -- 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
CPE Weekly: 2019-12-20
Hi everyone, Welcome to the CPE team weekly project update mail! Important Note: Please note there will be no weekly emails over the holiday period of 23rd December 2019 - 2nd January 2020*. The next CPE weekly email will be sent on Friday 10th January 2020. As you may be aware, either from the CPE weekly emails or from previous years, Red Hat has a mandatory shutdown period between Christmas and New Year in many countries. This allows most associates to celebrate the holiday season with friends and family and recharge their batteries after a busy year. Multiple Red Hat teams will be observing this period, including Fedora & CentOS infrastructure teams, and we want to raise awareness that availability will be minimal during this time. *While the formal shutdown period ends on the 2nd of January 2020, many people will not be back until Monday the 6th of January 2020. As all of our team members are also passionate Community members, there may be some coverage, but this is not guaranteed and will be on a best effort basis. Any coverage offered will ultimately be at the personal choice of the individual during their time off. We want to take this time to wish you and yours a healthy and happy Christmas period and a most prosperous New Year. We look forward to working closely with you over the coming year! Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. High Level Project Updates: Fedora: General Updates Nagios plugins were fixed to work on EL8/F31 Support was added for fedora messaging wire format to jms-messaging plugin There is one prerequisite:RabbitMQ PR needs to be merged first Other work this week with RabbitMQ includes: An issue in RabbitMQ jms-messaging plugin PR was fixed Two new PR’s in Anitya The issue in the-new-hotness was also fixed when it stopped consuming messages - it was caused by empty version and the fix for this already in Anitya master The team deployed distgit-bugzilla-sync script in openshift Pagure Updates We also worked on pagure-dist-git PR review/merges this week The team cleaned up the bugzilla override patches for pagure-dist-git https://pagure.io/pagure-dist-git/pull-request/82 We modified output of pagure-dist-git/scripts/pagure_poc.py to include assignee information https://pagure.io/pagure-dist-git/pull-request/90 We updated distgit_bugzilla_sync/script.py to read the assignee information from above instead of fedora-scm-requests https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/40 We fixed mdapi headers for CORS: https://pagure.io/mdapi/pull-request/93 And they are already reviewed and merged :) We also wrote script to read assignee information from fedora-scm-requests and added it to dist-git Tiger Team Updates: OSBS Issue deploying the aarch64 cluster. There is a problem while using openshift-ansible to authenticate with quay.io Bodhi CD Tiger Team Working on dockerizing the celery worker on the vm Community Fire Fighting Team Merged the PR adding a new API endpoint to pagure allowing to enable/disable git hooks Decommissioned ci-cc-rdu01 Good progress on anitya 0.18.0 (see below) Added CORS headers to mdapi making it easier to do cross-domain JSON/ajax requests to it Application Retirements Elections Everything should be ready now to move Elections to Communishift so stay tuned for a move date in the new year! Fedocal No progress on kanban board last eight weeks - looks abandoned https://teams.fedoraproject.org/project/fedora-calendar/kanban Jlanda’s permission error https://pagure.io/fedora-infrastructure/issue/8274 Nuancier Benson Muite is now working on OIDC authentication PR from sebwoj - Porting to Fedora messaging EPEL 8 Modularity This currently needs a rebuild to epel-release with new mirrorlist links https://src.fedoraproject.org/rpms/epel-release/pull-request/4) The team are currently facing this EPEL 8 Playground Modularity Blocker: https://pagure.io/fm-orchestrator/issue/1541 CentOS The CR variant from the Stream composes, seems to work, 8.1.1911 will use a similar variant to populate the CR repo on the mirrors The team is also still working on preparing the next migration to wiki.centos.org www.centos.org Forums The team have started new ansible roles to automate deploy + upgrade of those migrated services We are still finishing templates for mailman ansible
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On Fri, Dec 20, 2019 at 5:25 PM Tom Stellard wrote: > > On 12/20/2019 03:20 PM, Neal Gompa wrote: > > On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard wrote: > >> > >> On 12/20/2019 02:01 PM, Neal Gompa wrote: > >>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard wrote: > > On 12/20/2019 03:33 AM, Nicolas Chauvet wrote: > > Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit : > >> > >> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc > >> > >> == Summary == > >> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++ > >> symlinks are managed by update-alternatives. > >> > >> == Owner == > >> * Name: [[User:tstellar| Tom Stellard]] > >> * Email: > >> > >> == Detailed Description == > >> The gcc package currently installs symlinks to /usr/bin/cc and > >> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++ > >> respectively. For this change, the gcc package will be modified so > >> that update-alternatives creates and manages these symlinks. > >> > >> In addition to modifying the gcc package, the clang package will be > >> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as > >> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives > >> will have a lower priority than the gcc alternatives, so that by > >> default, gcc will provide the /usr/bin/cc and /usr/bin/c++ > >> implementations. > >> > >> The clang package currently has a run-time dependency on gcc, so this > >> ensures that gcc will always provide the default implementation, > >> because it's impossible to install clang without gcc. > >> > >> The only way users will be able to change the /usr/bin/cc or > >> /usr/bin/c++ implementations will be by explicitly using the > >> update-alternatives tool. > >> > >> == Benefit to Fedora == > >> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as > >> the default C/C++ compilers. Being able to easily swap out these > >> implementation will provide a lot of flexibility within Fedora for > >> doing things like: > >> > >> * Setting up alternative buildroots for testing. > >> * Installing a gcc wrapper script to /usr/bin/cc to help migrate > >> packages to new compiler flags or to capture statistics about compiler > >> usage. > >> * Letting users experiment easily with alternate compilers. > >> * Easily switch between system gcc and a development version of gcc. > >> > >> == Scope == > >> * Proposal owners: The proposal owner will implement the necessary > >> changes in the gcc and clang packages. > >> > >> * Other developers: The gcc maintainers will be responsible for > >> reviewing and approving changes to the gcc package. > >> > >> * Release engineering: (a check of an impact with Release Engineering > >> is needed) > >> * Policies and guidelines: No policies or guidelines will need to be > >> updated as a result of this change. > >> * Trademark approval: N/A (not needed for this Change) > >> > >> > >> == Upgrade/compatibility impact == > >> This change should not impact upgradeability. > >> > >> == How To Test == > >> CI tests will be added to the gcc package to ensure that /usr/bin/cc > >> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when > >> installed. There will also be a CI test added to the clang package to > >> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when > >> clang is installed. > >> > >> == User Experience == > >> This change will give users a much better way to experiment using > >> other compilers for their own development. They will be able to > >> easily switch between different compilers without having to modify > >> their projects build system or make non-standard changes to their > >> Fedora system. > >> > >> == Dependencies == > >> This change has no other dependencies besides the changes to the gcc > >> and clang packages. > >> > >> == Contingency Plan == > >> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner > >> will revert changes made to gcc and clang packages and rebuild. > >> * Contingency deadline: If the changes are not complete by 2 weeks > >> before the mass rebuild, then we will consider postponing to the next > >> Fedora release and back out any changes that were made. > >> * Blocks release? No > >> * Blocks product? None > >> > >> == Documentation == > >> Release notes will be added for this change. > >> > >> == Release Notes == > >> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by > >> update-alternatives. If you would like to change these symlinks to > >> point to another compiler, like clang, for example, you can use
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 12/20/2019 03:20 PM, Neal Gompa wrote:
> On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard wrote:
>>
>> On 12/20/2019 02:01 PM, Neal Gompa wrote:
>>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard wrote:
On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
>>
>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>>
>> == Summary ==
>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>> symlinks are managed by update-alternatives.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email:
>>
>> == Detailed Description ==
>> The gcc package currently installs symlinks to /usr/bin/cc and
>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>> respectively. For this change, the gcc package will be modified so
>> that update-alternatives creates and manages these symlinks.
>>
>> In addition to modifying the gcc package, the clang package will be
>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
>> will have a lower priority than the gcc alternatives, so that by
>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>> implementations.
>>
>> The clang package currently has a run-time dependency on gcc, so this
>> ensures that gcc will always provide the default implementation,
>> because it's impossible to install clang without gcc.
>>
>> The only way users will be able to change the /usr/bin/cc or
>> /usr/bin/c++ implementations will be by explicitly using the
>> update-alternatives tool.
>>
>> == Benefit to Fedora ==
>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>> the default C/C++ compilers. Being able to easily swap out these
>> implementation will provide a lot of flexibility within Fedora for
>> doing things like:
>>
>> * Setting up alternative buildroots for testing.
>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>> packages to new compiler flags or to capture statistics about compiler
>> usage.
>> * Letting users experiment easily with alternate compilers.
>> * Easily switch between system gcc and a development version of gcc.
>>
>> == Scope ==
>> * Proposal owners: The proposal owner will implement the necessary
>> changes in the gcc and clang packages.
>>
>> * Other developers: The gcc maintainers will be responsible for
>> reviewing and approving changes to the gcc package.
>>
>> * Release engineering: (a check of an impact with Release Engineering is
>> needed)
>> * Policies and guidelines: No policies or guidelines will need to be
>> updated as a result of this change.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> This change should not impact upgradeability.
>>
>> == How To Test ==
>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>> installed. There will also be a CI test added to the clang package to
>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>> clang is installed.
>>
>> == User Experience ==
>> This change will give users a much better way to experiment using
>> other compilers for their own development. They will be able to
>> easily switch between different compilers without having to modify
>> their projects build system or make non-standard changes to their
>> Fedora system.
>>
>> == Dependencies ==
>> This change has no other dependencies besides the changes to the gcc
>> and clang packages.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
>> will revert changes made to gcc and clang packages and rebuild.
>> * Contingency deadline: If the changes are not complete by 2 weeks
>> before the mass rebuild, then we will consider postponing to the next
>> Fedora release and back out any changes that were made.
>> * Blocks release? No
>> * Blocks product? None
>>
>> == Documentation ==
>> Release notes will be added for this change.
>>
>> == Release Notes ==
>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>> update-alternatives. If you would like to change these symlinks to
>> point to another compiler, like clang, for example, you can use these
>> commands:
>>
>> `update-alternatives --set cc /usr/bin/clang`
>>
>> `update-alternatives --set c++ /usr/bin/clang++`
>
> Does this process even works in RPM context ? given rpm -E %{__cc}
> outputs gcc, I don't think
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard wrote:
>
> On 12/20/2019 02:01 PM, Neal Gompa wrote:
> > On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard wrote:
> >>
> >> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> >>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email:
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively. For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers. Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed. There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development. They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives. If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`
> >>>
> >>> Does this process even works in RPM context ? given rpm -E %{__cc}
> >>> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> >>> for
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 12/20/2019 02:01 PM, Neal Gompa wrote:
> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard wrote:
>>
>> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
>>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
== Summary ==
Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
symlinks are managed by update-alternatives.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
The gcc package currently installs symlinks to /usr/bin/cc and
/usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
respectively. For this change, the gcc package will be modified so
that update-alternatives creates and manages these symlinks.
In addition to modifying the gcc package, the clang package will be
modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
will have a lower priority than the gcc alternatives, so that by
default, gcc will provide the /usr/bin/cc and /usr/bin/c++
implementations.
The clang package currently has a run-time dependency on gcc, so this
ensures that gcc will always provide the default implementation,
because it's impossible to install clang without gcc.
The only way users will be able to change the /usr/bin/cc or
/usr/bin/c++ implementations will be by explicitly using the
update-alternatives tool.
== Benefit to Fedora ==
Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
the default C/C++ compilers. Being able to easily swap out these
implementation will provide a lot of flexibility within Fedora for
doing things like:
* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate
packages to new compiler flags or to capture statistics about compiler
usage.
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.
== Scope ==
* Proposal owners: The proposal owner will implement the necessary
changes in the gcc and clang packages.
* Other developers: The gcc maintainers will be responsible for
reviewing and approving changes to the gcc package.
* Release engineering: (a check of an impact with Release Engineering is
needed)
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
CI tests will be added to the gcc package to ensure that /usr/bin/cc
and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
installed. There will also be a CI test added to the clang package to
ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
clang is installed.
== User Experience ==
This change will give users a much better way to experiment using
other compilers for their own development. They will be able to
easily switch between different compilers without having to modify
their projects build system or make non-standard changes to their
Fedora system.
== Dependencies ==
This change has no other dependencies besides the changes to the gcc
and clang packages.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal Owner
will revert changes made to gcc and clang packages and rebuild.
* Contingency deadline: If the changes are not complete by 2 weeks
before the mass rebuild, then we will consider postponing to the next
Fedora release and back out any changes that were made.
* Blocks release? No
* Blocks product? None
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
update-alternatives. If you would like to change these symlinks to
point to another compiler, like clang, for example, you can use these
commands:
`update-alternatives --set cc /usr/bin/clang`
`update-alternatives --set c++ /usr/bin/clang++`
>>>
>>> Does this process even works in RPM context ? given rpm -E %{__cc}
>>> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
>>> for __cxx, __cpp)
>>
>> /usr/bin/cc is the default compiler for cmake projects.
>>
>>> If that's only supposed to work in a local compilation context (not
>>> with RPM), what is the benefit from using alternatives rather than
>>> export CC=clang ?
>>
>> I'm actually not sure how
Re: Discrepancy between koji build and repository content
On Fri, 2019-12-20 at 14:42 -0800, Samuel Sieb wrote: > It's not a library, so it definitely won't be in the 64-bit repo. > The 32-bit repos have been discontinued, so the only way to get it Whoops. It makes sense. Thanks. A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Discrepancy between koji build and repository content
On 12/20/19 12:54 PM, alcir...@gmail.com wrote: Looking at https://koji.fedoraproject.org/koji/buildinfo?buildID=1423008 I can see that, for instance, samba-winbind-clients was successfully built for every architecture, in particular x86_64 and i686. But dnf reports that only the x86_64 package is available, and indeed, looking inside https://dl.fedoraproject.org/pub/fedora/linux/updates/31/Everything/x86_64/Packages/s/ there is not the i686 RPM. It's not a library, so it definitely won't be in the 64-bit repo. The 32-bit repos have been discontinued, so the only way to get it now is from koji. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard wrote:
>
> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> > Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
> >>
> >> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
> >>
> >> == Summary ==
> >> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> >> symlinks are managed by update-alternatives.
> >>
> >> == Owner ==
> >> * Name: [[User:tstellar| Tom Stellard]]
> >> * Email:
> >>
> >> == Detailed Description ==
> >> The gcc package currently installs symlinks to /usr/bin/cc and
> >> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> >> respectively. For this change, the gcc package will be modified so
> >> that update-alternatives creates and manages these symlinks.
> >>
> >> In addition to modifying the gcc package, the clang package will be
> >> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> >> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
> >> will have a lower priority than the gcc alternatives, so that by
> >> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> >> implementations.
> >>
> >> The clang package currently has a run-time dependency on gcc, so this
> >> ensures that gcc will always provide the default implementation,
> >> because it's impossible to install clang without gcc.
> >>
> >> The only way users will be able to change the /usr/bin/cc or
> >> /usr/bin/c++ implementations will be by explicitly using the
> >> update-alternatives tool.
> >>
> >> == Benefit to Fedora ==
> >> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> >> the default C/C++ compilers. Being able to easily swap out these
> >> implementation will provide a lot of flexibility within Fedora for
> >> doing things like:
> >>
> >> * Setting up alternative buildroots for testing.
> >> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> >> packages to new compiler flags or to capture statistics about compiler
> >> usage.
> >> * Letting users experiment easily with alternate compilers.
> >> * Easily switch between system gcc and a development version of gcc.
> >>
> >> == Scope ==
> >> * Proposal owners: The proposal owner will implement the necessary
> >> changes in the gcc and clang packages.
> >>
> >> * Other developers: The gcc maintainers will be responsible for
> >> reviewing and approving changes to the gcc package.
> >>
> >> * Release engineering: (a check of an impact with Release Engineering is
> >> needed)
> >> * Policies and guidelines: No policies or guidelines will need to be
> >> updated as a result of this change.
> >> * Trademark approval: N/A (not needed for this Change)
> >>
> >>
> >> == Upgrade/compatibility impact ==
> >> This change should not impact upgradeability.
> >>
> >> == How To Test ==
> >> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> >> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> >> installed. There will also be a CI test added to the clang package to
> >> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> >> clang is installed.
> >>
> >> == User Experience ==
> >> This change will give users a much better way to experiment using
> >> other compilers for their own development. They will be able to
> >> easily switch between different compilers without having to modify
> >> their projects build system or make non-standard changes to their
> >> Fedora system.
> >>
> >> == Dependencies ==
> >> This change has no other dependencies besides the changes to the gcc
> >> and clang packages.
> >>
> >> == Contingency Plan ==
> >> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
> >> will revert changes made to gcc and clang packages and rebuild.
> >> * Contingency deadline: If the changes are not complete by 2 weeks
> >> before the mass rebuild, then we will consider postponing to the next
> >> Fedora release and back out any changes that were made.
> >> * Blocks release? No
> >> * Blocks product? None
> >>
> >> == Documentation ==
> >> Release notes will be added for this change.
> >>
> >> == Release Notes ==
> >> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> >> update-alternatives. If you would like to change these symlinks to
> >> point to another compiler, like clang, for example, you can use these
> >> commands:
> >>
> >> `update-alternatives --set cc /usr/bin/clang`
> >>
> >> `update-alternatives --set c++ /usr/bin/clang++`
> >
> > Does this process even works in RPM context ? given rpm -E %{__cc}
> > outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> > for __cxx, __cpp)
>
> /usr/bin/cc is the default compiler for cmake projects.
>
> > If that's only supposed to work in a local compilation context (not
> > with RPM), what is the benefit from using alternatives rather than
> > export CC=clang ?
>
> I'm actually not sure how much better alternatives is that using only
>
[Bug 1785770] New: perl-EV-4.31 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1785770 Bug ID: 1785770 Summary: perl-EV-4.31 is available Product: Fedora Version: rawhide Status: NEW Component: perl-EV Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: c...@redhat.com, emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 4.31 Current version/release in rawhide: 4.30-1.fc32 URL: https://metacpan.org/release/EV Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7069/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 12/20/2019 05:27 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Dec 19, 2019 at 03:47:13PM -0600, Neal Gompa wrote: >>> == Release Notes == >>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by >>> update-alternatives. If you would like to change these symlinks to >>> point to another compiler, like clang, for example, you can use these >>> commands: >>> >>> `update-alternatives --set cc /usr/bin/clang` >>> >>> `update-alternatives --set c++ /usr/bin/clang++` >>> >> >> I don't know if I want *more* alternatives usage in Fedora. I like the >> fact that a basic buildroot is generally supposed to work without >> scriptlets... On the other hand, I think we're already using >> alternatives for ld... >> >> Aside from making it possible to swap the system compiler with >> alternatives, what benefit do we get? Are there other, less script-y >> approaches that we could use? > > I'm not sure that the benefits are really that big. For most cases, instead > of setting alternatives, the obvious solution would be to set $CC. Can you > expand a bit on why alternatives, which is effectively a global setting, > is preferred to a local override? > This is a good point, and something I don't have numbers for yet. As mentioned in my other response, I've only done rebuilds with CC=/usr/bin/cc *and* the alternatives changes together. These changes together get around ~70% of the packages building with clang. -Tom > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
>>
>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>>
>> == Summary ==
>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>> symlinks are managed by update-alternatives.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email:
>>
>> == Detailed Description ==
>> The gcc package currently installs symlinks to /usr/bin/cc and
>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>> respectively. For this change, the gcc package will be modified so
>> that update-alternatives creates and manages these symlinks.
>>
>> In addition to modifying the gcc package, the clang package will be
>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
>> will have a lower priority than the gcc alternatives, so that by
>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>> implementations.
>>
>> The clang package currently has a run-time dependency on gcc, so this
>> ensures that gcc will always provide the default implementation,
>> because it's impossible to install clang without gcc.
>>
>> The only way users will be able to change the /usr/bin/cc or
>> /usr/bin/c++ implementations will be by explicitly using the
>> update-alternatives tool.
>>
>> == Benefit to Fedora ==
>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>> the default C/C++ compilers. Being able to easily swap out these
>> implementation will provide a lot of flexibility within Fedora for
>> doing things like:
>>
>> * Setting up alternative buildroots for testing.
>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>> packages to new compiler flags or to capture statistics about compiler
>> usage.
>> * Letting users experiment easily with alternate compilers.
>> * Easily switch between system gcc and a development version of gcc.
>>
>> == Scope ==
>> * Proposal owners: The proposal owner will implement the necessary
>> changes in the gcc and clang packages.
>>
>> * Other developers: The gcc maintainers will be responsible for
>> reviewing and approving changes to the gcc package.
>>
>> * Release engineering: (a check of an impact with Release Engineering is
>> needed)
>> * Policies and guidelines: No policies or guidelines will need to be
>> updated as a result of this change.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> This change should not impact upgradeability.
>>
>> == How To Test ==
>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>> installed. There will also be a CI test added to the clang package to
>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>> clang is installed.
>>
>> == User Experience ==
>> This change will give users a much better way to experiment using
>> other compilers for their own development. They will be able to
>> easily switch between different compilers without having to modify
>> their projects build system or make non-standard changes to their
>> Fedora system.
>>
>> == Dependencies ==
>> This change has no other dependencies besides the changes to the gcc
>> and clang packages.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
>> will revert changes made to gcc and clang packages and rebuild.
>> * Contingency deadline: If the changes are not complete by 2 weeks
>> before the mass rebuild, then we will consider postponing to the next
>> Fedora release and back out any changes that were made.
>> * Blocks release? No
>> * Blocks product? None
>>
>> == Documentation ==
>> Release notes will be added for this change.
>>
>> == Release Notes ==
>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>> update-alternatives. If you would like to change these symlinks to
>> point to another compiler, like clang, for example, you can use these
>> commands:
>>
>> `update-alternatives --set cc /usr/bin/clang`
>>
>> `update-alternatives --set c++ /usr/bin/clang++`
>
> Does this process even works in RPM context ? given rpm -E %{__cc}
> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> for __cxx, __cpp)
/usr/bin/cc is the default compiler for cmake projects.
> If that's only supposed to work in a local compilation context (not
> with RPM), what is the benefit from using alternatives rather than
> export CC=clang ?
I'm actually not sure how much better alternatives is that using only CC=clang.
I haven't done a full rebuild with only CC=clang and without
the proposed /usr/bin/cc alternative pointing to clang to see what the
numbers look like.
What I have done is build all the packages that depend on gcc with /usr/bin/cc
pointing to clang and also CC=/usr/bin/cc (and
Discrepancy between koji build and repository content
Hello. Looking at https://koji.fedoraproject.org/koji/buildinfo?buildID=1423008 I can see that, for instance, samba-winbind-clients was successfully built for every architecture, in particular x86_64 and i686. But dnf reports that only the x86_64 package is available, and indeed, looking inside https://dl.fedoraproject.org/pub/fedora/linux/updates/31/Everything/x86_64/Packages/s/ there is not the i686 RPM. There is a specific reason or there is some kind of bug? Thanks, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]
On Fri, Dec 20, 2019 at 1:37 PM Jan Kratochvil wrote: > > On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote: > > == Summary == > > Enabling fstrim.timer will cause fstrim.service to execute weekly, > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > This is AFAIK not enough for LUKS drives, will it be supported for LUKS? Good question. This change [1] happened in Fedora 27. But because there's neither `discard` mount option, nor fstrim.timer enabled by default, that feature doesn't really do anything for most users. This feature proposal would build on that previous approval. If your LUKS drives are listed in fstab, they will have fstrim issued and it will pass down to the physical drive. I've updated the proposal how to modify fstrim.service unit to specify --all instead of --fstab, so all mounted devices have fstrim passed to them. [1] https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 12/19/2019 01:47 PM, Neal Gompa wrote: > On Thu, Dec 19, 2019 at 3:44 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc >> >> == Summary == >> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++ >> symlinks are managed by update-alternatives. >> >> == Owner == >> * Name: [[User:tstellar| Tom Stellard]] >> * Email: >> >> == Detailed Description == >> The gcc package currently installs symlinks to /usr/bin/cc and >> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++ >> respectively. For this change, the gcc package will be modified so >> that update-alternatives creates and manages these symlinks. >> >> In addition to modifying the gcc package, the clang package will be >> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as >> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives >> will have a lower priority than the gcc alternatives, so that by >> default, gcc will provide the /usr/bin/cc and /usr/bin/c++ >> implementations. >> >> The clang package currently has a run-time dependency on gcc, so this >> ensures that gcc will always provide the default implementation, >> because it's impossible to install clang without gcc. >> >> The only way users will be able to change the /usr/bin/cc or >> /usr/bin/c++ implementations will be by explicitly using the >> update-alternatives tool. >> >> == Benefit to Fedora == >> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as >> the default C/C++ compilers. Being able to easily swap out these >> implementation will provide a lot of flexibility within Fedora for >> doing things like: >> >> * Setting up alternative buildroots for testing. >> * Installing a gcc wrapper script to /usr/bin/cc to help migrate >> packages to new compiler flags or to capture statistics about compiler >> usage. >> * Letting users experiment easily with alternate compilers. >> * Easily switch between system gcc and a development version of gcc. >> >> == Scope == >> * Proposal owners: The proposal owner will implement the necessary >> changes in the gcc and clang packages. >> >> * Other developers: The gcc maintainers will be responsible for >> reviewing and approving changes to the gcc package. >> >> * Release engineering: (a check of an impact with Release Engineering is >> needed) >> * Policies and guidelines: No policies or guidelines will need to be >> updated as a result of this change. >> * Trademark approval: N/A (not needed for this Change) >> >> >> == Upgrade/compatibility impact == >> This change should not impact upgradeability. >> >> == How To Test == >> CI tests will be added to the gcc package to ensure that /usr/bin/cc >> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when >> installed. There will also be a CI test added to the clang package to >> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when >> clang is installed. >> >> == User Experience == >> This change will give users a much better way to experiment using >> other compilers for their own development. They will be able to >> easily switch between different compilers without having to modify >> their projects build system or make non-standard changes to their >> Fedora system. >> >> == Dependencies == >> This change has no other dependencies besides the changes to the gcc >> and clang packages. >> >> == Contingency Plan == >> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner >> will revert changes made to gcc and clang packages and rebuild. >> * Contingency deadline: If the changes are not complete by 2 weeks >> before the mass rebuild, then we will consider postponing to the next >> Fedora release and back out any changes that were made. >> * Blocks release? No >> * Blocks product? None >> >> == Documentation == >> Release notes will be added for this change. >> >> == Release Notes == >> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by >> update-alternatives. If you would like to change these symlinks to >> point to another compiler, like clang, for example, you can use these >> commands: >> >> `update-alternatives --set cc /usr/bin/clang` >> >> `update-alternatives --set c++ /usr/bin/clang++` >> > > I don't know if I want *more* alternatives usage in Fedora. I like the > fact that a basic buildroot is generally supposed to work without > scriptlets... On the other hand, I think we're already using > alternatives for ld... > > Aside from making it possible to swap the system compiler with > alternatives, what benefit do we get? Are there other, less script-y > approaches that we could use? > > The only benefit here is being able to swap out the system compiler. For a typical user, I'm not sure there is a good alternative to this for changing the default compiler. However, there are other options we have in the Fedora buildroots, to switch the default compiler, like using the __cc and __cxx macros and making sure the
Re: List of long term FTBFS packages to be retired in February (release candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The only living packages from this list without current f31 or rawhide builds: elasticsearch (gradle hellscape) expresso (abandoned upstream) infinispan (lots of deps orphaned) shim-unsigned-aarch64 (will let pjones handle) shim-unsigned-x64 (will let pjones handle) golang-gopkg-sourcemap was renamed to golang-gopkg-sourcemap-1 libocrdma was obsoleted by rdma-core nuvola-app-groove is dead because Microsoft Groove was discontinued at the end of 2017 owncloud is dead due to orphaning for 6+ weeks yaws is dead due to orphaning for 6+ weeks All the others have f31 or f32 builds. Tom -BEGIN PGP SIGNATURE- Version: FlowCrypt 7.3.4 Gmail Encryption Comment: Seamlessly send and receive encrypted email wkYEAREIAAYFAl39MHcACgkQPF6ZrZMFQmDgfgCgghbHvY/+OiuR8Cgk3Yb1 vilsEmMAoJJEySdo2H9wL4bOybG9ifhpngyo =NOCI -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
fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]
On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote: > == Summary == > Enabling fstrim.timer will cause fstrim.service to execute weekly, > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` This is AFAIK not enough for LUKS drives, will it be supported for LUKS? Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
I was heavily affected by this not running by default. I was almost convinced my hardware was broken, since there is no warning while having it not enabled, the last journalctl entries when the system freezes during a copy operation is from libinput that the mouse events can't be handled due to some latency. fstrim saved the day. My first thoughts after reading into this thread was if this could not be done automatically at storage device idle time instead of at time[date] but this has already been mentioned. Thank you Chris for this Change proposal. On Fri, Dec 20, 2019 at 8:57 PM Chris Murphy wrote: > > On Fri, Dec 20, 2019 at 10:22 AM Lennart Poettering > wrote: > > > > On Fr, 20.12.19 18:11, Louis Lagendijk (lo...@fazant.net) wrote: > > > > > On Fri, 2019-12-20 at 17:46 +0100, Lennart Poettering wrote: > > > > > > > > Or let me ask this differently: the "discard" mount option of various > > > > kernel file systems, what does it differently than what this new > > > > fedora feature is supposed to do? > > > > > > > fstrim does the discard once a week (or whenever it it triggered), > > > discard as a mount option does trigger discard when a block is freed. > > > Depending on the drive it may actually slow down IO as the SSD will > > > need more time to finish the IO. Doing an fstrim leaves the processing > > > to the SDD. That was the argument years ago. I don't know if this is > > > > Hmm? if the if the fs enqeues the trimming or userspace does, it's > > always the SSD that executes it... > > Sure. And devices, nor their standards, provide sufficient information > indicating their preference for such hints. Nor do devices indicate > the ensuing firmware behavior, as a result of getting those hints. And > the unsophisticated state of the kernel's facilities reflects the > unsophisticated state of devices and standards. > > > > still true for modern SSD's. For older SSDs fstrim would stil be the > > > safer option. And automatic trimming is long overdue in my opinion. > > > > So if trimming is slow, that's still no reason to let userspace pick a > > time for it. Sounds like the kernel fs should have discard=lazy or > > discard=5min or so. Which would enqueue a trim run automatically after > > the last IO after some delay. > > > > Still not grokking why to do this in userspace. > > The rudimentary userspace method proposed, exists today. The weekly > issuance makes it unlikely users will notice the effects, in the case > they have a device+workload that would exhibit a delay while the > firmware acts on the command, while still reaping the benefit. > > Whereas the existing kernel facility is inadequate, and a more > sophisticated facility doesn't exist, and isn't likely to exist in the > near future. The problem isn't well enough understood, nor is the > solution - and I direct that at the industry, not just kernel > developers. Should this change, and the kernel gets these facilities, > it's trivial to back out the userspace change. > > It is really a case of accepting an existing one size fits all > solution. Rejecting the proposal probably does hurt a tiny number of > users, but it does so disproportionately. > > -- > 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
Self Introduction: Michal Bocek
Hi, I've been working at Red Hat mainly on tools dealing with upgrades of major versions of RHEL. I've also developed a tool called convert2rhel which automates the conversion of CentOS and Oracle Linux to RHEL. I've recently open sourced the conver2rhel code and my goal now is to get it to EPEL (only, not Fedora). I would greatly appreciate a review of the package: https://bugzilla.redhat.com/show_bug.cgi?id=1785735 Thank you, -- Michal Bocek OS and Application Modernization Senior Software Engineer Red Hat Czech s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: List of long term FTBFS packages to be retired in February (release candidate)
On Fri, Dec 20, 2019 at 12:34:41PM -0700, Jerry James wrote: > On Fri, Dec 20, 2019 at 11:28 AM Kevin Fenzi wrote: > > During this, we hit a small number of packages that were built for > > really old releases and inherited into current, active releases. > > In order for them to avoid the archiving process, I tagged them into > > another tag: do-not-archive-yet. > [snip] > > coin-or-FlopC++-1.2.4-5.fc27 do-not-archive-yetreleng > > There are newer builds of coin-or-FlopC++ for F31 and Rawhide, but not > for F30. Is that the issue? yeah. > > > sympow-1.019-17.fc28 do-not-archive-yetreleng > > There are newer sympow builds for F30+, so I'm not sure why this one > showed up on your list. It was likely fixed after we tagged it. I can untag that one now. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Self Introduction: Michal Bocek
Hi, I've been working at Red Hat mainly on tools dealing with upgrades of major versions of RHEL. I've also developed a tool called convert2rhel which automates the conversion of CentOS and Oracle Linux to RHEL. I've recently open sourced the conver2rhel code and my goal now is to get it to EPEL (only, not Fedora). I would greatly appreciate a review of the package: https://bugzilla.redhat.com/show_bug.cgi?id=1785735 Thank you, -- Michal Bocek OS and Application Modernization Senior Software Engineer Red Hat Czech s.r.o. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February (release candidate)
On Fri, Dec 20, 2019 at 11:28 AM Kevin Fenzi wrote: > During this, we hit a small number of packages that were built for > really old releases and inherited into current, active releases. > In order for them to avoid the archiving process, I tagged them into > another tag: do-not-archive-yet. [snip] > coin-or-FlopC++-1.2.4-5.fc27 do-not-archive-yetreleng There are newer builds of coin-or-FlopC++ for F31 and Rawhide, but not for F30. Is that the issue? > sympow-1.019-17.fc28 do-not-archive-yetreleng There are newer sympow builds for F30+, so I'm not sure why this one showed up on your list. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, Dec 20, 2019 at 10:22 AM Lennart Poettering wrote: > > On Fr, 20.12.19 18:11, Louis Lagendijk (lo...@fazant.net) wrote: > > > On Fri, 2019-12-20 at 17:46 +0100, Lennart Poettering wrote: > > > > > > Or let me ask this differently: the "discard" mount option of various > > > kernel file systems, what does it differently than what this new > > > fedora feature is supposed to do? > > > > > fstrim does the discard once a week (or whenever it it triggered), > > discard as a mount option does trigger discard when a block is freed. > > Depending on the drive it may actually slow down IO as the SSD will > > need more time to finish the IO. Doing an fstrim leaves the processing > > to the SDD. That was the argument years ago. I don't know if this is > > Hmm? if the if the fs enqeues the trimming or userspace does, it's > always the SSD that executes it... Sure. And devices, nor their standards, provide sufficient information indicating their preference for such hints. Nor do devices indicate the ensuing firmware behavior, as a result of getting those hints. And the unsophisticated state of the kernel's facilities reflects the unsophisticated state of devices and standards. > > still true for modern SSD's. For older SSDs fstrim would stil be the > > safer option. And automatic trimming is long overdue in my opinion. > > So if trimming is slow, that's still no reason to let userspace pick a > time for it. Sounds like the kernel fs should have discard=lazy or > discard=5min or so. Which would enqueue a trim run automatically after > the last IO after some delay. > > Still not grokking why to do this in userspace. The rudimentary userspace method proposed, exists today. The weekly issuance makes it unlikely users will notice the effects, in the case they have a device+workload that would exhibit a delay while the firmware acts on the command, while still reaping the benefit. Whereas the existing kernel facility is inadequate, and a more sophisticated facility doesn't exist, and isn't likely to exist in the near future. The problem isn't well enough understood, nor is the solution - and I direct that at the industry, not just kernel developers. Should this change, and the kernel gets these facilities, it's trivial to back out the userspace change. It is really a case of accepting an existing one size fits all solution. Rejecting the proposal probably does hurt a tiny number of users, but it does so disproportionately. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [minimization] Feedback Pipeline feedback wanted
On Thu, 2019-12-19 at 13:10 +0100, Adam Samalik wrote:
> On Fri, Dec 13, 2019 at 8:20 PM Adam Williamson
> wrote:
>
> > On Fri, 2019-12-13 at 09:19 -0800, Kevin Fenzi wrote:
> > > It would be great if they could include the size +/- of all the images.
> > > Of course the most important ones would be boot.iso, workstation and
> > > server, but labs and spins could be very helpfull as well.
> >
> > This sort of thing is what fedfind can help with. As an example of
> > where you'd start:
> >
> > #!/bin/python3
> >
> > import fedfind.release
> > import fedfind.helpers
> >
> > rel = fedfind.release.get_release(cid="Fedora-Rawhide-20191213.n.0")
> > #rel = fedfind.release.get_release(1)
> > for img in rel.all_images:
> > imgid = fedfind.helpers.identify_image(img, out='string')
> > if img['disc_number'] > 1:
> > imgid += " disc {0}".format(img['disc_number'])
> > size = img.get('size')
> > if not size:
> > # this is something I should make fedfind handle...
> > # I swear it used to!
> > size = fedfind.helpers.get_size(img['direct_url'])
> > print("{0}: {1}".format(imgid, size))
> >
> > hopefully it's pretty simple to see where to go from there. :) You can
> > try it with either of the 'rel' lines and it'll work...so you can
> > compare the image sizes from Fedora Core 1 with those from today's
> > Rawhide nightly, though they only have one image entirely in common
> > (Everything-boot-iso).
> >
> > You can see I had to add a couple of bits to smoothly work with the
> > info for very old composes...I'll maybe tweak that a bit in fedfind
> > itself today, that code doesn't actually get *used* a lot so when I do
> > want to do something like this I usually find some issues that have
> > crept in.
> >
> > This should work for any Pungi 4 compose that hasn't been garbage
> > collected yet, and also for all stable releases and old candidate
> > composes.
> >
> > It...*could* also work for non-candidate (i.e. nightly) Pungi 4
> > composes that have been garbage collected by retrieving the info from
> > PDC, but this thread has made me realize that's a path that I've sort
> > of shut off with some design choices and I need to think about how to
> > open it up again.
> >
>
> That is really cool. And I'm aware of the compose report that goes to devel.
>
> What I'm looking for is sizes of (and other info about) some specific use
> cases,
> that we don't actually produce as artifacts. Like the httpd web server
> installed
> on top of an image we produce, etc. They represent something that people
> often install themselves as opposed us producing an image.
Right, I was replying to Kevin's suggestion, which *is* about the sizes
of the images. I guess we can say that since fedfind can do the above,
either the Feedback Pipeline wouldn't need to implement Kevin's
suggestion, or if it wants to be the frontend for it, fedfind could
potentially help on the back end.
> My goal is to detect changes that affect those use cases. It's conceptually
> similar to some parts of the compose report, just looking at a different
> thing.
>
> There is also one technical difference: Because we don't produce the use
> cases
> as artifacts (we produce the very useful bits people can use to build
> those),
> the service also needs to build them so it actually has something to look
> at.
>
> So I prototyped the service to validate its usefulness. And I'd be happy to
> throw away most of the code if something similar exists already — which was
> the reason it's not really optimized.
>
> Now I'm thinking if I could somehow use fedfind or the CI infrastructure
> for that...
Yeah, going back to the overall idea of the Feedback Pipeline, I just
wanted to make sure you were aware of this so we can avoid any
duplication if possible. If it turns out that fedfind/check-compose
don't help, hey, never mind. I'm happy to look at extending it in ways
that make sense if it could be useful, though doing some things may be
architecturally difficult and not worth the effort - it really depends
a lot on the details. I'm happy to kick those details around with you
any time, IRC or email :)
One thing I am going to do if I can find time is somehow set things up
so the data files we collect from openQA tests that check-compose uses
as its inputs don't get garbage collected after a while. We *should*
have interesting data on service loadouts and so on going back to the
date when I first started having openQA collect this data, but because
the files get garbage collected, we don't :( I will try and fix that
for sure, so if nothing else, systems like this can use that historical
data going forward.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Re: List of long term FTBFS packages to be retired in February (release candidate)
So, I thought it might be good to mention another list, related to this
list.
Eariler this year we archived old Fedora builds off to seperate archive
drives. This was to allow us to have a smaller set of things that are
active so we could keep them on fast storage, but move the old things
that people rarely if ever access off to slower storage. This process is
still ongoing, but we moved about 20TB or so of old fc6->f29 builds off
to archive volumes.
During this, we hit a small number of packages that were built for
really old releases and inherited into current, active releases.
In order for them to avoid the archiving process, I tagged them into
another tag: do-not-archive-yet.
You can see the list with: koji list-tagged do-not-archive-yet
These packages should match up with the FTBFS from older/eol releases,
but perhaps we should check.
kevin
--
Build Tag Built by
arachne-pnr-0.1-0.3.20170628git7e135ed.fc28 do-not-archive-yetbrouhaha
arpack-3.5.0-6.fc28 do-not-archive-yetreleng
aspell-hi-0.02-18.fc28do-not-archive-yetreleng
audio-convert-mod-3.46.0b-14.fc28 do-not-archive-yetreleng
blackbox-0.70.1-31.fc28 do-not-archive-yetreleng
coin-or-FlopC++-1.2.4-5.fc27 do-not-archive-yetreleng
dnssec-nodes-2.1-8.fc27 do-not-archive-yetreleng
elasticsearch-1.7.1-3.fc24do-not-archive-yethubbitus
expresso-0.9.2-11.fc28do-not-archive-yetreleng
f2fs-tools-1.10.0-1.fc28 do-not-archive-yetfiliperosset
fossil-2.2-5.fc28 do-not-archive-yetreleng
fsarchiver-0.8.3-2.fc28 do-not-archive-yetreleng
giada-0.14.4-1.fc28 do-not-archive-yetoget
gnomint-1.2.1-128.fc24do-not-archive-yetreleng
golang-github-montanaflynn-stats-0.2.0-3.20170729git4a16327.fc28
do-not-archive-yetreleng
golang-gopkg-sourcemap-1.0.5-2.fc28 do-not-archive-yetreleng
gourmet-0.17.4-12.fc28do-not-archive-yetreleng
gstreamer-plugins-base-0.10.36-18.fc27do-not-archive-yetreleng
gtatool-2.2.0-11.fc28 do-not-archive-yetvolter
hfsutils-3.2.6-34.fc28do-not-archive-yetreleng
httptunnel-3.3-20.fc28do-not-archive-yetreleng
hxtools-20150304-6.fc28 do-not-archive-yetreleng
infinispan-8.2.4-5.fc28 do-not-archive-yetreleng
jday-2.4-18.fc28 do-not-archive-yetreleng
ktoblzcheck-1.44-10.fc28 do-not-archive-yetreleng
kxstitch-2.0.0-4.fc28 do-not-archive-yetreleng
lbzip2-2.5-10.fc28do-not-archive-yetmsimacek
libAfterImage-1.20-18.fc28do-not-archive-yetreleng
libdsk-1.3.8-6.fc28 do-not-archive-yetreleng
libfaketime-0.9.6-6.fc27 do-not-archive-yetreleng
libgringotts-1.2.1-21.fc27do-not-archive-yetreleng
libiptcdata-1.0.4-20.fc28 do-not-archive-yetzbyszek
libocrdma-1.0.8-6.fc27do-not-archive-yetreleng
lilyterm-0.9.9.2-10.fc27 do-not-archive-yetreleng
liquidwar-5.6.4-28.fc28 do-not-archive-yetreleng
mod_cluster-1.3.3-11.fc27 do-not-archive-yetreleng
mon-1.2.0-22.fc27 do-not-archive-yetreleng
nightfall-1.86-6.fc27 do-not-archive-yetreleng
nodejs-gaze-0.5.1-7.fc27 do-not-archive-yetreleng
nuvola-app-groove-2.0-2.fc28 do-not-archive-yetignatenkobrain
owncloud-9.1.5-3.fc28 do-not-archive-yetreleng
pesign-0.112-22.fc28 do-not-archive-yetpbrobinson
planets-0.1.13-20.fc27do-not-archive-yetreleng
purple-plugin_pack-2.7.0-7.fc28 do-not-archive-yetreleng
python-oauth-1.0.1-17.fc28do-not-archive-yetreleng
python-pydns-2.3.6-10.fc28do-not-archive-yetreleng
reiserfs-utils-3.6.25-5.fc28 do-not-archive-yetreleng
rubygem-connection_pool-2.2.0-2.fc24 do-not-archive-yetilgrad
scantailor-0.9.11.1-20.fc28 do-not-archive-yetignatenkobrain
scsi-target-utils-1.0.70-4.fc28 do-not-archive-yetadamwill
shim-unsigned-aarch64-15-1.fc28 do-not-archive-yetpjones
shim-unsigned-x64-15-1.fc28 do-not-archive-yetpjones
spill-0.8-16.fc28 do-not-archive-yetreleng
stratagus-2.2.7-11.fc27 do-not-archive-yetreleng
sympow-1.019-17.fc28 do-not-archive-yetreleng
Re: Bug filing/triage/ownership policy for modules
On Fri, Dec 20, 2019 at 08:12:26AM +1000, Jeff Fearn wrote: > > I think ATM the problem is there is one component for a module so if > that module has 50 packages in it how do you report a bug against a > specific package in it? Well, since one person or group "owns" the module, I would just expect anything reported against that module would be fine. Of course if there's 50 bugs and people need more fine grained control that could be a problem, but right now at least I don't think it would be. > > You could modify suggestion 2 so a module component has a sub-component > for each package in it, technically it's pretty much the same. It is a > little more work as you have to move bugs, but it may have some benefits > in reporting and perhaps some maintainers would feel better about > handing off bugs for modules. Yeah, it seems like a lot of work for not much gain right now, but perhaps it will change when/if modules get more uptake. > > It probably comes down to your mental model of how modules and packages > relate and how that is best represented in a tree structure. Technically > there is little difference, one way may be more user friendly. > > e.g. > > Fedora > --protobuf > eclipse-module > --stream1 > > Vs > > Fedora > --eclipse-module > stream1 > --protobuf > > I added streams as it will probably be necessary. > > I'd lean towards the second myself, because it fits better with my > mental map of how it all relates. YMMMV (Your Mental Map May Very ;)) > > Cheers, Jeff. Yeah, likely it will come down to what module maintainers expect/want. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February (release candidate)
On 20. 12. 19 18:25, Tom Callaway wrote: I fixed dnssec-nodes (and dnssec-tools), gnomint, lilyterm, rubygem-connection_pool, rubygem-session, target-isns, tcmu-runner, telepathy-gabble, and telepathy-salut in rawhide. I thought about fixing elasticsearch, but there is not enough alcohol for me to touch a gradle package. Thank You! I'm afraid there's not enough alcohol on Earth for that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: digested list etiquette [ was: devel Digest, Vol 190, Issue 186 ]
On Fri, 2019-12-20 at 12:59 -0500, Robbie Harwood wrote: > Hi, > > When replying to digests, I'd appreciate if you could please make an > effort to have the posts thread properly for the rest of us. Fedora > mailing list guidance on this: > https://fedoraproject.org/wiki/Mailing_list_guidelines#Replying_to_Digests Will do. Sorry for making things harder on everyone in this regard. 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
Re: Fedora 32 System-Wide Change proposal: LTO by default for package builds
On Fri, 2019-12-20 at 11:52 +0100, Miro Hrončok wrote: > On 19. 12. 19 22:41, Ben Cotton wrote: > > https://fedoraproject.org/wiki/LTOByDefault > > > > == Contingency Plan == > > * Contingency mechanism: Revert the LTO flags injection > > * Contingency deadline: Beta freeze, but shooting for prior to mass > > rebuilds starting > > * Blocks release? No > > * Blocks product? No > > > > Most critically, if we don't address the GDB testsuite issue noted > > above, our fallback position would be to simply disable the LTO > > injection globally and re-evaluate for Fedora 33, similarly if we were > > to find some show-stopping LTO issue. > > Should the contingency plan include a second mass rebuild in case our > packages > successfully built with lto during the mass rebuild, but are broken at > runtime? > > Or do we safely assume that it's good as long as it builds fine? It would really depend on what we find and it's the kind of decision we deal with semi-regularly with the yearly compiler update in Fedora -- what to do if we find something horrifically wrong, whether it be an unexpected ABI change or a particularly nasty codegen issue. When we encounter these situations we often end up instrumenting the compiler to get a sense of how pervasive the problem is or building a scanner to look for problematic code sequences across the builds done with the problematic compiler/options. To-date I don't think we've ever had to do something like back out a major compiler update or request a mass rebuild in Fedora as a result of a compiler issue. We've had some "phew" moments for issues we thought were going to have wide impact, but for various reasons didn't. So while I wish I could give you a concrete answer, it's really something we (Jakub, Marek, Jason, Jon, myself and others) evaluate on a case by case basis looking at size/scope and determine a path forward, knowing that an unexpected mass rebuild would be catastrophic. What gives me a relatively high degree of confidence in the introduction of LTO is that openSUSE made this change for their distro in the spring of this year confirming the base LTO technology on a wide scale, combined with the testing we're already doing for Fedora with gcc-10. By *far* the biggest issue with LTO is the configure test snippets that are so horribly written that they can be easily compromised by aggressive optimization enabled by LTO and the widespread nature of that horrific code. Hence the desire to fix the most common and egregious issues by in-place editing of the already-generated configure files within %configure. And just to be clear, these code snippets would never actually run and nobody would ever write code this way expecting it to be executed -- they're primarily compile/link tests to look for features. Concerns over mis-configuring packages due to these issues is what led to the introduction of the capability to capture the generated config.h files and compare them against builds with standard tools in our tester. If we note any differences in the generated config.h files, the build is considered a failure and needs to be examined and the issue fixed. 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, Dec 20, 2019 at 2:24 AM Lennart Poettering wrote: > > On Do, 19.12.19 16:42, Ben Cotton (bcot...@redhat.com) wrote: > > > Over time, some users experience slow downs in certain flash storage > > devices. This might be alleviated by issuing a periodic fstrim command > > to the mounted file system. Devices and file systems that don't > > support fstrim are unaffected. > > So, if this is desirable, why doesn't the kernel do this on its own? The simple answer is, because we're only just now coming out of the stone age, and into the bronze age, of SSDs. There were too many significant differences in early SSD behavior across makes/models. The way that's been handled across platforms (Linux, macOS, Windows, BSD) differs too, reflecting that the standards weren't specific enough, ample vendor confusion and firmware bugs, etc. Today the supply of SSDs is very heterogeneous, and they inadequately announce their capabilities and preferences in this regard. > Why do we need a userspace component that just gets an event from the > kernel and then tells the kernel to do something? If this is generally > desirable, why is something as trivial as that not a kernel > functionality anyway? Issuing the command once per week harms no one, and benefits a few who happen to have devices that will perform better with this scheduled hint than without it. It's the most universally applicable way of doing it, however subjective. And as mentioned in the proposal, other distributions have had this same unit enabled for many years. It's reasonable to enable fstrim.timer now. *And* conduct parallel development to create a kernel facility to do this automatically, if it's even possible. I'm not convinced the drives report enough information to do this properly automatically, rather than on a schedule. But saying this belongs in the kernel, indeterminate future, while other distributions have been doing this on a schedule upwards of six years, and is supported on Windows and macOS for about that long too? *shrug* I'm not sure that makes sense. And to be true, Windows and macOS have used their own white listing method to do this, meaning quite a lot of devices aren't getting these hints and are left out. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: devel Digest, Vol 190, Issue 186
Hi, When replying to digests, I'd appreciate if you could please make an effort to have the posts thread properly for the rest of us. Fedora mailing list guidance on this: https://fedoraproject.org/wiki/Mailing_list_guidelines#Replying_to_Digests Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Tito 0.6.12 release
Hello, I am happy to announce that after two years since the last tito [1] release, the 0.6.12 is finally out! See release notes [2] This very moment, updates were submitted to bodhi [3], feel free to try them. [1] https://github.com/dgoodwin/tito/ [2] https://github.com/dgoodwin/tito/releases/tag/tito-0.6.12-1 [3] https://bodhi.fedoraproject.org/updates/FEDORA-2019-5523b63c9c PS: This was my first release of tito project, so I hope I did everything correctly. I would like to thank all contributors, Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Bug filing/triage/ownership policy for modules
On Thu, Dec 19, 2019 at 12:19:39PM -0800, Kevin Fenzi wrote: On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote: David Cantrell writes: ...snip... > I would like to see modules have a stronger policy around tracking and > handling CVEs. At the very least, what Fedora already does for > regular packages. I would like this as well, but don't think "what Fedora already does for regular packages" is sufficient here. To criticize process (and only process, not people) for a moment here: Just a note: Fedora doesn't do anything currently for regular packages. Red Hat Product Security opens bugs for CVES that are public for Fedora. I'd like to thank them for this tedious and very helpfull work. Noted. As stated in my reply to Robbie's post, I think defining more of a CVE process is worth a separate discussion. I do appreciate the work of the Red Hat Product Security team, but with modules we are exponentially increasing the risk here and I feel Fedora needs a more defined policy for CVE handling. Right now, the impetus for CVEs to be fixed[1] comes solely from the maintainer. Unless the CVE becomes a buzzword issue with a name and logo (Heartbleed has already been mentioned upthread), there are basically no consequences to not fixing CVEs in one's packages until non-responsive maintainer bugs start getting filed. There doesn't seem to be any monitoring of these, and unlike FTBFS bugs, they're not grounds for removing packages from the distro. Actually they can be... FESCo approved a policy around this: https://pagure.io/fesco/issue/1935 https://pagure.io/fesco/issue/2090 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/A5AOCRX75X4ULTWRJVF7JYT7V2LL6RXR/ We just don't currently have scripting to announce and do this. I don't want to put blame on anyone for this, of course - if it were easy to fix we would have done it already. My understanding is that a lot of the problems I described above are due to lack of capacity to perform the work associated. Asking the folks performing security-related tasks in the distro - who are already overloaded - to perform even more work does not strike me as a good idea. There needs to be an easy way for them to query what versions of what packages are present in Fedora - anywhere in Fedora - and file bugs against all of them individually such that they reach the correct maintainers without additional triage. Thanks, --Robbie 1: Often, even knowing that CVEs exist also requires the maintainer to be paying attention to upstream development. This is because tracker bugs are often missing, and usually late when they are created - in many cases, after the issue in question has already been fixed. yeah, but keep in mind that this is done as a 'above and beyond' by Red Hat Product security. kevin -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bug filing/triage/ownership policy for modules
On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote: David Cantrell writes: On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote: On 17. 12. 19 21:57, David Cantrell wrote: 1) Are modules allowed to bundle packages that are provided by and currently maintained in the base system? Are there are restrictions to what a module can bundle (e.g., can a module bundle glibc)? I am not aware of any policy against modularizing existing packages. Modular maintainers can module-bundle glibc. OTOH I don't know all the policies. There is a policy for making a default modular stream: if it overrides existing non-modular packages, it requires FESCo approval. So far this has not been retroactive and the ant and maven default modular streams do that. See also https://pagure.io/modularity/issue/170 I feel there should be some restrictions around this bundling. glibc is a good example, but I am also concerned about the ability for modules to bundle security-libraries which could lead to a system with multiple different versions of a shared library on a system. With protobuf as the example again, we saw that the eclipse module's bundled protobuf took the lead in depsolving and dnf upgraded systems to that regardless of whether or not they had the module installed. So the multiple shared library scenario is only a concern in a world where we do parallel installability. Putting that aside for the moment, I'd like to refine the above concern: We should have some restrictions about packages that can and cannot be bundled with modules. This may require defining some sort of criteria or a set of core packages or some other test. Likewise, packages like openssl need some thought because while we do not currently do parallel installability, even having parallel availability still means we could have multiple different builds of an openssl package. There should be a plan around that because having that be unbounded sets us up for a lot of panic mode work should there be something like Heartbleed happen again. Agreed. Especially with the work we do on crypto deprecations, I worry that there will be strong temptation to create bundled crypto packages that "make the old workflow work again" or so. That's exactly my thought as well. 2) Using protobuf as an example, if a bug is found by a user and they happen to deduce that the error is in protobuf, how do they file a bug? Do they file the bug against protobuf if the bundled one from the module has the issue? What maintainer is on the hook for handling that bug report? My assumption here is that the module maintainer is ultimately responsible for everything they bundle. Another concern I see here is we are opening ourselves up for N+1 different builds of protobuf where N is the number of modules installed on a system and all of them could have protobuf bundled. I would assume they file it in protobuf. They haven't opted for any module and they don't know it's modular, really. The non-modular maintainer may deduce from the NERVA that it is modular build and do some nontrivial digging to figure out where is this package coming from - if they can, they will reassign the bug report to that module component. I agree that the modular maintainers are ultimately responsible for everything they bundle. I share your concerns. Filing against protobuf makes sense, but then we get to the maintainers. The protobuf maintainer did not know eclipse bundled protobuf. Without being involved in that decision, I think it's unfair to expect package maintainers to be the triage point for all incoming bugs, either regular packages or bundled packages. That's just not going to really scale very well and will result in frustration among package maintainers and users. Maybe if a module bundles a package, the module maintainer also becomes a co-maintainer on the bundled package? This worries me because I don't think we have sufficiently fine-grained commit controls since the pkgdb retirement. While I would love to be incorrect about this, I don't see a way to restrict what branches can be committed to by those with access to a package - and I don't think it's at all reasonable for someone who makes a module version of a package to gain commit bits to all branches. (Especially without consent of the existing maintainer(s).) All reasonable concerns. I don't think we have the necessary controls in place for this either. In my mind I was thinking a discussion like this would involve both "do we think this is a good idea to implement" as well as "how would our tools need to change to allow that". An important part of this is communication so that module maintainers know who the regular package maintainer is (e.g., for coordinating work, etc) and that regular package maintainers know what modules are bundling the package at different points. I'm still not convinced this is a good workflow for all software we ship, but may be an ok mechanism for large
Re: List of long term FTBFS packages to be retired in February (release candidate)
I fixed dnssec-nodes (and dnssec-tools), gnomint, lilyterm, rubygem-connection_pool, rubygem-session, target-isns, tcmu-runner, telepathy-gabble, and telepathy-salut in rawhide. I thought about fixing elasticsearch, but there is not enough alcohol for me to touch a gradle package. Thanks, Tom On Sun, Dec 15, 2019 at 6:10 AM Miro Hrončok wrote: > Dear maintainers. > > Based on the latest fail to build from source policy, the following > packages > will be retired from Fedora 32 approximately one week before branching > (February > 2020). > > Policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > The packages in rawhide were not successfully built at least since Fedora > 30. > > This report is based on dist tags and represents a preliminary list of > packages. > > Packages collected via: > > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > The main purpose is to gather feedback. > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, please let > me > know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > > Package (co)maintainers Latest > build > > > dnssec-nodes hardaker Fedora > 27 > elasticsearch hubbitus, jvanek, lbazan,Fedora > 24 >zbyszek > expresso jamielinux, nodejs-sig, Fedora > 28 >patches > gnomint verdurin Fedora > 24 > libocrdma ocrdma Fedora > 27 > lilyterm cwickert Fedora > 27 > nuvola-app-google-calendarmartinkg Fedora > 29 > nuvola-app-groove martinkg Fedora > 28 > nuvola-app-logitech-media-martinkg Fedora > 29 > server > nuvola-app-plex martinkg Fedora > 29 > nuvola-app-soundcloud martinkg Fedora > 29 > nuvola-app-yandex-music martinkg Fedora > 29 > rubygem-connection_pool anujmore Fedora > 24 > rubygem-session gomixFedora > 29 > shim-unsigned-aarch64 pjones Fedora > 28 > shim-unsigned-x64 pjones Fedora > 28 > target-isns grover, mlombard Fedora > 27 > tcmu-runner mlombard Fedora > 26 > telepathy-gabble aperezbios Fedora > 29 > telepathy-salut aperezbios, johnpFedora > 29 > > The following packages require above mentioned packages: > Depending on: expresso (1) > nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh) > nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = > 0.9.2 > > Depending on: rubygem-connection_pool (45) > rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch) > rubygem-activestorage-5.2.3-3.fc31.src requires > rubygem(connection_pool) = 2.2.0-1 > > rubygem-activesupport (maintained by: jaruga, jstribny, kanarip, > mmorsi, > pvalena, ruby-packagers-sig, sseago, vondruch) > rubygem-activesupport-1:5.2.3-2.fc31.src requires > rubygem(connection_pool) = > 2.2.0-1 > > rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, > pvalena, > ruby-packagers-sig, sseago, tdawson, vondruch) > rubygem-rails-1:5.2.3-2.fc31.noarch requires > rubygem(activestorage) = 5.2.3 > > rubygem-railties (maintained by: mmorsi, pvalena, vondruch) > rubygem-railties-5.2.3-3.fc31.src requires > rubygem(activestorage) = 5.2.3 > > rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, > mmorsi, pvalena, > ruby-packagers-sig, sseago, vondruch) > rubygem-actionpack-1:5.2.3-3.fc31.noarch requires > rubygem(activesupport) = 5.2.3 > rubygem-actionpack-1:5.2.3-3.fc31.src requires > rubygem(activesupport) = 5.2.3 > > rubygem-actionview (maintained by: jaruga, pvalena, > ruby-packagers-sig) > rubygem-actionview-5.2.3-3.fc31.noarch requires > rubygem(activesupport) = 5.2.3 > rubygem-actionview-5.2.3-3.fc31.src requires > rubygem(activesupport) = 5.2.3 > > rubygem-activejob (maintained by: pvalena, vondruch) >
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fr, 20.12.19 18:11, Louis Lagendijk (lo...@fazant.net) wrote: > On Fri, 2019-12-20 at 17:46 +0100, Lennart Poettering wrote: > > > > Or let me ask this differently: the "discard" mount option of various > > kernel file systems, what does it differently than what this new > > fedora feature is supposed to do? > > > fstrim does the discard once a week (or whenever it it triggered), > discard as a mount option does trigger discard when a block is freed. > Depending on the drive it may actually slow down IO as the SSD will > need more time to finish the IO. Doing an fstrim leaves the processing > to the SDD. That was the argument years ago. I don't know if this is Hmm? if the if the fs enqeues the trimming or userspace does, it's always the SSD that executes it... > still true for modern SSD's. For older SSDs fstrim would stil be the > safer option. And automatic trimming is long overdue in my opinion. So if trimming is slow, that's still no reason to let userspace pick a time for it. Sounds like the kernel fs should have discard=lazy or discard=5min or so. Which would enqueue a trim run automatically after the last IO after some delay. Still not grokking why to do this in userspace. -- 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, 2019-12-20 at 17:46 +0100, Lennart Poettering wrote: > > Or let me ask this differently: the "discard" mount option of various > kernel file systems, what does it differently than what this new > fedora feature is supposed to do? > fstrim does the discard once a week (or whenever it it triggered), discard as a mount option does trigger discard when a block is freed. Depending on the drive it may actually slow down IO as the SSD will need more time to finish the IO. Doing an fstrim leaves the processing to the SDD. That was the argument years ago. I don't know if this is still true for modern SSD's. For older SSDs fstrim would stil be the safer option. And automatic trimming is long overdue in my opinion. Louis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fr, 20.12.19 14:10, Karel Zak (k...@redhat.com) wrote: > On Fri, Dec 20, 2019 at 10:23:50AM +0100, Lennart Poettering wrote: > > On Do, 19.12.19 16:42, Ben Cotton (bcot...@redhat.com) wrote: > > > > > Over time, some users experience slow downs in certain flash storage > > > devices. This might be alleviated by issuing a periodic fstrim command > > > to the mounted file system. Devices and file systems that don't > > > support fstrim are unaffected. > > > > So, if this is desirable, why doesn't the kernel do this on its own? > > When? Under the same conditions as this new fedora feature? i.e. time? > You can use "mount/swapon -o discard" to do it on-the-fly, but in some > cases it's bad idea and it's better to keep it in user's hands. Not saying it shouldn't be. i.e. could be a sysctl or so. I am just wondering what in any way would be better if userspace triggered this based on user configuration than when the kernel would trigger this on its own? > > Why do we need a userspace component that just gets an event from the > > kernel and then tells the kernel to do something? > > It does not get any event from kernel. It starts in specified time > operation which may be unwanted in another time. Yeah, I meant the timer event as event from the kernel... > > > If this is generally > > desirable, why is something as trivial as that not a kernel > > functionality anyway? > > You want to ask at LKML ;-) Nah, I don't. I am asking the folks behind the fedora feature, asking about their implementation. It sounds weird having userspace components whose only job is to issue one frickin' ioctl() every now and then? I mean, this reminds me of the venerable "update" daemon of traditional UNIXes, whose only job was to call sync() every 30s or so. We stopped doing that on Linux and instead let the kernel manage flushing buffers on its own, on its own timing (taking some sysctl tuning and tweaking into account). Why is the trimming much different than this? i.e. doesn't the kernel know better when a good time to trim is? Or let me ask this differently: the "discard" mount option of various kernel file systems, what does it differently than what this new fedora feature is supposed to do? To my knowledge ext4, xfs, btrfs all support "discard" natively. So why do we need a userspace component to enqueue the same operation if the file systems can do that anyway, at much better times? 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fr, 20.12.19 13:39, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 20.12.2019 10:23, Lennart Poettering wrote: > > So, if this is desirable, why doesn't the kernel do this on its own? > > Kernel's TRIM has issues with data corruption on some SSD controllers. > You can check drivers/ata/libata-core.c of Linux kernel sources for more > information. If that's the case, then what is different with the feature posted here? in both cases it's the kernel that issues the TRIM, how would it be safer to trigger that from a userspace program by default rather than triggering that from a kernel-internal timer by default? Why involve userspace in this at all? the kernel executes the actual operation either way, but why bother userspace with this? 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
Two stage Ruby compilation / Bootstrapping
Hi all, Ruby upstream is implementing more and more stuff directly in Ruby. We already had issues, that build of Ruby required Ruby when we did some modifications [1]. In subsequent ticket, one of Ruby committers said [2]: > ... snip ... > BASERUBY is already a build requirement > ... snip ... > I would like to implement more of Ruby using Ruby, so miniruby may depend on prelude one day. With recent changes, such as [3], I am afraid that the day has come. Previously, if you wanted to patch lets say "gem_prelude.rb", it was enough to patch it. But now you *need* Ruby to process it into miniprelude.c. There are possibly 4 ways out of this. 1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build Ruby using the previously built (mini)ruby. 2) Use previous version of Ruby available in Fedora to bootstrap Ruby. But this does not work ATM, at least when RubyGems are installed. And upstream is doing what they can to make RubyGems inseparable [4]. 3) Prepare patches locally and apply the required changes also to the pregenerated files. But the problem here is, that the patches might unpredictably fail between updates. I don't think that they keep any API/ABI promises for the tools used to generate those files. 4) Don't use the upstream tarball, but generate it from sources with patches integrated. I think we should probably start to take look at 1), specifically into the *miniruby* variant if that is enough. If that is done, the 2) could optionally blend in. And in the mean time use 3) because otherwise I really don't know how to integrate the ABRT hook support. I don't like 4) at all, unless we have some Fedora standardized way of doing so. On the positive side, 1(2) would allow us to stay better in line with "Pregenerated code" guidelines [5], because there is already quite a lot of pre-generated code shipped in Ruby release tarball. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c5117aa0d1228 [2] https://bugs.ruby-lang.org/issues/15306#note-1 [3] https://github.com/ruby/ruby/pull/2655 [4] https://bugs.ruby-lang.org/issues/16431 [5] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_pregenerated_code ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, Dec 20, 2019 at 4:13 AM John M. Harris Jr wrote: > > One, didn't we kill the release notes package recently? Yes, but ... > Are release notes even > being written now, or do you have to go and check the wiki for the list of > Changes? > ...release notes are published on the docs site as they have always been: https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ -- Ben Cotton He / Him / His Fedora Program Manager 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
[Bug 1785649] New: perl-Filesys-Df needed in EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1785649 Bug ID: 1785649 Summary: perl-Filesys-Df needed in EPEL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Filesys-Df Assignee: msu...@redhat.com Reporter: heinrich.mis...@univie.ac.at QA Contact: extras...@fedoraproject.org CC: msu...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Please create epel8 build. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Announcing fmt library soversion bump
On Wed, 18 Dec 2019 15:30:57 +0100, you wrote: >On Wed, Dec 18, 2019, 14:44 Vitaly Zaitsev via devel < >devel@lists.fedoraproject.org> wrote: >> Fmt 6.1.2 build completed for Rawhide. It include SOVERSION bump. All >> dependent packages need to be rebuilded. > > >It would be great to announce this stuff a week in advance, so maintainers >of dependent packages can coordinate the necessary rebuilds ... announcing >it like "this happened, now deal with it" (without even including a list of >packages that needs to be rebuilt) isn't really helpful. It would also likely be considerate not to do this just prior to a major holiday, when a lot of people are attempting to get stuff done prior to being gone for 1 or 2 weeks and so have a heavier workload. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Thu, Dec 19, 2019 at 10:39:45PM -0500, Stuart D. Gathman wrote: > On Thu, 19 Dec 2019, Ben Cotton wrote: > > >https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer > > > >== Summary == > >Enabling fstrim.timer will cause fstrim.service to execute weekly, > >which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > >== How To Test == > >The low level function of systemd timers, fstrim.service, and fstrim > >command are well understood and tested already, all Fedora needs to > >test is that the timer is enabled following clean installation and > >upgrades: > > After the initial change of defaults, the fstrim.timer SHOULD NOT be > re-enabled on subsequent updates if a user (who like me prefers choosing > when to run fstrim on which filesystem) has disabled it. The proposal mentions "modifying 90-default.preset to enable fstrim.timer". The effect of a change to presets is that when a *new* package is installed, the default %systemd_post scriptlet will enable the unit. Just changing the default doesn't effect existing systems (precisely speaking, systems which already had the rpm installed which provides the given service). This means that the part of the description: > fstrim.timer will be enabled on upgrade. An upgraded system should > exhibit the same behaviors as a clean installed system. does not match the proposed implementation. *If* it was desired to have new setting also take effect on upgrades (I'm not saying if that is appropriate, just describing a possible mechanism), a scriptlet could be added (in util-linux most likely), that would do convert existing scriptlets: %triggerpostun -- fedora-release < 32 systemctl preset fstrim.service Users who want to opt-out of the upgrade would have to either call systemctl disable to undo the change or, more cleanly, create a dropin before the upgrade: # /etc/systemd/system-preset/10-no-fstrim.preset disable fstrim.service Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On Thu, Dec 19, 2019 at 03:47:13PM -0600, Neal Gompa wrote: > > == Release Notes == > > The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by > > update-alternatives. If you would like to change these symlinks to > > point to another compiler, like clang, for example, you can use these > > commands: > > > > `update-alternatives --set cc /usr/bin/clang` > > > > `update-alternatives --set c++ /usr/bin/clang++` > > > > I don't know if I want *more* alternatives usage in Fedora. I like the > fact that a basic buildroot is generally supposed to work without > scriptlets... On the other hand, I think we're already using > alternatives for ld... > > Aside from making it possible to swap the system compiler with > alternatives, what benefit do we get? Are there other, less script-y > approaches that we could use? I'm not sure that the benefits are really that big. For most cases, instead of setting alternatives, the obvious solution would be to set $CC. Can you expand a bit on why alternatives, which is effectively a global setting, is preferred to a local override? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, Dec 20, 2019 at 12:25:24PM +0100, Miro Hrončok wrote: > On 19. 12. 19 22:42, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer > > > > == Summary == > > Enabling fstrim.timer will cause fstrim.service to execute weekly, > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > > Could we please have a summary that contains at least some generally used > terms such as "flash storage devices" or "discarding unused blocks"? > > Because for users not familiar with fstrim, this summary translates to: > > "Enabling something will cause something to execute weekly which in turn > executes something." +1, for example: Enabling fstrim.timer will cause fstrim to execute weekly. fstrim is used on a mounted filesystem to trim blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage. Karel -- Karel Zak http://karelzak.blogspot.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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Fri, Dec 20, 2019 at 10:23:50AM +0100, Lennart Poettering wrote: > On Do, 19.12.19 16:42, Ben Cotton (bcot...@redhat.com) wrote: > > > Over time, some users experience slow downs in certain flash storage > > devices. This might be alleviated by issuing a periodic fstrim command > > to the mounted file system. Devices and file systems that don't > > support fstrim are unaffected. > > So, if this is desirable, why doesn't the kernel do this on its own? When? You can use "mount/swapon -o discard" to do it on-the-fly, but in some cases it's bad idea and it's better to keep it in user's hands. > Why do we need a userspace component that just gets an event from the > kernel and then tells the kernel to do something? It does not get any event from kernel. It starts in specified time operation which may be unwanted in another time. > If this is generally > desirable, why is something as trivial as that not a kernel > functionality anyway? You want to ask at LKML ;-) (CC: to Lukas who is cares about it in kernel) Karel -- Karel Zak http://karelzak.blogspot.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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On 20.12.2019 10:23, Lennart Poettering wrote: > So, if this is desirable, why doesn't the kernel do this on its own? Kernel's TRIM has issues with data corruption on some SSD controllers. You can check drivers/ata/libata-core.c of Linux kernel sources for more information. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Carson Black
Oh, nice! I learnt something new. Thank you! On Thu, 19 Dec 2019 at 23:44, Carson Black wrote: > "ale li pona" is a Toki Pona proverb that can mean a lot of things, > but in this context, it means "all is good." > > -- Carson Black [jan Pontaoski] > > Am Do., 19. Dez. 2019 um 14:20 Uhr schrieb Silvia Sánchez < > bhkoh...@gmail.com>: > > > > > > Hello Carson! > > > > Welcome aboard! What does "ale li pona" means? > > > > Greetings, > > Silvia > > > > > > > > > > On Tue, 17 Dec 2019 at 05:52, Carson Black wrote: > >> > >> Greetings y'all. > >> > >> My name is Carson Black & it's nice to meet y'all. > >> I'm from Frankfort, Kentucky (and no, I'm not interested in bourbon), > and > >> I'm currently a student at one of the high schools here. I'd be lying > if I said I had > >> any explicit goals with the Fedora project, as I just do what I feel > like doing when > >> I feel like doing it. ale li pona. :) However, I'm writing this email > because I recently submitted a > >> package for review (https://bugzilla.redhat.com/show_bug.cgi?id=1784230). > I've been doing stuff with > >> OSS for about over a year now, from doing packaging for openSUSE to > abusing every last facility GTK+ provides > >> as maintainer of Breeze GTK for KDE. I have experience with a variety > of programming languages, but I'm most > >> familiar with C/C++, Python, Go, & Vala. > >> > >> My GPG fingerprint is A133 906C E9F6 6BFD 2F27 7D67 05DF 0193 8FF8 0320. > >> > >> Looking forward to participating here with y'all. > >> > >> -- Carson Black [jan Pontaoski] > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email:
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively. For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers. Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed. There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development. They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives. If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`
Does this process even works in RPM context ? given rpm -E %{__cc}
outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
for __cxx, __cpp)
If that's only supposed to work in a local compilation context (not
with RPM), what is the benefit from using alternatives rather than
export CC=clang ?
What about ccache ? (does it need to also be registered with alternatives) ?
As I imagine, setting clang for a given package with such alternatives
would requires to add a BR of some clang-default that will call
alternatives in %post.
At first sight, I would dramatically prefer to have a RPM macro that
would set __cc, __cpp,__cxx and the relevant cflags ldflgas in %prep.
(and eventually another macro that would set then back to default).
--
-
Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On 19. 12. 19 22:42, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer == Summary == Enabling fstrim.timer will cause fstrim.service to execute weekly, which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` Could we please have a summary that contains at least some generally used terms such as "flash storage devices" or "discarding unused blocks"? Because for users not familiar with fstrim, this summary translates to: "Enabling something will cause something to execute weekly which in turn executes something." Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: LTO by default for package builds
On 19. 12. 19 22:41, Ben Cotton wrote: https://fedoraproject.org/wiki/LTOByDefault == Contingency Plan == * Contingency mechanism: Revert the LTO flags injection * Contingency deadline: Beta freeze, but shooting for prior to mass rebuilds starting * Blocks release? No * Blocks product? No Most critically, if we don't address the GDB testsuite issue noted above, our fallback position would be to simply disable the LTO injection globally and re-evaluate for Fedora 33, similarly if we were to find some show-stopping LTO issue. Should the contingency plan include a second mass rebuild in case our packages successfully built with lto during the mass rebuild, but are broken at runtime? Or do we safely assume that it's good as long as it builds fine? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On 19. 12. 19 22:47, Neal Gompa wrote: I don't know if I want *more* alternatives usage in Fedora. I like the fact that a basic buildroot is generally supposed to work without scriptlets... On the other hand, I think we're already using alternatives for ld... Aside from making it possible to swap the system compiler with alternatives, what benefit do we get? Are there other, less script-y approaches that we could use? We could have a cc-is-gcc and cc-is-clang conflicting packages with /ur/bin/cc and: - require /usr/bin/cc from gcc and from clang - suggest cc-is-gcc from gcc - suggest cc-is-clang from clang That gets rid of the scriplets, but creates a nontrivial resolving chaos. Also when installing gcc and clang at the same time, we would not be able to trivially give cc-is-gcc higher priority unless we maybe suggest it from fedora-release, but that's... meh. We could mix in some recommends, but the current behavior would probably try to install it on every upgrade, so not sure if that works. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji builder status
On 19. 12. 19 21:10, Kevin Fenzi wrote: On Sun, Dec 15, 2019 at 10:24:16AM +0100, Fabio Valentini wrote: Side note: Considering that there are comparatively few armv7hl builders, I wonder why a rather big share of my noarch builds gets scheduled to run on them. Naively, I'd think that armv7hl should be busy doing builds for "archful" stuff since they're the slowest I'm not sure why that is. I would expect them to be busy more as well. I have the same experience with Python noarch builds. I have figured out that it is quite deterministic: When I need the build quickly and/or there are hundreds of slow-ish tests, I get arm. When I don't need the build quickly and/or there are no tests at all and it builds in seconds anywhere, I get x86. Based on that, I've determined that it is just a bias :D -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1785539] perl-Test-Prereq-2.003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1785539 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Test-Prereq-2.003-1.fc ||32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2019-12-20 10:27:20 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=39800300 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: koji builder status
On Fri, 20 Dec 2019 01:39:42 + Mat Booth wrote: > On Thu, 19 Dec 2019 at 21:13, Dan Horák wrote: > > > > On Thu, 19 Dec 2019 12:10:00 -0800 > > Kevin Fenzi wrote: > > > > > On Sun, Dec 15, 2019 at 10:24:16AM +0100, Fabio Valentini wrote: > > > > > > > > Side note: Considering that there are comparatively few armv7hl > > > > builders, I wonder why a rather big share of my noarch builds > > > > gets scheduled to run on them. Naively, I'd think that armv7hl > > > > should be busy doing builds for "archful" stuff since they're > > > > the slowest > > > > > > I'm not sure why that is. I would expect them to be busy more as > > > well. Do note that we are bringing some more hardware on line > > > after the new year, which should give us more armv7 builders. > > > > > > > builders and there are the fewest of them, except for s390x. > > > > > > s390x now is a great deal faster. It's often the one that finishes > > > right after x86_64/i686. > > > > even ahead x86_64/i686 sometimes :-) > > > > This is great to hear! Until now s390x was the slowest arch for Java > by quite a wide margin; with the special Java 8 JIT package[1] > installed, even 32bit arm was quicker than s390x :-o because there is no JIT for s390x in OpenJDK 1.8.0, it has been added in some later version (OpenJDK 10?). So until this version is the new default Java, s390x will be slow for Java. Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Thu, Dec 19, 2019 at 11:59:54PM -0700, Chris Murphy wrote: > > After the initial change of defaults, the fstrim.timer SHOULD NOT be > > re-enabled on subsequent updates if a user (who like me prefers choosing > > when to run fstrim on which filesystem) has disabled it. > > It's an interesting question. I'm not sure what the upgrade policy is > for vendor presets. Because there's a general expectation of getting > new features upon upgrade, without having to do a clean install, I > think this one should be enabled on upgrades. But I'm not sure how to > make sure F32>F33 upgrade does not reenable if the user has disabled > it; but still enable it with F31>F33 since Fedora supports upgrades > that skip one release. So yeah, I need to figure that out. User can prevent reenabling by "systemd mask fstrim". But it need to be concious action taken. We can document it in Release Notes. -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Do, 19.12.19 16:42, Ben Cotton (bcot...@redhat.com) wrote: > Over time, some users experience slow downs in certain flash storage > devices. This might be alleviated by issuing a periodic fstrim command > to the mounted file system. Devices and file systems that don't > support fstrim are unaffected. So, if this is desirable, why doesn't the kernel do this on its own? Why do we need a userspace component that just gets an event from the kernel and then tells the kernel to do something? If this is generally desirable, why is something as trivial as that not a kernel functionality anyway? 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
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Friday, December 20, 2019 12:24:44 AM MST Igor Gnatenko wrote: > Always before upgrade to a new *major* version of distribution, you > are supposed to read release notes. This will be noted there and you, > as a user, can explicitly disable it after upgrade. Or even ship your > own preset which would override system's one. Several things. One, didn't we kill the release notes package recently? Are release notes even being written now, or do you have to go and check the wiki for the list of Changes? Two, considering the implications of this Change, it's not something that makes sense to force on users who already have Fedora installed and running, in my opinion. Even as mentioned in the Change proposal, there are drawbacks, which users will not be informed of unless they read this mailing list. -- 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
