Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?
Will it be possible to document and modernize the configuration to build a rpm package in Fedora? It will be really great to make the guideline seamless and less messy. Luya On 2019-10-08 12:38 p.m., Przemek Klosowski via devel wrote: On 10/8/19 6:04 AM, Ankur Sinha wrote: Would anyone else have the cycles to review/update these pages in the meantime please? https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fquick-docs%2Fcreating-rpm-packages%2F&data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C677328d300d34ae9452508d74bd6fe69%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637061259072625298&sdata=Zm5OjqEFev1Fu%2FwPKz%2BO0P0HKnyUAf0ZMvvV00l4yH0%3D&reserved=0 https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fquick-docs%2Fcreate-hello-world-rpm%2F&data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C677328d300d34ae9452508d74bd6fe69%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637061259072635291&sdata=z1NhQVqJXEzKDTR9mGVTUJ54bX7lEoLlDhQ9zKx1WEk%3D&reserved=0 I feel guilty because I wrote the original Hello World artlcle 10 years ago, after my brain overheated while reading RPM manuals---I saw a need for a simple tutorial that would quickly start people in RPM packagaging. Over the years fo course the best practices changed and the original material became dated, so it's time to update this. I am willing to do that, but I need some help, as I'm a little rusty with the latest techniques---in my youth we used to carve raw zeroes and ones from the bedrock and carry them home on donkeys. I understand that Zbigniew's workflow (git/spectool/fedpkg/mock) is the recommended approach. I am not opposed to recommending some arcane .rpminit configuration, if it's one time and easily copied and pasted, as a modern equivalent of rpmdev-setuptree. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GNOME 3.34.1 megaupdate
On 10/7/19 09:25, Kalev Lember wrote: Hi all, This week is GNOME 3.34.1 release. I'm collecting builds in f31-gnome side tag and going to submit everything in a single megaupdate to Bodhi later this week. Please use 'fedpkg build --target f31-gnome' if you are helping with builds. Tonight also starts the F31 Final Freeze, which makes things a bit more complicated. I intend to request a freeze exception for the megaupdate so that it can land a few days after the freeze starts. This would let us include all the fixes that were done based on F31 Beta testing in the Final release media. It's in Bodhi now: https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f20f9e4e3 -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?
On 10/8/19 3:26 PM, Ankur Sinha wrote: On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote: Look, I'm no more in love with the traditional layout than anybody, I'm just saying changing the default is not as simple as you'd like to think. Anybody wanting to work on changing the default is welcome to propose it upstream, patches welcome and all. Would keeping this Fedora specific to begin with help slowly migrate people over? What if we announce this via the change process for F32? The change will be to modify `/usr/lib/rpm/macros` to use per-directory locations as you'd suggested in the snippet since it is closer to the dist-git workflow that is now in use. People can still easily revert to rpmbuild/*, and the contingency plan will be to just not make the change. I don't know how this would affect rpmdev-buildtree and how to handle that (remove it?). Changing rpm defaults will break existing setups, people will be unhappy and I'll get the blame regardless of who actually did it. I'd rather suggest changing rpmdev-setuptree to configure things that way, it already modifies ~/.rpmmacros in various ways, some totally redundant (like setting %_topdir to a longtime rpm default). That starts nudging people towards that direction, but leaves existing setups alone. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EPEL 7 is broken for python3 related builds
On 09. 10. 19 4:34, Nico Kadel-Garcia wrote: On Tue, Oct 8, 2019 at 1:56 PM Irina Boverman wrote: Using "BuildRequires: python%{python3_pkgversion}-devel" results in this error: fedpkg scratch-build DEBUG util.py:593: No matching package to install: 'python36-devel' A lot of Fedora .spec files use "python3-devel" and various "pyton3-" modules. If you switch this to "python%{python3_pkgversion}-", *AND* if you add "BuildRequires: epel-rpm-mocros" for rhel based environments, it works much better to play nicely with the new RHEL and the existing EPEL packages. Why do you need to add "BuildRequires: epel-rpm-mocros"? -- 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: [modularity] modularity team meeting minutes (Oct. 08, 2019)
> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) > * AGREED: We disagree with merging default streams into the main repo > as non-modular packages. Our approach is to implement a mechanism of > following default streams to give people the experience they want. > (+4 0 -0) (asamalik, 16:07:40) What is the consequence of this for module maintainers? Each module maintainer regularly does not have to update "fedora-module-defaults" repository's .yaml file any more? https://pagure.io/releng/fedora-module-defaults -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [modularity] modularity team meeting minutes (Oct. 08, 2019)
On Wed, Oct 9, 2019 at 6:08 AM Jun Aruga wrote: > > > * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) > > * AGREED: We disagree with merging default streams into the main repo > > as non-modular packages. Our approach is to implement a mechanism of > > following default streams to give people the experience they want. > > (+4 0 -0) (asamalik, 16:07:40) > > What is the consequence of this for module maintainers? > Each module maintainer regularly does not have to update > "fedora-module-defaults" repository's .yaml file any more? > https://pagure.io/releng/fedora-module-defaults > The consequence is that we'll remain dependent on modulemd for defaults. That means we *still* need to care about fedora-module-defaults. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [modularity] modularity team meeting minutes (Oct. 08, 2019)
On Tue, Oct 8, 2019, 23:18 Langdon White wrote: > Minutes: > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html > Minutes (text): > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.txt > Log: > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.log.html > > == > #fedora-meeting-3: Modularity Team Meeting > == > > Meeting started by langdon at 15:08:18 UTC. The full logs are available > at > > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.log.html > > Meeting summary > > --- > * roll call (langdon, 15:08:37) > > * agenda (langdon, 15:10:08) > * update on ursa prime (langdon, 15:10:16) > * update on libmodulemd (langdon, 15:11:23) > > * update on ursa prime (langdon, 15:12:33) > * Ursa Prime will be deployed to production next Tuesday (sgallagh, > 15:21:41) > * Ursa Prime configuration will initially be limited to Rawhide/F32 > and EPEL8[-playground] buildroots (sgallagh, 15:22:08) > * The remaining tasks to be done for Ursa Prime: 1) modify the > f32/rawhide platform.yaml record in MBS to enable this feature, 2) > set up a repo compose based on the defaults+overrides inputs, 3) > configure koji tags and targets so that the rawhide target is a > merged repo containing the modular and non-modular content (contyk, > 15:24:19) > * ACTION: contyk and sgallagh to work with nirik to finish those three > tasks. (sgallagh, 15:25:53) > * LINK: > > https://www.dictionary.com/browse/six-of-one--half-a-dozen-of-the-other > (langdon, 15:29:24) > What are the consequences of this for packages that are maintained - as both normal and modular packages, - as modules only? In particular, which "incarnation" of the package will land in the repos if it's available from both sources? If it's just the highest version, this will inevitably lead to conflicts and broken dependencies for dependent packages. Fabio > * libmodulemd update (langdon, 15:29:33) > * LINK: https://github.com/fedora-modularity/libmodulemd/issues/368 > (sgallagh, 15:31:20) > * ACTION: sgallagh to investigate libmodulemd 2.x migration for COPR > (sgallagh, 15:39:10) > * slow migration away from libmodulemd 1.x is resulting in increasing > maintenance burden (sgallagh, 15:39:51) > > * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) > * AGREED: We disagree with merging default streams into the main repo > as non-modular packages. Our approach is to implement a mechanism of > following default streams to give people the experience they want. > (+4 0 -0) (asamalik, 16:07:40) > > Meeting ended at 16:11:58 UTC. > > Action Items > > * contyk and sgallagh to work with nirik to finish those three tasks. > * sgallagh to investigate libmodulemd 2.x migration for COPR > > Action Items, by person > --- > * contyk > * contyk and sgallagh to work with nirik to finish those three tasks. > * sgallagh > * contyk and sgallagh to work with nirik to finish those three tasks. > * sgallagh to investigate libmodulemd 2.x migration for COPR > * **UNASSIGNED** > * (none) > > People Present (lines said) > --- > * sgallagh (87) > * langdon (77) > * asamalik (53) > * contyk (42) > * zodbot (13) > > Generated by `MeetBot`_ 0.1.4 > > .. _`MeetBot`: http://wiki.debian.org/MeetBot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Modularity and the system-upgrade path
On 04. 10. 19 21:31, Miro Hrončok wrote: On 04. 10. 19 16:57, Stephen Gallagher wrote: Right now, there are two conflicting requirements in Fedora Modularity that we need to resolve. 1. Once a user has selected a stream, updates should follow that stream and not introduce incompatiblities. Selected streams should not be changed without direct action from the user. 2. So far as possible, Modularity should be invisible to those who don't specifically need it. This means being able to set default streams so that `yum install package` works for module-provided content. Where this becomes an issue is at system-upgrade time (moving from Fedora 30->31 or continuously tracking Rawhide). Because of requirement 1, we cannot automatically move users between streams, but in the case of release upgrades we often want to move to a new default for the distribution. Wouldn't it be easier if the "default stream" would just behave like a regular package? I can think of two solutions of that: 1. (drastic for modular maintainers) We keep miantaining the default versions of things as ursine packages. We only modularize alternate versions. Pros: Users who don't want alternate versions won't be affected by imperfections of our modular design. No Ursa Major/Prime needed in the buildroot. Cons: Modular maintainers who do modules with just one stream because it is easier for them would need to rollback to what's easier for everybody else but them. Modular maintainers who do multiple modular streams would need to maintain both the alternate streams and ursine packages. 2. (potentially dangerous consequences?) We put the default modular stream into our regular repos, similarly to what we try to do in the buildroot. "dnf install Foo" would install the Foo package and would not enbale any streams or modules. The modular maintainers would keep maintaining the modules as now, the infrastructure would compose the defaults into the regular repo (or an additional but default-enabled one). Pros: Maintainers would keep doing what they desire. Cons: We would need to make this technically possible and figure out all the corner cases (however AFAIK this needs to be done for the "modules in buildroot" thing as well). WDYT? So despite providing zero feedback here, this was voted at the modularity meeting: * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) * AGREED: We disagree with merging default streams into the main repo as non-modular packages. Our approach is to implement a mechanism of following default streams to give people the experience they want. (+4 0 -0) (asamalik, 16:07:40) https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html I disagree strongly with the reasons provided in the logs, but clearly, we should aim for solution 1. if solution 2. is not negotiable by the modularity WG. -- 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: Modularity and the system-upgrade path
On Wed, Oct 9, 2019, 12:29 Miro Hrončok wrote: > On 04. 10. 19 21:31, Miro Hrončok wrote: > > On 04. 10. 19 16:57, Stephen Gallagher wrote: > >> Right now, there are two conflicting requirements in Fedora Modularity > >> that we need to resolve. > >> > >> 1. Once a user has selected a stream, updates should follow that > >> stream and not introduce incompatiblities. Selected streams should not > >> be changed without direct action from the user. > >> 2. So far as possible, Modularity should be invisible to those who > >> don't specifically need it. This means being able to set default > >> streams so that `yum install package` works for module-provided > >> content. > >> > >> Where this becomes an issue is at system-upgrade time (moving from > >> Fedora 30->31 or continuously tracking Rawhide). Because of > >> requirement 1, we cannot automatically move users between streams, but > >> in the case of release upgrades we often want to move to a new default > >> for the distribution. > > > > > > Wouldn't it be easier if the "default stream" would just behave like a > regular > > package? > > > > I can think of two solutions of that: > > > > 1. (drastic for modular maintainers) > > > > We keep miantaining the default versions of things as ursine packages. > We only > > modularize alternate versions. > > > > Pros: Users who don't want alternate versions won't be affected by > imperfections > > of our modular design. No Ursa Major/Prime needed in the buildroot. > > > > Cons: Modular maintainers who do modules with just one stream because it > is > > easier for them would need to rollback to what's easier for everybody > else but > > them. Modular maintainers who do multiple modular streams would need to > maintain > > both the alternate streams and ursine packages. > > > > > > 2. (potentially dangerous consequences?) > > > > We put the default modular stream into our regular repos, similarly to > what we > > try to do in the buildroot. "dnf install Foo" would install the Foo > package and > > would not enbale any streams or modules. The modular maintainers would > keep > > maintaining the modules as now, the infrastructure would compose the > defaults > > into the regular repo (or an additional but default-enabled one). > > > > Pros: Maintainers would keep doing what they desire. > > > > Cons: We would need to make this technically possible and figure out all > the > > corner cases (however AFAIK this needs to be done for the "modules in > buildroot" > > thing as well). > > > > WDYT? > > So despite providing zero feedback here, this was voted at the modularity > meeting: > > * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) >* AGREED: We disagree with merging default streams into the main repo > as non-modular packages. Our approach is to implement a mechanism of > following default streams to give people the experience they want. > (+4 0 -0) (asamalik, 16:07:40) > > > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html > > I disagree strongly with the reasons provided in the logs, but clearly, we > should aim for solution 1. if solution 2. is not negotiable by the > modularity WG. > Why am I not getting rid of the feeling that Modularity is getting shoved down our throats no matter the objections we raise? > -- > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Modularity and the system-upgrade path
On Wed, Oct 9, 2019 at 6:32 AM Fabio Valentini wrote: > > On Wed, Oct 9, 2019, 12:29 Miro Hrončok wrote: >> >> On 04. 10. 19 21:31, Miro Hrončok wrote: >> > On 04. 10. 19 16:57, Stephen Gallagher wrote: >> >> Right now, there are two conflicting requirements in Fedora Modularity >> >> that we need to resolve. >> >> >> >> 1. Once a user has selected a stream, updates should follow that >> >> stream and not introduce incompatiblities. Selected streams should not >> >> be changed without direct action from the user. >> >> 2. So far as possible, Modularity should be invisible to those who >> >> don't specifically need it. This means being able to set default >> >> streams so that `yum install package` works for module-provided >> >> content. >> >> >> >> Where this becomes an issue is at system-upgrade time (moving from >> >> Fedora 30->31 or continuously tracking Rawhide). Because of >> >> requirement 1, we cannot automatically move users between streams, but >> >> in the case of release upgrades we often want to move to a new default >> >> for the distribution. >> > >> > >> > Wouldn't it be easier if the "default stream" would just behave like a >> > regular >> > package? >> > >> > I can think of two solutions of that: >> > >> > 1. (drastic for modular maintainers) >> > >> > We keep miantaining the default versions of things as ursine packages. We >> > only >> > modularize alternate versions. >> > >> > Pros: Users who don't want alternate versions won't be affected by >> > imperfections >> > of our modular design. No Ursa Major/Prime needed in the buildroot. >> > >> > Cons: Modular maintainers who do modules with just one stream because it is >> > easier for them would need to rollback to what's easier for everybody else >> > but >> > them. Modular maintainers who do multiple modular streams would need to >> > maintain >> > both the alternate streams and ursine packages. >> > >> > >> > 2. (potentially dangerous consequences?) >> > >> > We put the default modular stream into our regular repos, similarly to >> > what we >> > try to do in the buildroot. "dnf install Foo" would install the Foo >> > package and >> > would not enbale any streams or modules. The modular maintainers would keep >> > maintaining the modules as now, the infrastructure would compose the >> > defaults >> > into the regular repo (or an additional but default-enabled one). >> > >> > Pros: Maintainers would keep doing what they desire. >> > >> > Cons: We would need to make this technically possible and figure out all >> > the >> > corner cases (however AFAIK this needs to be done for the "modules in >> > buildroot" >> > thing as well). >> > >> > WDYT? >> >> So despite providing zero feedback here, this was voted at the modularity >> meeting: >> >> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) >>* AGREED: We disagree with merging default streams into the main repo >> as non-modular packages. Our approach is to implement a mechanism of >> following default streams to give people the experience they want. >> (+4 0 -0) (asamalik, 16:07:40) >> >> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html >> >> I disagree strongly with the reasons provided in the logs, but clearly, we >> should aim for solution 1. if solution 2. is not negotiable by the >> modularity WG. > > > Why am I not getting rid of the feeling that Modularity is getting shoved > down our throats no matter the objections we raise? > It's being pushed so hard because it has been promoted as a top level objective, and because it's in RHEL now, no one can afford to let it fail. It *has* to succeed for RHEL, and for Fedora to remain a natural upstream for RHEL, it *must* succeed here too. The problem is that the RHEL approach to modules only works because RHEL is centrally developed and can be correctly coordinated to overcome issues in the design. This is not true in Fedora, and there doesn't seem to be allowances for this difference. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?
On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote: > On 10/8/19 3:26 PM, Ankur Sinha wrote: > > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote: > > > > > > > > > Look, I'm no more in love with the traditional layout than anybody, I'm > > > just > > > saying changing the default is not as simple as you'd like to think. > > > Anybody > > > wanting to work on changing the default is welcome to propose it upstream, > > > patches welcome and all. > > > > Would keeping this Fedora specific to begin with help slowly migrate > > people over? What if we announce this via the change process for F32? > > The change will be to modify `/usr/lib/rpm/macros` to use per-directory > > locations as you'd suggested in the snippet since it is closer to the > > dist-git workflow that is now in use. People can still easily revert to > > rpmbuild/*, and the contingency plan will be to just not make the > > change. I don't know how this would affect rpmdev-buildtree and how to > > handle that (remove it?). > > > > Changing rpm defaults will break existing setups, people will be unhappy and > I'll get the blame regardless of who actually did it. > > I'd rather suggest changing rpmdev-setuptree to configure things that way, > it already modifies ~/.rpmmacros in various ways, some totally redundant > (like setting %_topdir to a longtime rpm default). > That starts nudging people towards that direction, but leaves existing > setups alone. Sure. That sounds good. I'll see what I can come up with an open PRs etc. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: EPEL 7 is broken for python3 related builds
On Wed, Oct 9, 2019 at 5:33 AM Miro Hrončok wrote: > > On 09. 10. 19 4:34, Nico Kadel-Garcia wrote: > > On Tue, Oct 8, 2019 at 1:56 PM Irina Boverman wrote: > >> > >> Using "BuildRequires: python%{python3_pkgversion}-devel" results in this > >> error: > >> > >> fedpkg scratch-build > >> DEBUG util.py:593: No matching package to install: 'python36-devel' > > > > A lot of Fedora .spec files use "python3-devel" and various "pyton3-" > > modules. If you switch this to "python%{python3_pkgversion}-", *AND* > > if you add "BuildRequires: epel-rpm-mocros" for rhel based > > environments, it works much better to play nicely with the new RHEL > > and the existing EPEL packages. > > Why do you need to add "BuildRequires: epel-rpm-mocros"? It's going to be a while before EPEL gets all of the "python36" labeled packages rebuilt to say "Provides: python3-module" as well as "Provides: python36-module" for complete consistency with the altered name used by RHEL. The epel-rpm-macros package sets the python modules to set "python3_pkgversion" to be "36" instead of plain "3", and helps find and resolve the python dependencies from the slightly older EPEL versions. It also helps distinguish new built modules as being EPEL based instead of merely RHEL or CentOS based. I'm not happy that RHEL upstream selected to use "python3" instead of "python36" as the package name for their release of Python 3.6. Like modularity, it's solving one problem but generating others. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Review swap (htslib)
On Tue, Oct 08, 2019 at 06:03:26PM +0200, Jun Aruga wrote: > Someone, could give us advice about below situation, if the new > package htslib's "/usr/lib64/libhts.so.1.9" is valid? > "1.9" is upstream software's version. "2" is ABI's version (so version). The patterns used in filenames of so objects aren't really well defined. In particular, the numbers typically used like libfoo.so.MAJOR.MINOR.PATCH are only informative. The libhts convention is: libhts.so.SO_VERSION → libhts.so.PROJECT_VERSION. Upstream correctly says that there's no chance of conflict because PROJECT_VERSION always includes a dot and SO_VERSION doesn't. The compiler doesn't care. I'd say that this is a bit misleading, but not wrong. Not worth deviating from upstream. FTR: In [34]: d = os.scandir('/usr/lib64') ...: for e in d: ...: if e.is_symlink() and '.so.' in e.name and not e.name.startswith('.'): ...: t = os.readlink(e.path) ...: if e.name not in t and '.so.' in t: ...: print(e.name, t) ...: libgcalc-1.so.0.0.0 libgcalc-1.so.0 libosgFX.so.131 libosgFX.so.3.4.1 libcrypto.so.10 libcrypto.so.1.0.2o libzzip-0.so.12 libzzip-0.so.13 libosgManipulator.so.131 libosgManipulator.so.3.4.1 libosgUtil.so.131 libosgUtil.so.3.4.1 libXaw.so.7 libXaw7.so.7 libexiv2.so.27 libexiv2.so.0.27.2 libOpenThreads.so.20 libOpenThreads.so.3.3.0 libosgWidget.so.131 libosgWidget.so.3.4.1 libosgParticle.so.131 libosgParticle.so.3.4.1 libgcr-3.so.1 libgcr-ui-3.so.1.0.0 libosgText.so.131 libosgText.so.3.4.1 libzzipfseeko-0.so.12 libzzipfseeko-0.so.13 libclucene-contribs-lib.so.1 libclucene-contribs-lib.so.2.3.3.4 libjsoncpp.so.21 libjsoncpp.so.1.9.1 libgit2.so.28 libgit2.so.0.28.3 libkbookmarkmodel_private.so.6 libkbookmarkmodel_private.so.5.97.0 libosgVolume.so.131 libosgVolume.so.3.4.1 libssl.so.10 libssl.so.1.0.2o libosgViewer.so.131 libosgViewer.so.3.4.1 libmono-2.0.so.1.0.0 libmonosgen-2.0.so.1.0.0 libosgDB.so.131 libosgDB.so.3.4.1 libzzipmmapped-0.so.10 libzzipmmapped-0.so.13 libssh_threads.so.4.8.1 libssh.so.4.8.1 libzzip-0.so.11 libzzip-0.so.13 libzzipmmapped-0.so.11 libzzipmmapped-0.so.13 libosgSim.so.131 libosgSim.so.3.4.1 libosgTerrain.so.131 libosgTerrain.so.3.4.1 libv8_libbase.so.7 /usr/lib64/libnode.so.72 libKF5KExiv2.so.15.0.0 libKF5KExiv2.so.5.0.0 libzzip-0.so.10 libzzip-0.so.13 libminizip.so.2.5 libminizip.so.2.8.9 libosgAnimation.so.131 libosgAnimation.so.3.4.1 libGLX_system.so.0 /usr/lib64/libGLX_mesa.so.0 libutempter.so.0 libutempter.so.1.1.6 libzzipfseeko-0.so.10 libzzipfseeko-0.so.13 libv8.so.7 /usr/lib64/libnode.so.72 libclucene-shared.so.1 libclucene-shared.so.2.3.3.4 libv8_libplatform.so.7 /usr/lib64/libnode.so.72 libzzipfseeko-0.so.11 libzzipfseeko-0.so.13 libgcc_s.so.1 libgcc_s-9-20190827.so.1 libclucene-core.so.1 libclucene-core.so.2.3.3.4 libosgShadow.so.131 libosgShadow.so.3.4.1 libopencc.so.2 libopencc.so.1.0.0 libssh_threads.so.4 libssh.so.4.8.1 libosgUI.so.131 libosgUI.so.3.4.1 libclutter-glx-1.0.so.0 libclutter-1.0.so.0.2600.2 libosgPresentation.so.131 libosgPresentation.so.3.4.1 libosgGA.so.131 libosgGA.so.3.4.1 libosg.so.131 libosg.so.3.4.1 libfbclient.so.2 libfbclient.so.3.0.4 libmono-2.0.so.1 libmonosgen-2.0.so.1 libgit2.so.27 libgit2.so.0.27.8 libzzipmmapped-0.so.12 libzzipmmapped-0.so.13 libgcr-3.so.1.0.0 libgcr-ui-3.so.1.0.0 libopenjp2.so.7 libopenjp2.so.2.3.1 ... so yeah, this happens quite a bit. 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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
On Tue, 2019-10-08 at 18:42 +0100, Tomasz Kłoczko wrote: > IMO above shows clearly that adding "aspell-en" in mc or aspell > dependencies does not solve issue .. at all. > Kind of mitigation of that problem should be IMO change aspell error > message (by add Fedora/any rpm based distro patch) informing that > system has missing aspell- package. This sounds reasonable, making a maintainable downstream patch could be tricky though. I'll try to come up with something. Thanks, Nikola ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EPEL 7 is broken for python3 related builds
On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: It's going to be a while before EPEL gets all of the "python36" labeled packages rebuilt to say "Provides: python3-module" as well as "Provides: python36-module" for complete consistency with the altered name used by RHEL. The epel-rpm-macros package sets the python modules to set "python3_pkgversion" to be "36" instead of plain "3", and helps find and resolve the python dependencies from the slightly older EPEL versions. It also helps distinguish new built modules as being EPEL based instead of merely RHEL or CentOS based. How does epel-rpm-macros package sets the python modules to do that? What kind of sorcery is there? AFAIk it is the %python_provide macro defined in python-rpm-macors (required by python3-devel). I'm not happy that RHEL upstream selected to use "python3" instead of "python36" as the package name for their release of Python 3.6. Like modularity, it's solving one problem but generating others. All RHEL python3 packages also provide their python36 names. Where is the problem? If there is some, how can we fix it? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
Hi all, decided to disable aspell support in mc as a whole. Note it is disabled by default configure option in mc anyway. A beneficial side effect is we have now even smaller dependency footprint and the annoying message while editing *any* file goes away without aspell + friends installed. This whole feature just opens can of worms on so many levels. Jindrich On Wed, Oct 9, 2019 at 2:01 PM Nikola Forró wrote: > On Tue, 2019-10-08 at 18:42 +0100, Tomasz Kłoczko wrote: > > IMO above shows clearly that adding "aspell-en" in mc or aspell > > dependencies does not solve issue .. at all. > > Kind of mitigation of that problem should be IMO change aspell error > > message (by add Fedora/any rpm based distro patch) informing that > > system has missing aspell- package. > > This sounds reasonable, making a maintainable downstream patch could be > tricky though. I'll try to come up with something. > > Thanks, > Nikola > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to unretire libresample package, needs re-review
I intend to unretire the "libresample" package in Fedora, now that I have it building properly from source again. It needs a re-review, which I've asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928. I will open a Rel-Eng ticket for unretirement once the package has been re-reviewed. -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Intent to unretire libresample package, needs re-review
On Wed, Oct 9, 2019 at 7:47 AM Jared K. Smith wrote: > I intend to unretire the "libresample" package in Fedora, now that I have > it building properly from source again. It needs a re-review, which I've > asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928. > I can take it unless someone gets to it first. I'm in training today and then have to catch up everything else once I'm done so it may be a few days :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy
https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy Note that this was originally discussed on the devel mailing list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI == Summary == This change is about replacing the {{package|bzr}} package with {{package|breezy}}. [https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32. == Owner == * Name: [[User:churchyard| Miro Hrončok]] * Email: * Name: [[User:dormouse| Marcel Plch]] * Email: == Detailed Description == The {{package|breezy}} package will be introduced. It provides and obsoletes bzr and git-remote-bzr, it contains /usr/bin/bzr (link to /usr/bin/brz) and /usr/bin/git-remote-bzr. Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired. The reasons for this include: * bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]] * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to build from source] * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install] * bzr [https://pagure.io/fesco/issue/2227 has no maintainer] == Benefit to Fedora == Users of Fedora will be able to use bazaar repositories via breezy. If we don't do this, bzr would be simply removed without a replacement. == Scope == * '''Proposal owners:''' package {{package|breezy}} and it's dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964 the package review]) * '''Other developers:''' Test that your packages work with breezy ({{package|trac-bazaar-plugin}}, {{package|etckeeper}}, {{package|ikiwiki}}, {{package|python-vcstools}}, {{package|python-wstool}}, {{package|golang-github-masterminds-vcs}}, {{package|python-pip}} are impacted). Adapt, drop the dependency or retire the packages. * Release engineering: no impact with Release Engineering is anticipated * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Eventually removed depndent packages need to be obsoleted. Breezy aims to be compatible with bazaar, but there might be some differences. == How To Test == Test that installing bzr installs breezy, test that you can use it successfully. Test that bzr gets replaced by breezy when upgrading to Fedora 32. == User Experience == Users installing bzr will get breezy instead. The bzr command will be provided as a symbolic link to the brz (breezy) command. The basic API of that command should be the same. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Proposal owners will orphan both breezy and bzr (sorry, but not sorry). * Contingency deadline: final freeze * Blocks release? No * Blocks product? No == Documentation == # https://breezy-vcs.org/doc/en/ == Release Notes == TBD -- 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
Re: Intent to unretire libresample package, needs re-review
On Wed, Oct 9, 2019 at 8:57 AM Richard Shaw wrote: > I can take it unless someone gets to it first. I'm in training today and > then have to catch up everything else once I'm done so it may be a few days > :) > Thanks... let me know if you'd like me to review one of your packages in return. -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Replace Bazaar with Breezy
On Wed, Oct 9, 2019 at 9:15 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy > > Note that this was originally discussed on the devel mailing list: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI > > == Summary == > This change is about replacing the {{package|bzr}} package with > {{package|breezy}}. > [https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control > system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of > Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32. > > == Owner == > * Name: [[User:churchyard| Miro Hrončok]] > * Email: > > * Name: [[User:dormouse| Marcel Plch]] > * Email: > > > == Detailed Description == > The {{package|breezy}} package will be introduced. It provides and > obsoletes bzr and git-remote-bzr, it > contains /usr/bin/bzr (link to /usr/bin/brz) > and /usr/bin/git-remote-bzr. > > Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired. > > The reasons for this include: > > * bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]] > * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to > build from source] > * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install] > * bzr [https://pagure.io/fesco/issue/2227 has no maintainer] > > == Benefit to Fedora == > Users of Fedora will be able to use bazaar repositories via breezy. If > we don't do this, bzr would be simply removed without a replacement. > > == Scope == > * '''Proposal owners:''' package {{package|breezy}} and it's > dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964 > the package review]) > > * '''Other developers:''' Test that your packages work with breezy > ({{package|trac-bazaar-plugin}}, {{package|etckeeper}}, > {{package|ikiwiki}}, {{package|python-vcstools}}, > {{package|python-wstool}}, {{package|golang-github-masterminds-vcs}}, > {{package|python-pip}} are impacted). Adapt, drop the dependency or > retire the packages. > > * Release engineering: no impact with Release Engineering is anticipated > * Policies and guidelines: N/A > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > Eventually removed depndent packages need to be obsoleted. > > Breezy aims to be compatible with bazaar, but there might be some differences. > > == How To Test == > Test that installing bzr installs breezy, test that you can use it > successfully. > Test that bzr gets replaced by breezy when upgrading to Fedora 32. > > == User Experience == > Users installing bzr will get breezy instead. The bzr > command will be provided as a symbolic link to the brz > (breezy) command. The basic API of that command should be the same. > Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people can start using it? Aside from the Obsoletes and the symlinks, there's no particular reason that we couldn't have it in F31, and conditioning for below F32 would make things easier... Also, bzr failed to build in Fedora 31, last I checked... So does this mean we simply don't have a Bazaar implementation for Fedora 31? -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy
On 09. 10. 19 16:00, Neal Gompa wrote: Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people can start using it? Aside from the Obsoletes and the symlinks, there's no particular reason that we couldn't have it in F31, and conditioning for below F32 would make things easier... I think we could, if we double check for conflicts. For example the /usr/bin/git-remote-bzr file needs to be removed or renamed. I'll start by backporting the dependencies. Also, bzr failed to build in Fedora 31, last I checked... So does this mean we simply don't have a Bazaar implementation for Fedora 31? It failed to build but it is still there. We have an implementation that is not rebuildable and possibly insecure, as we cannot fix any CVE. -- 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
[Test-Announce] Reminder: Open TestCon CfP open through 31 October
You may have seen this posted in a few places, but the Open TestCon CfP is open through 31 October. This conference is focused on testing quality in open source projects. It will be held 30–31 March 2020 in Beijing, CN. Additionally, the DevConf.CZ (24–26 January in Brno, CZ) CfP is open through 1 November. DevConf.CZ has tracks dedicated to Fedora and Quality/Testing. You can see more information about both conferences and links to proposal submissions on the Community Blog post: https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reminder: DevConf.CZ CfP open through 1 November
You may have seen this posted in a few places, but the DevConf.CZ Call for Proposals is open. As in years past, there is a dedicated Fedora track in addition to tracks on Community, IoT, cloud/containers, microservices, networking, desktop, and more. DevConf.CZ is 24–26 Jaunary 2020 in Brno, CZ. Open TestCon's (30–31 March, 2020 in Beijing, CN) CfP is also open through 31 October. You can see more information about both conferences and links to proposal submissions on the Community Blog post: https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Replace Bazaar with Breezy
On 09. 10. 19 16:08, Miro Hrončok wrote: On 09. 10. 19 16:00, Neal Gompa wrote: Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people can start using it? Aside from the Obsoletes and the symlinks, there's no particular reason that we couldn't have it in F31, and conditioning for below F32 would make things easier... I think we could, if we double check for conflicts. For example the /usr/bin/git-remote-bzr file needs to be removed or renamed. I'll start by backporting the dependencies. I've also imported breezy with a bcond (off now) that replaces bzr. https://src.fedoraproject.org/rpms/breezy/c/7f084c727721b09c3406aaa636a0d8b5c081452e?branch=master -- 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
Heads-up: openQA scheduling outage over last 2 days
Hey folks! Just to let folks know that the openQA job scheduling robot (for the production instance) had a bad day and needed to go lie down for a bit, so it didn't schedule any tests for any new composes or critpath updates that appeared from about Oct 07 17:08:42 UTC until about Oct 09 15:00:00 (about 20 minutes ago). Thanks to Christian Heimes for alerting me to this. I just gave it a mug of tea and a headache pill and some sympathetic conversation and it's back in top form and scheduling tests again; it's scheduled all the things it missed and the test system is catching up with the backlog, so results will start appearing for updates and composes that were missed soon. Sorry for any inconvenience. -- 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 devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Replace Bazaar with Breezy
On 09. 10. 19 17:19, Miro Hrončok wrote: On 09. 10. 19 16:08, Miro Hrončok wrote: On 09. 10. 19 16:00, Neal Gompa wrote: Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people can start using it? Aside from the Obsoletes and the symlinks, there's no particular reason that we couldn't have it in F31, and conditioning for below F32 would make things easier... I think we could, if we double check for conflicts. For example the /usr/bin/git-remote-bzr file needs to be removed or renamed. I'll start by backporting the dependencies. I've also imported breezy with a bcond (off now) that replaces bzr. https://src.fedoraproject.org/rpms/breezy/c/7f084c727721b09c3406aaa636a0d8b5c081452e?branch=master And https://bodhi.fedoraproject.org/updates/FEDORA-2019-7fb253a20a -- 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: Modularity and the system-upgrade path
On Wed, Oct 09, 2019 at 06:39:07AM -0400, Neal Gompa wrote: > It's being pushed so hard because it has been promoted as a top level > objective, and because it's in RHEL now, no one can afford to let it > fail. It *has* to succeed for RHEL, and for Fedora to remain a natural > upstream for RHEL, it *must* succeed here too. Yes; Modularity was created in response to the too-fast/too-slow issue we see from opposite sides of the coin in both Fedora and RHEL -- and work on it was funded by Red Hat. I'm happy to encourage work towards this problem from basically any quarter, because I think it's a fundamental one we need to solve in order to continue to be relevant not just as an upstream for RHEL but in general. > The problem is that the RHEL approach to modules only works because > RHEL is centrally developed and can be correctly coordinated to > overcome issues in the design. This is not true in Fedora, and there > doesn't seem to be allowances for this difference. This seems *partly* fair. It's in some ways a natural consequence of Red Hat funding the work and having to fit into RHEL release schedules. But I think we can also get attention and work towards Fedora's needs -- especially with 8 out the door and 9 just twinkle in product management's eye. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20191009.n.0 changes
OLD: Fedora-Rawhide-20191007.n.0 NEW: Fedora-Rawhide-20191009.n.0 = SUMMARY = Added images:0 Dropped images: 3 Added packages: 31 Dropped packages:42 Upgraded packages: 176 Downgraded packages: 2 Size of added packages: 56.16 MiB Size of dropped packages:232.10 MiB Size of upgraded packages: 3.03 GiB Size of downgraded packages: 13.98 MiB Size change of upgraded packages: -29.81 MiB Size change of downgraded packages: 71.46 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20191007.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20191007.n.0-sda.raw.xz Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20191007.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: R-cyclocomp-1.1.0-1.fc32 Summary: Cyclomatic Complexity of R Code RPMs:R-cyclocomp Size:40.65 KiB Package: R-xmlparsedata-1.0.3-1.fc32 Summary: Parse Data of 'R' Code as an 'XML' Tree RPMs:R-xmlparsedata Size:28.80 KiB Package: cawbird-1.0.2-2.fc32 Summary: Fork of the Corebird GTK Twitter client that continues to work with Twitter RPMs:cawbird Size:2.57 MiB Package: flamethrower-0.10-3.fc32 Summary: A DNS performance and functional testing utility RPMs:flamethrower Size:1.40 MiB Package: golang-github-anaskhan96-soup-1.1.1-1.fc32 Summary: Web Scraper in Go, similar to BeautifulSoup RPMs:golang-github-anaskhan96-soup-devel Size:16.16 KiB Package: golang-github-hajimehoshi-mp3-0.2.1-1.fc32 Summary: MP3 decoder in pure Go RPMs:golang-github-hajimehoshi-mp3-devel Size:10.63 MiB Package: golang-github-hajimehoshi-oto-0.5.0-1.fc32 Summary: Low-level library to play sound on multiple platforms RPMs:golang-github-hajimehoshi-oto-devel Size:30.91 KiB Package: golang-github-jroimartin-gocui-0.4.0-1.fc32 Summary: Minimalist Go package aimed at creating Console User Interfaces RPMs:golang-github-jroimartin-gocui-devel Size:37.89 KiB Package: golang-github-lunixbochs-vtclean-1.0.0-1.fc32 Summary: Strips terminal escapes from text, can preserve color RPMs:golang-github-lunixbochs-vtclean golang-github-lunixbochs-vtclean-devel Size:3.48 MiB Package: golang-github-mbndr-figlet4go-0-0.1.20191009gitd6cef5b.fc32 Summary: Port of figlet to golang RPMs:golang-github-mbndr-figlet4go golang-github-mbndr-figlet4go-devel Size:3.51 MiB Package: golang-github-tomnomnom-xtermcolor-0.1.2-2.fc32 Summary: Command to convert color.Colour to the nearest xterm/bash/shell color RPMs:golang-github-tomnomnom-xtermcolor golang-github-tomnomnom-xtermcolor-devel Size:3.02 MiB Package: jdeparser-2.0.3-1.fc32 Summary: Source generator library for Java RPMs:jdeparser jdeparser-javadoc Size:310.54 KiB Package: libretro-desmume2015-0-0.1.20170817gitc27bb71.fc32 Summary: Port of Desmume to libretro RPMs:libretro-desmume2015 Size:805.26 KiB Package: libretro-gambatte-0-0.1.20190823git4d9ad7b.fc32 Summary: Libretro implementation of libgambatte RPMs:libretro-gambatte Size:693.19 KiB Package: libretro-stella2014-0-0.1.20190921git6d74ad9.fc32 Summary: Port of Stella to libretro RPMs:libretro-stella2014 Size:2.20 MiB Package: mypaint2-brushes-2.0.1-1.fc32 Summary: Collections of brushes for MyPaint RPMs:mypaint2-brushes mypaint2-brushes-devel Size:2.64 MiB Package: octave-iso2mesh-1.9.1-1.fc32 Summary: A 3D surface and volumetric mesh generator for MATLAB/Octave RPMs:iso2mesh-demos octave-iso2mesh Size:7.05 MiB Package: octave-jnifti-0.5-1.fc32 Summary: Fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter for MATLAB/Octave RPMs:jnifti-demos octave-jnifti Size:10.10 MiB Package: octave-mcxlab-0.9.5-1.fc32 Summary: MCXLAB - A GPU Monte Carlo 3-D photon transport simulator for MATLAB/Octave RPMs:octave-mcxlab Size:5.29 MiB Package: octave-zmat-0.9-1.fc32 Summary: A portable data compression/decompression toolbox for MATLAB/Octave RPMs:octave-zmat Size:606.33 KiB Package: perl-MusicBrainz-DiscID-0.06-1.fc32 Summary: Perl interface for the MusicBrainz libdiscid library RPMs:perl-MusicBrainz-DiscID Size:108.04 KiB Package: perl-WebService-MusicBrainz-1.0.5-3.fc32 Summary: Perl interface to search the musicbrainz.org database RPMs:perl-WebService-MusicBrainz Size:18.53 KiB Package: python-enthought-sphinx-theme-0.6.1-2.fc32 Summary: Sphinx theme for Enthought projects RPMs:python3-enthought-sphinx-theme Size:526.85 KiB Package: python-spdx-2.5.0-1.fc32 Summary: SPDX license list database RPMs:python3-spdx Size:317.27 KiB Package: python-spdx-lookup-0.3.2-1.fc32 Summary: SPDX license list query tool RPMs:python3-spdx-lookup Size:17.20 KiB Package: python-upt-fedora-0.3-1.fc32 Summary: Fedora backend for upt RPMs:python3-upt-fedor
[Test-Announce] Fedora 31 Final Go/No-Go meeting
Dear all, The Go/No-Go meeting for the Fedora 31 Beta release will be held on Thursday, 2019-10-17 at 17:00 UTC in #fedora-meeting-1. For more information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting View the meeting on Fedocal at: https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9631 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Re: Fedora 31 Final Go/No-Go meeting
On Wed, Oct 9, 2019 at 1:20 PM Ben Cotton wrote: > > The Go/No-Go meeting for the Fedora 31 Beta release will be held on I mean final, of course. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FreeCAD required updates (PySide2 & Coin4)
On Tue, 2019-10-08 at 10:07 -0500, Richard Shaw wrote: > On Tue, Oct 8, 2019 at 1:35 AM Ralf Corsepius wrote: > > > On 10/8/19 8:03 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote: > > > > On Mon, 7 Oct 2019, Richard Shaw wrote: > > > > > > > > > I am in the midst of updating the freecad package in two major ways: > > > > > Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from > > > > Python > > > > > 2 to 3) > > > > > and > > > > > Coin3 -> Coin4 (Which requires several other packages move to Coin4) > > > > > > > > > > I have been working with the Coin2/3, SoQt, & SIMVoleon maintainer > > > > Ralf but > > > > > I stopped getting responses. The last response by email being > > > > > September > > > > > 13th. > > > > > > > > > > I have even submitted pull requests so my requested changes can be > > > > easily > > > > > evaluated. > > > > > > > > > > https://src.fedoraproject.org/rpms/SoQt/pull-request/2 > > > > > https://src.fedoraproject.org/rpms/OpenSceneGraph/pull-request/2 > > > > > https://src.fedoraproject.org/rpms/SIMVoleon/pull-request/1 > > > > > > > > > > Updating to Coin4 is required to take care of a longstanding bug[1] > > > > > > > > > > So I'm trying to be nice but I don't think it's doing any good to wait > > > > for a > > > > > reply that may never come meanwhile the users could easily get the > > > > idea that > > > > > I (or Fedora) don't care about fixing bugs. > > > > > > Those are fairly substantial changes, but time is of essence here. > > > > I could not disagree more. Quality and stability is of more essence, here. > > > > Very few of us (packagers) are computer scientists or the like or paid like > RHEL to evaluate every possible problem that could arise with adopting new > releases of software. Nor can we all be expected to backport fixes in every > case. If you want that, run RHEL/CentOS instead. In the case of Coin4 is > addresses a REAL issue with FreeCAD and Coin3. I built test packages of the > whole stack and even went so far as to create a COPR to test the result and > moving to Coin4 does indeed fix the problem with importing SVG images as > geometry. > > So what do you suggest I do instead? Fedora tends to run the latest > versions of packages on purpose. > > > > I reviewed all three PRs, and they look fine. (One needs a rebase). > > > I think you should just push and build all packages. > > > > You don't want to know what I think of this. > > > > I knew you probably wouldn't like the changes which is why I bent over > backwards to be nice about it including submitting pull requests and > communicating with you over email. > > I even implemented the alternatives for Coin4 that you have on Coin2/3 just > so they would be compatible instead of just conflicting with Coin2 (which > is a leaf package in Fedora and Coin3 which will be a leaf package after > moving the dependencies over). > > I appreciate all the work you did maintaining the Coin3D stack over the > years in Fedora but at the end of the day we are package maintainers not > owners, a clarification that was referenced a few years ago. > > Unfortunately I had to resort to posting here on the mailing list to > provoke a response because 3 emails and almost a month later you couldn't > even reply just to say "I'm really busy but I will review your changes." > > So again I ask, what was I supposed to do? Ignore a REAL issue because you > don't like people touching your packages? Wait indefinitely? > > How long would you wait if you were in my position? What should I have done > differently? > > FreeCAD has been in a terrible state in Fedora for years and after a crap > ton of work with getting PySIde2 into Fedora, updating the Coin stack I > would like to be able to ship FUNCTIONAL packages. > > Thanks, > Richard Richard I use FreeCAD in Fedora and I want to tahnk you for your work, it is really appreciated, I think you did the right thing given the circumstances. If a maintainer wants to have a say, they have to do the work, or be completely responsive at least, otherwise they need to let go and let the ones that care do the work have their way. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: FreeCAD required updates (PySide2 & Coin4)
Stupid question: does FreeCAD have nightly packages (like openscad)? If so, how complicate would it be to run the coin4 version there for a while so people can monkey with it and find issues? Then give some time; if it seems to work happy, make it production. Just my two pesos Russos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 31 Final Freeze
Hi, Some minutes before started "Final Freeze" we send some packages to stable on bodhi [1], but bodhi didn't push then ... . I.e After final freeze announce could we have the last bodhi push ? I my point of view is not fair as a developer , having to deal with Bodhi delays ... Thanks [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c On Tue, 2019-10-08 at 12:55 -0400, Mohan Boddu wrote: > Hi all, > > Today, October 8th 2019, is an important day on the Fedora 31 > schedule [1], with significant cut-offs. > > Today we have the Final Freeze [2]. This means that only packages > which fix accepted blocker or freeze exception bugs [3][4][5] will be > marked as 'stable' and included in the Final composes. Other builds > will remain in updates-testing until the Final release is approved, > at > which point the Final freeze is lifted and packages can move to the > 'updates' repository, pending updates will be pushed before final > release as zero day updates. > > [1] https://fedoraproject.org/wiki/Releases/31/Schedule > [2] https://fedoraproject.org/wiki/Milestone_freezes > [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process > [4] > https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process > [5] > https://qa.fedoraproject.org/blockerbugs/milestone/31/final/buglist > > Regards, > Mohan Boddu > Release Engineering > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?
On Wed, Oct 09, 2019 11:54:14 +0100, Ankur Sinha wrote: > On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote: > > On 10/8/19 3:26 PM, Ankur Sinha wrote: > > > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote: > > > > > > > > > > > > Look, I'm no more in love with the traditional layout than anybody, I'm > > > > just > > > > saying changing the default is not as simple as you'd like to think. > > > > Anybody > > > > wanting to work on changing the default is welcome to propose it > > > > upstream, > > > > patches welcome and all. > > > > > > Would keeping this Fedora specific to begin with help slowly migrate > > > people over? What if we announce this via the change process for F32? > > > The change will be to modify `/usr/lib/rpm/macros` to use per-directory > > > locations as you'd suggested in the snippet since it is closer to the > > > dist-git workflow that is now in use. People can still easily revert to > > > rpmbuild/*, and the contingency plan will be to just not make the > > > change. I don't know how this would affect rpmdev-buildtree and how to > > > handle that (remove it?). > > > > > > > Changing rpm defaults will break existing setups, people will be unhappy and > > I'll get the blame regardless of who actually did it. > > > > I'd rather suggest changing rpmdev-setuptree to configure things that way, > > it already modifies ~/.rpmmacros in various ways, some totally redundant > > (like setting %_topdir to a longtime rpm default). > > That starts nudging people towards that direction, but leaves existing > > setups alone. > > Sure. That sounds good. I'll see what I can come up with an open PRs > etc. PR filed: https://pagure.io/rpmdevtools/pull-request/48 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 0 packages were orphaned 0 packages were retired 0 packages unorphaned - 0 packages were unretired 0 packages were given 0 packages had new branches Sources: https://github.com/pypingou/fedora-owner-change ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 Final Release Readiness Meeting
Dear all, Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 31 Final Release Readiness meeting. This meeting will be held on Thursday, 2019-10-17 at 19:00 UTC. We will meet to make sure we are coordinated and ready for the release of Fedora 31 Final. Please note that this meeting will be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may receive this message several times in order to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. For more information, see https://fedoraproject.org/wiki/Release_Readiness_Meetings. View the meeting on Fedocal: https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9630 -- 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
Fedora 31 compose report: 20191009.n.0 changes
OLD: Fedora-31-20191008.n.1 NEW: Fedora-31-20191009.n.0 = SUMMARY = Added images:3 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-31-20191009.n.0.iso Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-31-20191009.n.0.iso Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-31-20191009.n.0-sda.raw.xz = DROPPED IMAGES = Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191008.n.1.x86_64.vagrant-libvirt.box Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191008.n.1.x86_64.vagrant-virtualbox.box = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: EPEL 7 is broken for python3 related builds
> On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote: > >> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: >> It's going to be a while before EPEL gets all of the "python36" >> labeled packages rebuilt to say "Provides: python3-module" as well as >> "Provides: python36-module" for complete consistency with the altered >> name used by RHEL. The epel-rpm-macros package sets the python modules >> to set "python3_pkgversion" to be "36" instead of plain "3", and helps >> find and resolve the python dependencies from the slightly older EPEL >> versions. It also helps distinguish new built modules as being EPEL >> based instead of merely RHEL or CentOS based. > > How does epel-rpm-macros package sets the python modules to do that? > What kind of sorcery is there? AFAIk it is the %python_provide macro defined > in python-rpm-macors (required by python3-devel). It restores the python3_pkgversion to “36”, which EPEL packages expect and set requirements for. >> I'm not happy that RHEL upstream selected to use "python3" instead of >> "python36" as the package name for their release of Python 3.6. Like >> modularity, it's solving one problem but generating others. > > All RHEL python3 packages also provide their python36 names. Where is the > problem? If there is some, how can we fix it? Complete the reverse process. Have all EPEL python 36 modules “provide” python3-module, as well. Otherwise, building the packages with mock or koji is a bit of an adventure. > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EPEL 7 is broken for python3 related builds
On Wed, 9 Oct 2019 at 15:24, Nico Kadel-Garcia wrote: > > > > > On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote: > > > >> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: > >> It's going to be a while before EPEL gets all of the "python36" > >> labeled packages rebuilt to say "Provides: python3-module" as well as > >> "Provides: python36-module" for complete consistency with the altered > >> name used by RHEL. The epel-rpm-macros package sets the python modules > >> to set "python3_pkgversion" to be "36" instead of plain "3", and helps > >> find and resolve the python dependencies from the slightly older EPEL > >> versions. It also helps distinguish new built modules as being EPEL > >> based instead of merely RHEL or CentOS based. > > > > How does epel-rpm-macros package sets the python modules to do that? > > What kind of sorcery is there? AFAIk it is the %python_provide macro > > defined in python-rpm-macors (required by python3-devel). > > > It restores the python3_pkgversion to “36”, which EPEL packages expect and > set requirements for. > > >> I'm not happy that RHEL upstream selected to use "python3" instead of > >> "python36" as the package name for their release of Python 3.6. Like > >> modularity, it's solving one problem but generating others. > > > > All RHEL python3 packages also provide their python36 names. Where is the > > problem? If there is some, how can we fix it? > > Complete the reverse process. Have all EPEL python 36 modules “provide” > python3-module, as well. Otherwise, building the packages with mock or koji > is a bit of an adventure. Could we have an example package which is currently broken showing what you are seeing? I say this because I am most likely going to pull out a package to test which will work which doesn't invalidate your problem.. it just means I was lucky. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Open NeuroFedora team meeting: 1500 UTC on Thursday, 10th October
Hello everyone, You are all invited to attend the Open NeuroFedora team meeting this week on Thursday (10th October) at 1500UTC in #fedora-neuro on IRC (Freenode): https://webchat.freenode.net/?channels=#fedora-neuro You can convert the meeting time to your local time using: $ date --date='TZ="UTC" 1500 next Thu' or use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Neuro-Fedora+team+meeting&iso=20191010T15&p1=%3A The meeting will be chaired by @ankursinha (FranciscoD). The agenda for the meeting is: - Introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-10-03-15.06.html - Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Open bugs: https://tinyurl.com/neurofedora-bugs - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. In the "Neuroscience query of the week" section, we hope to provide attendees with the chance to ask about a neuroscience topic that they are curious about. Please go through the tickets on Pagure, and mark any other tickets that need to be discussed with the "S: Next meeting" tag. We hope to see you there! -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot Enable module default streams in the buildroot repository for modular and non-modular RPMs. == Summary == This Change (colloquially referred to as "Ursa Prime") enables the Koji build-system to include the RPM artifacts provided by module default streams in the buildroot when building non-modular (or "traditional") RPMs. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com * Responsible WG: Modularity WG == Detailed Description == As a major part of the Modularity design, we have a concept of default module streams. These streams are built as modules, but the RPM artifacts they deliver are intended to be used just like non-modular RPMS. The aspirational goal is that a user of the system who never executes a module-specific command (such as `dnf module install nodejs:8`) should experience no meaningful changes in behavior from how they would interact with a completely non-modular system. In practice, this may mean that the informational output of package managers may indicate that modules are being enabled and used, but a user that does not have a specific reason to interact with the selection of a module stream should have that managed on their behalf. Similarly, the experience for package maintainers of non-modular packages should be unaffected by an RPM dependency moving from the non-modular repository into a default module stream. Up to the present, this has not been the case; no module stream content has been available in the non-modular buildroot for other packages to consume. Koji builds of non-modular RPMs have had only the other non-modular RPMs from that release available to their buildroots. In contrast, building on local systems has access to both the non-modular RPMs and the RPMs from any of the default module streams. With this Change, Koji builds will have the same behavior and be able to depend on content provided by default module streams. It also enables the same behavior for Modular builds: the `platform` stream will now include the contents of the default module streams for each release and do not need to be explicitly specified in the modulemd `buildrequires`. Note: This Change does not address the other major Modularity issue we are facing around distribution upgrades with differing default streams. When discussing this Change, please keep that topic separate. == Benefit to Fedora == This will simplify the lives of package maintainers in Fedora in two primary ways. I'll use a hypothetical example of the Node.js interpreter and a JSApp package which is capable of running on Node.js 10 or 12 (but requires newer features than are provided by Node.js 8). Additionally, the JSApp package requires the same versions of Node.js at build-time. * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module streams. The `nodejs:10` stream is set as the default stream. * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module streams. The `nodejs:10` stream is set as the default stream. * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The `nodejs:12` stream is set as the default stream. The `nodejs:14` stream will likely become available during the F31 lifetime. * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The `nodejs:12` stream is set as the default stream. The `nodejs:14` stream will likely become available during the F32 lifetime. On Fedora 29 through 31, the Node.js package maintainer needs to build the `nodejs:10` package both as a module and as a non-modular RPM in the distribution so that the JSApp package can be built. With this Change, the Node.js package maintainer in Fedora 32+ will only need to build the various Node.js streams and make one of them the default stream. The packages from it will then be added to the buildroot for non-modular packages. This will also make the packaging process somewhat more efficient, as the maintainer needs only to manage the module stream and the MBS will build it for all configured platforms. Similarly, from the perspective of dependent maintainers, there will no longer be anxiety about needing to move their package to a module if one or more of their dependencies drops their non-modular version in favor of a default stream. Their builds will continue to work as they do today. == Scope == * Proposal owners: # Update Packaging Guidelines with [https://pagure.io/modularity/issue/146#comment-600328 requirements] for module default streams # Create a Pungi configuration to generate the buildroot from the default module streams. # Include `default_modules_scm_url` in the platform virtual module specification # Configure Koji tags for inheriting the new modular-defaults buildroot into the standard buildroot * Other developers: Packagers of default module streams will be required to conform to the [https://pagure.io/modularity/issue/146#comment-600328 policy] regarding visibility of stream artifacts. Any
Re: Modularity and the system-upgrade path
On 09. 10. 19 18:30, Matthew Miller wrote: The problem is that the RHEL approach to modules only works because RHEL is centrally developed and can be correctly coordinated to overcome issues in the design. This is not true in Fedora, and there doesn't seem to be allowances for this difference. This seems *partly* fair. It's in some ways a natural consequence of Red Hat funding the work and having to fit into RHEL release schedules. But I think we can also get attention and work towards Fedora's needs -- especially with 8 out the door and 9 just twinkle in product management's eye. And this is exactly the best time to stop and plan for a little and before we implement the a very fragile workaround proposed at the beginning of the thread just to approach the ideal state of "default modular packages behave just like regular packages". In RHEL, we put some packages in modules to have the ability to declare: This module is only supported for X years, unlike the rest of RHEL. In Fedora, we plan to maintain and treat the default modular streams the same way we do with regular packages. We have the ability to keep them as regular packages. This approach was clearly treated positively by the community in this thread so far. Let's keep modularity in Fedora to do what it was promised to do: Make it possible to install alternate versions of software. Instead, the majority of Fedora's modules is one stream only. I seriously think that brings no benefit to the users and it makes everything needlessly more complicated. -- 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: EPEL 7 is broken for python3 related builds
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote: On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote: On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: It's going to be a while before EPEL gets all of the "python36" labeled packages rebuilt to say "Provides: python3-module" as well as "Provides: python36-module" for complete consistency with the altered name used by RHEL. The epel-rpm-macros package sets the python modules to set "python3_pkgversion" to be "36" instead of plain "3", and helps find and resolve the python dependencies from the slightly older EPEL versions. It also helps distinguish new built modules as being EPEL based instead of merely RHEL or CentOS based. How does epel-rpm-macros package sets the python modules to do that? What kind of sorcery is there? AFAIk it is the %python_provide macro defined in python-rpm-macors (required by python3-devel). It restores the python3_pkgversion to “36”, which EPEL packages expect and set requirements for. I've just double checked and the package that sets this is indeed epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds. I'm not happy that RHEL upstream selected to use "python3" instead of "python36" as the package name for their release of Python 3.6. Like modularity, it's solving one problem but generating others. All RHEL python3 packages also provide their python36 names. Where is the problem? If there is some, how can we fix it? Complete the reverse process. Have all EPEL python 36 modules “provide” python3-module, as well. Otherwise, building the packages with mock or koji is a bit of an adventure. What adventure? Just BRing python%{python3_pkgversion}-foo as always worked prior to this change and it still works afterwards. -- 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: Review swap (htslib)
Jun Aruga wrote: > Someone, could give us advice about below situation, if the new > package htslib's "/usr/lib64/libhts.so.1.9" is valid? > "1.9" is upstream software's version. "2" is ABI's version (so version). This can happen with non-autotools, non-libtool projects. libtool enforces some strict rules where the full version must be of the form major.minor.revision and the major version just major. (Actually, libtool doesn't even let you specify major and minor directly, but LT_CURRENT and LT_AGE, and it computes major=LT_CURRENT-LT_AGE and minor=LT_AGE for you.) Other build systems such as CMake allow you to set arbitrary strings as the major version and the full version, and the major version need not necessarily be a prefix of the full version. So they will let you get away with 1.9 as the full version and 2 as the major version. There is nothing wrong with arbitrary versions if the build system used by upstream allows them. The Fedora packages should NOT change the upstream versioning scheme because it would make the packages incompatible with upstream. So, to sum it up, yes, /usr/lib64/libhts.so.1.9 and /usr/lib64/libhts.so.2 is a valid combination. Unusual, but valid. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
Dridi Boukelmoune wrote: > Modularity should have been opt-in until major bugs are ironed out, > and maybe we would have realized in time that either it's great or it > doesn't solve anything the problem it's addressing. +1 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
Matthew Miller wrote: > Yeah, I agree that there's a problem with non-parallel-installable modules > that aren't effectively leaves. The problem does not only happen if the module is a non-leaf at module level, but there can also be conflicts at package level, if the modules bundle non-leaf packages that then conflict between the 2 modules. (Actually, there could even be package-level conflicts from leaf packages in 2 different modules, but usually, the conflicting packages are bundled for a reason, so they are typically not leaves.) So banning non-leaf modules would not by itself be enough to solve the problem (because the modules would then resort to bundling the non-leaf packages they need and running into the package-level conflicts). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Miro Hrončok wrote: > I disagree strongly with the reasons provided in the logs, but clearly, we > should aim for solution 1. if solution 2. is not negotiable by the > modularity WG. +1 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Fabio Valentini wrote: > Why am I not getting rid of the feeling that Modularity is getting shoved > down our throats no matter the objections we raise? I have had that feeling from day one. Things have not improved since. So you are not alone with that feeling. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Robbie Harwood wrote: > What's missing from a more Debian-style solution [1] (for instance) is a > more full understanding of dependencies. We could implement "Provides:" > (or something like it) and be done with it. This also could have the > side affect of making package version upgrades more clean. [snip] > > So does having "foo-full" and "foo-minimal" both provide "foo" :) This is already possible now. "Provides: foo" has been implemented in RPM for decades. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On 09. 10. 19 22:46, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot Enable module default streams in the buildroot repository for modular and non-modular RPMs. == Summary == This Change (colloquially referred to as "Ursa Prime") enables the Koji build-system to include the RPM artifacts provided by module default streams in the buildroot when building non-modular (or "traditional") RPMs. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@redhat.com * Responsible WG: Modularity WG == Detailed Description == As a major part of the Modularity design, we have a concept of default module streams. These streams are built as modules, but the RPM artifacts they deliver are intended to be used just like non-modular RPMS. The aspirational goal is that a user of the system who never executes a module-specific command (such as `dnf module install nodejs:8`) should experience no meaningful changes in behavior from how they would interact with a completely non-modular system. In practice, this may mean that the informational output of package managers may indicate that modules are being enabled and used, but a user that does not have a specific reason to interact with the selection of a module stream should have that managed on their behalf. If this is the goal of default modular streams, wouldn't it be in fact much easier to keep the default versions as urisne packages? Similarly, the experience for package maintainers of non-modular packages should be unaffected by an RPM dependency moving from the non-modular repository into a default module stream. Up to the present, this has not been the case; no module stream content has been available in the non-modular buildroot for other packages to consume. Koji builds of non-modular RPMs have had only the other non-modular RPMs from that release available to their buildroots. In contrast, building on local systems has access to both the non-modular RPMs and the RPMs from any of the default module streams. With this Change, Koji builds will have the same behavior and be able to depend on content provided by default module streams. It also enables the same behavior for Modular builds: the `platform` stream will now include the contents of the default module streams for each release and do not need to be explicitly specified in the modulemd `buildrequires`. What I miss in the description is: 1. How does this thing actually work? is there an additional repository composed from the default streams available in Koji only? 2. How are conflicts between packages from the default streams and ursine package be handled? 3. What is the local experience if the packager is using mock. What if they are using rpmbuild directly? 4. How are we handling default streams with dependencies on non-default streams of other modules? ... == Scope == * Proposal owners: # Update Packaging Guidelines with [https://pagure.io/modularity/issue/146#comment-600328 requirements] for module default streams # Create a Pungi configuration to generate the buildroot from the default module streams. # Include `default_modules_scm_url` in the platform virtual module specification # Configure Koji tags for inheriting the new modular-defaults buildroot into the standard buildroot * Other developers: Packagers of default module streams will be required to conform to the [https://pagure.io/modularity/issue/146#comment-600328 policy] regarding visibility of stream artifacts. Any default module stream that is not in compliance by one week before Beta Freeze will cease to be a default stream. What are the packagers of ursine packages that are shadowed by their modular counterparts supposed to do here (assuming such shadowing happens)? What are the packagers of modular packages that are shadowed by their ursine counterparts supposed to do here (assuming such shadowing happens)? ... == How To Test == # Build a modular stream # Make that stream a default stream (or a buildroot override) # Build a non-modular RPM that requires an artifact RPM from the modular stream. How can I test this as an ursine package maintainer assuming I have build dependencies that were ursine packages but now will be form modules? ... == Contingency Plan == * Contingency mechanism: Disable the buildroot inheritance in Koji to revert to the current behavior. Assuming ursine packges will be retired from Fedora, what is the contingency there? Consider this scenario: 1. maintainers of the ook module welcome this change and finally they retire ook from ursine Fedora, shipping only the default ook:12 modular stream. 2. maintainers of ook-cool and ook-free happily build against modular ook:12 3. a previously unknown fundamental flaw in design triggers the contingency plan 4. ook-cool and ook-free FTBFS, maintainer of ook do no longer wish to maintain ook as ursine package, because the entire depndncy tree to make that happen was gone/update
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, 9 Oct 2019 at 18:46, Miro Hrončok wrote: > > What I miss in the description is: > > 1. How does this thing actually work? is there an additional repository > composed > from the default streams available in Koji only? > > 2. How are conflicts between packages from the default streams and ursine > package be handled? > > 3. What is the local experience if the packager is using mock. What if they > are > using rpmbuild directly? > So from doing a lot of builds with mock, then the packager should be ok because mock pulls in modules and you can define in mock which module streams you want if you needed something differently. For rpmbuild it is a bit harder because you may have used one module on your local system and built with another.. However in someways this is similar to rpm where I might have installed an F31 package on my F30 system to test something and then found out my local rpmbuild didn't work. In many ways I found working with mock easier than working with any of the other system tools when dealing with modules. The file is very well commented and it was clear what I needed to do to make it work. So I can't answer anything else.. but I think the local experience for mock users will be smoother than elsewhere. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Modules in Non-Modular Buildroot
On 10. 10. 19 1:44, Stephen John Smoogen wrote: On Wed, 9 Oct 2019 at 18:46, Miro Hrončok wrote: What I miss in the description is: 1. How does this thing actually work? is there an additional repository composed from the default streams available in Koji only? 2. How are conflicts between packages from the default streams and ursine package be handled? 3. What is the local experience if the packager is using mock. What if they are using rpmbuild directly? So from doing a lot of builds with mock, then the packager should be ok because mock pulls in modules and you can define in mock which module streams you want if you needed something differently. For rpmbuild it is a bit harder because you may have used one module on your local system and built with another.. However in someways this is similar to rpm where I might have installed an F31 package on my F30 system to test something and then found out my local rpmbuild didn't work. In many ways I found working with mock easier than working with any of the other system tools when dealing with modules. The file is very well commented and it was clear what I needed to do to make it work. So I can't answer anything else.. but I think the local experience for mock users will be smoother than elsewhere. What I really care about here is that the mock experience more or less equals the Koji experience. I.e. I don't want the packagers to (need to) enable modules in mock when in fact in Koji they are not enabled, but some other magic is happening. Having a description about what this change actually does to enable modules in the buildroot will hopefully steer this discussion more to the specifics of how to enable the same thing in mock (by default). -- 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
Fedora-31-20191009.n.0 compose check report
No missing expected images. Failed openQA tests: 4/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191008.n.1): ID: 465842 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/465842 Old failures (same test failed in Fedora-31-20191008.n.1): ID: 465793 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/465793 ID: 465832 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/465832 ID: 465855 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/465855 ID: 465858 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/465858 Soft failed openQA tests: 1/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20191008.n.1): ID: 465911 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/465911 Passed openQA tests: 148/153 (x86_64) New passes (same test not passed in Fedora-31-20191008.n.1): ID: 465819 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/465819 ID: 465851 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/465851 ID: 465852 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/465852 ID: 465865 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/465865 ID: 465907 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/465907 Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.73 to 0.53 Previous test data: https://openqa.fedoraproject.org/tests/464899#downloads Current test data: https://openqa.fedoraproject.org/tests/465824#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.49 to 0.38 Previous test data: https://openqa.fedoraproject.org/tests/464901#downloads Current test data: https://openqa.fedoraproject.org/tests/465826#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 3.80 to 1.36 Average CPU usage changed from 38.46190476 to 28.29047619 Previous test data: https://openqa.fedoraproject.org/tests/464914#downloads Current test data: https://openqa.fedoraproject.org/tests/465839#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 2.16 to 0.76 Previous test data: https://openqa.fedoraproject.org/tests/464916#downloads Current test data: https://openqa.fedoraproject.org/tests/465841#downloads Installed system changes in test x86_64 universal install_package_set_minimal: System load changed from 0.00 to 0.12 Previous test data: https://openqa.fedoraproject.org/tests/464992#downloads Current test data: https://openqa.fedoraproject.org/tests/465917#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used mem changed from 776 MiB to 1000 MiB 1 services(s) added since previous compose: pcscd.service System load changed from 1.33 to 2.22 Average CPU usage changed from 1.53809524 to 86.46190476 Previous test data: https://openqa.fedoraproject.org/tests/465007#downloads Current test data: https://openqa.fedoraproject.org/tests/465932#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-31-20191008.n.1 compose check report
No missing expected images. Failed openQA tests: 8/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191007.n.0): ID: 464926 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/464926 ID: 464927 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/464927 ID: 464940 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/464940 ID: 464982 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/464982 ID: 464986 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/464986 Old failures (same test failed in Fedora-31-20191007.n.0): ID: 464868 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/464868 ID: 464907 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/464907 ID: 464930 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/464930 ID: 464933 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/464933 Soft failed openQA tests: 1/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20191007.n.0): ID: 464894 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/464894 Passed openQA tests: 144/153 (x86_64) Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.62 to 0.73 Average CPU usage changed from 11.14285714 to 30.72380952 Previous test data: https://openqa.fedoraproject.org/tests/464364#downloads Current test data: https://openqa.fedoraproject.org/tests/464899#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.33 to 0.49 Previous test data: https://openqa.fedoraproject.org/tests/464366#downloads Current test data: https://openqa.fedoraproject.org/tests/464901#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 0.54 to 3.80 Previous test data: https://openqa.fedoraproject.org/tests/464379#downloads Current test data: https://openqa.fedoraproject.org/tests/464914#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.88 to 2.16 Previous test data: https://openqa.fedoraproject.org/tests/464381#downloads Current test data: https://openqa.fedoraproject.org/tests/464916#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Mount /run/user/1000 contents changed to 114.1315015% of previous size Previous test data: https://openqa.fedoraproject.org/tests/464397#downloads Current test data: https://openqa.fedoraproject.org/tests/464934#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 0.29 to 1.33 Previous test data: https://openqa.fedoraproject.org/tests/464446#downloads Current test data: https://openqa.fedoraproject.org/tests/465007#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20191009.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 45 required tests failed, 2 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 5/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191007.n.0): ID: 465484 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/465484 ID: 465502 Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/465502 Old failures (same test failed in Fedora-Rawhide-20191007.n.0): ID: 465431 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/465431 ID: 465489 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/465489 ID: 465493 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/465493 ID: 465496 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/465496 Soft failed openQA tests: 4/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20191007.n.0): ID: 465470 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/465470 Old soft failures (same test soft failed in Fedora-Rawhide-20191007.n.0): ID: 465542 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/465542 ID: 465547 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/465547 ID: 465549 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/465549 Passed openQA tests: 144/153 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191007.n.0): ID: 465541 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/465541 ID: 465579 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/465579 Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 1 packages(s) added since previous compose: psmisc Previous test data: https://openqa.fedoraproject.org/tests/464174#downloads Current test data: https://openqa.fedoraproject.org/tests/465427#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 1 packages(s) added since previous compose: psmisc 1 services(s) removed since previous compose: pcscd.service Previous test data: https://openqa.fedoraproject.org/tests/464176#downloads Current test data: https://openqa.fedoraproject.org/tests/465429#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used mem changed from 886 MiB to 1002 MiB Used swap changed from 3 MiB to 5 MiB 3 packages(s) added since previous compose: criu, libnet, runc 1 services(s) added since previous compose: bolt.service System load changed from 0.52 to 0.94 Average CPU usage changed from 13.49523810 to 33.3667 Previous test data: https://openqa.fedoraproject.org/tests/464209#downloads Current test data: https://openqa.fedoraproject.org/tests/465462#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 3 packages(s) added since previous compose: criu, libnet, runc 1 services(s) added since previous compose: bolt.service Average CPU usage changed from 6.80952381 to 26.05238095 Previous test data: https://openqa.fedoraproject.org/tests/464211#downloads Current test data: https://openqa.fedoraproject.org/tests/465464#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 747 MiB to 870 MiB System load changed from 4.29 to 3.06 Average CPU usage changed from 71.01904762 to 32.29523810 Previous test data: https://openqa.fedoraproject.org/tests/464224#downloads Current test data: https://openqa.fedoraproject.org/tests/465477#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.70 to 1.52 Previous test data: https://openqa.fedoraproject.org/tests/464226#downloads Current test data: https://openqa.fedoraproject.org/tests/465479#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Mount /run/user/1000 contents changed to 114.0824338% of previous size Used mem changed from 725 MiB to 881 MiB Used Swap grew from 0 to 9 MiB 1 services
Re: EPEL 7 is broken for python3 related builds
On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok wrote: > > On 09. 10. 19 21:23, Nico Kadel-Garcia wrote: > >> On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote: > >>> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: > >>> It's going to be a while before EPEL gets all of the "python36" > >>> labeled packages rebuilt to say "Provides: python3-module" as well as > >>> "Provides: python36-module" for complete consistency with the altered > >>> name used by RHEL. The epel-rpm-macros package sets the python modules > >>> to set "python3_pkgversion" to be "36" instead of plain "3", and helps > >>> find and resolve the python dependencies from the slightly older EPEL > >>> versions. It also helps distinguish new built modules as being EPEL > >>> based instead of merely RHEL or CentOS based. > >> > >> How does epel-rpm-macros package sets the python modules to do that? > >> What kind of sorcery is there? AFAIk it is the %python_provide macro > >> defined in python-rpm-macors (required by python3-devel). > > > > > > It restores the python3_pkgversion to “36”, which EPEL packages expect and > > set requirements for. > > > I've just double checked and the package that sets this is indeed > epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds. > > >>> I'm not happy that RHEL upstream selected to use "python3" instead of > >>> "python36" as the package name for their release of Python 3.6. Like > >>> modularity, it's solving one problem but generating others. > >> > >> All RHEL python3 packages also provide their python36 names. Where is the > >> problem? If there is some, how can we fix it? > > > > Complete the reverse process. Have all EPEL python 36 modules “provide” > > python3-module, as well. Otherwise, building the packages with mock or koji > > is a bit of an adventure. > > What adventure? Just BRing python%{python3_pkgversion}-foo as always worked > prior to this change and it still works afterwards. Except that, for RHEL 7.7 and CentOS 7.7, they set python3_pkgversion to "3". epel-rpm-macros restores it to "36", and re-enables build-time dependency on the python36 modules that are only available from EPEL. Fedora SRPM's have taken to listing dependencies as "python3-module", so if you try to build a Fedora SRPM on RHEL or CentOS without doing this "epel-rpm-macros" and replacing "python3-" with "python%{python3_pkgversion}", you can't resolve the dependencies. I've run full force into this with backporting things like updated releases of awscli. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EPEL 7 is broken for python3 related builds
On 10. 10. 19 2:11, Nico Kadel-Garcia wrote: On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok wrote: On 09. 10. 19 21:23, Nico Kadel-Garcia wrote: On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote: On 09. 10. 19 13:47, Nico Kadel-Garcia wrote: It's going to be a while before EPEL gets all of the "python36" labeled packages rebuilt to say "Provides: python3-module" as well as "Provides: python36-module" for complete consistency with the altered name used by RHEL. The epel-rpm-macros package sets the python modules to set "python3_pkgversion" to be "36" instead of plain "3", and helps find and resolve the python dependencies from the slightly older EPEL versions. It also helps distinguish new built modules as being EPEL based instead of merely RHEL or CentOS based. How does epel-rpm-macros package sets the python modules to do that? What kind of sorcery is there? AFAIk it is the %python_provide macro defined in python-rpm-macors (required by python3-devel). It restores the python3_pkgversion to “36”, which EPEL packages expect and set requirements for. I've just double checked and the package that sets this is indeed epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds. I'm not happy that RHEL upstream selected to use "python3" instead of "python36" as the package name for their release of Python 3.6. Like modularity, it's solving one problem but generating others. All RHEL python3 packages also provide their python36 names. Where is the problem? If there is some, how can we fix it? Complete the reverse process. Have all EPEL python 36 modules “provide” python3-module, as well. Otherwise, building the packages with mock or koji is a bit of an adventure. What adventure? Just BRing python%{python3_pkgversion}-foo as always worked prior to this change and it still works afterwards. Except that, for RHEL 7.7 and CentOS 7.7, they set python3_pkgversion to "3". epel-rpm-macros restores it to "36", and re-enables build-time dependency on the python36 modules that are only available from EPEL. Fedora SRPM's have taken to listing dependencies as "python3-module", so if you try to build a Fedora SRPM on RHEL or CentOS without doing this "epel-rpm-macros" and replacing "python3-" with "python%{python3_pkgversion}", you can't resolve the dependencies. That wasn't possible before either. -- 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: EPEL 7 is broken for python3 related builds
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote: I'm not happy that RHEL upstream selected to use "python3" instead of "python36" as the package name for their release of Python 3.6. Like modularity, it's solving one problem but generating others. All RHEL python3 packages also provide their python36 names. Where is the problem? If there is some, how can we fix it? Complete the reverse process. Have all EPEL python 36 modules “provide” python3-module, as well. If you give me a list of packages that you need, I can rebuild them to add the provide. Please don't just say "all", but actually either only give me the ones that block you or all that still don't have it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Final Freeze
Sérgio Basto wrote on 2019/10/10 3:06: Hi, Some minutes before started "Final Freeze" we send some packages to stable on bodhi [1], but bodhi didn't push then ... . I.e After final freeze announce could we have the last bodhi push ? I my point of view is not fair as a developer , having to deal with Bodhi delays ... Thanks [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c Because as written on https://fedoraproject.org/wiki/Releases/31/Schedule (and as some people already complains about it), the freeze time was 2019-10-08 0:00 UTC, not 2019-10-08 23:59 UTC . So when the final freeze announce was sent, it was _already_ frozen. Regards, Mamoru On Tue, 2019-10-08 at 12:55 -0400, Mohan Boddu wrote: Hi all, Today, October 8th 2019, is an important day on the Fedora 31 schedule [1], with significant cut-offs. Today we have the Final Freeze [2]. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. [1] https://fedoraproject.org/wiki/Releases/31/Schedule [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/31/final/buglist Regards, Mohan Boddu Release Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FedoraRespin-30-updates-20191009.0 compose check report
Missing expected images: Soas live x86_64 Failed openQA tests: 2/31 (x86_64) ID: 466138 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/466138 ID: 466148 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/466148 Soft failed openQA tests: 1/31 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 466130 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/466130 Passed openQA tests: 28/31 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FreeCAD required updates (PySide2 & Coin4)
On Tue, Oct 8, 2019 at 3:54 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Oct 08, 2019 at 08:32:47AM +0200, Ralf Corsepius wrote: > > > > > >Those are fairly substantial changes, but time is of essence here. > > I could not disagree more. Quality and stability is of more essence, > here. > > Richard is working on updating Coin to the latest version along with the > dependent packages. The PRs were for rawhide. I don't think there's much > choice: we need to update to latest versions of packages and rawhide is > the appropriate place to do it, and we are early in the release cycle. > So the PRs were for Rawhide, but the bug I'm trying to fix exists on all supported Fedora releases. I wasn't planning on updating F29 at this point but F30 does have a lot of life left. I don't like the idea of major upgrades within a release but the list of dependencies (as noted by the list of PRs) is fairly small and through my COPR I have found no *build* issues with the update. I'm open to suggestion here but I don't like leaving broken software in Fedora and basically having to tell the user, "It's fixed in Rawhide so you'll get it eventually..." Thoughts? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390x: glibc32 and gcc
Hi all, I'm in the midst of the mpfr 4 rebuilds. I just tried to kick off a long chain build, the first build of which is the final gcc rebuild that will give us an mpfr 4-using gcc. Unfortunately, not all of its dependencies could be installed on s390x; root.log says: DEBUG util.py:593: No matching package to install: '/lib/libc.so.6' DEBUG util.py:595: Package glibc-2.30.9000-11.fc32.s390x is already installed. DEBUG util.py:593: No matching package to install: '/usr/lib/libc.so' DEBUG util.py:595: Package binutils-2.32-27.fc32.s390x is already installed. DEBUG util.py:595: Package glibc-2.30.9000-11.fc32.s390x is already installed. DEBUG util.py:593: Not all dependencies satisfied DEBUG util.py:593: Error: Some packages could not be found. The previous build found glibc32, but I see this in the glibc32 changelog: * Tue Oct 08 2019 Florian Weimer - 2.30-6.1 - Update to glibc-2.30-6.fc31. - Drop ppc64 and s390x support. ppc64 is gone completely, and Fedora no longer has a 31-bit userland on s390x. - Add scripts and instructions from downstream. Written by Carlos O'Donell. The previous build managed to grab the last build of glibc32 for s390x, it seems. I'm going to assume that this means that s390x should be removed from the multilib_64_arches variable in the gcc spec, just so I can keep these builds going. (There are at least 3 days of builds still to go.) If that is wrong, please let me know ASAP so I can make it right before anything lands in Rawhide. I think this glibc32 change should have been mentioned on fedora-devel-list. Thanks, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
koji web interface is very slow
Anyone else seeing this? If so, anyone know the reason and plans to fix? Thanks! -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: s390x: glibc32 and gcc
On Wed, Oct 9, 2019 at 8:25 PM Jerry James wrote: > The previous build managed to grab the last build of glibc32 for > s390x, it seems. I'm going to assume that this means that s390x > should be removed from the multilib_64_arches variable in the gcc > spec, just so I can keep these builds going. (There are at least 3 > days of builds still to go.) If that is wrong, please let me know > ASAP so I can make it right before anything lands in Rawhide. Sadly, simply removing s390x from multilib_64_arches was insufficient. In file included from /usr/include/features.h:489, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:27, from ../../../../libgcc/../gcc/tsystem.h:87, from ../../../../libgcc/libgcov.h:42, from ../../../../libgcc/libgcov-merge.c:26: /usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such file or directory 8 | # include | ^~~~ compilation terminated. make[5]: *** [Makefile:920: _gcov_merge_add.o] Error 1 So does that mean that glibc has to be rebuilt first, with s390 and s390x removed from biarcharches? Whoever knows how to fix this, please poke me when you've done whatever magic needs to be done so I can restart the big chain build to finish off the mpfr 4 change. Thanks! -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x: glibc32 and gcc
* Jerry James: > On Wed, Oct 9, 2019 at 8:25 PM Jerry James wrote: >> The previous build managed to grab the last build of glibc32 for >> s390x, it seems. I'm going to assume that this means that s390x >> should be removed from the multilib_64_arches variable in the gcc >> spec, just so I can keep these builds going. (There are at least 3 >> days of builds still to go.) If that is wrong, please let me know >> ASAP so I can make it right before anything lands in Rawhide. > > Sadly, simply removing s390x from multilib_64_arches was insufficient. > > In file included from /usr/include/features.h:489, > from /usr/include/bits/libc-header-start.h:33, > from /usr/include/stdio.h:27, > from ../../../../libgcc/../gcc/tsystem.h:87, > from ../../../../libgcc/libgcov.h:42, > from ../../../../libgcc/libgcov-merge.c:26: > /usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such > file or directory > 8 | # include > | ^~~~ > compilation terminated. > make[5]: *** [Makefile:920: _gcov_merge_add.o] Error 1 > > > So does that mean that glibc has to be rebuilt first, with s390 and > s390x removed from biarcharches? Sorry, I wasn't aware that you were trying to rebuild gcc this week. I spoke to Jakub about the glibc32 change, and he had no objections. It's not clear how you are handling the transition. Why do you need to change GCC build requirements? Did anyone request this? I would have expected a run-time-only compat-mpfr library with the old soname, so that GCC keeps working until it is rebuilt. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org