Re: RFC: Modularity Simplified
Le 2019-12-02 07:47, Igor Gnatenko a écrit : Hi Neal, On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote: I think we need to recognize that we've done some poor optimization for the majority of packager workflows. Even if we consider modules, the vast majority of components will never be modularized. Moreover, we already know that the overwhelming majority of specs are managed identically across branches. Yeah, indeed. I think this (optimization of packager workflows) was never an explicit goal of people working on Modularity. And for that reason alone, it should have been sent directly back to the drawing board. Creating new tooling, without trying to optimize the workflow of the intended users of the tooling, was always doomed to have no user adoption community-side. Making tooling for fairies, because you can redefine at will what the fairies want, and no actual fairy will ever materialize to contradict you, is easier design-side. But, it’s 100% a gamble that can (and most often will) misfire. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
Le 2019-12-02 08:17, Igor Gnatenko a écrit : I simply can't. If somebody gets a package into repo just because he wants to build foo, it is probably not very reasonable to ask them to "properly" maintain it. It is very reasonable to expect anyone building in Fedora, reusing the work of countless other Fedora contributors, to produce things in a form others can build and contribute upon. That’s free software 101. Building communities takes time and energy and has no immediate benefit. But, long-term, it's the most efficient way to do things (the “free software development model” Red Hat suits love to congratulate themselves on; it’s a development model, not just a bunch of licenses and deployment formats). Promoting Kleenex packaging, is ultimately self-defeating for Fedora. It does not create the community synergy, that makes working within a distribution worthwhile. The only people it makes happy are the devs that loathed any community or distribution engagement in the first place. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel wrote: > > Le 2019-12-02 07:23, Igor Gnatenko a écrit : > > On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel > > wrote: > >> > >> Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit : > > >> > And we can't actually > >> > have multiple versions of a package with same name (without "mangled" > >> > names) in a repo due to the way how our buildsystem works (and not > >> > only buildsystem, with some caveats). > >> > >> I suppose you're talking about filename here, because we certainly > >> have > >> packages that provide the same thing today. Anyway, this looks a lot > >> less complex to fix than all the complexity modularity has already > >> created. > > > > No, I am talking about package name here. Koji always takes latest > > build for buildroot per name. So if you build foo-1-1 and then > > foo-2-1, only the latter one will be in buildroot. Also tools like > > pungi (compose tool) always takes latest version and nothing else. > > Actually, in that case, it would be better to have a foo-1 and foo-2 > package names. That's how the Go macros do it: > 1. major version ends up in the package name name=foo- > 2. if for some stupid reason there is a need for a specific code state > within a major version, name=compat-foo-- > > >> > I need to deal with Obsoletes but I > >> > simply can't continuously add new Obsoletes into the > >> > fedora-obsolete-packages. > >> > >> Then make the module build infra generate a garbage collector rpm per > >> stream. That's the kind of repetitive thing it's supposed to handle. > > > > Do you have some idea how to do that? > > Make the module multibuild thinguie write a generated package list on > each > run; save the list with the module descriptor in a git repo; on next > run, > add everything not re-generated to a modulename-obsoletes package. I meant more how to do it technically, in Koji :) > >> Anyway, this kind of package needs to exist and be supported as long > >> as > >> the resulting repo contains leaf packages built from it. Otherwise, > >> you're breaking the security audit chain. > > > > No, I don't. They still exist in Koji > > That's academic. Downstream users do not get a koji copy, they get a > copy > of produced repos at a particular date. Please don't start shoving into > deep koji corners materials that should end up in package repos. As long > as things exist as Fedora packages, all their build chain must exist in > Fedora package repos (with eventual minor version updates) > > Having all build elements in the package repos themselves is the CORE > feature that makes the “share” community dimension of Fedora work. > Anyone > can take the packages and do whatever he wants with them (audit, > rebuild, > modify), in any rpm build infra (koji, copr, mock, rpmbuild, obs) > without > depending on the Fedora build infra of the year. It would be nice, however please return back to the reality. Many of packages are FTBFS (e.g. some BRs do not exist anymore (due to the dependency update)). So this does not work in practice. It would be cool to get to the point where Fedora repos are self-hosted, but we are quite far from this. > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
copr builders moved to F31, with more builders
Hey all, Jakub recently finished movement of copr builders from Fedora 30 to Fedora F31. At this moment we are not aware of any serious issues related to this change, but please let us know if you noticed anything. With a great help of fedora infra (Kevin) we were able to add a new set of builders for x86_64 architecture, so the build queue processing should be faster now. Also, the new machines should be a bit faster (while we still keep the old machines), so please be prepared that the x86_64 builder set is not that homogeneous as before. There's currently no way to pick VM from one or another set. Happy building! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Modularity Simplified
Le 2019-12-02 07:23, Igor Gnatenko a écrit : On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel wrote: Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit : > And we can't actually > have multiple versions of a package with same name (without "mangled" > names) in a repo due to the way how our buildsystem works (and not > only buildsystem, with some caveats). I suppose you're talking about filename here, because we certainly have packages that provide the same thing today. Anyway, this looks a lot less complex to fix than all the complexity modularity has already created. No, I am talking about package name here. Koji always takes latest build for buildroot per name. So if you build foo-1-1 and then foo-2-1, only the latter one will be in buildroot. Also tools like pungi (compose tool) always takes latest version and nothing else. Actually, in that case, it would be better to have a foo-1 and foo-2 package names. That's how the Go macros do it: 1. major version ends up in the package name name=foo- 2. if for some stupid reason there is a need for a specific code state within a major version, name=compat-foo-- > I need to deal with Obsoletes but I > simply can't continuously add new Obsoletes into the > fedora-obsolete-packages. Then make the module build infra generate a garbage collector rpm per stream. That's the kind of repetitive thing it's supposed to handle. Do you have some idea how to do that? Make the module multibuild thinguie write a generated package list on each run; save the list with the module descriptor in a git repo; on next run, add everything not re-generated to a modulename-obsoletes package. Anyway, this kind of package needs to exist and be supported as long as the resulting repo contains leaf packages built from it. Otherwise, you're breaking the security audit chain. No, I don't. They still exist in Koji That's academic. Downstream users do not get a koji copy, they get a copy of produced repos at a particular date. Please don't start shoving into deep koji corners materials that should end up in package repos. As long as things exist as Fedora packages, all their build chain must exist in Fedora package repos (with eventual minor version updates) Having all build elements in the package repos themselves is the CORE feature that makes the “share” community dimension of Fedora work. Anyone can take the packages and do whatever he wants with them (audit, rebuild, modify), in any rpm build infra (koji, copr, mock, rpmbuild, obs) without depending on the Fedora build infra of the year. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
Hi Kevin, On Mon, Dec 2, 2019 at 4:43 AM Kevin Kofler wrote: > > Igor Gnatenko wrote: > > 1. Do we want to package multiple streams only for "leaf" software or > > any kind of it? > > I believe that we need both, and we do support both. However, it might > > not look as nice as it could: > > * Need to create multiple repos for different "streams" > > * Need to maintain epel7/epel8/f30/f31/master branches > > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is > > manual work > > Your proposal addresses these, but skips the same requirement the current > Modularity also fails to address by design, i.e.: > > > * However, those are supposed to be (according to the guidelines) > > parallel-installable (and not be conflicting in any way) > > In particular, your proposal suggests: > > > * Packages produced from nodejs.src have Provides: stream(nodejs) > > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is > > explicitly not possible to install 9 and 10 at the same time > > which explicitly excludes the parallel installability. So I do not see how > it addresses the main drawback Modularity has compared to compatibility > packages. Yes, however maintainer of nodejs does not want to rename binaries and patch sources to be parallel-installable. And today, we would block adding such "compat" package into the repositories. I agree it would be nice to have them parallel-installable, but I don't think we need to force it onto all packages. > (Note: The sentence as stated also means that the package Conflicts with > itself, which will probably also badly confuse some tools, but that is a > technical detail that should be fixable. It is the underlying concept of > Conflicting with all other versions that is the real issue.) > > Your proposal is essentially a proposal to automate the creation of > versioned (with suffixed Name) compatibility packages, but it excludes the > most essential part of the compatibility package pattern, the one that makes > it suited for this use case unlike the current Modularity. So I fail to see > how it addresses in any way the issues we are having with the current > Modularity. We have different problems with modularity, like: * Whole new tooling which has its own inputs/outputs (and many times it actually does not work) * Overcomplication of dependency solving (even after so many years, DNF still can't handle it properly) * Different workflow from standard packages which hurts discoverability and maintainability (basically it creates small distros within one distro) and many more. > You suggest to change the packaging guidelines to match the technical > limitations of your proposed technology: > > > * Packaging guidelines should be adopted to accept conflicting > > packages and tooling should be improved to show the conflicts and how > > to resolve them > > but the guideline that compatibility packages should not conflict exists for > a strong reason, and removing the guideline will not make the issues that > lead to its existence magically go away. > > Non-default versions of non-leaf packages MUST be parallel installable with > the default version for the distribution to be consistent and for users to > be allowed to freely choose their applications without arbitrary conflicts. I believe that exactly one of the reasons why Modularity has been created. It requires patching of source code and renaming binaries and sometimes it is not trivial amount of work. And at the end of the day, most of the people probably don't need installed multiple versions of a package at the same time (e.g. nodejs). > Otherwise (i.e., if parallel installability is not implemented), what you > write: > > > Using some examples from previous threads, why does bugzilla have to be > > built against 2 different versions of perl and users could choose? I think > > maintainer should choose one version of perl and let bugzilla use it. > > is just not true. If the 2 different versions of Perl cannot coexist, > building Bugzilla against only one version is not possible without making > Bugzilla incompatible with anything built against the other version. Sure, we just have to accept this until perl is made parallel-installable. Which may or may not happen, but if I have choice between "only one version of perl and no bugzilla" or "two conflicting versions of perl and bugzilla using non-default version of perl", I will choose latter. Unfortunately reality is not perfect. > I agree that we should only build each package against one version of Perl > (the distribution default wherever possible, otherwise the most suitable > version), but that requires that the users can actually install more than > one version at the same time. > > But going back to your questions and answers: > > > 2. Do we want to support buildtime-only packages? > > I would rather generalize this category as "less-supported packages". > > This is getting dangerously close to the strawman antipattern: you are >
Fedora-Cloud-30-20191202.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
Hi Neal, On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote: > > On Tue, Nov 26, 2019 at 10:59 AM Igor Gnatenko > wrote: > > > > Hello fellows, > > > > After last publication on LWN about Fedora Modularity mess, I think it > > is time to describe the idea I was proposing internally with few other > > folks (Adam Samalik, Brian Exelbierd) back in the RH times. > > > > Before I actually go deep, I'll try to answer main questions to myself > > (so that you can understand why I am proposing this particular thing). > > > > 1. Do we want to package multiple streams only for "leaf" software or > > any kind of it? > > I believe that we need both, and we do support both. However, it might > > not look as nice as it could: > > * Need to create multiple repos for different "streams" > > * Need to maintain epel7/epel8/f30/f31/master branches > > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is > > manual work > > * However, those are supposed to be (according to the guidelines) > > parallel-installable (and not be conflicting in any way) > > Doing git merge / git cherry-pick and maintaining many git remotes > > requires some advanced git knowledge and a time. And we can't actually > > have multiple versions of a package with same name (without "mangled" > > names) in a repo due to the way how our buildsystem works (and not > > only buildsystem, with some caveats). > > We do have some kind of a solution for multiple releases building from > > one branch (package.cfg), however this work has been never finished, > > thus there are many problems with this approach. > > > > I think we need to recognize that we've done some poor optimization > for the majority of packager workflows. Even if we consider modules, > the vast majority of components will never be modularized. Moreover, > we already know that the overwhelming majority of specs are managed > identically across branches. Yeah, indeed. I think this (optimization of packager workflows) was never an explicit goal of people working on Modularity. > In these cases, we can make fedpkg better for handling this. There's > no reason that people can't have a single master branch and only > branch for distro releases as needed. > > I'm trying this workflow myself with libeconf[1], but unfortunately > fedpkg doesn't handle this model well right now. I proposed a > particular feature request for this[2], but there might be other ways > to make this work. The current approach for package.cfg is terribly > broken, though. It definitely needs more thinking and probably requires more concrete proposal how it should work overall. Not just "if package.cfg is there, parse it and build for targets specified in there". I'm also not entirely sure if we should encode this information in the git repo as a file because it is not possible to query this information (e.g. to find out which branches build where) and do checks (e.g. that you don't build 1.x and 2.x in the f31 and you choose not to mangle names). > As for the name mangling, I think this is a relatively minor issue for > supporting multiple versions of software. There *are* things we could > do to minimize this, but it's not a good point to focus on right now. > > [1]: https://src.fedoraproject.org/rpms/libeconf > [2]: https://pagure.io/fedpkg/issue/352 > > > 2. Do we want to support buildtime-only packages? > > I would rather generalize this category as "less-supported packages". > > I maintain 800+ Rust packages and very often I need to update them to > > an incompatible version. In Rawhide I just do it, update all dependent > > packages to use new version, and if I can't do that for some reason, > > create "compat" package. Obviously, all patches are sent to the > > upstream. > > I think we should categorically disallow > build-time-only/buildroot-only packages. They don't make sense in a > Fedora context and make it impossible to share resources. What's worse > with this model as it is currently implemented is that nobody can > figure out whether there are buildroot-only packages involved, and > multiple maintainers of packages basically can't happen. Well, if we make easier builds for multiple targets (without pushing 5 times, creating 10 overrides and waiting for repos) and relax update policy for such packages, then I definitely don't mind having them in the main repo. > Re-introducing those buildroot-only packages back into the main > package collection gives people an opportunity to depend on them > freely and co-maintain them. Now, we can't force anyone to co-maintain > packages, but as we see with the large number of orphanings that have > been happening lately, if people actually want or need packages, they > tend to take them on too. That's because those packages are required in the runtime, while I was talking about case like with Rust packages which are used only in build time and linked statically. > I think we can make it easier to support shipping these things to > stable releases
[Bug 1778598] perl-Clipboard-0.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1778598 --- Comment #1 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1778598] New: perl-Clipboard-0.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1778598 Bug ID: 1778598 Summary: perl-Clipboard-0.21 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Clipboard Keywords: FutureFeature, Triaged Assignee: mkre...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, mkre...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.21 Current version/release in rawhide: 0.20-3.fc31 URL: http://search.cpan.org/dist/Clipboard/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/14091/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
Hey Michal, On Sat, Nov 30, 2019 at 5:08 PM clime wrote: > > Hey Igor, > > On Tue, 26 Nov 2019 at 17:00, Igor Gnatenko > wrote: > > > > Hello fellows, > > > > After last publication on LWN about Fedora Modularity mess, I think it > > is time to describe the idea I was proposing internally with few other > > folks (Adam Samalik, Brian Exelbierd) back in the RH times. > > > > Before I actually go deep, I'll try to answer main questions to myself > > (so that you can understand why I am proposing this particular thing). > > > > 1. Do we want to package multiple streams only for "leaf" software or > > any kind of it? > > I believe that we need both, and we do support both. However, it might > > not look as nice as it could: > > * Need to create multiple repos for different "streams" > > * Need to maintain epel7/epel8/f30/f31/master branches > > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is > > manual work > > * However, those are supposed to be (according to the guidelines) > > parallel-installable (and not be conflicting in any way) > > Doing git merge / git cherry-pick and maintaining many git remotes > > requires some advanced git knowledge and a time. And we can't actually > > have multiple versions of a package with same name (without "mangled" > > names) in a repo due to the way how our buildsystem works (and not > > only buildsystem, with some caveats). > > We do have some kind of a solution for multiple releases building from > > one branch (package.cfg), however this work has been never finished, > > thus there are many problems with this approach. > > > > 2. Do we want to support buildtime-only packages? > > I would rather generalize this category as "less-supported packages". > > I maintain 800+ Rust packages and very often I need to update them to > > an incompatible version. In Rawhide I just do it, update all dependent > > packages to use new version, and if I can't do that for some reason, > > create "compat" package. Obviously, all patches are sent to the > > upstream. > > Upstreams are removing features, I need to deal with Obsoletes but I > > simply can't continuously add new Obsoletes into the > > fedora-obsolete-packages. And what for if they are used only during > > build of other, more important, packages? Why do I have to spend time > > with upgradepaths? I definitely want some mechanism which will tell to > > user that "THIS PACKAGE IS NOT FULLY SUPPORTED." > > Obviously, for packages which are used in runtime need a proper > > support as we do today for all packages to share work (that's the > > place where I agree with Kevin Kofler.) > > > > 3. Can we have different lifecycles for the software in Fedora? > > Right now we have to keep all versions of software which was there at > > GA point. And from the updates repo. We never remove packages > > entirely. That said, if package was there at GA time, it will have to > > be "supported" until the end of that Fedora release. > > I don't think we can (should?) do much in this regard. If we make > > packages to build from "stream" branch, we can put an information to > > that branch that this package should be built for all distributions > > (Fedora, EPEL) until this date. Or even store this info somewhere else > > like PDC (yes, I know we want to kill it). fedpkg build will take this > > into account and submit proper builds. And we can design some API in > > infra which would tell until when some particular stream of a package > > is supported. Much like it is done with Fedora releases & GNOME > > Software. > > > > 4. Do we want to have some kind of "stream expansion" where software > > builds against all Pythons, Perls and whatnot? > > I think this should be conscious choice of a distribution, and in > > specific cases, maintainer. Using some examples from previous threads, > > why does bugzilla have to be built against 2 different versions of > > perl and users could choose? I think maintainer should choose one > > version of perl and let bugzilla use it. Being able to build > > combinations of software is definitely nice, but I don't think this > > should be standard practice. openSUSE does that with ruby and python > > (they build all modules automatically for all versions) and I like > > this. But having all packages built against all is just combinatoric > > explosion. Given how many updates have feedback in Bodhi, I'm pretty > > sure 99% of combination won't be tested (or even installed?) ever. > > > > 5. Are we still trying to be a Linux distribution or we are just > > letting people to do whatever they want in our infrastructure? > > This question bothers me from time to time and I don't have answer. > > For example, Modularity is very flexible and I very often find people > > saying that you can expand this and that, but in Fedora we limit its > > usefulness. Do we actually need to develop something like this > > (knowing in advance that probably nobody outside of Fedora/RHEL will > > be using this
Re: RFC: Modularity Simplified
On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel wrote: > > Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit : > > Hi, Igor > > > > And we can't actually > > have multiple versions of a package with same name (without "mangled" > > names) in a repo due to the way how our buildsystem works (and not > > only buildsystem, with some caveats). > > I suppose you're talking about filename here, because we certainly have > packages that provide the same thing today. Anyway, this looks a lot > less complex to fix than all the complexity modularity has already > created. No, I am talking about package name here. Koji always takes latest build for buildroot per name. So if you build foo-1-1 and then foo-2-1, only the latter one will be in buildroot. Also tools like pungi (compose tool) always takes latest version and nothing else. > > I need to deal with Obsoletes but I > > simply can't continuously add new Obsoletes into the > > fedora-obsolete-packages. > > Then make the module build infra generate a garbage collector rpm per > stream. That's the kind of repetitive thing it's supposed to handle. Do you have some idea how to do that? > Anyway, this kind of package needs to exist and be supported as long as > the resulting repo contains leaf packages built from it. Otherwise, > you're breaking the security audit chain. No, I don't. They still exist in Koji and if needed, it can be "reproduced". It simply keeps packages which were used in buildroot of any build. Definitely it is more complicated than this, but that's how it works in short. > > Are we trying to create > > technologies which would be very extensible and used in other > > distributions instead of solving some specific problems? > > In my experience, solving specific problems should come first. You > won't get any adoption elsewhere without showing some practical benefit > Fedora-side, and chasing all-encompasing mythical beasts is a great way > to burn time and money without ever delivering anything. > > > > > * If desired, packages can depend on a specific stream via Requires: > > stream(nodejs:10) without actually depending on nodejs (this requires > > some small piece of code in libsolv) > > Why the heck would you want that? Packages should not depend on stream > anymore than they depend on a release as a whole. They should depend on > something specifically inside a stream. And that's just a > Requires: something with stream(streamname) yeah, sure. I just wanted to point out that we *can* do that, not that we *need* to actually do it. > > * All standard Conflicts/Requires/Obsoletes/… will simply work > > Yes, please make it back a single unified rpm-level dependency graph > instead of separate module universes that don't behave with one another > or with the main distro stream. > > That would be totally AWESOME > > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Modularity Simplified
On Tue, Nov 26, 2019 at 6:35 PM Zbigniew Jędrzejewski-Szmek wrote: > > As a meta-goal, we should break up "Modularity" into a number of > separate components, some build-side, some client-side. Modularity > suffers greatly from trying to encode everything into one document. > This greatly raises the complexity of the task and makes it hard to > consider alternative proposals for various parts. > > Let's consider them separately: > > 1. what to build against what branches > > You said: > > * each has package.cfg or some alternative which specifies what is the > > EOL and/or for which releases to build > > Right now we use dist-git branches for this. Having a package.cfg > might sound easier , but the caveat is that building against different > branches requires tweaks sometimes. So we immediately hit a choice: do > we want a single branch and the %ifdef mess, or multiple branches and > the cherry picking troubles. Yeah, but if there is clear map between branches & builds stored somewhere, it could be quite convenient for both. If you say "I want to have separate branches", then you still have f31/f32 while you should be able to say "I have 2.x branch and it is going to be built in all releases". That should be easily discoverable. > Right now, big disadvantage of multiple branches is that %changelogs > and Release bumps introduce trivial conflicts. I think we should > explore the proposals (incl. your and Neal's) to make this better. > Fixing this would be good also for normal packaging, because it'd remove > one or two more steps that need to be done every time. Yeah, at the current job I'm exploring something similar so when I get some time, I'll try to write proposal. > We should explore both directions, i.e. package.conf and easier branches. +1 > We should experiment with better/easier control of what to build > where. This would benefit normal packaging too. Right now our tooling > is just hard to use, with multiple commands in different tools needed > to start builds, schedule updates, control koji status, etc. We need > changes for "normal" packages as much as for "streams". +1 > 2. how to deliver rpms to users and how to let them control installed versions > > > How I would imagine having multiple streams: > > * rpms/nodejs has multiple branches - 10, 11, 12 > > * in all of them, nodejs.spec exists as-is without "mangled" name > > (just with different versions and such) > > * when builds are submitted, Koji automatically adds suffix to a main > > package and subpackages containing branch name > > * during the rpmbuild, extra provides are added (for the unversioned > > names and indication of a stream) and conflicts (possibly depending on > > some macro which user can disable) automatically > > Yes. The crucial part is that the rpms that are delivered are > just normal rpms. All the complications are kept on the build-side > and the client side doesn't need to care if this magic happened, the > same result could have been achieved with manually mangled spec file. > > > * If software needs to specify that it wants 9 ≤ nodejs ≤ 11 it can > > describe this in standard way (Requires: (nodejs >= 9 with nodejs <= > > 11)) and one will be picked up automatically > > ... > > * All standard Conflicts/Requires/Obsoletes/… will simply work > > Yes. More of "just normal packages". > > > * If user wants to switch from 9 to 10, he can run `dnf swap nodejs9 > > nodejs10` > > * If that requires some conflicting dependency to be switched, it will > > be switched automatically > > * Packages produced from nodejs.src have Provides: stream(nodejs) > > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is > > explicitly not possible to install 9 and 10 at the same time > > * If desired, packages can depend on a specific stream via Requires: > > stream(nodejs:10) without actually depending on nodejs (this requires > > some small piece of code in libsolv) > > * In the very similar way, user can lock themselves to a specific > > stream by writing some conf file which DNF would read (if point above > > is implemented, about just tens of lines of the code in libdnf, or > > even libsolv can be teached about that as well) > > * DNF can be teached about these special things so that you can > > automatically swap conflicting dependencies, but lock yourself to some > > streams of a package > > ... and here I'm not sure. I'm not convinced we need to try to manage > all this like that. We already have packages which Conflict, or specify > conflicting Requires, and the user gives a dnf command, and a certain > transaction is prepared for them. The transaction will occasionally > specify a list of rpms to remove. If the user doesn't like this, they can > cancel and give a different command. This would imply that we have --allowerasing set by default, but we don't... And probably we should not since it is dangerous (a bit?). > Specifically, some streams might conflict, other might not, etc. > We could have a macro
Re: RFC: Modularity Simplified
On Sat, Nov 30, 2019 at 9:28 PM Kevin Fenzi wrote: > > On Tue, Nov 26, 2019 at 05:35:27PM +, Zbigniew Jędrzejewski-Szmek wrote: > > As a meta-goal, we should break up "Modularity" into a number of > > separate components, some build-side, some client-side. Modularity > > suffers greatly from trying to encode everything into one document. > > This greatly raises the complexity of the task and makes it hard to > > consider alternative proposals for various parts. > > > > Let's consider them separately: > > > > 1. what to build against what branches > > > > You said: > > > * each has package.cfg or some alternative which specifies what is the > > > EOL and/or for which releases to build > > > > Right now we use dist-git branches for this. Having a package.cfg > > might sound easier , but the caveat is that building against different > > branches requires tweaks sometimes. So we immediately hit a choice: do > > we want a single branch and the %ifdef mess, or multiple branches and > > the cherry picking troubles. > > Yeah, this is a difficult thing to answer, since there's people in both > camps right now happy with either end, and lots in between. > > > > Right now, big disadvantage of multiple branches is that %changelogs > > and Release bumps introduce trivial conflicts. I think we should > > explore the proposals (incl. your and Neal's) to make this better. > > Fixing this would be good also for normal packaging, because it'd remove > > one or two more steps that need to be done every time. > > +1 > > > We should explore both directions, i.e. package.conf and easier branches. > > > > We should experiment with better/easier control of what to build > > where. This would benefit normal packaging too. Right now our tooling > > is just hard to use, with multiple commands in different tools needed > > to start builds, schedule updates, control koji status, etc. We need > > changes for "normal" packages as much as for "streams". > > I wonder if we couldn't explore using tags for this. > ie, if you tag a commit in a specific way it tells the system what to > build, what to run ci on, etc. IMO we should be building and testing all commits automatically unless maintainer put some comment like "[skip ci]" in the commit message. > ...snip... > > > > A different proposal: we add a new rpm flag (maybe as a special > > Requires: line) that specifies that a package is only supported as a > > build-time dependency. DNF could then gain a trivial patch that > > it would ask the user "Do you want to install those unsupported packages? > > If you do, please do not file bugs, because ...". > > The advantages: > > a) packages are available for local builds and downstream rebuilds > > b) no problem with mock and koji being different > > c) we avoid any perception of "welding down the engine hood". > > > > This would just acknowledge the truth that there are many packages > > in Fedora that are not supported beyond an occasional version bump > > and rebuild, giving better transparency for the users in general. > > Well, if we are doing that, couldn't we just not add bugzilla components > for them? But perhaps we do want the bugs, even if the package isn't > 'maintained' wouldn't it still be good to know about bugs? I think we still should create BZ (or have it opt-out and have issues on pagure?) because it is useful to get bugreports about some CVE and whatnot. > ...snip... > > I think we should allow "rolling" versions more widely, like we do with > > firefox, the kernel, spam blockers, and probably some other things. > > As long some piece software is most backwards compatible, I think we'd > > be better of abandoning the strict guidelines we have now. > > This depends on each specific package though. > > Yes, I think this very much depends on the package. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[389-devel] 389 DS nightly 2019-12-02 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/02/report-389-ds-base-1.4.2.4-20191202git94354d8.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: RFC: Modularity Simplified
Igor Gnatenko wrote: > 1. Do we want to package multiple streams only for "leaf" software or > any kind of it? > I believe that we need both, and we do support both. However, it might > not look as nice as it could: > * Need to create multiple repos for different "streams" > * Need to maintain epel7/epel8/f30/f31/master branches > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is > manual work Your proposal addresses these, but skips the same requirement the current Modularity also fails to address by design, i.e.: > * However, those are supposed to be (according to the guidelines) > parallel-installable (and not be conflicting in any way) In particular, your proposal suggests: > * Packages produced from nodejs.src have Provides: stream(nodejs) > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is > explicitly not possible to install 9 and 10 at the same time which explicitly excludes the parallel installability. So I do not see how it addresses the main drawback Modularity has compared to compatibility packages. (Note: The sentence as stated also means that the package Conflicts with itself, which will probably also badly confuse some tools, but that is a technical detail that should be fixable. It is the underlying concept of Conflicting with all other versions that is the real issue.) Your proposal is essentially a proposal to automate the creation of versioned (with suffixed Name) compatibility packages, but it excludes the most essential part of the compatibility package pattern, the one that makes it suited for this use case unlike the current Modularity. So I fail to see how it addresses in any way the issues we are having with the current Modularity. You suggest to change the packaging guidelines to match the technical limitations of your proposed technology: > * Packaging guidelines should be adopted to accept conflicting > packages and tooling should be improved to show the conflicts and how > to resolve them but the guideline that compatibility packages should not conflict exists for a strong reason, and removing the guideline will not make the issues that lead to its existence magically go away. Non-default versions of non-leaf packages MUST be parallel installable with the default version for the distribution to be consistent and for users to be allowed to freely choose their applications without arbitrary conflicts. Otherwise (i.e., if parallel installability is not implemented), what you write: > Using some examples from previous threads, why does bugzilla have to be > built against 2 different versions of perl and users could choose? I think > maintainer should choose one version of perl and let bugzilla use it. is just not true. If the 2 different versions of Perl cannot coexist, building Bugzilla against only one version is not possible without making Bugzilla incompatible with anything built against the other version. I agree that we should only build each package against one version of Perl (the distribution default wherever possible, otherwise the most suitable version), but that requires that the users can actually install more than one version at the same time. But going back to your questions and answers: > 2. Do we want to support buildtime-only packages? > I would rather generalize this category as "less-supported packages". This is getting dangerously close to the strawman antipattern: you are modifying the question before answering it. That said, you then add: > Obviously, for packages which are used in runtime need a proper > support as we do today for all packages to share work which limits the scope to build-time-only packages again. So why did you attempt to modify it above? > I maintain 800+ Rust packages and very often I need to update them to > an incompatible version. In Rawhide I just do it, update all dependent > packages to use new version, and if I can't do that for some reason, > create "compat" package. Obviously, all patches are sent to the > upstream. > Upstreams are removing features, I need to deal with Obsoletes but I > simply can't continuously add new Obsoletes into the > fedora-obsolete-packages. It is a common misconception that any package removed from Fedora belongs into fedora-obsolete-packages. In most cases, you should actually NOT add the package there. Just stop shipping it. If the user has an obsolete package installed, it should be kept by default. Only if it actually causes file conflicts with current software, it makes sense to Obsolete the package at RPM level. (Arguably also for dependency conflicts, but those can actually be resolved with the DNF --allowremove flag, so it is not that clear cut. I would argue for keeping the packages by default and letting the users remove obsolete packages with broken dependencies manually.) We should not remove software that users may still be using from users' systems for no good reason. Especially not if it causes extra
Fedora rawhide compose report: 20191201.n.0 changes
OLD: Fedora-Rawhide-20191130.n.1
NEW: Fedora-Rawhide-20191201.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 1
Dropped packages:0
Upgraded packages: 32
Downgraded packages: 0
Size of added packages: 1.44 MiB
Size of dropped packages:0 B
Size of upgraded packages: 908.68 MiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 48.63 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path:
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20191201.n.0.ppc64le.tar.xz
= DROPPED IMAGES =
= ADDED PACKAGES =
Package: python-javabridge-1.0.18-3.20190729gitc7ccaed.fc32
Summary: Python wrapper for the Java Native Interface
RPMs:python3-javabridge
Size:1.44 MiB
= DROPPED PACKAGES =
= UPGRADED PACKAGES =
Package: calligraplan-3.2.1-1.fc32
Old package: calligraplan-3.2.0-1.fc32
Summary: A Project Planner
RPMs: calligraplan calligraplan-libs
Size: 22.61 MiB
Size change: 11.55 KiB
Changelog:
* Sat Nov 30 2019 Rex Dieter - 3.2.1-1
- 3.2.1
Package: conmon-2:2.0.4-0.2.dev.git42bce45.fc32
Old package: conmon-2:2.0.4-0.1.dev.gitf6d23b5.fc32
Summary: OCI container runtime monitor
RPMs: conmon
Size: 185.92 KiB
Size change: 639 B
Changelog:
* Fri Nov 29 2019 RH Container Bot -
2:2.0.4-0.2.dev.git42bce45
- autobuilt 42bce45
Package: dino-0.0-0.16.20191129.git.d194eae.fc32
Old package: dino-0.0-0.15.20190917.git.f746ce7.fc32
Summary: Modern XMPP ("Jabber") Chat Client using GTK+/Vala
RPMs: dino dino-devel
Size: 6.27 MiB
Size change: 152.21 KiB
Changelog:
* Sat Nov 30 2019 Randy Barlow -
0.0-0.16.20191129.git.d194eae6
- Update to d194eae6.
- https://github.com/dino/dino/compare/f746ce74...d194eae6
Package: dkms-2.8.1-1.fc32
Old package: dkms-2.7.1-2.fc31
Summary: Dynamic Kernel Module Support Framework
RPMs: dkms
Size: 75.46 KiB
Size change: 506 B
Changelog:
* Sun Dec 01 2019 Simone Caronni - 2.8.1-1
- Update to 2.8.1.
Package: etckeeper-1.18.12-1.fc32
Old package: etckeeper-1.18.10-6.fc32
Summary: Store /etc in a SCM system (git, mercurial, bzr or darcs)
RPMs: etckeeper etckeeper-brz etckeeper-dnf
Size: 63.91 KiB
Size change: -692 B
Changelog:
* Sun Dec 01 2019 Thomas Moschny - 1.18.12-1
- Update to 1.18.12.
- New version of patch to fix logging with Ansible (#1762693).
Package: fcitx-4.2.9.7-1.fc32
Old package: fcitx-4.2.9.6-6.fc31
Summary: An input method framework
RPMs: fcitx fcitx-data fcitx-devel fcitx-gtk2 fcitx-gtk3 fcitx-libs
fcitx-pinyin fcitx-qt4 fcitx-qw fcitx-table fcitx-table-chinese
Size: 22.24 MiB
Size change: -70.53 KiB
Changelog:
* Sun Dec 01 2019 Robin Lee - 4.2.9.7-1
- Release 4.2.9.7
Package: fcitx-cloudpinyin-0.3.7-1.fc32
Old package: fcitx-cloudpinyin-0.3.5-6.fc31
Summary: Cloudpinyin module for fcitx
RPMs: fcitx-cloudpinyin
Size: 180.07 KiB
Size change: -8.04 KiB
Changelog:
* Sun Dec 01 2019 Robin Lee - 0.3.7-1
- Release 0.3.7 (RHBZ#1778439)
Package: fcitx-qt5-1.2.4-1.fc32
Old package: fcitx-qt5-1.2.3-10.fc32
Summary: Fcitx IM module for Qt5
RPMs: fcitx-qt5 fcitx-qt5-devel
Size: 1.29 MiB
Size change: -16.67 KiB
Changelog:
* Sun Dec 01 2019 Robin Lee - 1.2.4-1
- Release 1.2.4
Package: gap-pkg-float-0.9.1-5.fc32
Old package: gap-pkg-float-0.9.1-4.fc32
Summary: GAP access to mpfr, mpfi, mpc, fplll and cxsc
RPMs: gap-pkg-float gap-pkg-float-doc
Size: 996.98 KiB
Size change: -6.10 KiB
Changelog:
* Thu Nov 28 2019 Jerry James - 0.9.1-5
- Rebuild for libfplll 5.3.0
Package: ghdl-0.37dev-7.20191130git3bd9a18.fc32
Old package: ghdl-0.37dev-6.20191121git03862a4.fc32
Summary: A VHDL simulator, using the GCC technology
RPMs: ghdl ghdl-grt ghdl-llvm ghdl-llvm-grt ghdl-mcode ghdl-mcode-grt
Size: 50.18 MiB
Size change: 171.86 KiB
Changelog:
* Sun Dec 01 2019 Dan Hor??k - 0.37dev-7.20191130git3bd9a18
- updated to new ghdl snapshot
- fix library and include path for synth
Package: golang-github-osbuild-composer-4-1.fc32
Old package: golang-github-osbuild-composer-3-1.fc32
Summary: An image building service based on osbuild
RPMs: golang-github-osbuild-composer
Size: 52.12 MiB
Size change: 31.63 MiB
Changelog:
* Sun Dec 01 2019 Ondrej Budai - 4-1
- New upstream release.
Package: golang-github-tdewolff-parse-2.4.0-1.fc32
Old package: golang-github-tdewolff-parse-2.3.13-1.fc32
Summary: Go parsers for web formats
RPMs: golang-github-tdewolff-parse-devel
Size: 83.78 KiB
Size change: 1.90 KiB
Changelog:
* Sat Nov 30 2019 Elliott Sales de Andrade -
2.4.0-1
- Update to latest version
Package: gol
[Bug 1778382] [RFE] EPEL-8 branch for perl-HTTP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1778382 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-HTTP-Lite-2.44-19.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-028e7682c1 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1756036] [RFE] perl-XML-TreePP build for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1756036 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- perl-XML-TreePP-0.43-14.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f63526dde7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-Rawhide-20191201.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 14/161 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191130.n.1): ID: 491639 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/491639 ID: 491729 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/491729 ID: 491730 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/491730 ID: 491747 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/491747 ID: 491750 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/491750 Old failures (same test failed in Fedora-Rawhide-20191130.n.1): ID: 491587 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/491587 ID: 491602 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/491602 ID: 491603 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/491603 ID: 491615 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/491615 ID: 491626 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/491626 ID: 491628 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/491628 ID: 491644 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/491644 ID: 491653 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/491653 ID: 491658 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/491658 ID: 491672 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/491672 Soft failed openQA tests: 10/161 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20191130.n.1): ID: 491589 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/491589 ID: 491745 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/491745 Old soft failures (same test soft failed in Fedora-Rawhide-20191130.n.1): ID: 491581 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/491581 ID: 491582 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/491582 ID: 491590 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/491590 ID: 491630 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/491630 ID: 491665 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/491665 ID: 491695 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/491695 ID: 491696 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/491696 ID: 491728 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/491728 Passed openQA tests: 133/161 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191130.n.1): ID: 491641 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/491641 ID: 491646 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/491646 Skipped gating openQA tests: 1/161 (x86_64) Old skipped gating tests (same test skipped in Fedora-Rawhide-20191130.n.1): ID: 491601 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/491601 Skipped non-gating openQA tests: 4 of 163 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.00 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/491417#downloads Current test data: https://openqa.fedoraproject.org/tests/491621#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 6 MiB to 7 MiB System load changed from 0.48 to 1.53 Previous test data: https://openqa.fedoraproject.org/tests/491419#downloads Current test data: https://openqa.fedoraproject.org/tests/491623#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed
[Bug 1772875] Please branch and build perl-Text-Format for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1772875 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Text-Format-0.61-6.el8 Resolution|--- |ERRATA Last Closed||2019-12-02 00:14:44 --- Comment #4 from Fedora Update System --- perl-Text-Format-0.61-6.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
rawhide protobuf update with new soname
I prepared a protobuf upgrade from 3.6 to 3.11 in rawhide. It comes with
a soname update and requires its dependencies to be rebuilt.
I tested it all in copr and most of the packages are rebuilding except
for the following packages:
* dynafed - compile error:
In file included from
/builddir/build/BUILD/dynafed-1.5.1/src/UgrMemcached.pb.h:23,
from
/builddir/build/BUILD/dynafed-1.5.1/src/LocationInfo.cc:21:
/usr/include/google/protobuf/io/coded_stream.h:842:16: error: macro
"Error" requires 2 arguments, but only 1 given
842 | uint8* Error() {
|^
* community-mysql:
there is a simple upstream patch to fix the compile error but the test
fails in copr with:
Failed to connect to systemd notification socket named
/run/systemd/nspawn/notify. Error: 'Permission denied'
Does not sound like it is related to the protobuf update
* mumble - compile error:
In file included from BanEditor.cpp:36:
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
| ^
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
| ^
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
|
* paraview - cmake failure:
CMake Error at CommandLineExecutables/CMakeLists.txt:77 (get_property):
get_property could not find TARGET pthread. Perhaps it has not yet been
created.
* fts: No matching package to install: 'activemq-cpp-devel'
* kismet: error: Invalid version (double separator '-'): 2019-08-GIT:
pkgconfig(kismet) = 2019-08-GIT
Most of the errors do not sound protobuf related.
I want to do the protobuf upgrade in rawhide on Monday, 2019-12-09, just
after the rawhide compose has finished to be able to rebuild all
dependencies before the next compose.
Please let me know if you want to rebuild your package yourself or if
you see other problems with the protobuf upgrade.
Adrian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1742913] biber-2.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1742913 --- Comment #5 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1742913] biber-2.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1742913 Upstream Release Monitoring changed: What|Removed |Added Summary|biber-2.13 is available |biber-2.14 is available --- Comment #4 from Upstream Release Monitoring --- Latest upstream release: 2.14 Current version/release in rawhide: 2.12-1.fc32 URL: http://biblatex-biber.sourceforge.net/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6443/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy
https://bugzilla.redhat.com/show_bug.cgi?id=1778465 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/20178 https://pagure.io/releng/fedora-scm-requests/issue/20179 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: Self Introduction: James Elford
> I think the next step is to open a Package Review request on bugzilla, > including a new spec file - is that right? In the time it took me to write this introduction, I've already had a very speed response on Pagure to confirm that's what I need to do. I'll post further updates on the Pagure issue / the review request directly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: James Elford
Hi, I'm a long-time user of Fedora, but have yet to contribute. My experience is as a software engineer, and I have a couple of small previous open source contributions (here's[1] my github) - hopefully this will be my first to Fedora. I'd like to take over maintaining the package for brightnessctl[2], which was orphaned a little while ago when the previous maintainer had to step away[3]. I've opened an issue on pagure[4] and mentioned my interest to the brightnessctl maintainers, but I'm not quite sure the process from here. The previous version of the brightnessctl package needs a few updates before it's ready to be re-included - for example I'd like to move it to the latest upstream, and enable the sd-bus integration. I'd very much appreciate any pointers. I've seen the page on orphaned packages[5], and I'm trying to follow the instructions there. I think the next step is to open a Package Review request on bugzilla, including a new spec file - is that right? Thanks, James [1] https://github.com/jelford/ [2] https://github.com/Hummer12007/brightnessctl [3] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TTRKFTADCEHAJSZ55YXIPT3DOZY5RTYW/ [4] https://pagure.io/releng/issue/9067 [5] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy
https://bugzilla.redhat.com/show_bug.cgi?id=1778465 Paul Howarth changed: What|Removed |Added Blocks||1744700 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1744700 [Bug 1744700] [RFE] EPEL8 branch perl-Authen-Passphrase -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778382] [RFE] EPEL-8 branch for perl-HTTP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1778382 Paul Howarth changed: What|Removed |Added Blocks||1778465 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1778465 [Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778463] [RFE] EPEL-8 branch for perl-Data-Float
https://bugzilla.redhat.com/show_bug.cgi?id=1778463 Paul Howarth changed: What|Removed |Added Blocks||1778465 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1778465 [Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy
https://bugzilla.redhat.com/show_bug.cgi?id=1778465 Paul Howarth changed: What|Removed |Added Depends On||1761850, 1778463, 1778382 Doc Type|--- |If docs needed, set a value Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761850 [Bug 1761850] perl-Crypt-Rijndael for EL8 https://bugzilla.redhat.com/show_bug.cgi?id=1778382 [Bug 1778382] [RFE] EPEL-8 branch for perl-HTTP-Lite https://bugzilla.redhat.com/show_bug.cgi?id=1778463 [Bug 1778463] [RFE] EPEL-8 branch for perl-Data-Float -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1761850] perl-Crypt-Rijndael for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761850 Paul Howarth changed: What|Removed |Added Blocks||1778465 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1778465 [Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778465] New: [RFE] EPEL-8 branch for perl-Data-Entropy
https://bugzilla.redhat.com/show_bug.cgi?id=1778465 Bug ID: 1778465 Summary: [RFE] EPEL-8 branch for perl-Data-Entropy Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Data-Entropy Assignee: emman...@seyman.fr Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-de...@lists.fedoraproject.org Target Milestone: --- Classification: Fedora This is needed for perl-Authen-Passphrase (#1744700). -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1778463] New: [RFE] EPEL-8 branch for perl-Data-Float
https://bugzilla.redhat.com/show_bug.cgi?id=1778463 Bug ID: 1778463 Summary: [RFE] EPEL-8 branch for perl-Data-Float Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Data-Float Assignee: ppi...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora This is needed for perl-Data-Entropy and perl-Authen-Passphrase. The current master branch builds cleanly with no additional dependencies required in EPEL-8. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1756036] [RFE] perl-XML-TreePP build for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1756036 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2019-f63526dde7 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f63526dde7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Fedora rawhide compose report: 20191130.n.1 changes
OLD: Fedora-Rawhide-20191129.n.0 NEW: Fedora-Rawhide-20191130.n.1 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 1 Dropped packages:1 Upgraded packages: 91 Downgraded packages: 0 Size of added packages: 8.55 MiB Size of dropped packages:149.12 KiB Size of upgraded packages: 1.93 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 4.08 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20191130.n.1-sda.raw.xz Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20191130.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: gstreamer-0.10.36-25.fc32 Summary: GStreamer streaming media framework runtime RPMs:gstreamer gstreamer-devel gstreamer-devel-docs gstreamer-tools Size:8.55 MiB = DROPPED PACKAGES = Package: libmfx-1.25-4.fc31 Summary: Intel hardware video acceleration dispatcher library RPMs:libmfx libmfx-devel Size:149.12 KiB = UPGRADED PACKAGES = Package: Lmod-8.2.7-1.fc32 Old package: Lmod-8.2.5-1.fc32 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.03 MiB Size change: 1.24 KiB Changelog: * Fri Nov 29 2019 Orion Poplawski - 8.2.6-1 - Update to 8.2.6 * Sat Nov 30 2019 Orion Poplawski - 8.2.7-1 - Update to 8.2.7 Package: ModemManager-1.10.8-1.fc32 Old package: ModemManager-1.10.6-2.fc32 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 10.65 MiB Size change: -31.90 KiB Changelog: * Fri Nov 29 2019 Lubomir Rintel - 1.10.8-1 - Update to 1.10.8 release Package: NetworkManager-1:1.22.0-0.2.fc32 Old package: NetworkManager-1:1.22.0-0.1.fc32 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Added RPMs: NetworkManager-cloud-setup Size: 26.78 MiB Size change: 398.61 KiB Changelog: * Fri Nov 29 2019 Thomas Haller - 1:1.21.0-0.2 - Update to 1.21.90 (1.22-rc1) Package: OpenImageIO-2.0.12-1.fc32 Old package: OpenImageIO-2.0.11-1.fc32 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 34.17 MiB Size change: -198.00 KiB Changelog: * Fri Nov 29 2019 Richard Shaw - 2.0.12-1 - Update to 2.0.12. - Add proper attribution for bundled fmtlib. Package: R-caTools-1.17.1.3-1.fc32 Old package: R-caTools-1.17.1.2-1.fc32 Summary: Tools: moving window statistics, GIF, Base64, ROC AUC, etc. RPMs: R-caTools Size: 1.14 MiB Size change: 871 B Changelog: * Sat Nov 30 2019 Elliott Sales de Andrade - 1.17.1.3-1 - Update to latest version Package: adapt-0.3.4-1.fc32 Old package: adapt-0.3.3-5.fc32 Summary: Mycroft's Adapt Intent Parser RPMs: python3-adapt Size: 43.42 KiB Size change: 57 B Changelog: * Fri Nov 29 2019 Peter Robinson 0.3.4-1 - Update to 0.3.4 Package: alsa-lib-1.2.1.2-1.fc32 Old package: alsa-lib-1.2.1.1-1.fc32 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm Size: 7.16 MiB Size change: 27.75 KiB Changelog: * Fri Nov 29 2019 Jaroslav Kysela - 1.2.1.2-1 - Updated to 1.2.1.2 Package: ansible-lint-4.2.0a1-1.fc32 Old package: ansible-lint-4.1.1a5-1.fc32 Summary: Best practices checker for Ansible RPMs: python3-ansible-lint Size: 89.87 KiB Size change: 134 B Changelog: * Sat Nov 30 2019 Parag Nemade - 4.2.0a1-1 - Update to 4.2.0a1 version (#1776487) Package: apache-commons-dbcp-1.4-28.fc32 Old package: apache-commons-dbcp-1.4-27.fc31 Summary: Apache Commons DataBase Pooling Package RPMs: apache-commons-dbcp apache-commons-dbcp-javadoc Size: 324.63 KiB Size change: -47 B Changelog: * Sat Nov 30 2019 Mat Booth - 1.4-28 - Set compiler source and target to fix FTBFS Package: apache-commons-digester-2.1-14.fc32 Old package: apache-commons-digester-2.1-13.fc31 Summary: XML to Java object mapping module RPMs: apache-commons-digester apache-commons-digester-javadoc Size: 392.50 KiB Size change: 229 B Changelog: * Tue Nov 05 2019 Fabio Valentini - 2.1-14 - Add missing maven compiler source and target overrides. Package: apache-commons-pool-1.6-21.fc32 Old package:
Re: Provisional pyproject RPM macros: Dynamic BuildRequires for Python packages
On Sunday, 01 December 2019 at 00:07, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 30, 2019 at 05:26:14PM +0100, Dominik 'Rathann' Mierzejewski > wrote: [...] > > Two observations: > > > > 1. It actually generates more BRs than I specify manually (I had 3). It > > adds python3-wheel and it brings in python3-pip and python3-pytoml on it > > own, so my package ends up with 4 additional BRs for no apparent gain. > > BR or R? If it just a few additional BR on small python packages, I don't > it matters much. BR and it matters in this case, because it increases the number of BRs by 100%, precisely because it is a small package. It makes the build setup slower, especially on ARM. > > 2. It would be useful if it generated the file list automatically, too. > > I had to drop .egg-info and .dist-info manually. I meant: > > I had to drop .egg-info and *add* .dist-info manually. > That, OTOH, sounds like a bug... Nah. It's just the difference between setup.py and pyproject builds. 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
Fedora-Rawhide-20191130.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 13/161 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191129.n.0): ID: 491398 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/491398 ID: 491399 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/491399 ID: 491411 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/491411 ID: 491422 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/491422 ID: 491424 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/491424 ID: 491426 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/491426 ID: 491435 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/491435 ID: 491437 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/491437 ID: 491440 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/491440 ID: 491454 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/491454 ID: 491523 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/491523 Old failures (same test failed in Fedora-Rawhide-20191129.n.0): ID: 491383 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/491383 ID: 491449 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/491449 ID: 491468 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/491468 Soft failed openQA tests: 10/161 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20191129.n.0): ID: 491377 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/491377 ID: 491378 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/491378 ID: 491442 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/491442 Old soft failures (same test soft failed in Fedora-Rawhide-20191129.n.0): ID: 491386 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/491386 ID: 491461 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/491461 ID: 491491 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/491491 ID: 491492 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/491492 ID: 491524 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/491524 ID: 491540 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/491540 ID: 491541 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/491541 Passed openQA tests: 134/161 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191129.n.0): ID: 491385 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/491385 ID: 491409 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/491409 ID: 491416 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/491416 ID: 491417 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/491417 ID: 491463 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/491463 ID: 491473 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/491473 ID: 491502 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/491502 ID: 491517 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/491517 ID: 491537 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/491537 Skipped gating openQA tests: 1/161 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20191129.n.0): ID: 491397 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/491397 Skipped non-gating openQA
[Bug 1776561] perl-IO-Async-0.75 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1776561 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-IO-Async-0.75-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2019-12-01 09:23:01 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1418593 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1777071] perl-Email-Sender-1.300033 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1777071 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Email-Sender-1.300033- ||1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2019-12-01 09:22:04 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1418595 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Fedora-Cloud-31-20191201.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1778382] [RFE] EPEL-8 branch for perl-HTTP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1778382 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-028e7682c1 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-028e7682c1 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
