Re: GCC / annobin changes in F30
Le ven. 28 juin 2019 à 06:03, Michael Cronenworth a écrit : > > Hi, > > I was attempting to package the Kodi 18.3 update for RPMFusion but ran into a > compiler > error very early in the build. GCC outputs the following type of messages: > > cc: error: .annobin-Wl,-wrap,_IO_getc.end: No such file or directory > cc: error: .annobin-Wl,-wrap,_IO_getc.start: No such file or directory > ...snip... > cc: error: .text.-Wl,-wrap,_IO_getc.group: No such file or directory > cc: error: .text.-Wl,-wrap,_IO_getc_unlocked.group: No such file or directory > ...snip... IIRC, the problem we had with kodi buildsys is that every compiler option that isn't known isn't wrapped as appropriate. So if a new annobin option is used, it has to be declared to an exception list. Please have a look (and update) kodi-18-annobin-aarch64-workaround.patch as appropriate. Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: always update the bootloader during major upgrades
Le jeudi 27 juin 2019 à 12:26 -0600, Chris Murphy a écrit : > On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III > wrote: > > On Wed, Jun 26, 2019 at 14:19:26 -0600, > > Chris Murphy wrote: > > > Short version: Fedora should take responsibility for the > > > bootloader > > > being up to date, by updating it during major version upgrades. > > > This > > > is already the case on UEFI with conventional installations. I'd > > > like > > > to make sure it always happens on major version upgrades for BIOS > > > installations. What's the problem? This would step on any custom > > > bootloader configuration a user has for multiboot. There is no > > > reasonable mechanism on BIOS systems to determine if the > > > bootloader is > > > a Fedora bootloader, and somehow only update a Fedora bootloader > > > and > > > not touch any other bootloader. > > > > How do you envision this working for rawhide? > > I had a problem where grub1 configs were no longer updated with > > kernel > > updates, where I finally needed to upgrade to grub2. > > Yep, small problem. And I'm not even sure how a 'grub2-install' on > BIOS systems would be initiated only at major upgrade time. But even > Fedora Rawhide does change versions when fcXX becomes fcXX+1, but is > that a sane trigger? It's not, such magic “it's FCX time” break all the time for users that only do dnf update, or use rawhide (which branches before the next version logic is deployed), etc > I'm not sure what the alternatives are. That's, easy, 1. add a generic bootctl install command that knows the different variants of bootloader used in Fedora, how to install them, how to identify which variant is appropriate for a system (make grub and other bootloaders packages install the corresponding info in a directory read by this command) 2. make it write the id, generation, and deployment options used in a lockfile every time it (re)installs the bootloader 3. add a config file with a variable to inhibit auto-redeployment 4. add a scriptlet to the bootctl package that calls bootctl install and – checks the variant in the lockfile is appropriate for the hardware (in case of disk mode or copy) – checks if the generation is current or unknown (unknown = future, do not touch) – and if any of those is false, reinstalls the bootloader, unless the inhibit variable is set 5. add a --force switch to bootctl to allow the operator to force a bootloader rewrite every time somethins else broke it -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On 6/25/19 12:25 PM, Miro Hrončok wrote: On 25. 06. 19 12:07, Pierre-Yves Chibon wrote: On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote: On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: I would say the scoping should happen (e.g. in copr) first, then we'll know what the scope (and hence feasibility) of this change truly is. What will the scoping actually tell us? If it tells us that X hundred packages need to add BR for python3-test, we'll just do that and report the list to upstream. We can do that during the mass rebuild. If there would indeed be X hundred packages affected, would this move still make sense? The python3-test subpackage is even larger than most of the rest of python3 combined, and the vast majority of it is irrelevant to other packages. Such usage would indicate to me that some work needs to be done within the ecosystem to respect its official status as internal-only. (Perhaps, in that case, a move to python3- devel could be considered instead.) Good questions. What number of affected packages do you think would be crucial? I say X hundred, because I don't anticipate it will go to thousands. However with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that this is build dependency, not a runtime one. Nevertheless, there has been a great deal of effort recently to shrink buildroots and speed up build times. Having to add BR: python3-test to packages would mean adding a download of ~9MiB and an installation of ~3K files to every single affected package's build time. IMO this needs to be fully scoped before consideration. Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, but currently these files are part of python3-libs which *every packages* get. In other words, for the packages that require python3-test the amount of data downloaded doesn't change while for all the packages that do *not* require python3-test, the amount of data is reduced. This sounds like a win to me :) Unfortunately, this is not correct. python3-test already is large. We just move a small bit of python3-libs (test.support) and we move it to python3-test for consistency. test.support is 396K installed (for Python 3.8). Arf, then it's a lesser win than I thought. Have you considered doing a python3-test-support subpackage? This would allow the separate package and thus give you the information you're looking for as well as avoid downloading the entire python3-test for these few files. The purpose of this change is to make packaging of Python easier and avoid problems, when the test.support module cannot be properly used without the rest of the test module. What you are proposing will make packaging more complicated and would not eliminate the problems at all. I think we are talking about couple packages here. Would it make sense to have a number and say that if more than X packages suddenly need to add BR for python3-test, we revert the change and consider a different approach? BTW python3-test is now buildrequired by 7 packages: python-bz2file python-honcho python-iniparse python-kitchen python-typing-extensions python-urwid python-zodbpickle I am bringing here some numbers which help us to understand that the change won't affect a lot of packages. I've prepared a special COPR [0] where test.support module is not available at all and then I rebuilt all Python packages. From 2952 packages 2769 built successfully and only 182 failed. Most failures were caused by missing dependencies (python2-), incompatible pytest or sphinx version, etc. and only 7 packages fail to build because of the missing test.support module. From those 7 packages, 4 already require python3-test so there will be need to change only 3 packages after we'll move test.support module from python3-libs to python3-test. [0] https://copr.fedorainfracloud.org/coprs/lbalhar/test.support_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
Re: Fedora 31 System-Wide Change proposal: Python means Python3
On Thu, Jun 27, 2019 at 5:20 PM Miro Hrončok wrote: > > On 27. 06. 19 17:15, Adam Williamson wrote: > > On Thu, 2019-06-27 at 12:32 +0200, Miro Hrončok wrote: > >> On 26. 06. 19 20:07, Adam Williamson wrote: > >>> On Wed, 2019-06-26 at 13:57 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > == Summary == > In package and command names, "Python" will mean "Python 3". > > Users installing and running Python or Python packages without > specifying a version will get Python 3. > > Running python will run python3. > >>> > >>> Oh, man. I thought we'd decided against this in the past? > >> > >> We did. Circumstances changed. > > > > Out of interest, what circumstances? > > Mostly date. > > https://fedoraproject.org/wiki/Changes/Python_means_Python3#Benefit_to_Fedora > > "The name 'Python' will not refer to software that will be unmaintained > upstream > for most of Fedora 31's lifetime and retired from Fedora 32." > > Also, before, we have decided to not do this, as it was against the upstream > recommendation. That recommendation is changing now as Python 2 approaches > EOL. > > See https://github.com/python/peps/pull/989 > > >>> I'm worried > >>> about the cost/benefit ratio on such a change. > >> > >> What worries you do most about "the cost"? > > > > I mean, generalized existential dread? :) > > > > The most obvious is scripts with #!/usr/bin/python . OK, we can try and > > find every single one in the distro and patch them (though I'm sure > > some will get missed somehow) > > Yes, we've already done that. > https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package > https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error > > > but there will certainly be ones that > > *aren't part of the distro* that get bitten by this. > > There, you are correct. However, would we want "python" to mean Python 2 > forever? Or do we want to phase things out slowly and make a designated point > in > the future, where this is changed? I suppose to me the big one with be pypi and what the expectation in that community is around which version of python points to /usr/bin/python, have they been running tests against the repositories there and if it'll break things installed via pip. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
On 28. 06. 19 10:22, Peter Robinson wrote: On Thu, Jun 27, 2019 at 5:20 PM Miro Hrončok wrote: On 27. 06. 19 17:15, Adam Williamson wrote: On Thu, 2019-06-27 at 12:32 +0200, Miro Hrončok wrote: On 26. 06. 19 20:07, Adam Williamson wrote: On Wed, 2019-06-26 at 13:57 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Python_means_Python3 == Summary == In package and command names, "Python" will mean "Python 3". Users installing and running Python or Python packages without specifying a version will get Python 3. Running python will run python3. Oh, man. I thought we'd decided against this in the past? We did. Circumstances changed. Out of interest, what circumstances? Mostly date. https://fedoraproject.org/wiki/Changes/Python_means_Python3#Benefit_to_Fedora "The name 'Python' will not refer to software that will be unmaintained upstream for most of Fedora 31's lifetime and retired from Fedora 32." Also, before, we have decided to not do this, as it was against the upstream recommendation. That recommendation is changing now as Python 2 approaches EOL. See https://github.com/python/peps/pull/989 I'm worried about the cost/benefit ratio on such a change. What worries you do most about "the cost"? I mean, generalized existential dread? :) The most obvious is scripts with #!/usr/bin/python . OK, we can try and find every single one in the distro and patch them (though I'm sure some will get missed somehow) Yes, we've already done that. https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error but there will certainly be ones that *aren't part of the distro* that get bitten by this. There, you are correct. However, would we want "python" to mean Python 2 forever? Or do we want to phase things out slowly and make a designated point in the future, where this is changed? I suppose to me the big one with be pypi and what the expectation in that community is around which version of python points to /usr/bin/python, have they been running tests against the repositories there and if it'll break things installed via pip. In my experience pip installed packages generally handle shebangs well (e.g. they set the shebang to the pip's interpreter). Of course there might be some packages where this is not true, but the enormous adaptation of using Python virtual environments IMHO battle tested this for years. -- 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 Self-Contained Change proposal: DNF Make Best Mode the Default
On 2019-06-27, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DNF_Default_Best > >== Summary == > Currently, DNF prefers clean dependency resolution over package > updates; a package (almost) silently won't get updated to a newer > version if the new version has dependency problems. DNF will be > changed to prefer updates and fail if they have dependency resolution > issues, while the failure has a temporal or permanent workaround hint > for users who want to use the older behavior. > This will also apply to DNF in Koji. And that will complicate bootstrapping Perl ecosystem. We will probably cope with the change by adding another step to the process of boostrapping Perl. Nevertheless I have a question whether the "best" strategy applies to package NEVRAs only or if it also applies to Provides and Requires. E.g. if a package A provides FOO = 1 and a package B provides FOO = 2, will installing FOO insist on installing package B or will it keep freedom to choose between A and B? -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default
On Fri, Jun 28, 2019 at 10:35 AM Petr Pisar wrote: > On 2019-06-27, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DNF_Default_Best > > > >== Summary == > > Currently, DNF prefers clean dependency resolution over package > > updates; a package (almost) silently won't get updated to a newer > > version if the new version has dependency problems. DNF will be > > changed to prefer updates and fail if they have dependency resolution > > issues, while the failure has a temporal or permanent workaround hint > > for users who want to use the older behavior. > > > This will also apply to DNF in Koji. And that will complicate > bootstrapping Perl ecosystem. We will probably cope with the change by > adding another step to the process of boostrapping Perl. > > Nevertheless I have a question whether the "best" strategy applies to > package NEVRAs only or if it also applies to Provides and Requires. E.g. > if a > > package A provides FOO = 1 > > and a > > package B provides FOO = 2, > > will installing FOO insist on installing package B or will it keep > freedom to choose between A and B? > If you request Package A you will always get package A. If you will request package in lover version, you will get the package in requested version. Jaroslav > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: DNF Make Best Mode the Default
Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > On Thu, Jun 27, 2019 at 10:37:28AM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/DNF_Default_Best > I wanted to update today, and I got the following report: > $ sudo dnf upgrade --best > Last metadata expiration check: 0:00:18 ago on Thu 27 Jun 2019 10:45:00 PM > CEST. > Error: > Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libnetlib.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libv3p_netlib.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvcl.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvnl.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvnl_algo.so.1.14()(64bit), but none of the providers can be installed > - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64 > - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64 > - cannot install the best update candidate for package > vxl-1.17.0-30.fc30.x86_64 > - cannot install the best update candidate for package > InsightToolkit-4.9.1-9.fc29.x86_64 > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages) > > The problem with this is that it's not possible to figure out what who is too > blame. > Specifically: > 1. How am I to know that vxl is related to libnetlib.so.1.14()(64bit) and >the other virtual provides? > > 2. >> - cannot install the best update candidate for package >> vxl-1.17.0-30.fc30.x86_64 >> - cannot install the best update candidate for package >> InsightToolkit-4.9.1-9.fc29.x86_64 > I see that vxl-1.17 and vxl-2.0.2 are mentioned. 1.17 is the older version. > So this message talks about old vxl version, so I assume it also talks about > old InsightToolkit version. But all logs above that only talk about one > version > of InsightToolkit. Why would I care about requirements of the old version, > when > about to upgrade to new version? What is even the new InsightToolkit version > dnf is trying to upgrade to? > > 3. >> - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64 >> - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64 > The second line is noise, already reported previously, but I can't find the > bug > now. > > So even in simple case with two packages, I'd need to do repoquery spelunking > to figure out what is going on. If dnf could tell me something like... > > Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libnetlib.so.1.14()(64bit), libv3p_netlib.so.1.14()(64bit), > libvcl.so.1.14()(64bit), libvnl.so.1.14()(64bit), > libvnl_algo.so.1.14()(64bit), currently provided by vxl-1.17.0. > - There is no upgrade candidate for InsightToolkit. > - Best upgrade candidate vxl-2.0.2-4.fc30.x86_64 does have those Provides. > → cannot install both vxl-2.0.2-4.fc30.x86_64 and > vxl-1.17.0-30.fc30.x86_64 because vxl is not an installonly package. >→ cannot install the best update candidate for package vxl > > i.e. group relevant Provides that "connect" two package into one list instead > of repeating the whole set of messages every time, > don't talk about upgrade candidates that don't actually exist, > mention the connection between Provides and package names, > omit evra when not required, > provide more explanations in general, > > then I'd see this change in a more positive light. I think the output > right now is just noise for most users. > > The premise that bug reports from users will help us catch such cases > — I don't see this as true. We *already know* that InsightToolkit has a > problem, > there's a FTBFS bug for it somewhere. > > The idea of "fault tolerant systems" is that the system mostly > continues to work in face of small failures in components. The distro > is a big system with thousands of interacting components, and *some* > simply must fail occasionally. The proposal is to make the system > fault-intolerant to notice errors earlier. That just seems wrong. > Returning to the example, why can't dnf print in red letters > at the end of the transaction log: > > Upgrade of vxl-1.17.0-30.fc30.x86_64 to vxl-2.0.2-4.fc30.x86_64 was held > back because of dependency issues. > > Users would see that too. Yep, this is problem. I opened DNF tickets requesting improvement of the messages, but apparently unsuccessfully :( Vít > > 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/
Re: Fedora 31 System-Wide Change proposal: gawk 5.0.1
On Thursday, 27 June 2019 at 16:37, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Gawk501
>
> ** Note that this has already landed in Rawhide:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF/#IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF
>
> == Summary ==
> New upstream major version of gawk has been released (4.2.1 -> 5.0.X).
> Among many changes, the version 5 introduced a namespaces, which may
> possible break some of the existing scripts.
[...]
> == Dependencies ==
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'gawk'
[...]
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora --enablerepo=updates
> --enablerepo=updates-testing --whatrequires 'gawk'
[...]
The build dependency list is almost certainly incomplete. gawk is always
installed in the buildroot, so many packages don't declare it as a
build dependency. I know I don't do that in my packages.
One would need to check for (g)awk usage in every build.log.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
On 6/28/19 2:48 AM, Gerald Henriksen wrote: On Thu, 27 Jun 2019 16:09:58 -0400, you wrote: On Thu, Jun 27, 2019 at 2:52 PM Dan Book wrote: As an outsider to the Python community, not having any binary or package that responds to the expected name "python" would be a disaster. Can you expand on that? As I understand it, most things that are calling for "python" now are expecting that to be "python2". So when it becomes "python3", they'll break anyway. So why perpetuate a pattern that's not future-proof (for some values of "proof")? Because it's not about what some python code expects, it about what the human being using Fedora expects. Nobody trying to compile a C program expects to have to use gcc9, they just expect to type in gcc. This. On my home computer I was able to get rid of python-unversioned-command and symlinked ~/bin/python to /usr/bin/python3, so whenever I need python I get what I want and not the about-to-retire piece of history, ah the sanity. On my work laptop I still run into needing /usr/bin/python -> python2 every now and then, unfortunately. Eagerly waiting for the day when it starts pointing to python3 instead. - 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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default
Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages) This is message for people who are willing/are able to fix or report things. For regular user this should be .. or run with "--nobest" to skip broken deps. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orhpaning rubygem-binding_of_caller
I have orphaned rubygem-binding_of_caller. The package was initially introduced into Fedora as a dependency of rubygem-web-console, which migrated off binding_of_caller later. Therefore, I don't have use for this package anymore. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2019-06-28)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-06-28 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Nonresponsive maintainer: bioinfornatics https://pagure.io/fesco/issue/2147 APPROVED (+4, 0, -0) Non-responsive maintainer: mflobo https://pagure.io/fesco/issue/2142 APPROVED (+5, 0, -0) = Followups = #topic #2152 "backport" branches in src.fp.o for backports to coreos stable streams .fesco 2152 https://pagure.io/fesco/issue/2152 = New business = #topic #2145 python2 packaging exception for python2-soupsieve, python2-css-parser .fesco 2145 https://pagure.io/fesco/issue/2145 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default
On Fri, Jun 28, 2019 at 11:12 AM Miroslav Suchý wrote: > Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > > (try to add '--allowerasing' to command line to replace conflicting > packages or '--skip-broken' to skip uninstallable packages) > > This is message for people who are willing/are able to fix or report > things. For regular user this should be > .. or run with "--nobest" to skip broken deps. > Can somebody clarify the difference between --skip-broken and --nobest? Because even after reading the man page, I still don't get it. And I believe most our users will not get it either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FYI: OCaml 4.08.0 in Fedora Rawhide
We've rebuilt some of the OCaml packages in Fedora Rawhide (31) against OCaml 4.08.0. It's expected that some packages will have broken dependencies. This is because they depend on ocaml-camlp4, the old, deprecated macro package, which has not been ported to 4.08. If camlp4 gets ported in the near future we'll be able to recompile these packages and I'm not expecting any problems with that. However if it turns out that camlp4 cannot / will not be ported then we'll have to deal with the broken packages on a case-by-case basis. There are several possibilities: (1) If they can use camlp5 instead, move to using that. However this is not usually a simple change since camlp4/camlp5 have diverged quite substantially over years. (2) If they depend on camlp4 but only for some optional feature (or even if the dependency was added by accident) then turn off that dependency and compile the package without the feature. (3) If they depend on camlp4 in some fundamental way then they will have to be retired. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: gawk 5.0.1
On Thu, Jun 27, 2019 at 9:38 AM Ben Cotton wrote: > The introduction of namespaces may break some scripts written for > gawk 4.2.1 due to different variable names. (This is considered to > be a bug by the upstream and there is a patch fixing this) > It seems that the patch fixing this would be carried, and this would not be an issue then? Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
On Thu, 27 Jun 2019 at 20:37, Gerald Henriksen wrote:
> On Thu, 27 Jun 2019 16:09:58 -0400, you wrote:
>
> >On Thu, Jun 27, 2019 at 2:52 PM Dan Book wrote:
> >>
> >> As an outsider to the Python community, not having any binary or
> package that responds to the expected name "python" would be a disaster.
> >>
> >Can you expand on that? As I understand it, most things that are
> >calling for "python" now are expecting that to be "python2". So when
> >it becomes "python3", they'll break anyway. So why perpetuate a
> >pattern that's not future-proof (for some values of "proof")?
>
> Because it's not about what some python code expects, it about what
> the human being using Fedora expects.
>
> Nobody trying to compile a C program expects to have to use gcc9, they
> just expect to type in gcc.
>
>
Thank you. My brain is not wired that way because I had worked in too many
environments where I have had to have multiple versions of tools for
customer reasons. Thus I have been seeing things myopically via my personal
experience ("Of course you want to have the exact version in the command,
how else can you test that you have code coverage???") I have to remember
that I am not usual consumer.
> Similarly someone sitting down to use a tutorial to learn Python is
> going to expect to type python and get something they can use,
> particularly going forward when Python3 really just become Python as
> Python2 fades from memory.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
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 31 Self-Contained Change proposal: DNF Make Best Mode the Default
On Fri, Jun 28, 2019 at 02:00:22PM +0200, Kamil Paral wrote: > On Fri, Jun 28, 2019 at 11:12 AM Miroslav Suchý wrote: > > > Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > > > (try to add '--allowerasing' to command line to replace conflicting > > packages or '--skip-broken' to skip uninstallable packages) > > > > This is message for people who are willing/are able to fix or report > > things. For regular user this should be > > .. or run with "--nobest" to skip broken deps. > > > > Can somebody clarify the difference between --skip-broken and --nobest? > Because even after reading the man page, I still don't get it. And I > believe most our users will not get it either. --nobest means: consider older versions of packages for installation, don't insist on upgrading everything. --skip-broken means: skip packages which were selected but cannot be installed, instead of erroring out. At least that's how I understand it. 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
Fedora Rawhide-20190628.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed, 4 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 Failed openQA tests: 15/146 (x86_64), 2/24 (i386), 1/2 (arm) New failures (same test not failed in Rawhide-20190625.n.0): ID: 416629 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/416629 ID: 416640 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/416640 ID: 416641 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/416641 ID: 416642 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/416642 ID: 416651 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/416651 ID: 416654 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/416654 ID: 416657 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/416657 ID: 416658 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/416658 ID: 416659 Test: x86_64 Silverblue-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/416659 ID: 416703 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/416703 ID: 416713 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/416713 ID: 416726 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/416726 ID: 416746 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/416746 Old failures (same test failed in Rawhide-20190625.n.0): ID: 416612 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/416612 ID: 416631 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/416631 ID: 416655 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/416655 ID: 416721 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/416721 ID: 416738 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/416738 Soft failed openQA tests: 3/24 (i386), 3/146 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Rawhide-20190625.n.0): ID: 416615 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/416615 ID: 416616 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/416616 ID: 416627 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/416627 ID: 416634 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/416634 ID: 416635 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/416635 ID: 416639 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/416639 Passed openQA tests: 112/146 (x86_64), 19/24 (i386) New passes (same test not passed in Rawhide-20190625.n.0): ID: 416731 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/416731 Skipped gating openQA tests: 4/146 (x86_64) New skipped gating tests (same test not skipped in Rawhide-20190625.n.0): ID: 416646 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/416646 ID: 416647 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/416647 ID: 416649 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/416649 ID: 416650 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/416650 Skipped non-gating openQA tests: 13 of 172 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) added since previous compose: flatpak-session-helper 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service Previous test data: http
Re: Fedora 31 System-Wide Change proposal: Python means Python3
Stephen John Smoogen wrote: > Actually I think it makes more sense that F31 provides no /usr/bin/python. > Then a lot of things which depend on it can be found and fixed since they > have not adapted to the Future any other way. I agree. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
Rex Dieter wrote: > Stephen John Smoogen wrote: > >> Actually I think it makes more sense that F31 provides no >> /usr/bin/python. Then a lot of things which depend on it can be found and >> fixed since they have not adapted to the Future any other way. > > I agree. Apologies for not fully reading the proposal to realize this is a new upstream recommendation. I withdraw any objection. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
On 26. 06. 19 19:57, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Python_means_Python3
== Summary ==
In package and command names, "Python" will mean "Python 3".
Users installing and running Python or Python packages without
specifying a version will get Python 3.
Running python will run python3. Running
pytest will run the Python 3 version of pytest, and
similarly for pydoc, pylint, etc.
dnf install python will install {{package|python3}}, and
similarly for other python-* provides, e.g. dnf
install python-requests will install
{{package|python3-requests}}.
This is the final preparation for
[https://fedoraproject.org/wiki/Changes/RetirePython2 the retirement
of Python 2 in Fedora 32] done in line with the
[https://github.com/python/peps/pull/989 soon to be finalized]
upstream recommendations.
Based on some questions and proposals that were repeated in the thread (thank
you!), we have edited the proposal to include an "Alternative proposals" section:
https://fedoraproject.org/wiki/Changes/Python_means_Python3#Alternative_proposals
--
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 System-Wide Change proposal: Python means Python3
On Thu, Jun 27, 2019 at 5:51 PM, Stephen John Smoogen wrote: Actually I think it makes more sense that F31 provides no /usr/bin/python. Then a lot of things which depend on it can be found and fixed since they have not adapted to the Future any other way. It would mean we have no chance of maintaining python scripts that work for both macOS and Fedora. Fedora's preference doesn't win here: on macOS /usr/bin/python is python2, and there is no /usr/bin/python2 so we can't use that in shebangs, and none of that is going to change. So e.g. WebKit's scripts have to use #!/usr/bin/python or #!/usr/bin/env python no matter what Fedora wants. Trying to convince Apple to use a virtualenv for building WebKit isn't going to happen. (Actually #!/usr/bin/python cannot be used ever, because that doesn't work on FreeBSD, so we use #!/usr/bin/env python and rely on downstreams to rewrite it to the #!/usr/bin/python version if required for packaging. Messy enough yet?) Anyway, we were able to make WebKit build in Fedora without using /usr/bin/python by using a combination of (a) changing shebangs for Linux-specific scripts, and (b) executing the scripts through CMake otherwise, so the shebang doesn't matter. So it's not an issue that /usr/bin/python is unavailable during package builds. It's an issue for developers using Fedora who need to use unpackaged scripts that are required to work on macOS. If Fedora has /usr/bin/python, then at least we have a *chance* to make the scripts we care about work in both python2 and python3 (our current plan). Whereas without /usr/bin/python, we're really out of options. So I very much support /usr/bin/python -> /usr/bin/python3. It will cause some problems for us and we'll have a difficult transition period, but at least there will exist the possibility of transitioning. Without /usr/bin/python we'd probably have to tell developers to manually install as python2 in /usr/local so that scripts using /usr/bin/env python get python2... way worse. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: adding speech installation to fedora network installation image
On Thu, 27 Jun 2019 22:01:23 +0200 Mmobilea wrote: > OK. If you can, open a new bug. Because of the response of mcatanzaro, Only the live image runs in a GNOME session where GNOME session services like orca are expected to be working. The netinstall image only runs anaconda, it doesn't run GNOME at all. it doesn't make sense to open a bug. There is no gnome, and because adding gnome would make the image too large, it will not be added. Netinstall is a minimal image meant to be used from virtual consoles with no graphical support. Your only alternative for accessibility is the workstation live image. https://download.fedoraproject.org/pub/fedora/linux/releases/30/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-1.2.iso This is approximately 1.8GB in size, so about 3 times as large as the netinstall images. Is that too large for your pen drive? It seems unlikely, unless it is very old. If you are running windows or mac, you will need the fedora media writer, from one of the links on this page at the upper left. https://getfedora.org/en/workstation/download/ This page gives alternatives for creating a bootable live image from linux (fedora in particular). https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/index.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Python means Python3
On Fri, Jun 28, 2019 at 10:42 AM, mcatanz...@gnome.org wrote: If Fedora has /usr/bin/python, then at least we have a *chance* to make the scripts we care about work in both python2 and python3 (our current plan). Whereas without /usr/bin/python, we're really out of options. So I very much support /usr/bin/python -> /usr/bin/python3. It will cause some problems for us and we'll have a difficult transition period, but at least there will exist the possibility of transitioning. Accidentally hit send too soon. I meant to add: /usr/bin/python -> /usr/bin/python3 is better than all available alternatives. It's the only way that /usr/bin/python remains in Fedora pointing to a supported python interpreter. And that is the only chance that cross-platform python scripts have to work without pain and suffering (beyond that of making the script work with both python2 and python3). We're not python developers and just want to run some python scripts; wrapping up all our python inside e.g. bash scripts that start a virtualenv would be a sad end to this tale. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: adding speech installation to fedora network installation image
On Fri, Jun 28, 2019 at 10:44 AM, stan via devel wrote: it doesn't make sense to open a bug. There is no gnome, and because adding gnome would make the image too large, it will not be added. Netinstall is a minimal image meant to be used from virtual consoles with no graphical support. But remember this isn't exclusive to netinstall. Only the live image runs a GNOME session: that's the only scenario when anaconda is running inside GNOME. I think it makes sense to open a bug against anaconda to ask the anaconda developers whether text-to-speech is intended to work outside of live images. It seems odd to require that blind users exclusively use live images to install Fedora. E.g. that's not how RHEL is expected to be installed. And non-Workstation Fedora products do not have live installers. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: always update the bootloader during major upgrades
On Fri, 2019-06-28 at 09:18 +0200, Nicolas Mailhot via devel wrote: > That's, easy, > > 1. add a generic bootctl install command that knows the different > variants of bootloader used in Fedora, how to install them, how to > identify which variant is appropriate for a system (make grub and other > bootloaders packages install the corresponding info in a directory read > by this command) I am not sure you quite understand the meaning of the word "easy". :P -- 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 31 System-Wide Change proposal: Python means Python3
On Thu, 2019-06-27 at 18:51 -0400, Stephen John Smoogen wrote: > On Thu, 27 Jun 2019 at 18:49, Neal Gompa wrote: > > > What about postponing this change to F32? I'd prefer python2 to be > > > > > retired and gone from the distro first, and the symlink and > > > > > %python_provide definition only switched then. I think that having > > > > > this middle state where python2 is available but python points to > > > > > python3 for exactly one release will be more confusing that switching > > > > > directly to the final state where python2 is gone and python simply > > > > > means python3. > > > > > > > > > > > > > I think it makes sense to make the switch before we retire, because > > > > then people's expectations are changed ahead of time and they can > > > > adapt to The Future(TM). > > > > > > Actually I think it makes more sense that F31 provides no /usr/bin/python. > Then a lot of things which depend on it can > be found and fixed since they have not adapted to the Future any other way. But it also efectively leaves a "hole" in the availability of the "python" command for a single Fedora release - that's not good user experience IMHO. > > > ___devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
proposal for changing the "Nonresponsive maintainer" policy
Please see https://pagure.io/fesco/issue/2149#comment-579981 for the full text of the latest proposal. The biggest change is that the reporter would have less work to do (fesco would take care of sending reminders from its ticket), and the reported would normally be assigned comaintainership rights soon after opening the fesco ticket, to speed the whole procedure up. Any comments here or in the fesco ticket are welcome. 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: adding speech installation to fedora network installation image
On Fri, 2019-06-28 at 10:50 -0500, mcatanz...@gnome.org wrote: > On Fri, Jun 28, 2019 at 10:44 AM, stan via devel > wrote: > > it doesn't make sense to open a bug. There is no gnome, and because > > adding gnome would make the image too large, it will not be added. > > Netinstall is a minimal image meant to be used from virtual consoles > > with no graphical support. > > But remember this isn't exclusive to netinstall. Only the live image > runs a GNOME session: that's the only scenario when anaconda is running > inside GNOME. > > I think it makes sense to open a bug against anaconda to ask the > anaconda developers whether text-to-speech is intended to work outside > of live images. Certainly - but I'm afraid we in the Anaconda team don't have any experience what all needs to be available (what packages should be included & what services started) to make text-to-speech work on the image. We would definitely welcome some feedback from a domain expert on this. There is also possibly an issue with size of the network installation image growing (which influences minimum RAM requirements for network installations in some cases), but I think we can look into that once we have concrete numbers available. > It seems odd to require that blind users exclusively > use live images to install Fedora. E.g. that's not how RHEL is expected > to be installed. And non-Workstation Fedora products do not have live > installers. > > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
Summary/Minutes from today's FESCo Meeting (2019-06-28)
=== #fedora-meeting: FESCO (2019-06-28) === Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-06-28/fesco.2019-06-28-15.00.log.html Meeting summary --- * init process (contyk, 15:00:07) * #2152 "backport" branches in src.fp.o for backports to coreos stable streams (contyk, 15:02:22) * LINK: https://pagure.io/fesco/issue/2152 (contyk, 15:02:26) * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1266753 This was a build for a test day kernel (jforbes, 15:34:25) * AGREED: Let's use tags. The exact workflow is up to the CoreOS team. (+8, 0, -0) (contyk, 15:47:52) * #2145 python2 packaging exception for python2-soupsieve, python2-css-parser (contyk, 15:48:14) * LINK: https://pagure.io/fesco/issue/2145 (contyk, 15:48:18) * AGREED: python2 packaging exception for python2-soupsieve, python2-css-parser is approved (+7, 1, -0) (contyk, 15:50:22) * Next week's chair (contyk, 15:50:55) * The next FESCo meeting will be held on July 12 (contyk, 15:52:59) * ACTION: ignatenkobrain will chair the next meeting, on July 12 (contyk, 15:56:33) * Open Floor (contyk, 15:56:45) * #2149: Proposal to change non-responsive maintainer policy (contyk, 16:04:52) * Will be discussed in two weeks (contyk, 16:07:10) Meeting ended at 16:08:17 UTC. Action Items * ignatenkobrain will chair the next meeting, on July 12 Action Items, by person --- * ignatenkobrain * ignatenkobrain will chair the next meeting, on July 12 People Present (lines said) --- * contyk (101) * mhroncok (80) * dustymabe (66) * zbyszek (49) * jforbes (36) * nirik (35) * sgallagh (26) * zodbot (21) * ignatenkobrain (18) * bookwar (13) * bcotton (3) * jcline (1) * otaylor (0) 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: always update the bootloader during major upgrades
Le vendredi 28 juin 2019 à 09:06 -0700, Adam Williamson a écrit : > On Fri, 2019-06-28 at 09:18 +0200, Nicolas Mailhot via devel wrote: > > That's, easy, > > > > 1. add a generic bootctl install command that knows the different > > variants of bootloader used in Fedora, how to install them, how to > > identify which variant is appropriate for a system (make grub and > > other > > bootloaders packages install the corresponding info in a directory > > read > > by this command) > > I am not sure you quite understand the meaning of the word "easy". :P It's the same core logic that already exists in anaconda, and in the envisionned dist upgrade, except packaged in a sane reusable easy to test unit. Packaging it sanely does not make the core logic simpler sure, but it removes the mass of problems caused by bootloader installations happening in multiple badly defined in-between gray dimensions, without any tracking of what was effectively done in the past. And the core logic need to be maintained in any case. So yes, I do believe that quick and dirty is more difficult in the long run. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: adding speech installation to fedora network installation image
On Fri, Jun 28, 2019 at 11:13 AM, Martin Kolman wrote: Certainly - but I'm afraid we in the Anaconda team don't have any experience what all needs to be available (what packages should be included & what services started) to make text-to-speech work on the image. We would definitely welcome some feedback from a domain expert on this. I've been advised that the domain experts are available at orca-l...@gnome.org: https://mail.gnome.org/mailman/listinfo/orca-list which seems to be pretty active. Good place for questions for both developers and users. I'm also told that standard advice is currently to only use live installers if accessibility features are required. Shame. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
adding speech installation to fedora network installation image
The fedora media writer isn’t accessible with nvda, the screenreader on windows. I will use Rufus. Thank you for answer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 System-Wide Change proposal: Python means Python3
On 06/28/19 10:46, mcatanz...@gnome.org wrote: > > On Fri, Jun 28, 2019 at 10:42 AM, mcatanz...@gnome.org wrote: >> If Fedora has /usr/bin/python, then at least we have a *chance* to make the >> scripts we care about work in both python2 and python3 (our current plan). >> Whereas without /usr/bin/python, we're really out of options. So I very much >> support /usr/bin/python -> /usr/bin/python3. It will cause some problems for >> us and we'll have a difficult transition period, but at least there will >> exist the possibility of transitioning. > > Accidentally hit send too soon. I meant to add: /usr/bin/python -> > /usr/bin/python3 is better than all available alternatives. It's the only way > that /usr/bin/python remains in Fedora pointing to a supported python > interpreter. And that is the only chance that cross-platform python scripts > have to work without pain and suffering (beyond that of making the script > work with both python2 and python3). We're not python developers and just > want to run some python scripts; wrapping up all our python inside e.g. bash > scripts that start a virtualenv would be a sad end to this tale. Thank you. I work on multiple platforms so I make my utility scripts work on both Python 2 and 3 and only use the standard library. It would be super annoying if I had to have multiple versions just because of the shebang line. -- Mátyás (Mat) Selmeci Open Science Grid Software Team / Center for High-Throughput Computing University of Wisconsin-Madison Department of Computer Sciences ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On Fri, 2019-06-28 at 09:25 +0200, Lumir Balhar wrote: > On 6/25/19 12:25 PM, Miro Hrončok wrote: > > On 25. 06. 19 12:07, Pierre-Yves Chibon wrote: > > > On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote: > > > > On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: > > > > > > > > > > I would say the scoping should happen (e.g. in copr) first, > > > > > > > > > > then we'll > > > > > > > > > > know what the scope (and hence feasibility) of this change > > > > > > > > > > truly is. > > > > > > > > > > > > > > > > > > What will the scoping actually tell us? If it tells us that X > > > > > > > > > hundred packages > > > > > > > > > need to add BR for python3-test, we'll just do that and > > > > > > > > > report the list to > > > > > > > > > upstream. We can do that during the mass rebuild. > > > > > > > > > > > > > > > > If there would indeed be X hundred packages affected, would > > > > > > > > this move > > > > > > > > still make sense? The python3-test subpackage is even larger > > > > > > > > than most > > > > > > > > of the rest of python3 combined, and the vast majority of it is > > > > > > > > irrelevant to other packages. Such usage would indicate to me > > > > > > > > that > > > > > > > > some work needs to be done within the ecosystem to respect its > > > > > > > > official > > > > > > > > status as internal-only. (Perhaps, in that case, a move to > > > > > > > > python3-devel could be considered instead.) > > > > > > > > > > > > > > Good questions. What number of affected packages do you think > > > > > > > would be crucial? > > > > > > > I say X hundred, because I don't anticipate it will go to > > > > > > > thousands. However > > > > > > > with 3000 Python packages, couple hundreds is IMHO not a big > > > > > > > deal. Note that > > > > > > > this is build dependency, not a runtime one. > > > > > > > > > > > > Nevertheless, there has been a great deal of effort recently to > > > > > > shrink > > > > > > buildroots and speed up build times. Having to add BR: > > > > > > python3-test to > > > > > > packages would mean adding a download of ~9MiB and an installation > > > > > > of > > > > > > ~3K files to every single affected package's build time. IMO this > > > > > > needs to be fully scoped before consideration. > > > > > > > > > > Wait a minute, adding a BR python3-test would mean an additional 9MiB > > > > > ok, but > > > > > currently these files are part of python3-libs which *every packages* > > > > > get. > > > > > In other words, for the packages that require python3-test the amount > > > > > of data > > > > > downloaded doesn't change while for all the packages that do *not* > > > > > require > > > > > python3-test, the amount of data is reduced. > > > > > This sounds like a win to me :) > > > > > > > > Unfortunately, this is not correct. > > > > > > > > python3-test already is large. > > > > > > > > We just move a small bit of python3-libs (test.support) and we move it > > > > to > > > > python3-test for consistency. > > > > > > > > test.support is 396K installed (for Python 3.8). > > > > > > Arf, then it's a lesser win than I thought. > > > Have you considered doing a python3-test-support subpackage? This would > > > allow > > > the separate package and thus give you the information you're looking for > > > as > > > well as avoid downloading the entire python3-test for these few files. > > > > The purpose of this change is to make packaging of Python easier and > > avoid problems, when the test.support module cannot be properly used > > without the rest of the test module. What you are proposing will make > > packaging more complicated and would not eliminate the problems at all. > > > > I think we are talking about couple packages here. Would it make sense > > to have a number and say that if more than X packages suddenly need to > > add BR for python3-test, we revert the change and consider a different > > approach? > > > > BTW python3-test is now buildrequired by 7 packages: > > python-bz2file > > python-honcho > > python-iniparse > > python-kitchen > > python-typing-extensions > > python-urwid > > python-zodbpickle > > > I am bringing here some numbers which help us to understand that the > change won't affect a lot of packages. > > I've prepared a special COPR [0] where test.support module is not > available at all and then I rebuilt all Python packages. From 2952 > packages 2769 built successfully and only 182 failed. Most failures were > caused by missing dependencies (python2-), incompatible pytest or sphinx > version, etc. and only 7 packages fail to build because of the missing > test.support module. From those 7 packages, 4 already require > python3-test so there will be need to change only 3 packages after we'll > move test.support module from python3-libs to python3-test. > > [0] https://copr.fedorainfracloud.org/coprs/lbalhar/test.support_change/ Thank you for doing that. This information should be inclu
Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome
https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome == Summary == Make Qt applications to run natively on Gnome Wayland session, using the Qt Wayland platform plugin instead of the XCB plugin which is used for X11/XWayland. Other desktop environments already run natively on Wayland sessions, only Gnome is excluded by Qt. == Owner == * Name: [[User:jgrulich| Jan Grulich]] * Email: * Product: Spins / Workstation * Responsible WG: Desktop == Detailed Description == Qt Wayland plugin has been available for a long time, but it hasn't been in condition where it could be enabled by default. With Qt 5.12 the state of the Wayland plugin is much better and it's becoming more and more reliable. It now supports all the needed protocols and has been enabled by default for non-Gnome Wayland sessions. With Qt Wayland on Gnome Wayland session we need to support CSD, it's actually the only way how decorations are going to work in Qt apps right now. Qt Wayland implements basic decorations, which really doesn't match Gnome Adwaita theme, therefore there are new CSD being implemented as part of QGnomePlatform. To make Qt applications run natively on Wayland we need to modify Qt 5, specifically '''qt5-qtbase''' module, where we allow the Wayland plugin to be used also for Gnome sessions. The new decorations from QGnomePlatform will be used automatically once they are fully implemented and updated in Fedora. == Benefit to Fedora == Qt applications running with the Wayland plugin run generally faster and smoother on Wayland enabled sessions like Gnome Wayland and better support HiDPI displays (respects desktop scale) . == Scope == * Proposal owners: # Modify Qt 5 (qt5-qtbase) to not exclude Gnome when deciding whether to use the wayland platform plugin # Update QGnomePlatform with upcoming upstream release including window decorations * Other developers: # Test and watch for regressions. * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Run any Qt application on Gnome Wayland session and check any issues you may see. == User Experience == * Smoother font rendering compared to Qt applications using XCB plugin * Honor display scale, better user experience on HiDPI and semi-HiDPI desktops. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Switch back default to XCB plugin. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? product No == Documentation == N/A (not a System Wide Change) -- 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: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome
Quoting from the proposal: > Qt Wayland plugin has been available for a long time, but it hasn't > been in condition where it could be enabled by default. With Qt 5.12 > the state of the Wayland plugin is much better and it's becoming more > and more reliable. It now supports all the needed protocols Actually, the primary selection protocol (middle-click paste) is only supported in Qt ≥ 5.14 (not released yet). (It also requires a compositor implementing the final specification. I'm not sure whether GNOME Shell already moved from the GNOME private version to the upstreamed version of the protocol.) 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: always update the bootloader during major upgrades
On Fri, Jun 28, 2019, 1:19 AM Nicolas Mailhot via devel wrote: > > Le jeudi 27 juin 2019 à 12:26 -0600, Chris Murphy a écrit : > > Yep, small problem. And I'm not even sure how a 'grub2-install' on > > BIOS systems would be initiated only at major upgrade time. But even > > Fedora Rawhide does change versions when fcXX becomes fcXX+1, but is > > that a sane trigger? > > It's not, such magic “it's FCX time” break all the time for users that > only do dnf update, or use rawhide (which branches before the next > version logic is deployed), etc Twice a year for Rawhide. And upon initiation of major upgrade on release versions. It wouldn't be all the time. > > > I'm not sure what the alternatives are. > > That's, easy, > > 1. add a generic bootctl install command that knows the different > variants of bootloader used in Fedora, how to install them, how to > identify which variant is appropriate for a system (make grub and other > bootloaders packages install the corresponding info in a directory read > by this command) > > 2. make it write the id, generation, and deployment options used in a > lockfile every time it (re)installs the bootloader > > 3. add a config file with a variable to inhibit auto-redeployment > > 4. add a scriptlet to the bootctl package that calls bootctl install > and > – checks the variant in the lockfile is appropriate for the hardware > (in case of disk mode or copy) > – checks if the generation is current or unknown (unknown = future, do > not touch) > – and if any of those is false, reinstalls the bootloader, unless the > inhibit variable is set > > 5. add a --force switch to bootctl to allow the operator to force a > bootloader rewrite every time somethins else broke it I think that's completely out of scope. It's inappropriate to wait 10 months let alone 10 years to resolve this problem. And it's an overly complicated solution. It sounds like the bootloader install equivalent of grubby that was just deprecated in Fedora 30, not least of which it was so overly complicated it was difficult getting people to contribute to or maintain it. Yet another one command to rule them all? No thanks. It might be sane for Anaconda to write out a file, or modify /etc/default/grub, to indicate the user chose to prevent the Fedora bootloader from being installed (as far as I'm aware this only actually works on x86 BIOS computers even though it's presented in the UI for all other firmwares and archs) when Fedora was installed. And from that information, infer that they do not want the Fedora bootloader (re)installed. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
On Sat, Jun 8, 2019 at 10:35 PM Nicolas Mailhot via devel wrote: > > Hi, > > Fedora’s new Go packaging macros landed in rawhide (koji) today. > > The corresponding Fedora Go packaging conventions are therefore > EFFECTIVE for new rawhide builds. For the first time in Fedora’s > history, we will be able to perform Go package builds conforming to an > approved Fedora Packaging Guideline. > > Packaging documentation: > https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ > and approval: https://pagure.io/packaging-committee/issue/382 > The go-rpm-templates package provides more complete info. > > F31 change page: > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > and approval: https://pagure.io/fesco/issue/2120 > > While the guidelines will feel familiar to anyone who created a Fedora > Go packages in the last two years, they DO include a backwards- > incompatible change. Making GOPATH manipulation robust required moving > the corresponding logic to %prep with a new %goprep macro. > > Therefore, existing specs are expected to fail without the addition of > the %goprep call. > > This is of course not the end of the road, just a key step. > > It opens the way to a mass cleanup and refresh of the Fedora Go stack. > https://pagure.io/packaging-committee/issue/901 > > A preview of this refresh is available here: > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ > > Enormous thanks to > – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing > updating and cleaning-up all those packages, and to > – Elliott Sales de Andrade (Qulogic), that picked up maintenance of > golist and fixed many of its long-standing bugs and limitations. > > Many thanks to the mock, rpm and redhat-rpm-config maintainers, > that integrated the changes, we built upon (Igor Gnatenko, Florian > Festi, Miroslav Suchý, Panu Matilainen) > > The macro set supports Go DynamicBuildRequires > https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > They will be usable in mock as soon as rpm 4.15 lands > https://fedoraproject.org/wiki/Changes/RPM-4.15 > > Use in koji or copr will have to wait for the corresponding refresh > buldsystem-side. So this part of the change is a technology preview for > now. > > Best regards, > > -- > Nicolas Mailhot What should I do at this moment as a packager that maintaining some Go packages? Should I fix my packages and build against f31-go in Koji? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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
