[Test-Announce] [Test Week] Kernel 5.7 2020-06-22 to 2020-06-29
Hey All, The Kernel team and Fedora QA team is holding Kernel 5.7 Test Week[0] starting Monday. It's fairly simple, head over to the wiki [0] and read in details about the test week and simply run the test case mentioned in[1] and enter your results. Should you have any questions, come and talk to us at #fedora-test-day@freenode [0] https://fedoraproject.org/wiki/Test_Day:2020-06-22_Kernel_5.7_Test_Week [1] http://testdays.fedorainfracloud.org/events/85 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ 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
Modules building for Fedora 30
I just noticed that my openmpi module build is building for Fedora 30. This seems like a mistake. Where do I report that? -- 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: Orphaned 215 packages
On Thu, 18 Jun 2020, Stephen Gallagher wrote: Stewardship SIG guy speaking :) If you have a limited set of packages that you want to keep working, e.g. to keep a minimal environment available to build other NodeJS rpm packages in fedora, then that's exactly what the Stewardship SIG was originally intended to to, albeit for a limited time only. We also have some tooling to check leaf package status and analyze dependency trees, which would also help here. I have some packages depending on indirectly on nodejs things being retired. How do I find out which ones I need to save? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] Proposal to CANCEL: 2020-06-22 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't have anything urgent new this week. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On 19. 06. 20 23:11, Ben Cotton wrote: All make invocations in spec files that don't use the install target will be modified to use the %make_build macro Many Python packages build Sphinx documentation with variant of "make html". Such invocation will always be just 1 job. Hence there is no benefit of parallel make. Replacing it with %make_build will only make it harder to read. Can we exclude such cases? Or do we want all make invocations to be mecronized, even if there is no benefit? -- 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 33 System-Wide Change proposal: Use %make_build and %make_install macros
On Fri, 19 Jun 2020 at 22:20, Ben Cotton wrote: [..] > The %make_build macro enables parallel make builds using the -j option. > In case a package does not build correctly with parallel make, then > parallel make will be disabled for that package by redefining the > %_smp_mflags macro like this: > > %global _smp_mflags -j1 > Sometimes only %build or %install or %check is failing. Any -j1 tweaks should be *only temporary* so IMO formalising this kind of changes is pointless. All parallel build issues should be treated *as critical bugs* which should be *ASAP fixed*. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 33 System-Wide Change proposal: Zanata Removal
https://fedoraproject.org/wiki/Changes/Zanata_removal
== Summary ==
While most Fedora project migrated to Weblate, the old translation platform
still exists and needs to be removed (the community shouldn't have to go to
multiple place to contribute, and nobody assume Zanata maintenance).
== Owner ==
* Owner: the [[L10N]] group ({{fpchat|#fedora-i18n}})
* Primary contact: [[User:jibecfed|Jean-Baptiste Holcroft]]
* Email: [
https://lists.fedoraproject.org/archives/list/tr...@lists.fedoraproject.org/
localization mailing list]
== Detailed Description ==
We created a migration page to follow projects migration from Zanata to
Weblate: [[L10N Move to Weblate]].
Remaining projects should either: migrate to Weblate or move to another
translation platform.
== Feedback ==
Weblate configuration: unless your team knows Weblate, Jibecfed will do
first configuration and make you admin of your project so you can add more
components.
Pull request support for Pagure: it is unlikely this features lands in
Weblate before Zanata removal. Suggestion is to allow
https://pagure.io/user/weblatebot for commits.
Some project requiring Sign-off:
https://docs.weblate.org/en/latest/admin/licensing.html#signed-off-by
Reducing translation impact in your repository:
* you can configure weblate's components to save po files without any line
number, saving many useless commits if you do frequent pot updates
* you can configure weblate's components to squash commits per author to
limit the number of commits
== Benefit to Fedora ==
This makes the distribution more efficient:
* translators have one single place for translating, and get many
interesting features (alerts, comments, etc.)
* newcomers can directly translate without approval
* maintainer have less automation to do (po updates, etc.)
* reduce complexity (all in one place) & infrastructure costs
== Scope ==
* Proposal owners: continue to answer questions from upstream projects and
translators
* Other developers:
** if we created a ticket for you, answer it. It may require you to change
your l10n/i18n automation (likely) and git repositories (unlikely).
** if not, open a ticket to l10n team: https://pagure.io/fedora-l10n/tickets
* Release engineering: [https://pagure.io/releng/issue/9537 #9537]
* Policies and guidelines: No
* Trademark approval: No
== Upgrade/compatibility impact ==
This impact upstream projects, not the delivered operating system.
Worse case scenario: less translations reach upstream.
== How To Test ==
Project is in readonly in https://fedora.zanata.org
Project exists in Fedora Weblate: https://translate.fedoraproject.org
Modification done in Fedora Weblate can be seen in upstream repository.
== User Experience ==
This improve the experience of users that don't speak English correctly
(90% of the world, source CLDR + Wikipedia) or not at all (80% of the
world, source CLDR + Wikipedia)
== Dependencies ==
None (this doesn't impact packaging)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) No contingency,
Zanata won't be kept any longer, we already gave 6 more month to let
project migrate at their own pace to the new system
* Contingency deadline: none
* Blocks release? No
== Documentation ==
* [[L10N/Translate_on_Weblate|How to translate on Weblate?]]
* List of Weblate file formats support:
https://docs.weblate.org/en/latest/formats.html
* Weblate's FAQ: https://docs.weblate.org/en/latest/faq.html
* Weblate evolves fast, reading changes is interesting:
https://docs.weblate.org/en/latest/changes.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro == Summary == This change will update all spec files in Fedora that use make and replace the make invocations with either the %make_build or %make_install macros. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: == Detailed Description == The goal of this change is to standardize the usage of make in Fedora. All make invocations in spec files that don't use the install target will be modified to use the %make_build macro, and all make invocations that use the install target will be updated to use the %make_install macro. Any additional arguments to make that are not included in either the %make_build and %make_install will be preserved. The %make_build macro enables parallel make builds using the -j option. In case a package does not build correctly with parallel make, then parallel make will be disabled for that package by redefining the %_smp_mflags macro like this: %global _smp_mflags -j1 All changes will be submitted to dist-git repositories via pull requests. Pull requests will be merged after 1 week if there are no objections or earlier if approved by the package maintainers. A script will be used to apply the necessary changes to the spec files, and the result will be manually inspected before being merged. All packages updated by this change request will be rebuilt after the spec file changes are merged. Some packages already use the %make_build and %make_install macros. These packages will be left unchanged. == Benefit to Fedora == * Reduced build times: Using the %make_build macros enables parallel make builds which will reduce build times for Fedora packages. * This will make it easier to enforce consistent build flag usage across all of Fedora. == Scope == * Proposal owners: Update spec files and submit pull requests and do new package builds. Optional: Merge pull requests (Proposal Owner would need to request to be added to provenpackagers group) * Other developers: Package owners may merge pull requests and submit new builds if they want, but this is not required for them. A member of the provenpackagers group will be needed to merge pull requests. * Release engineering: [https://pagure.io/releng/issues/9533 #9533] * Policies and guidelines: Package guidelines already specify that packages should use these macros when possible. Documentation will be updated to clarify that %make_build should be used for all make invocations (besides make install), and also with instructions for packages that fail to build with parallel make. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact. == How To Test == End-users will not notice any changes. == Dependencies == No real dependencies, each package can be updated independently. == Contingency Plan == * Contingency mechanism: None. If not all packages are updated in time, then the work can continue into the next release. * Contingency deadline: All work will be done in the rawhide branch, and will not be backported into the f33 branch once it is created, so whatever gets done before the branch date will make it into the release. * Blocks release? No == Documentation == The packaging guidelines will be updated as described in the Scope Section. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: LLVM 11
https://fedoraproject.org/wiki/Changes/LLVM-11 == Summary == Update all llvm sub-projects in Fedora to version 11. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: == Detailed Description == All llvm sub-projects in Fedora will be updated to version 11, and there will be a soname version change for the llvm libraries. Compatibility packages clang10 and llvm10 will be added to ensure that packages that currently depend on clang and llvm version 10 libraries will continue to work. Also, changing in this update is the compatibility package naming. The .0 will be dropped from the package name, so the compatibility packages will be called llvm10 and clang10 instead of llvm10.0 and clang10.0. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Request a f33-llvm side-tag from Release Engineering. ** Build llvm10 and clang10 into the side-tag. ** When the upstream LLVM project releases version 11.0.0-rc1 (2020-7-15), package this and build it into the side tag. ** Merge side-tag into rawhide prior to the f33 branch date. ** Continue packaging newer release candidates into rawhide and f33 until the final release is complete (~2020-8-26) * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang10 and llvm10 compatibility packages if they want to rebuild their package and it does not work with LLVM 11 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 11 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [https://pagure.io/releng/issues/9535] * Policies and guidelines: No policies or guidelines will need to be updated as a result of this change. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change should not impact upgradeability. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 11. == User Experience == Users will benefit from new features and bug-fixes in the latest version of LLVM. == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 10 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If there are major problems with LLVM 11, the compatibility package provide a way for other packages to continue using LLVM 10. In the worst case, we could always revert LLVM back to LLVM 10, but this would only happen if their were an unprecedented amount of problems. * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 11: * llvm * clang * lld * lldb * compiler-rt * libomp * llvm-test-suite * libcxx * libcxxabi * python-lit -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 2:54 PM David Cantrell wrote: > > On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote: > >Hopefully that provides some context and helps FESCo and the wider > >community understand where Red Hat is headed with modularity on the > >Enterprise side. > > Around the idea and concept of modularity... what are the benefits to Fedora, > Fedora developers, and Fedora contributors? Through the various discussions > on modularity, nothing solid in this regard has been presented. If I am > Fedora contributor now, what can modularity do for me? > > Most of the remainder of this thread talks about the problems with the > implementation as it exists today and problems with other known options. > Putting that aside for now, why should Fedora contributors care about > modularity? > > Put another way, what does the developer experience look like for modularity? These are good questions, but I feel like there has been about 2+ years of discussion and debate about what Fedora could get out of modularity. I'm not sure I have anything to offer that is directly new or better. I do think that ELN presents a new opportunity for those that have already found value in the Fedora community to use and improve it there in the absence of widespread Fedora adoption. Perhaps that would allow a place for the ideas to grow and could prove to be illustrative. At any rate, my goal isn't to evangelize or convert Fedora to suddenly embrace modularity wholescale. I am simply offering clarity on the plans for RHEL 9 with this technology. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 08:06:29AM -0500, Martin Jackson wrote: On 6/19/20 7:46 AM, Daniel P. Berrangé wrote: On Fri, Jun 19, 2020 at 02:32:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote: [...] I can only see this being solvable if non-default modules streams are required to be built into a unique /opt prefix instead of /usr. Are you trying to re-invent the SCLs? I'm not trying to do anything myself, just pointing out that I believe modularity is broken by design because it leads to the need to have mutually incompatible versions of things installed at the same place at the same time. SCL was one concept that nicely avoided this problem, by giving users the ability to have multiple versions of a stream installed in parallel. Flatpaks and containers are alternative ways to let users deploy different versions of software without any clashing with the default package set provided by the distro. To be fair, while SCL's do solve this problem, they do so via subtle but really important changes to user behavior. In my $work environment we had lots of users that preferred to, for example, compile their own versions of Python rather than use the SCL version. While the restrictions SCL imposes make sense if you understand the underlying plumbing with linking and so on, many users (even power users) want /usr/bin/python in a shebang line. Modularity attempts to solve the user experience problem by effectively shifting this complexity to the admin side of the equation. So if the only thing you care about is getting /usr/bin/something (and you have other things that depend on conventional pathing for any of a host of reasons), you can get it. I agree in general that the problems that modularity solves haven't been worth the complexities in the ecosystem that they've generated. There are several other ways to install multiple pythons, and make them installable in parallel that are easier than SCL (python2 vs. python3 in /usr/bin). I use flatpaks on Fedora (Discord and okular), and I've really enjoyed the experience with them. I'm not sure how well that would translate to the server environment though, but that general approach seems to do a good job of preserving user experience while isolating potentially troublesome conflicts in a way that doesn't mess up the "base system". Both of your points are valid. Daniel's point of the shared install namespace but delivering multiple conflicting versions of files will lead to problems. There is no amount of covering things up that escape that reality. [And by conflicting files, I have taken it to mean I have libsomething version 2.0 and libsomething version 2.1. Both deliver libsomething.so.2 (that's what other programs will list as a DT_NEEDED) but because of life being what it is in the world of Linux distributions, those libraries actually carry different symbols even though they advertise the same SONAME. None of that matters though because at the dnf level the NVR's of the packages are libsomething-2.0-1 and libsomething-2.1-1 and dnf is enforcing installation, upgrade, or downgrade based on that information.] Like you say, SCLs get around this fact by impacting the user experience. It's not terrible, but it could be better. Modularity has, as I see it, not yet clearly defined this reality. We could enforce uniform SONAME rules, install things in separate prefixes, make use of DT_RPATH, or any of a number of other mechanisms to let files from packages and modules coexist. And my example here doesn't even address languages like Python or Perl, but I feel those offer path management flexibility where additional subdirectories could be added and not collide with files of the same name from another package. I find flatpaks really nice from a user perspective. I have not spent a lot of time building them. I went through the docs and built an example one for myself and it was easy, but I did not get in to a lot of details. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote: Hello Fedora Community! I am a long-time Fedora Community member, and may be familiar to many through previous FESCo or devel list discussions and passionate debates. However I write to you today with a different community hat on, as a lead Architect for Red Hat Enterprise Linux. The RHEL organization has been following the modularity discussions within Fedora, particularly around ELN, and often the question of what plans we have for modularity in RHEL 9 has come up. Our Fedora Project Lead and a number of FESCo members have reached out and asked if we can provide some perspective here, and I am both happy and excited to have that opportunity. As the Fedora Council has pointed out [1], we certainly acknowledge there are improvements to be made and have a team already working on them. They recently outlined their plans in conjunction with our Product Management team in a Fedora Council call as well [2]. We’re continuing to invest time and effort in this packaging solution and are confident that the team can deliver against their plan. It is somewhat of a new experience for all of us when Red Hat is direct with our product intentions, but we discussed the larger gaps we see with usage in RHEL and are putting our efforts towards solving those gaps with this plan. Modularity is important to RHEL and those efforts are already underway. We will be leveraging modularity in RHEL 9 where it most makes sense. This is primarily centered around our Application Streams concept, which has been well received by our customer base. Providing a consistent but improved experience is the base requirement, which allows us to have continuity from RHEL 8 to RHEL 9 and lowers the hurdle for our customers when upgrading from one major version to another. It is always good to push the boundaries and search for better ideas and improvements, and that is part of what makes Fedora great. We are doing this in the context of the RHEL 9 release as well, so our near term timeline and requirements mean we are working on evolving modularity, not a revolution or a replacement. We are excited by ELN, as it presents a possible space to allow those that want to continue to iterate on modules a place to do so without necessarily impacting the broader Fedora distribution in its entirety. It is my personal hope that we can use that opportunity to improve modules and modularity in the open source, Fedora-first way we’d prefer. Our near term effort to improve the existing modularity implementation ahead of RHEL 9 needs to occur, and we’d like to do that work in Fedora, rather than in closed product development. Longer term, we are open to contributing to a better replacement that meets many of the same goals. This is what makes our distribution ecosystem work well, and not having that upstream lessens the value we all get from such experimentation in the open. Hopefully that provides some context and helps FESCo and the wider community understand where Red Hat is headed with modularity on the Enterprise side. Around the idea and concept of modularity... what are the benefits to Fedora, Fedora developers, and Fedora contributors? Through the various discussions on modularity, nothing solid in this regard has been presented. If I am Fedora contributor now, what can modularity do for me? Most of the remainder of this thread talks about the problems with the implementation as it exists today and problems with other known options. Putting that aside for now, why should Fedora contributors care about modularity? Put another way, what does the developer experience look like for modularity? Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020, at 12:44 PM, Daniel P. Berrangé wrote: > IIUC from the docs, when using Modularity to build Flatpaks, the > prefix is changed to /app instead of /usr, which makes it much > closers to SCL: > >https://docs.fedoraproject.org/en-US/flatpak/concepts/ The reason for that has nothing to do with modularity, but actually a core distinction between flatpak and "containers" by which it's usually understood one is talking about Docker/OCI. (Also the confusion gets even bigger here because flatpak can use Docker/OCI as a transport, but differs in the model of how it uses those images) flatpak *dynamically links* applications with the runtime (in contrast to the Docker/OCI model). That's why flatpak apps are in /app. (There's nothing truly desktop/flatpak specific about doing this, but trying to propagate it to the wider container world around e.g. Kubernetes is a large complex topic) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
On Fri, Jun 19, 2020 at 11:12 AM Robert-André Mauchin wrote: > Done, no swap needed for now. Thank you! Let me know if I can do anything for you in the future. -- 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: Review swap
On Friday, 19 June 2020 18:28:43 CEST Jerry James wrote: > Alt-ergo 2.2.0 has been released under a public license. It has a new > dependency, however. Would someone like to swap reviews? I need this > one: > > ocaml-psmt2-frontend: https://bugzilla.redhat.com/show_bug.cgi?id=1847772 > > Thanks! Done, no swap needed for now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 11:16:33AM -0400, Stephen Gallagher wrote: > On Fri, Jun 19, 2020 at 9:08 AM Martin Jackson wrote: > > > > I use flatpaks on Fedora (Discord and okular), and I've really enjoyed > > the experience with them. I'm not sure how well that would translate to > > the server environment though, but that general approach seems to do a > > good job of preserving user experience while isolating potentially > > troublesome conflicts in a way that doesn't mess up the "base system". > > > > I love how people hold up "containers" as a solution to these problems > without considering for a moment how exactly the container itself gets > built. If you were to look into the flatpak build system in Fedora, > you'd see that they are using Modularity to construct them. > > One of the reasons for Modularity is that we agree that containers are > one "right" way to handle parallel-installability. But we also know > from past experience (SCLs) that having content in unusual locations > like /opt means that applications have to be modified. By using > modules to put the version of software you want into the standard > location and then using a container to isolate it and/or provide > parallel-installability, you also get the assurance of knowing the the > content in your container is just as trusted as your standard RPM > deployments. IIUC from the docs, when using Modularity to build Flatpaks, the prefix is changed to /app instead of /usr, which makes it much closers to SCL: https://docs.fedoraproject.org/en-US/flatpak/concepts/ When I looked a packaging my Entangle application as a Flatpak though, I ended up picking Flathub instead of Fedora. That felt like a simpler approach than using modularity, as it eliminates the intermediate RPM packaging step which isn't really relevant to the end result. It is a quicker code, build, test cycle if you can build from upstream sources straight into the flatpak root in one go, especially if testing locally outside the build system. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swap
Alt-ergo 2.2.0 has been released under a public license. It has a new dependency, however. Would someone like to swap reviews? I need this one: ocaml-psmt2-frontend: https://bugzilla.redhat.com/show_bug.cgi?id=1847772 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: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 9:16 AM Stephen Gallagher wrote: > I love how people hold up "containers" as a solution to these problems > without considering for a moment how exactly the container itself gets > built. If you were to look into the flatpak build system in Fedora, > you'd see that they are using Modularity to construct them. You're right, Flatpak is doing that. Alternatively, my team and I build containers with multiple repos when we want to choose versions of software. "fedpkg container-build --repo-url" takes multiple .repo files. This works well because it uses the standard behavior that we've relied on in Yum and DNF for many years. The corner-cases around dependencies and what-version-overrides-what are well understood across the developer community. This same .repo method works well across RHEL 7, RHEL 8, and beyond. The .repo files are extremely flexible and can come from a variety of systems that are not MBS. Contrast this with the way that OSBS and ODCS work. The current implementation is misleading, and the reason I say this is because several independent teams recently arrived at the same erroneous conclusions around how developers are supposed to use modules with OSBS and ODCS: https://github.com/containerbuildsystem/osbs-docs/pull/152 - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 9:08 AM Martin Jackson wrote: > I use flatpaks on Fedora (Discord and okular), and I've really enjoyed > the experience with them. I'm not sure how well that would translate to > the server environment though, but that general approach seems to do a > good job of preserving user experience while isolating potentially > troublesome conflicts in a way that doesn't mess up the "base system". > I love how people hold up "containers" as a solution to these problems without considering for a moment how exactly the container itself gets built. If you were to look into the flatpak build system in Fedora, you'd see that they are using Modularity to construct them. One of the reasons for Modularity is that we agree that containers are one "right" way to handle parallel-installability. But we also know from past experience (SCLs) that having content in unusual locations like /opt means that applications have to be modified. By using modules to put the version of software you want into the standard location and then using a container to isolate it and/or provide parallel-installability, you also get the assurance of knowing the the content in your container is just as trusted as your standard RPM deployments. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Wondering what to do with fritzing versioning
On Fri, Jun 19, 2020 at 8:19 AM Artur Iwicki wrote:
> A few days ago I adopted fritzing and fritzing-parts, which were orphaned
> by their original maintainer.
> I looked at the package and at the upstream project and noticed a few
> things:
> - Looking at the releases page for the app [1], upstream stopped doing
> releases manually and relies on a
> Continuous Delivery service. This is fine by itself, but at the same
> time, upstream switched to
> using the Continuous Delivery build ID as the main unique identifier for
> releases - and now there are
> two releases [2], [3] with the same semver. I suppose this may happen
> again in the future, so my thought was to
> use a combination of semver and the CD-build-ID as the Version: of the
> Fedora package, something like `0.9.4.CD498`.
> - Looking at the releases page for the parts repository [4], upstream
> stopped bothering with git tags
> quite some time ago. The "build & release" script [5] that upstream uses
> just pulls the latest commit
> from the fritzing-parts repository when doing a build.
>
> So now I'm just wondering:
> 1) Does the versioning scheme for the main package make sense?
> 2) For the fritzing-parts package, should I package the commit matching
> the official release
>(e.g. version CD-498 was released on 2019-12-01, so pick the 2019-11-24
> commit from fritzing-parts,
>since that was "latest" at time of build), or don't care for
> synchronizing these and just go with the latest commit?
>The latter approach is easier, but I worry about potential
> backwards-incompatible changes.
> 3) For the fritzing-parts package, should I keep the semver and go with
> `semver-release.DATEgitCOMMIT`,
>or switch to `DATE-release.gitCOMMIT`? The latter option makes sense,
> but I'm not too keen
>about changing the versioning scheme.
>
I'm having to view the cached version of the version guidelines right now
due to the infra outage but something like:
-.CD{%?dist}
??
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
Wondering what to do with fritzing versioning
A few days ago I adopted fritzing and fritzing-parts, which were orphaned by their original maintainer. I looked at the package and at the upstream project and noticed a few things: - Looking at the releases page for the app [1], upstream stopped doing releases manually and relies on a Continuous Delivery service. This is fine by itself, but at the same time, upstream switched to using the Continuous Delivery build ID as the main unique identifier for releases - and now there are two releases [2], [3] with the same semver. I suppose this may happen again in the future, so my thought was to use a combination of semver and the CD-build-ID as the Version: of the Fedora package, something like `0.9.4.CD498`. - Looking at the releases page for the parts repository [4], upstream stopped bothering with git tags quite some time ago. The "build & release" script [5] that upstream uses just pulls the latest commit from the fritzing-parts repository when doing a build. So now I'm just wondering: 1) Does the versioning scheme for the main package make sense? 2) For the fritzing-parts package, should I package the commit matching the official release (e.g. version CD-498 was released on 2019-12-01, so pick the 2019-11-24 commit from fritzing-parts, since that was "latest" at time of build), or don't care for synchronizing these and just go with the latest commit? The latter approach is easier, but I worry about potential backwards-incompatible changes. 3) For the fritzing-parts package, should I keep the semver and go with `semver-release.DATEgitCOMMIT`, or switch to `DATE-release.gitCOMMIT`? The latter option makes sense, but I'm not too keen about changing the versioning scheme. If someone's willing to share their thoughts and advice, I'll be grateful. A.I. [1] https://github.com/fritzing/fritzing-app/releases [2] https://github.com/fritzing/fritzing-app/releases/tag/CD-498 [3] https://github.com/fritzing/fritzing-app/releases/tag/CD-415 [4] https://github.com/fritzing/fritzing-parts/releases [5] https://github.com/fritzing/fritzing-app/blob/cb7c9cc452d11bd8fe26e67048e6ff7d92c87e72/tools/linux%20release%20script/release.sh#L98 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On 6/19/20 7:46 AM, Daniel P. Berrangé wrote: On Fri, Jun 19, 2020 at 02:32:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote: [...] I can only see this being solvable if non-default modules streams are required to be built into a unique /opt prefix instead of /usr. Are you trying to re-invent the SCLs? I'm not trying to do anything myself, just pointing out that I believe modularity is broken by design because it leads to the need to have mutually incompatible versions of things installed at the same place at the same time. SCL was one concept that nicely avoided this problem, by giving users the ability to have multiple versions of a stream installed in parallel. Flatpaks and containers are alternative ways to let users deploy different versions of software without any clashing with the default package set provided by the distro. To be fair, while SCL's do solve this problem, they do so via subtle but really important changes to user behavior. In my $work environment we had lots of users that preferred to, for example, compile their own versions of Python rather than use the SCL version. While the restrictions SCL imposes make sense if you understand the underlying plumbing with linking and so on, many users (even power users) want /usr/bin/python in a shebang line. Modularity attempts to solve the user experience problem by effectively shifting this complexity to the admin side of the equation. So if the only thing you care about is getting /usr/bin/something (and you have other things that depend on conventional pathing for any of a host of reasons), you can get it. I agree in general that the problems that modularity solves haven't been worth the complexities in the ecosystem that they've generated. There are several other ways to install multiple pythons, and make them installable in parallel that are easier than SCL (python2 vs. python3 in /usr/bin). I use flatpaks on Fedora (Discord and okular), and I've really enjoyed the experience with them. I'm not sure how well that would translate to the server environment though, but that general approach seems to do a good job of preserving user experience while isolating potentially troublesome conflicts in a way that doesn't mess up the "base system". Marty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 02:32:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote: > [...] > > I can only see this being solvable if non-default modules streams are > > required to be built into a unique /opt prefix instead of /usr. > > Are you trying to re-invent the SCLs? I'm not trying to do anything myself, just pointing out that I believe modularity is broken by design because it leads to the need to have mutually incompatible versions of things installed at the same place at the same time. SCL was one concept that nicely avoided this problem, by giving users the ability to have multiple versions of a stream installed in parallel. Flatpaks and containers are alternative ways to let users deploy different versions of software without any clashing with the default package set provided by the distro. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote: [...] > I can only see this being solvable if non-default modules streams are > required to be built into a unique /opt prefix instead of /usr. Are you trying to re-invent the SCLs? 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: RHEL 9 and modularity
- Original Message - > From: "Daniel P. Berrangé" > To: "Development discussions related to Fedora" > > Sent: Friday, June 19, 2020 5:58:28 AM > Subject: Re: RHEL 9 and modularity > > On Fri, Jun 19, 2020 at 11:28:58AM +0200, Vít Ondruch wrote: > > > > Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a): > > > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr > > > wrote: > > >> The issues I've seen so far affect both Fedora and RHEL, but have gotten > > >> a bit > > >> better in Fedora. For example, a major concern that has been much worse > > >> in > > >> Fedora than RHEL, for obvious reasons: > > >> > > >> One month you can do a fresh install, install a package that, as it > > >> turns out, > > >> is a module for some reason. > > >> > > >> Then you install a fresh system the next month, install the same > > >> package. > > >> Perform a dnf update on the previous system, and you'll find that you > > >> have a > > >> different version of the package installed, because you're tracking a > > >> different version of a default stream. > > >> > > > Can you give an example of where you've seen this? Because our > > > policies in Fedora forbid changing a default stream in a released > > > Fedora. There were a couple exceptions around Java/Maven and libgit2 > > > in the past due to their default streams being broken > > > > > > Sorry, but I don't remember this as "their default streams being > > broken". AFAIR, there were multiple applications trying to use different > > version of libgit2 at the same time which is not possible. That is > > problem of modules design, not problem of the specific default stream as > > you put it. > > That clashing libraries problem is the fatal design flaw in modularity > as it exists today. > > We've made it possible for each module to ship arbitrarily different > versions of the same libraries, while all wanting to install into > the same directory prefix. Thus two separately maintained modules can > easily become mutually exclusive, which is a big pain for users who > need to use both concurrently. This is essentially the "DLL Hell" > problem. > > The single shared /usr hierarchy only works (in the general case) when > you have a single stream where everyone agrees on using the same version > of each package. > > I can only see this being solvable if non-default modules streams are > required to be built into a unique /opt prefix instead of /usr. Or better, if all the work that has gone into maintaining separately packaged libraries went into maintaining one version and fixing associated dependent packages as necessary... Especially for Java and libgit2. > > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange > |:| > |: https://libvirt.org -o-https://fstop138.berrange.com > |:| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange > |:| > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unavailability of some fedoraproject.org services
Thanks for the heads up. A couple of my Bodhi updates have "failed to talk to Greenwave" and Greewave is on the list of affected services shown in that pagure issue. Not sure if I need to resubmit the affected packages at a later date. I guess we will just wait and see. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unavailability of some fedoraproject.org services
Hi everyone, we are currently experiencing network issues in IAD2 datacenter. There are plenty of services on fedoraproject.org unavailable right now. Please stay calm and don't ping us on IRC. If you want to follow the issue, we have a ticket for this [0]. On behalf of Fedora Infrastructure team, Michal [0] - https://pagure.io/fedora-infrastructure/issue/9051 -- Role: Fedora CPE Team - Software Engineer IRC: mkonecny FAS: zlopez ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 11:28:58AM +0200, Vít Ondruch wrote: > > Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a): > > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr > > wrote: > >> The issues I've seen so far affect both Fedora and RHEL, but have gotten a > >> bit > >> better in Fedora. For example, a major concern that has been much worse in > >> Fedora than RHEL, for obvious reasons: > >> > >> One month you can do a fresh install, install a package that, as it turns > >> out, > >> is a module for some reason. > >> > >> Then you install a fresh system the next month, install the same package. > >> Perform a dnf update on the previous system, and you'll find that you have > >> a > >> different version of the package installed, because you're tracking a > >> different version of a default stream. > >> > > Can you give an example of where you've seen this? Because our > > policies in Fedora forbid changing a default stream in a released > > Fedora. There were a couple exceptions around Java/Maven and libgit2 > > in the past due to their default streams being broken > > > Sorry, but I don't remember this as "their default streams being > broken". AFAIR, there were multiple applications trying to use different > version of libgit2 at the same time which is not possible. That is > problem of modules design, not problem of the specific default stream as > you put it. That clashing libraries problem is the fatal design flaw in modularity as it exists today. We've made it possible for each module to ship arbitrarily different versions of the same libraries, while all wanting to install into the same directory prefix. Thus two separately maintained modules can easily become mutually exclusive, which is a big pain for users who need to use both concurrently. This is essentially the "DLL Hell" problem. The single shared /usr hierarchy only works (in the general case) when you have a single stream where everyone agrees on using the same version of each package. I can only see this being solvable if non-default modules streams are required to be built into a unique /opt prefix instead of /usr. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cxxtools-3.0 test suite fails on mock build, but works on local machine
I tried to build on my computer, seems to be no problem with the package itself, maybe some new packages that is not currently available in repository but used by koji brokes the build? Koji is unavailable due to a 503 error here, maybe checking if koji is using a different dependencies version other that what you see on your computer? Martin Gansser 于2020年6月19日周五 下午5:29写道： > > on my local machine, i tried also mock (in this case for rawhide) an it > builds without problems. > mock -r fedora-rawhide-x86_64 --resultdir=/tmp/mock --rebuild > ../SRPMS/cxxtools-3.0-1.fc32.src.rpm > and also rpmbuild builds without problem. > Should I simply deactivate the test suite in general? > > Regards > Martin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a): > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr > wrote: >> The issues I've seen so far affect both Fedora and RHEL, but have gotten a >> bit >> better in Fedora. For example, a major concern that has been much worse in >> Fedora than RHEL, for obvious reasons: >> >> One month you can do a fresh install, install a package that, as it turns >> out, >> is a module for some reason. >> >> Then you install a fresh system the next month, install the same package. >> Perform a dnf update on the previous system, and you'll find that you have a >> different version of the package installed, because you're tracking a >> different version of a default stream. >> > Can you give an example of where you've seen this? Because our > policies in Fedora forbid changing a default stream in a released > Fedora. There were a couple exceptions around Java/Maven and libgit2 > in the past due to their default streams being broken Sorry, but I don't remember this as "their default streams being broken". AFAIR, there were multiple applications trying to use different version of libgit2 at the same time which is not possible. That is problem of modules design, not problem of the specific default stream as you put it. Vít > and causing > issues, but other than those extreme cases, this should never happen > in a stable release. (On Rawhide, that's a different story and if > that's what you're describing, that's a known issue and is being > tracked as part of the upgrade path work.) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: cxxtools-3.0 test suite fails on mock build, but works on local machine
on my local machine, i tried also mock (in this case for rawhide) an it builds without problems. mock -r fedora-rawhide-x86_64 --resultdir=/tmp/mock --rebuild ../SRPMS/cxxtools-3.0-1.fc32.src.rpm and also rpmbuild builds without problem. Should I simply deactivate the test suite in general? Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cxxtools-3.0 test suite fails on mock build, but works on local machine
On your local computer, are you using mock to build or just rpmbuild? If you are using rpmbuild on your local computer that can be missing dependencies for testing. If not so, maybe the test need some network or something like that, since I can't open koji now, I am unsure about this. Martin Gansser 于2020年6月19日周五 下午5:09写道： > > Hi, > > I am currently working on an rpm package for the new version 3.0 of cxxtools, > but the mock build [2] of the test suite fails on ervery > platform. On the other hand, the package for f32 and the test suite are > built on the local computer. What could be the reason ? > > [1] > https://martinkg.fedorapeople.org/Packages/cxxtools/cxxtools-3.0-1.fc32.src.rpm > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=45864911 > > Regards > Martin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- I am looking for someone to review my packages (RHBZ: 1846175, 1847451), and if possible sponsor me into packagers group. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
cxxtools-3.0 test suite fails on mock build, but works on local machine
Hi, I am currently working on an rpm package for the new version 3.0 of cxxtools, but the mock build [2] of the test suite fails on ervery platform. On the other hand, the package for f32 and the test suite are built on the local computer. What could be the reason ? [1] https://martinkg.fedorapeople.org/Packages/cxxtools/cxxtools-3.0-1.fc32.src.rpm [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=45864911 Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: A shim bug 1651016 in Fedora
> I'm not sure who is maintaining the Fedora shim pkg, if none of you, > could you suggest who is the right person to ping. > > The bug below is not fixed yet for long time, can we get an update? > https://bugzilla.redhat.com/show_bug.cgi?id=1651016 pjones is the maintainer, I know there's some issue blocking a new release there but I'm not exactly sure what, I'm awaiting a new release for other issues too. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Orphaned 215 packages
On Thu, Jun 18, 2020 at 6:50 PM Ben Rosser wrote: > Hi Fabio, > > I'm not sure how much time I'll be able to put in, but I'd be very > happy to (help) work on this, either as part of the Stewardship or > Nodejs SIGs, or both. Hopefully others interested in the nodejs > ecosystem (Sérgio and Jared, perhaps?) would be willing to consider > helping too. > > The Nodejs SIG does have ACLs on (almost?) all of these packages, and > I know there are at least a few active packagers there, so hopefully > they would be willing to help as well. I think the immediate problem > is figuring out what in this large stack of nodejs packages is > actually useful (and stopping them from being retired in a week and a > half), so being able to use the tooling you mentioned would be very > helpful, I think. Then we'd need to ultimately find new > points-of-contact for the useful ones (while allowing the non-useful > ones to be retired); in the long term, I'd be willing to pick up some > of those (hopefully not all, but who knows). > > How does one go about joining the Stewardship SIG? Hi Ben, I think the situation for the NodeJS SIG is a bit different, since it already has a group for organizing dist-git access, we didn't have that for the Java stack, so we needed a new FAS group. I think it should be possible to adapt our tooling for the purposes of the nodejs-sig. The scripts and tooling we use to make maintenance easier for us are in this git repo: https://github.com/fedora-stewardship/fedora-stewardship.github.io It should be pretty straightforward to adapt some scripts (especially ./sig_report.py and ./check_sig_leaf.py) - I think changing the string "stewardship-sig" for "nodejs-sig" should be enough in most cases :) The page with reports and statistics that's generated with those scripts is online here: https://fedora-stewardship.github.io/ Maybe it can serve as inspiration for the nodejs-sig. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
