Re: Help needed with failing PPC build: cannot find MPI with openmpi
On 10/15/19 1:33 PM, Ankur Sinha wrote: Hi Orion, On Tue, Sep 17, 2019 15:37:57 -0600, Orion Poplawski wrote: I have no idea as I really don't know exactly what --enable-mpi-cxx does. I was surprised that it didn't appear to affect more packages. F30 still seems to suffer from this issue. Any chance the fix could be include there also please? https://koji.fedoraproject.org/koji/taskinfo?taskID=38314982 https://bodhi.fedoraproject.org/updates/FEDORA-2019-497f765fe8 -- 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: Modularity and the system-upgrade path
There seems to be some confusion here as to the use cases of Fedora vs RHEL. What's good for RHEL is not necessarily what's good for Fedora. I'm sorry, but Fedora is not simply a sandbox to test things for RHEL, and that needs to be made clear. I'm comfortable saying that most Fedora users are not installing the distro just to support one specific application, as one might with RHEL or CentOS, but to benefit from the Four Foundations of Fedora, in this case the most important ones being Freedom, Features and First. It'd be great to have a working modular system, but since we don't seem to have that, it's not a good idea to force the broken implementation on users. We need to consider what is best for Fedora's users, not what is best for Red Hat, at least in my opinion. I see no reason that dropping certain parts of Modularity from actual releases of Fedora will harm the relationship with Red Hat, as Stephen suggests. Such tests can, and probably should, be done in Rawhide, until they're actually ready for users. So far, the best approach seems to be to remove default modules, and require a non-modular version for fedora releases and branched. (In addition to whatever packagers would package as modules. To clarify, I am not attempting to suggest nothing should be done with Modularity except in Rawhide.) We're not saying this to discourage you, at least that is not my goal. My goal is to ensure the best result for the end user. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Neal Gompa wrote: > It'd be interesting if an "inverse filter" could be applied. Instead > of modules shadowing non-modular content, the other way around would > occur. That would make it easy to clean that up. And as I pointed out, if the proposal to require a non-modular default version for all packages were implemented, that "inverse filter" would actually only have to be the default for two releases (two to support upgrades skipping one release). Once the users are migrated to the non- modular default versions, the default could be safely changed back to the current filter. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Stephen Gallagher wrote: > On Wed, Oct 16, 2019 at 8:44 PM Neal Gompa wrote: >> It was damaging when it was happening before we have a way to depend >> on modules from non-modular content. It essentially forces other >> packagers to move to modules too. It's a snowball effect. And *right >> now* modularization is a one way road. I'm pleased to hear that we >> will get a way to demodularize, but currently we don't have it. > > That's a fair observation. I can only plead my team's lack of > omnipotence and our willingness to correct our mistakes. You do not need omnipotence to not deploy a change before the contingency plan is ready, only patience. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
Stephen Gallagher wrote: > Not necessarily. It may be that we have to content ourselves with some > software always requiring a module enablement to use it. For example, > I maintain a module for Review Board, a Django-based code review tool. > For complicated reasons, it cannot run against Django newer than 1.6 > (the Review Board upstream maintains the 1.6 stream of Django for > security patches). If we decide that deps of default streams are bound > to the same rules as default streams (or, alternately, Matthew's > proposal of requiring only depending on default streams), then the > necessary outcome is that Review Board can only be available via > non-default stream (since it depends on django:1.6). The user-friendly approach for that is to use a parallel-installable compatibility package (with a suffixed Name, such as django1.6) instead of a module. > There's still a case that you haven't considered, which is things that > work at runtime as a default but cannot *build* against the default > set of packages. For example, we might have packages whose buildsystem > still relies on Python 2 (WAF?) but doesn't require it at runtime. There too, the correct approach is to provide (continue providing) a python2 compatibility package. (Even the python27 one the Python SIG has introduced in Rawhide might be enough, actually.) There is no technical reason for it being in a module. > There might be packages that haven't yet migrated to a new, > backwards-incompatible change to Docbook for generating documentation. > Or packages that only build properly with a newer version of golang > than shipped in that release, or any of a thousand other examples that > are easily solved by build-time-only content and dependencies in > module streams. The preferred solution there is really to fix the package to build with the latest version, which is the way we have always handled such FTBFS issues. But in the worst case, we can just ship the last successful build until the FTBFS is fixed. I think we are giving way too much importance to FTBFS bugs. > Also there are yet other packages (such as in the Go and Rust > ecosystems) that could simply be built once on Rawhide with the latest > compiler and shipped to each of the other releases without needing a > rebuild because they are statically linked. Modules allow this, basic > RPMs not so much. As Neal Gompa hinted at, that is not a good idea because the build will be linked with the Rawhide glibc and, as a result, typically not run on the older releases. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Hi On Wed, Oct 16, 2019 at 9:21 PM Neal Gompa wrote: > On Wed, Oct 16, 2019 at 9:17 PM Stephen Gallagher > wrote: > > > > On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram > wrote: > > If that's the case, the most obvious way to inform you is to disallow > > the upgrade and have you resolve it by doing a `dnf module remove bat` > > and then rerunning the upgrade. > One could do that yes but it is helpful to have dnf essentially offer to do this an option > > When "bat" was non-modular, we didn't require this. Why does it being > a module change this? The underlying RPMs still have their > dependencies satisfied. If they didn't, DNF would elect to offer its > removal as part of the upgrade after passing "--allowerasing". This > behavior is sane, useful, and understandable. I don't see a reason it > wouldn't map cleanly to modular content. > Indeed. Before --allowerasing was implemented by dnf and it gained the feature to suggest that users run it to workaround broken dependencies, one would manually be able to remove the dependencies and unbreak themselves out of that problem and upgrading using yum wiki page did prominently suggest that workaround. Allowerasing was a step up in usability however and I wouldn't want orphaned or broken modules to a hindrance to that. Again, in the case of bat, the underlying breakages was blocking updates for a while till I figured out the right steps. So this isn't merely a theoretical example either Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Stephen Gallagher wrote:
> On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler wrote:
>> So completely disable all module support in DNF by default with some
>> global flag (make all the module code conditional under some new
>> enable_modules flag and default the flag to enable_modules = 0), then it
>> will treat the packages as normal packages and you only have to provide a
>> higher EVR. All this module processing should only happen if the user
>> explicitly enables it.
>
> Given that many of the modules in the distribution currently are there
> specifically to provide newer, less-stable versions of the versions in
> the non-modular/default stream, this would be fairly disastrous. For
> example, Node.js 10.x is the default stream in Fedora 30 because it's
> the LTS branch. It also provides a non-default stream for 8.x (the
> previous LTS branch that a lot of applications still rely on) and
> 12.x, which will be the next LTS branch in November, but is not
> guaranteed stable yet. With the approach you're describing, everyone
> would be forcibly updated to the unstable 12.x release.
>
> The only way we could assure ourselves that this wouldn't happen would
> be to do another mass-rebuild, bumping the epoch of every package that
> exists in a module. That's a lot of work.
So it looks like I did not describe clearly enough what my proposed
enable_modules=0 flag would do. ("Disable all module code" was apparently
too vague.)
How I think it should work would be:
* For repositories, it completely ignores modular metadata and processes
only the non-modular parts of the repository metadata. Therefore, it does
not see the Node.js 12.x stream at all. It only sees whatever Node.js is
in the non-modular repository. If there are currently only modular
versions, then it sees none at all. But with the proposal to require a
non-modular default version, it would then see that version, which would
likely be Node.js 10.x. Nobody would get forcefully upgraded from 10.x to
12.x.
* For installed modules, it completely ignores them, acting as if the
database of installed modules were empty. (It just does not read that
database at all.)
* For installed packages, it treats them all as non-modular. Sure, packages
originally installed from a module have weird EVRs encoding module
metadata, but otherwise they get processed exactly like a non-modular
package. So the default repository only has to provide a newer EVR to
upgrade the package. That should address upgrades from 8.x or 10.x to the
new default 10.x. If the user had previously installed 12.x, they will
only get downgraded if they distro-sync or if package-level dependency
issues with the F30 build of 12.x on F31 force the downgrade.
I hope that clears it up.
>> A slightly more elaborate, but slightly harder to implement, approach
>> would be to let DNF simply disable modules that are enabled locally but
>> no longer available in the repositories, together with disabling the
>> fedora-modular and updates-modular repositories by default.
>
> And again, this only works if every packager who has spent time
> creating a module with a default stream takes their content and shoves
> it back into the non-modular repository. Which in some cases they
> probably cannot do, because they have build-dependencies that are in
> conflict. This is a highly non-trivial process and it would need to be
> done individually for every single package. That's far more
> packager-hostile than fixing the default stream/buildroot problem and
> the upgrade path problem.
You are overestimating by far the effort required to demodularize the
handful packages that are currently module-only. The evidence Fabio
Valentini has gathered so far shows that actually very few packages would be
affected and they would not be too hard to fix. And Miro has also offered
help with fixing affected packages.
All in all, it would require fixing a handful packages once and for all
instead of implementing workarounds affecting the entire distribution and
its thousands of users.
>> And the case of demodularizing packages has to be addressed sooner or
>> later anyway, so better address it sooner rather than later, before more
>> and more damage is done by maintainers moving packages to module-only
>> without a way back.
>
> I've already acknowledged upthread that demodularizing packages is a
> problem we need to solve. It's being worked on, but it's a lot harder
> than you think, because we have failsafe code implemented in libdnf to
> prevent *accidental* demodularization that's in conflict with this
> desire.
And exactly that code needs to go, at least in Fedora. I think having a way
to migrate away from modules is the common case to prioritize here.
That said, it shall be pointed out that, if the proposal to demodularize all
default versions of packages gets implemented, we only need a *short term*
solution for demodularization in DNF. After 2 releases, we have no default
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 9:00 PM Stephen Gallagher wrote: > > On Wed, Oct 16, 2019 at 8:44 PM Neal Gompa wrote: > > > > On Wed, Oct 16, 2019 at 8:27 PM Stephen Gallagher > > wrote: > > > > > > On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler > > > wrote: > > > > > > > > Stephen Gallagher wrote: > > > > > An awful lot of people are repeating this as if it's a solution > > > > > without understanding the existing architecture. Believe it or not, > > > > > attempting to abandon default streams and go back to only non-modular > > > > > content available by default is a lot harder than it sounds (or should > > > > > be, but I noted that we're working on that in another reply elsewhere > > > > > in the thread). There is currently no path to upgrades that would get > > > > > back from the modular versions and the closest we could manage would > > > > > be to rely on the dist-upgrade distro-sync, but in that case we > > > > > *still* need to have DNF recognize that the default stream has changed > > > > > (in this case, been dropped) and handle that accordingly. > > > > > > > > So completely disable all module support in DNF by default with some > > > > global > > > > flag (make all the module code conditional under some new enable_modules > > > > flag and default the flag to enable_modules = 0), then it will treat the > > > > packages as normal packages and you only have to provide a higher EVR. > > > > All > > > > this module processing should only happen if the user explicitly > > > > enables it. > > > > > > > > > > Given that many of the modules in the distribution currently are there > > > specifically to provide newer, less-stable versions of the versions in > > > the non-modular/default stream, this would be fairly disastrous. For > > > example, Node.js 10.x is the default stream in Fedora 30 because it's > > > the LTS branch. It also provides a non-default stream for 8.x (the > > > previous LTS branch that a lot of applications still rely on) and > > > 12.x, which will be the next LTS branch in November, but is not > > > guaranteed stable yet. With the approach you're describing, everyone > > > would be forcibly updated to the unstable 12.x release. > > > > > > The only way we could assure ourselves that this wouldn't happen would > > > be to do another mass-rebuild, bumping the epoch of every package that > > > exists in a module. That's a lot of work. > > > > > > > > > > We could let "dnf distro-sync" take care of it. Rebuilds to remove > > RPMTAG_MODULARITYLABEL from the package headers would be necessary, > > but otherwise nothing else should need to change. > > > > That would still lead to upgrading to the highest NEVRA though. Which > is problematic as I mentioned above. > It'd be interesting if an "inverse filter" could be applied. Instead of modules shadowing non-modular content, the other way around would occur. That would make it easy to clean that up. > > > > A slightly more elaborate, but slightly harder to implement, approach > > > > would > > > > be to let DNF simply disable modules that are enabled locally but no > > > > longer > > > > available in the repositories, together with disabling the > > > > fedora-modular > > > > and updates-modular repositories by default. > > > > > > > > > > And again, this only works if every packager who has spent time > > > creating a module with a default stream takes their content and shoves > > > it back into the non-modular repository. Which in some cases they > > > probably cannot do, because they have build-dependencies that are in > > > conflict. This is a highly non-trivial process and it would need to be > > > done individually for every single package. That's far more > > > packager-hostile than fixing the default stream/buildroot problem and > > > the upgrade path problem. > > > > > > > And the case of demodularizing packages has to be addressed sooner or > > > > later > > > > anyway, so better address it sooner rather than later, before more and > > > > more > > > > damage is done by maintainers moving packages to module-only without a > > > > way > > > > back. > > > > > > > > > > I've already acknowledged upthread that demodularizing packages is a > > > problem we need to solve. It's being worked on, but it's a lot harder > > > than you think, because we have failsafe code implemented in libdnf to > > > prevent *accidental* demodularization that's in conflict with this > > > desire. Also, this paragraph was needlessly antagonistic: moving > > > packages to modules is not "damage". > > > > > > > > > > It was damaging when it was happening before we have a way to depend > > on modules from non-modular content. It essentially forces other > > packagers to move to modules too. It's a snowball effect. And *right > > now* modularization is a one way road. I'm pleased to hear that we > > will get a way to demodularize, but currently we don't have it. > > > > That's a fair observation. I can only plead my team's lack of > omnipotence and our
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 9:17 PM Stephen Gallagher wrote: > > On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram wrote: > > > > > > Stephen Gallagher wrote: > >> > >> > >> Currently, our default stance has been "disallow the system upgrade if > >> the modules they've locked onto won't be available there". This is > >> based on our philosophy that ultimately "the app is what matters". > >> Most people don't install Linux because they enjoy clicking buttons in > >> Anaconda. They install Linux because they have an application they > >> want to deploy > > > > > > You have to consider that not all applications are as important as keeping > > up with the distribution lifecycle itself. If I have Fedora deployed in a > > bunch of places, I need to be able to move to the next release which is > > supported if the current release I am running is nearing EOL. At that > > point, if a module is orphaned and it happens to be a leaf application (say > > the bat utility which is currently provided as a module and one I happen to > > use), I don't really want it blocking my ability to upgrade. I would > > certain like to be informed about the fact but I would want to get to the > > next release anyway. > > > > If that's the case, the most obvious way to inform you is to disallow > the upgrade and have you resolve it by doing a `dnf module remove bat` > and then rerunning the upgrade. When "bat" was non-modular, we didn't require this. Why does it being a module change this? The underlying RPMs still have their dependencies satisfied. If they didn't, DNF would elect to offer its removal as part of the upgrade after passing "--allowerasing". This behavior is sane, useful, and understandable. I don't see a reason it wouldn't map cleanly to modular content. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram wrote: > > > Stephen Gallagher wrote: >> >> >> Currently, our default stance has been "disallow the system upgrade if >> the modules they've locked onto won't be available there". This is >> based on our philosophy that ultimately "the app is what matters". >> Most people don't install Linux because they enjoy clicking buttons in >> Anaconda. They install Linux because they have an application they >> want to deploy > > > You have to consider that not all applications are as important as keeping up > with the distribution lifecycle itself. If I have Fedora deployed in a bunch > of places, I need to be able to move to the next release which is supported > if the current release I am running is nearing EOL. At that point, if a > module is orphaned and it happens to be a leaf application (say the bat > utility which is currently provided as a module and one I happen to use), I > don't really want it blocking my ability to upgrade. I would certain like to > be informed about the fact but I would want to get to the next release anyway. > If that's the case, the most obvious way to inform you is to disallow the upgrade and have you resolve it by doing a `dnf module remove bat` and then rerunning the upgrade. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 8:42 PM Stephen Gallagher wrote: > > On Wed, Oct 16, 2019 at 8:12 PM Kevin Kofler wrote: > > > > Stephen Gallagher wrote: > > > 3) We need to get the policy I described above written onto -stone > > > tablets- the Packaging Guidelines and then we need to go and make any > > > stream that isn't compliant with it a non-default stream. > > > > But then we need a policy that requires a default version (non-modular or at > > least a default stream) to be available. Otherwise we end up with packages > > that are not installable out of the box because they have no default version > > at all. > > > > Not necessarily. It may be that we have to content ourselves with some > software always requiring a module enablement to use it. For example, > I maintain a module for Review Board, a Django-based code review tool. > For complicated reasons, it cannot run against Django newer than 1.6 > (the Review Board upstream maintains the 1.6 stream of Django for > security patches). If we decide that deps of default streams are bound > to the same rules as default streams (or, alternately, Matthew's > proposal of requiring only depending on default streams), then the > necessary outcome is that Review Board can only be available via > non-default stream (since it depends on django:1.6). > > That said, I'm sure that we can come up with ways to make that more > discoverable, but today we have limitations with how DNF is able to do > `search` or `repoquery`... it can only manage this with default or > enabled streams and it doesn't "see" the non-default streams. If we go > this path, I'd want to hear some input (and get some help!) on > improving the discovery experience. > A big chunk of the problem in fixing this will go away once this is merged: https://github.com/rpm-software-management/libdnf/pull/814 > > Matthew Miller wrote: > > > How would this act in the case where a default stream depends on a > > > non-default stream? > > > > From a policy standpoint, that non-default stream then ought to be bound by > > the same rules as default streams. But allowing a default stream to depend > > on a non-default stream paves the way for version conflicts to happen, so I > > am not convinced that it is a good idea to begin with. > > > > With the notable caveat of the example above, I'm willing to accept > this restriction in Fedora. We just need to acknowledge that it *will* > mean that some software we provide is less discoverable. If that's > deemed to be a worthwhile tradeoff, I have no problems with > implementing it. > We need a way for module dependencies to not care of default/non-default and handle this gracefully, even in transitions. > > > (And how would restricting default streams to only be able to depend on > > > default streams change things?) > > > > It would solve the version conflicts issue, so it makes a lot of sense, but > > at that point, why not require the default versions to just be non-modular > > instead? The main argument for using default streams was that they can > > depend on non-default streams of other modules. So if we disallow this > > (which I think makes sense), we may as well disallow default streams > > entirely and simplify things for everyone. (We would just need a short-term > > workaround for the default streams that exist now. The problem would be gone > > in the long run.) > > > > There's still a case that you haven't considered, which is things that > work at runtime as a default but cannot *build* against the default > set of packages. For example, we might have packages whose buildsystem > still relies on Python 2 (WAF?) but doesn't require it at runtime. > There might be packages that haven't yet migrated to a new, > backwards-incompatible change to Docbook for generating documentation. > Or packages that only build properly with a newer version of golang > than shipped in that release, or any of a thousand other examples that > are easily solved by build-time-only content and dependencies in > module streams. > > Also there are yet other packages (such as in the Go and Rust > ecosystems) that could simply be built once on Rawhide with the latest > compiler and shipped to each of the other releases without needing a > rebuild because they are statically linked. Modules allow this, basic > RPMs not so much. > This is actually not true. Every language stack we have does some degree of dynamic linking, even if it's only to glibc. The *only* reason we don't allow non-modular RPMs to be built once in rawhide and shipped to all releases without a rebuild is purely policy. We can mechanically do that since Koji lets you multi-tag RPMs into multiple collections. > So even if we eliminate the version conflicts issue by restricting > what comprises a default stream, there are other benefits to module > default streams. Ehh... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list --
Re: Modularity and the system-upgrade path
Stephen Gallagher wrote: > > Currently, our default stance has been "disallow the system upgrade if > the modules they've locked onto won't be available there". This is > based on our philosophy that ultimately "the app is what matters". > Most people don't install Linux because they enjoy clicking buttons in > Anaconda. They install Linux because they have an application they > want to deploy > You have to consider that not all applications are as important as keeping up with the distribution lifecycle itself. If I have Fedora deployed in a bunch of places, I need to be able to move to the next release which is supported if the current release I am running is nearing EOL. At that point, if a module is orphaned and it happens to be a leaf application (say the bat utility which is currently provided as a module and one I happen to use), I don't really want it blocking my ability to upgrade. I would certain like to be informed about the fact but I would want to get to the next release anyway. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 8:44 PM Neal Gompa wrote: > > On Wed, Oct 16, 2019 at 8:27 PM Stephen Gallagher wrote: > > > > On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler wrote: > > > > > > Stephen Gallagher wrote: > > > > An awful lot of people are repeating this as if it's a solution > > > > without understanding the existing architecture. Believe it or not, > > > > attempting to abandon default streams and go back to only non-modular > > > > content available by default is a lot harder than it sounds (or should > > > > be, but I noted that we're working on that in another reply elsewhere > > > > in the thread). There is currently no path to upgrades that would get > > > > back from the modular versions and the closest we could manage would > > > > be to rely on the dist-upgrade distro-sync, but in that case we > > > > *still* need to have DNF recognize that the default stream has changed > > > > (in this case, been dropped) and handle that accordingly. > > > > > > So completely disable all module support in DNF by default with some > > > global > > > flag (make all the module code conditional under some new enable_modules > > > flag and default the flag to enable_modules = 0), then it will treat the > > > packages as normal packages and you only have to provide a higher EVR. All > > > this module processing should only happen if the user explicitly enables > > > it. > > > > > > > Given that many of the modules in the distribution currently are there > > specifically to provide newer, less-stable versions of the versions in > > the non-modular/default stream, this would be fairly disastrous. For > > example, Node.js 10.x is the default stream in Fedora 30 because it's > > the LTS branch. It also provides a non-default stream for 8.x (the > > previous LTS branch that a lot of applications still rely on) and > > 12.x, which will be the next LTS branch in November, but is not > > guaranteed stable yet. With the approach you're describing, everyone > > would be forcibly updated to the unstable 12.x release. > > > > The only way we could assure ourselves that this wouldn't happen would > > be to do another mass-rebuild, bumping the epoch of every package that > > exists in a module. That's a lot of work. > > > > > > We could let "dnf distro-sync" take care of it. Rebuilds to remove > RPMTAG_MODULARITYLABEL from the package headers would be necessary, > but otherwise nothing else should need to change. > That would still lead to upgrading to the highest NEVRA though. Which is problematic as I mentioned above. > > > A slightly more elaborate, but slightly harder to implement, approach > > > would > > > be to let DNF simply disable modules that are enabled locally but no > > > longer > > > available in the repositories, together with disabling the fedora-modular > > > and updates-modular repositories by default. > > > > > > > And again, this only works if every packager who has spent time > > creating a module with a default stream takes their content and shoves > > it back into the non-modular repository. Which in some cases they > > probably cannot do, because they have build-dependencies that are in > > conflict. This is a highly non-trivial process and it would need to be > > done individually for every single package. That's far more > > packager-hostile than fixing the default stream/buildroot problem and > > the upgrade path problem. > > > > > And the case of demodularizing packages has to be addressed sooner or > > > later > > > anyway, so better address it sooner rather than later, before more and > > > more > > > damage is done by maintainers moving packages to module-only without a way > > > back. > > > > > > > I've already acknowledged upthread that demodularizing packages is a > > problem we need to solve. It's being worked on, but it's a lot harder > > than you think, because we have failsafe code implemented in libdnf to > > prevent *accidental* demodularization that's in conflict with this > > desire. Also, this paragraph was needlessly antagonistic: moving > > packages to modules is not "damage". > > > > > > It was damaging when it was happening before we have a way to depend > on modules from non-modular content. It essentially forces other > packagers to move to modules too. It's a snowball effect. And *right > now* modularization is a one way road. I'm pleased to hear that we > will get a way to demodularize, but currently we don't have it. > That's a fair observation. I can only plead my team's lack of omnipotence and our willingness to correct our mistakes. > > > > I started this discussion to ask the community to help us identify the > > > > best path *forward*. An endless barrage of "kill it off" replies is > > > > not helpful or productive. If anyone has specific advice on how to > > > > move forward (or, indeed, if you can figure out how to migrate back > > > > without considerable release engineering and packager effort), that > > > > would be productive. Just please keep in
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 8:27 PM Stephen Gallagher wrote: > > On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler wrote: > > > > Stephen Gallagher wrote: > > > An awful lot of people are repeating this as if it's a solution > > > without understanding the existing architecture. Believe it or not, > > > attempting to abandon default streams and go back to only non-modular > > > content available by default is a lot harder than it sounds (or should > > > be, but I noted that we're working on that in another reply elsewhere > > > in the thread). There is currently no path to upgrades that would get > > > back from the modular versions and the closest we could manage would > > > be to rely on the dist-upgrade distro-sync, but in that case we > > > *still* need to have DNF recognize that the default stream has changed > > > (in this case, been dropped) and handle that accordingly. > > > > So completely disable all module support in DNF by default with some global > > flag (make all the module code conditional under some new enable_modules > > flag and default the flag to enable_modules = 0), then it will treat the > > packages as normal packages and you only have to provide a higher EVR. All > > this module processing should only happen if the user explicitly enables it. > > > > Given that many of the modules in the distribution currently are there > specifically to provide newer, less-stable versions of the versions in > the non-modular/default stream, this would be fairly disastrous. For > example, Node.js 10.x is the default stream in Fedora 30 because it's > the LTS branch. It also provides a non-default stream for 8.x (the > previous LTS branch that a lot of applications still rely on) and > 12.x, which will be the next LTS branch in November, but is not > guaranteed stable yet. With the approach you're describing, everyone > would be forcibly updated to the unstable 12.x release. > > The only way we could assure ourselves that this wouldn't happen would > be to do another mass-rebuild, bumping the epoch of every package that > exists in a module. That's a lot of work. > > We could let "dnf distro-sync" take care of it. Rebuilds to remove RPMTAG_MODULARITYLABEL from the package headers would be necessary, but otherwise nothing else should need to change. > > A slightly more elaborate, but slightly harder to implement, approach would > > be to let DNF simply disable modules that are enabled locally but no longer > > available in the repositories, together with disabling the fedora-modular > > and updates-modular repositories by default. > > > > And again, this only works if every packager who has spent time > creating a module with a default stream takes their content and shoves > it back into the non-modular repository. Which in some cases they > probably cannot do, because they have build-dependencies that are in > conflict. This is a highly non-trivial process and it would need to be > done individually for every single package. That's far more > packager-hostile than fixing the default stream/buildroot problem and > the upgrade path problem. > > > And the case of demodularizing packages has to be addressed sooner or later > > anyway, so better address it sooner rather than later, before more and more > > damage is done by maintainers moving packages to module-only without a way > > back. > > > > I've already acknowledged upthread that demodularizing packages is a > problem we need to solve. It's being worked on, but it's a lot harder > than you think, because we have failsafe code implemented in libdnf to > prevent *accidental* demodularization that's in conflict with this > desire. Also, this paragraph was needlessly antagonistic: moving > packages to modules is not "damage". > > It was damaging when it was happening before we have a way to depend on modules from non-modular content. It essentially forces other packagers to move to modules too. It's a snowball effect. And *right now* modularization is a one way road. I'm pleased to hear that we will get a way to demodularize, but currently we don't have it. > > > I started this discussion to ask the community to help us identify the > > > best path *forward*. An endless barrage of "kill it off" replies is > > > not helpful or productive. If anyone has specific advice on how to > > > move forward (or, indeed, if you can figure out how to migrate back > > > without considerable release engineering and packager effort), that > > > would be productive. Just please keep in mind that we have to go to > > > war with the army we have, not the one we wish we had. > > > > If you are standing in front of a cliff, moving forward is just not the > > answer. Not all changes are improvements. Sometimes, you have to realize > > that you made a mistake and move back before things only get worse. > > > > Sure, but we are nowhere near a cliff. As I just posted in the Change > Proposal thread, there are three problems we need to solve, two of > which we already have
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 8:12 PM Kevin Kofler wrote: > > Stephen Gallagher wrote: > > 3) We need to get the policy I described above written onto -stone > > tablets- the Packaging Guidelines and then we need to go and make any > > stream that isn't compliant with it a non-default stream. > > But then we need a policy that requires a default version (non-modular or at > least a default stream) to be available. Otherwise we end up with packages > that are not installable out of the box because they have no default version > at all. > Not necessarily. It may be that we have to content ourselves with some software always requiring a module enablement to use it. For example, I maintain a module for Review Board, a Django-based code review tool. For complicated reasons, it cannot run against Django newer than 1.6 (the Review Board upstream maintains the 1.6 stream of Django for security patches). If we decide that deps of default streams are bound to the same rules as default streams (or, alternately, Matthew's proposal of requiring only depending on default streams), then the necessary outcome is that Review Board can only be available via non-default stream (since it depends on django:1.6). That said, I'm sure that we can come up with ways to make that more discoverable, but today we have limitations with how DNF is able to do `search` or `repoquery`... it can only manage this with default or enabled streams and it doesn't "see" the non-default streams. If we go this path, I'd want to hear some input (and get some help!) on improving the discovery experience. > Matthew Miller wrote: > > How would this act in the case where a default stream depends on a > > non-default stream? > > From a policy standpoint, that non-default stream then ought to be bound by > the same rules as default streams. But allowing a default stream to depend > on a non-default stream paves the way for version conflicts to happen, so I > am not convinced that it is a good idea to begin with. > With the notable caveat of the example above, I'm willing to accept this restriction in Fedora. We just need to acknowledge that it *will* mean that some software we provide is less discoverable. If that's deemed to be a worthwhile tradeoff, I have no problems with implementing it. > > (And how would restricting default streams to only be able to depend on > > default streams change things?) > > It would solve the version conflicts issue, so it makes a lot of sense, but > at that point, why not require the default versions to just be non-modular > instead? The main argument for using default streams was that they can > depend on non-default streams of other modules. So if we disallow this > (which I think makes sense), we may as well disallow default streams > entirely and simplify things for everyone. (We would just need a short-term > workaround for the default streams that exist now. The problem would be gone > in the long run.) > There's still a case that you haven't considered, which is things that work at runtime as a default but cannot *build* against the default set of packages. For example, we might have packages whose buildsystem still relies on Python 2 (WAF?) but doesn't require it at runtime. There might be packages that haven't yet migrated to a new, backwards-incompatible change to Docbook for generating documentation. Or packages that only build properly with a newer version of golang than shipped in that release, or any of a thousand other examples that are easily solved by build-time-only content and dependencies in module streams. Also there are yet other packages (such as in the Go and Rust ecosystems) that could simply be built once on Rawhide with the latest compiler and shipped to each of the other releases without needing a rebuild because they are statically linked. Modules allow this, basic RPMs not so much. So even if we eliminate the version conflicts issue by restricting what comprises a default stream, there are other benefits to module default streams. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler wrote: > > Stephen Gallagher wrote: > > An awful lot of people are repeating this as if it's a solution > > without understanding the existing architecture. Believe it or not, > > attempting to abandon default streams and go back to only non-modular > > content available by default is a lot harder than it sounds (or should > > be, but I noted that we're working on that in another reply elsewhere > > in the thread). There is currently no path to upgrades that would get > > back from the modular versions and the closest we could manage would > > be to rely on the dist-upgrade distro-sync, but in that case we > > *still* need to have DNF recognize that the default stream has changed > > (in this case, been dropped) and handle that accordingly. > > So completely disable all module support in DNF by default with some global > flag (make all the module code conditional under some new enable_modules > flag and default the flag to enable_modules = 0), then it will treat the > packages as normal packages and you only have to provide a higher EVR. All > this module processing should only happen if the user explicitly enables it. > Given that many of the modules in the distribution currently are there specifically to provide newer, less-stable versions of the versions in the non-modular/default stream, this would be fairly disastrous. For example, Node.js 10.x is the default stream in Fedora 30 because it's the LTS branch. It also provides a non-default stream for 8.x (the previous LTS branch that a lot of applications still rely on) and 12.x, which will be the next LTS branch in November, but is not guaranteed stable yet. With the approach you're describing, everyone would be forcibly updated to the unstable 12.x release. The only way we could assure ourselves that this wouldn't happen would be to do another mass-rebuild, bumping the epoch of every package that exists in a module. That's a lot of work. > A slightly more elaborate, but slightly harder to implement, approach would > be to let DNF simply disable modules that are enabled locally but no longer > available in the repositories, together with disabling the fedora-modular > and updates-modular repositories by default. > And again, this only works if every packager who has spent time creating a module with a default stream takes their content and shoves it back into the non-modular repository. Which in some cases they probably cannot do, because they have build-dependencies that are in conflict. This is a highly non-trivial process and it would need to be done individually for every single package. That's far more packager-hostile than fixing the default stream/buildroot problem and the upgrade path problem. > And the case of demodularizing packages has to be addressed sooner or later > anyway, so better address it sooner rather than later, before more and more > damage is done by maintainers moving packages to module-only without a way > back. > I've already acknowledged upthread that demodularizing packages is a problem we need to solve. It's being worked on, but it's a lot harder than you think, because we have failsafe code implemented in libdnf to prevent *accidental* demodularization that's in conflict with this desire. Also, this paragraph was needlessly antagonistic: moving packages to modules is not "damage". > > I started this discussion to ask the community to help us identify the > > best path *forward*. An endless barrage of "kill it off" replies is > > not helpful or productive. If anyone has specific advice on how to > > move forward (or, indeed, if you can figure out how to migrate back > > without considerable release engineering and packager effort), that > > would be productive. Just please keep in mind that we have to go to > > war with the army we have, not the one we wish we had. > > If you are standing in front of a cliff, moving forward is just not the > answer. Not all changes are improvements. Sometimes, you have to realize > that you made a mistake and move back before things only get worse. > Sure, but we are nowhere near a cliff. As I just posted in the Change Proposal thread, there are three problems we need to solve, two of which we already have solutions designed for and one (this thread) that we are trying to finalize. That's far from "standing in front of a cliff". Please understand that "I don't understand how this works" is not the same thing as "This doesn't work". > The overwhelmingly negative feedback that you are getting is a clear > indication that something is wrong. You should not ignore it or summarily > file it off as luddites wanting to return to the past. There are real issues > with modules, and the Modularity WG is only offering partial workarounds > (adding more and more complexity) and no real fixes. > So, literally every word of this is wrong. The negative feedback is not "overwhelming". It is approximately four noisy individuals, all of whom have
Re: Recommending proprietary software in Fedora
mcatanz...@gnome.org wrote: > I think you're probably right that people mainly want Chrome for the > multimedia support. But well, surely you are well aware that we'll > never be able to point to the rpmfusion codecs packages in any official > location. I know it's very frustrating, but the legal team is just > trying to protect Red Hat (and Fedora). It would be helpful to please > keep your argumentation within the realm of the legal constraints we > have to respect. So leave the task of informing users to people who are able to tell them the true story instead of misleadingly offering them only a proprietary alternative because it is the only one your lawyers let you tell them about. I shall also note that, according to the FSF statements about GPL/LGPL and patents, any patent license Google may have obtained for Chrome is likely incompatible with the LGPL license on the FFmpeg code they are using to implement the patented codecs, which would imply that Chrome would necessarily be in violation of either the patents or the FFmpeg copyright license. We just have no way to tell which is the case because Google's patent arrangements are obviously not public. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
Stephen Gallagher wrote: > 3) We need to get the policy I described above written onto -stone > tablets- the Packaging Guidelines and then we need to go and make any > stream that isn't compliant with it a non-default stream. But then we need a policy that requires a default version (non-modular or at least a default stream) to be available. Otherwise we end up with packages that are not installable out of the box because they have no default version at all. Matthew Miller wrote: > How would this act in the case where a default stream depends on a > non-default stream? From a policy standpoint, that non-default stream then ought to be bound by the same rules as default streams. But allowing a default stream to depend on a non-default stream paves the way for version conflicts to happen, so I am not convinced that it is a good idea to begin with. > (And how would restricting default streams to only be able to depend on > default streams change things?) It would solve the version conflicts issue, so it makes a lot of sense, but at that point, why not require the default versions to just be non-modular instead? The main argument for using default streams was that they can depend on non-default streams of other modules. So if we disallow this (which I think makes sense), we may as well disallow default streams entirely and simplify things for everyone. (We would just need a short-term workaround for the default streams that exist now. The problem would be gone in the long run.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Stephen Gallagher wrote: > An awful lot of people are repeating this as if it's a solution > without understanding the existing architecture. Believe it or not, > attempting to abandon default streams and go back to only non-modular > content available by default is a lot harder than it sounds (or should > be, but I noted that we're working on that in another reply elsewhere > in the thread). There is currently no path to upgrades that would get > back from the modular versions and the closest we could manage would > be to rely on the dist-upgrade distro-sync, but in that case we > *still* need to have DNF recognize that the default stream has changed > (in this case, been dropped) and handle that accordingly. So completely disable all module support in DNF by default with some global flag (make all the module code conditional under some new enable_modules flag and default the flag to enable_modules = 0), then it will treat the packages as normal packages and you only have to provide a higher EVR. All this module processing should only happen if the user explicitly enables it. A slightly more elaborate, but slightly harder to implement, approach would be to let DNF simply disable modules that are enabled locally but no longer available in the repositories, together with disabling the fedora-modular and updates-modular repositories by default. And the case of demodularizing packages has to be addressed sooner or later anyway, so better address it sooner rather than later, before more and more damage is done by maintainers moving packages to module-only without a way back. > I started this discussion to ask the community to help us identify the > best path *forward*. An endless barrage of "kill it off" replies is > not helpful or productive. If anyone has specific advice on how to > move forward (or, indeed, if you can figure out how to migrate back > without considerable release engineering and packager effort), that > would be productive. Just please keep in mind that we have to go to > war with the army we have, not the one we wish we had. If you are standing in front of a cliff, moving forward is just not the answer. Not all changes are improvements. Sometimes, you have to realize that you made a mistake and move back before things only get worse. The overwhelmingly negative feedback that you are getting is a clear indication that something is wrong. You should not ignore it or summarily file it off as luddites wanting to return to the past. There are real issues with modules, and the Modularity WG is only offering partial workarounds (adding more and more complexity) and no real fixes. I have provided above 2 possible approaches to address the "migrating back" issue. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
Alexander Bokovoy wrote: > You are mixing up parallel availability and parallel installability. > These aren't the same. Modularity does solve parallel availability > problem. It was never designed to solve parallel installability problem. … which is exactly why it causes version hell. > I don't think it is not only reasonable to have this requirement but it > is also detrimental to the project to have the requirement that > basically doubles the amount of work volunteers have to do. Merging the modular specfile into the non-modular branches (with a fast- forward merge) is almost no work (it takes only seconds). If, for whatever reason, there need to be specfile differences between the modular and the non-modular versions, they can be handled with %if conditionals. > Simply providing content of default modules in non-modular way ignores the > fact that you somehow need to be able to rebuild those packages and they > might depend in their build dependencies on packages from other modules, > including non-default streams. The default version of a package should NEVER depend on a non-default version of another package. That is just a recipe for version hell. If you really cannot fix your package to build with the default version of some other package foo, then you should package the version N you need as a fooN compatibility package (where at least the runtime MUST be parallel- installable with the default foo, and the -devel parts SHOULD if possible), not as a module. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wednesday, October 16, 2019 2:30:21 PM MST Matthew Miller wrote: > On Wed, Oct 16, 2019 at 04:30:32PM -0400, Stephen Gallagher wrote: > > > The idea is that it would act exactly the same way that dnf on the > > local system would act: if you builddep software from a stream that > > requires a non-default stream, it would enable that non-default > > stream. > > > Ah, I see. Thanks! > > > > > (And how would restricting default streams to only be able to depend on > > > default streams change things?) > > > > There wouldn't need to be a behavior change; this is all done at the > > libdnf layer; it just means that there is less available software in > > the buildroot (since we'd necessarily have to exclude anything that > > would conflict). > > > I still see "non default stream enabled by default stream" to be surprising > behavior we should avoid. But perhaps I am making too big a hammer of it. > :) > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Realistically, I believe that default streams themselves are something we should avoid, if the cost is low, and it is. There are many users, probably the vast majority of users, that don't use Modularity. It's great to have the option available, but to force it upon them is really unfortunate. Additionally, wouldn't a "default module" pulling in a "non-default module" cause mass breakage? I can only see that causing ABI breakage.. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762510] Please build perl-Any-URI-Escape in normal EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762510 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-6c0e6c1ed5 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c0e6c1ed5 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 04:30:32PM -0400, Stephen Gallagher wrote: > The idea is that it would act exactly the same way that dnf on the > local system would act: if you builddep software from a stream that > requires a non-default stream, it would enable that non-default > stream. Ah, I see. Thanks! > > (And how would restricting default streams to only be able to depend on > > default streams change things?) > There wouldn't need to be a behavior change; this is all done at the > libdnf layer; it just means that there is less available software in > the buildroot (since we'd necessarily have to exclude anything that > would conflict). I still see "non default stream enabled by default stream" to be surprising behavior we should avoid. But perhaps I am making too big a hammer of it. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762510] Please build perl-Any-URI-Escape in normal EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762510 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanuel Seyman --- master builds on epel8 without issue. https://pagure.io/releng/fedora-scm-requests/issue/18432 https://pagure.io/releng/fedora-scm-requests/issue/18433 -- 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 1762510] New: Please build perl-Any-URI-Escape in normal EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762510 Bug ID: 1762510 Summary: Please build perl-Any-URI-Escape in normal EPEL8 Product: Fedora EPEL Version: epel7 Status: NEW Component: perl-Any-URI-Escape Assignee: emman...@seyman.fr Reporter: tdaw...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Please build perl-Any-URI-Escape in EPEL8 -- 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
[389-devel] please review: PR 50656 - access log etime is not properly formatted
https://pagure.io/389-ds-base/pull-request/50656 -- 389 Directory Server Development Team ___ 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: proposal to allow on-demand side tags in F32+
On Wed, Oct 16, 2019 at 10:49:29AM -0700, Kevin Fenzi wrote: > On Wed, Oct 16, 2019 at 10:02:12AM +, Zbigniew Jędrzejewski-Szmek wrote: > > I submitted a Change for wrangling today, but I'm also putting it here > > for discussion: > > https://fedoraproject.org/wiki/Changes/OnDemandSideTags > > > > This is intended to be an alternative to modularity, in the sense > > that it allows some rpms to be built against older or newer versions > > of dependencies, but the details of this process are invisible for > > end users, who get only normal rpms. > > > > The text is too long to paste here, so please take a look on the wiki. > > I'm especially interested in feedback if this would work for *your* > > use case and make *your* life easier. I think we're talking about two different things here. The proposal is to allow the buildroot to be arranged in some specific way, but does not say whether the stuff that is built will be *correct*. E.g., as you say below, if the built rpm has a dependency that cannot be satisfied, the rpm will not be installable. This is where gating comes in. I think rawhide gating would an excellent way to verity that the rpm is *correct*, but it is outside of scope of the proposal. But let's compare it with two scenarios: a) I build an rpm (non-modular) right now, and I declare a Requires: that cannot be satisfied. End result: an rpm that FTI. b) I build an rpm as part of a module, but it requires some old version of the library. End result: an rpm that FTI. Of course with modules the situation is more complicated, because the module might try to bring in the rpm with some old library, but that causes problems and is currently forbidden, because this breaks other packages. c) I build an rpm in a side tag with older packages pulled in. If this results in installation-time dependencies on those packages, FTI. So there really isn't much difference with the proposal: the packager still needs to make sure that the resulting rpms are installable. The proposal makes it easy to pull older rpms during build, solving *part* of the "too fast, too slow" problem. If older versions they are also necessary for installation, compat package would need to be used. > So... this is rawhide multibuild gating with some more stuff on top of > it, unless I am misreading? (ie, much of this is already being > implemented as part of that). And the stuff on top has to do with > modules interaction. > > I don't understand how the 'newer or older' builds would work though. > > Say I built my rawhide foo stack against openssl-100. I merge it back, > either it doesn't merge openssl-100 and all my foo that links against it > is broken, or it does and it conflicts with the existing openssl version > and breaks everything else. Or are you assuming no runtime older/newer? > How is that checked? I guess if we have tests for it, gating could stop > it. > > This is pretty much exactly how multibuild rawhide gating will work > (very soon now!) Yes, that is excellent news, in the scope of this proposal and also independently of it. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 2:41 PM Matthew Miller wrote: > > On Wed, Oct 16, 2019 at 01:28:37PM -0400, Stephen Gallagher wrote: > > 1) This will be solved by the new Koji/MBS feature that we've > > codenamed "Ursa Prime" (as a replacement for the original "Ursa Major" > > tool that was built for RHEL 8). Unlike its predecessor, it requires > > no additional daemon service running to handle things. We will create > > a buildroot compose for each release that is created from the set of > > packages available from all of the default streams and both Koji (in > > infra) and mock (on packager systems) will be able to consume this. > > Koji will behave the same as mock, where it will rely on libdnf's > > default module stream handling to populate the buildroot, so we won't > > have to worry about disparities between the local and infrastructure > > packager experiences. > > How would this act in the case where a default stream depends on a > non-default stream? > The idea is that it would act exactly the same way that dnf on the local system would act: if you builddep software from a stream that requires a non-default stream, it would enable that non-default stream. > (And how would restricting default streams to only be able to depend on > default streams change things?) There wouldn't need to be a behavior change; this is all done at the libdnf layer; it just means that there is less available software in the buildroot (since we'd necessarily have to exclude anything that would conflict). ___ 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 1761845] perl-Cache-Memcached for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761845 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-b698c2cae3 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b698c2cae3 -- 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 1761856] perl-HTML-Template for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761856 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org --- Comment #2 from Paul Howarth --- I'm doing 'perl(IPC::SharedCache)' at the moment. You'll need to raise a separate bug for perl-GTop, which is Jitka's package. It seems to build cleanly with no further dependencies needed. -- 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
[389-devel] Re: Should stopping the server interrupt an import job?
> On 16 Oct 2019, at 00:27, Mark Reynolds wrote: > > > On 10/14/19 11:13 PM, William Brown wrote: >> >>> On 15 Oct 2019, at 15:51, Mark Reynolds wrote: >>> >>> >>> On 10/14/19 6:35 PM, William Brown wrote: > On 15 Oct 2019, at 06:58, Mark Reynolds wrote: > > So we are finding these race conditions (leading to heap-use-after-free) > when you stop the server while an import task is running. The current > code aborts the task which leaves the database unusable until it is fully > reinitialized at a later time. Unfortunately the code that handles this > is complex, and very error prone. > > I'd like to allow the import task to complete before fully shutting the > server down. Code fix is trivial, but do we want the import to finish, > or should the import be aborted (and database left broken)? Thoughts? > Opinions? The question is "what does the admin expect"? I could envisage if you start an import and then cancel the task, you expect: * The task to be immediately stopped * The db content rolled back. Shouldn't we be in a betxn or similar during an import so we can revert? Failing this, I'd assume the user would expect a ctrl-c to immediately cancel the task. What kind of use-after-frees are we seeing? >>> See >>> >>> https://pagure.io/389-ds-base/issue/50646 >>> >>> Pretty sure the first thing the import does is delete the db directory, but >>> I have not found that in the code yet, but there are definitely no >>> transactions used during an "import". It's a very different process. Now >>> rolling back the database would be nice, but I can imagine very large >>> databases(100+ million entries) where disk space could be an issue if you >>> have to keep the old database around until the new one is imported. >>> >>> As for aborting, currently there is no abort mechanism except for stopping >>> the server. So a ctrl-C is not really an option at this time. Keep in >>> mind I can still easily keep the current abort behavior during a shutdown, >>> but in the current design if you abort an import the database is hosed. >> What about at least hosing it but nicely somehow? So we rm db, then we >> start the import into some temp location, so on ctrl-c even if we crash, db >> is an empty dir and still mildly hosed? >> >> I can see your point though about the db size stuff. So I guess my thinking >> then is: >> >> * Could we just fix the use after free *and* make the db hosing nicer >> somehow? > I can fix the use-after-free, that's easy, but fixing the "hosing" is not > trivial, and it is out of the scope of what I am trying to do in 1.3.x. fair >> * What happens if we ignore the ctrl-c and just block on import? I think >> someone would reach for ctrl+\ pretty fast ... > The import code launches a thread to the do the work. So hitting control-C > on a CLI tool will not stop the import, and there is currently no abort > process for Slapi Tasks that I am aware of besides creating a new "Abort > Import" task. This is something we could do in 1.4.3, or 1.5.x along with > the new backend work. Yeah, that seems like the possible solution to have each thread check periodically for a cancel signal in it's work loop? >> >> >> > Thanks, > > Mark > > -- > > 389 Directory Server Development Team > ___ > 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 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 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 >>> -- >>> >>> 389 Directory Server Development Team >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> > -- > > 389 Directory Server Development Team — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[Bug 1762261] [RFE] EPEL8 branch of perl-Module-Runtime-Conflicts
https://bugzilla.redhat.com/show_bug.cgi?id=1762261 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-c4da423c9b has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c4da423c9b -- 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 1762253] perl-Moo for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762253 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-ad33471a82 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ad33471a82 -- 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 1761860] perl-String-Random for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761860 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-2fd74f43b8 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2fd74f43b8 -- 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 1761854] perl-FCGI-ProcManager for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761854 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-a0e7ec5fd0 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-a0e7ec5fd0 -- 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: Recommending proprietary software in Fedora
On Wed, Oct 16, 2019 at 07:10:11PM -, Leigh Scott wrote: > > Yes; Leigh, let's please refrain from name calling. I often disagree with > > John, but I don't think he's acting in bad faith here (or in Fedora in > > general). > Did I manage to earn another misconduct badge for that? ;-) I hope there's no badges. :) As the Code of Conduct says, "Don’t forget that it is human to err ..." I appreciate your on-list apology! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
> On Tue, Oct 15, 2019 at 09:01:31PM -0700, John M. Harris Jr wrote: > > Yes; Leigh, let's please refrain from name calling. I often disagree with > John, but I don't think he's acting in bad faith here (or in Fedora in > general). Did I manage to earn another misconduct badge for that? ;-) ___ 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: Recommending proprietary software in Fedora
> On Tuesday, October 15, 2019 8:59:18 PM MST Leigh Scott wrote: > > I am not a troll, and I definitely am listening. I read the third party > software guidelines very carefully, on both the FESCo page, and the > Workstation Group's page. Sorry for mislabeling you :-) Fedora only provides the repo's to install some limited thirdparty apps, these are disabled by default. There aren't any usable replacements the nvidia driver or steam packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 2:56 PM Matthew Miller wrote: > > On Wed, Oct 16, 2019 at 01:32:49PM -0400, Stephen Gallagher wrote: > > remove it" or something like that. It should never be used in the > > general case. Not even for "This is so old we should force upgrades". > > For that we should just drop the stream entirely from the next > > release, which would result in the upgrade being impossible until the > > user took a manual action to get off that stream. > > What might that look like from a UX perspective? What about from GNOME > Software? Given that this should *almost never* happen, I'd avoid going to great lengths to build UX around it. I think it should basically just *happen* as part of the update process. I want to repeat: this should only be used if we have absolutely no other choice. I'd say the most UX we should do is actually in CI: we should disallow a module update to be pushed with this attribute set without an override. ___ 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: [Ambassadors] FOSDEM
On Wed, Oct 16, 2019 at 06:22:52PM +0200, Brian (bex) Exelbierd wrote: > I haven't heard anyone mention FOSDEM yet. Booth applications are due soon > and I'd like to see us coordinate again with our friends in CentOS. Is > there anyone interested in owning this? If so, can you put together a > proposal for Mindshare? I am likely to be at FOSDEM, but I have a GNOME adboard meeting plus based on experience will be wiped out from DevConf.cz, so I can't own or lead the proposal. Happy to work with and support, though. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 01:32:49PM -0400, Stephen Gallagher wrote: > remove it" or something like that. It should never be used in the > general case. Not even for "This is so old we should force upgrades". > For that we should just drop the stream entirely from the next > release, which would result in the upgrade being impossible until the > user took a manual action to get off that stream. What might that look like from a UX perspective? What about from GNOME Software? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
On Wed, Oct 16, 2019 at 02:33:41PM -0400, Matthew Miller wrote: > This isn't a settled question in Fedora, and it's one that people feel very > passionate about in both sides. In the end, we decided that allowing the > experiment was worthwhile _as a means to the eventual end_. This is why > there's a section about free and open source software in the third party > policy, and why it includes the line "Wherever available, free and open > source alternatives are listed and users are encouraged to prefer these to > their restricted counterparts." ... and this should go without saying but it doesn't hurt to say it: Fedora is always going to be a free and open source software project, and we're not producing a distribution which includes proprietary software (with the exception of the firmware exception we've had for basically forever). Nothing around that is changing and I can't imagine it changing. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
https://bugzilla.redhat.com/show_bug.cgi?id=1744690 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|rc040...@freenet.de |emman...@seyman.fr --- Comment #3 from Emmanuel Seyman --- I'll take this off Ralf's hands since he doesn't want to maintain epel branches. -- 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 1762449] perl-Type-Tiny for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762449 Emmanuel Seyman changed: What|Removed |Added Blocks||1744709 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1744709 [Bug 1744709] [RFE] EPEL8 branch of perl-FCGI-Client -- 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 1762253] perl-Moo for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762253 Emmanuel Seyman changed: What|Removed |Added Blocks||1744709 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1744709 [Bug 1744709] [RFE] EPEL8 branch of perl-FCGI-Client -- 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 1744709] [RFE] EPEL8 branch of perl-FCGI-Client
https://bugzilla.redhat.com/show_bug.cgi?id=1744709 Emmanuel Seyman changed: What|Removed |Added Depends On||1762253, 1762449 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1762253 [Bug 1762253] perl-Moo for EL8 https://bugzilla.redhat.com/show_bug.cgi?id=1762449 [Bug 1762449] perl-Type-Tiny for EL8 -- 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: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote: > This is not true. It should be *possible* to have a fully modularized > distribution, but that isn't a specific goal for Fedora or RHEL. Because this keeps coming up, we talked about this at the Fedora Council meeting today. Our goals for modularity are: 1. Users should have alternate streams of software available. 2. Those alternate streams should be able to have different lifecycles. 3. Packaging an individual stream for multiple outputs should be easier than before. The idea of modularizing the whole distro isn't a bad vision, but we're aiming a little closer to home for now. I'm perfectly happy with a lot of different ways to get to that goal. I think the modularity team has done a lot of amazing, hard work _even if we're not there yet_. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762449] New: perl-Type-Tiny for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762449 Bug ID: 1762449 Summary: perl-Type-Tiny for EL8 Product: Fedora Version: rawhide Status: NEW Component: perl-Type-Tiny Assignee: rc040...@freenet.de Reporter: emman...@seyman.fr QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Hi, Could you please build perl-Type-Tiny in EPEL 8 (or give me access to create the branch and maintain it myself)? Regards, Emmanuel -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 01:28:37PM -0400, Stephen Gallagher wrote: > 1) This will be solved by the new Koji/MBS feature that we've > codenamed "Ursa Prime" (as a replacement for the original "Ursa Major" > tool that was built for RHEL 8). Unlike its predecessor, it requires > no additional daemon service running to handle things. We will create > a buildroot compose for each release that is created from the set of > packages available from all of the default streams and both Koji (in > infra) and mock (on packager systems) will be able to consume this. > Koji will behave the same as mock, where it will rely on libdnf's > default module stream handling to populate the buildroot, so we won't > have to worry about disparities between the local and infrastructure > packager experiences. How would this act in the case where a default stream depends on a non-default stream? (And how would restricting default streams to only be able to depend on default streams change things?) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762242] perl-Unicode-MapUTF8 for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762242 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-a54aeeb49c has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-a54aeeb49c -- 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 1759023] Upgrade perl-Mail-Box to 3.008
https://bugzilla.redhat.com/show_bug.cgi?id=1759023 Tom "spot" Callaway changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2019-10-16 18:38:48 --- Comment #1 from Tom "spot" Callaway --- 3.008 in rawhide. -- 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 1761775] [RFE] Please build for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761775 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED Depends On||1758574 --- Comment #1 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18416 https://pagure.io/releng/fedora-scm-requests/issue/18417 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1758574 [Bug 1758574] perl-ExtUtils-CChecker for EL8 -- 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 1758574] perl-ExtUtils-CChecker for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758574 Emmanuel Seyman changed: What|Removed |Added Blocks||1761775 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761775 [Bug 1761775] [RFE] Please build for EPEL8 -- 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: Recommending proprietary software in Fedora
On Tue, Oct 15, 2019 at 01:00:37PM -0400, Przemek Klosowski via devel wrote: > It's a difficult choice. My understanding is that Fedora does not > 'recommend' proprietary software, but rather allows it to be found, > in response to people searching for it by either specific terms > (package name) or specific functionality. Yes. We talked about this at length on the Fedora Council -- and on the Board before that. There's basically a big philosophical question about the right response and what benefits free software (and Fedora) best overall. If someone needs Chrome for their job (and it is sadly the case that Chromium does not always suffice), do we do better by saying "okay, here's how you can get that easily" or by saying "sorry, go somewhere else"? This isn't a settled question in Fedora, and it's one that people feel very passionate about in both sides. In the end, we decided that allowing the experiment was worthwhile _as a means to the eventual end_. This is why there's a section about free and open source software in the third party policy, and why it includes the line "Wherever available, free and open source alternatives are listed and users are encouraged to prefer these to their restricted counterparts." You can see some of the history of all of this here: https://pagure.io/Fedora-Council/tickets/issue/57 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1761846] perl-Config-IniFiles for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761846 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-4811cb7b72 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4811cb7b72 -- 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 1761852] perl-Email-Sender for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761852 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18414 https://pagure.io/releng/fedora-scm-requests/issue/18415 -- 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 1762445] New: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be installed
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 Bug ID: 1762445 Summary: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be installed Product: Fedora Version: 29 Status: NEW Component: perl-HTTP-Tiny Assignee: ppi...@redhat.com Reporter: jflor...@doubledog.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Description of problem: Doing routine package upgrade fails. Version-Release number of selected component (if applicable): perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch How reproducible: 100% (on this host, at least) Steps to Reproduce: $ sudo dnf upgrade Actual results: Dependencies resolved. Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be installed - cannot install both perl-libs-4:5.26.2-410.module_1681+b405d8e2.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install both perl-libs-4:5.26.2-413.module_2073+eebc5b71.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch - package perl-libs-4:5.26.3-415.module_2543+eed510a0.armv7hl is excluded === PackageArchitecture Version Repository Size === Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): perl-libs armv7hl 4:5.26.2-410.module_1681+b405d8e2 fedora-modular 1.4 M perl-libs armv7hl 4:5.26.2-413.module_2073+eebc5b71 fedora-modular 1.4 M Skipping packages with broken dependencies: perl-HTTP-Tiny noarch 0.076-1.module_2073+eebc5b71 fedora-modular 55 k Transaction Summary === Skip 3 Packages Nothing to do. Complete! Expected results: For the upgrade to succeed. Additional info: I have done nothing with Fedora Modules on any of my hosts and know little to nothing about them, but this looks like borked packaging dependencies in the default stream. -- 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 1761854] perl-FCGI-ProcManager for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761854 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18410 https://pagure.io/releng/fedora-scm-requests/issue/18411 -- 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 1761845] perl-Cache-Memcached for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761845 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18412 https://pagure.io/releng/fedora-scm-requests/issue/18413 -- 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 1761855] perl-GD-SecurityImage for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761855 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18408 https://pagure.io/releng/fedora-scm-requests/issue/18409 -- 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 1761860] perl-String-Random for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761860 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18406 https://pagure.io/releng/fedora-scm-requests/issue/18407 -- 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 1762253] perl-Moo for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762253 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18404 https://pagure.io/releng/fedora-scm-requests/issue/18405 -- 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 1762261] [RFE] EPEL8 branch of perl-Module-Runtime-Conflicts
https://bugzilla.redhat.com/show_bug.cgi?id=1762261 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/18402 https://pagure.io/releng/fedora-scm-requests/issue/18403 -- 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
[389-devel] please review: PR 50654 - objectclass parsing does not log useful error message
https://pagure.io/389-ds-base/pull-request/50654 -- 389 Directory Server Development Team ___ 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: Recommending proprietary software in Fedora
On Tue, Oct 15, 2019 at 09:01:31PM -0700, John M. Harris Jr wrote: > > Don't waste your time answering this troll, he isn't listening. > I am not a troll, and I definitely am listening. I read the third party > software guidelines very carefully, on both the FESCo page, and the > Workstation Group's page. Yes; Leigh, let's please refrain from name calling. I often disagree with John, but I don't think he's acting in bad faith here (or in Fedora in general). -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
On Wed, Oct 16, 2019 at 01:06:50PM -0500, Ty Young wrote: > This is gold. Red Hat and Fedora will happily enforce a ridiculous > Code of Conduct on non Red Hat and Fedora members but Red Hat and > Fedora contributors will readily engage in name calling, harassment, > and intimidation both on and off the mailing lists. No; name calling, harassment, and intimidation are not welcome or allowed. I'm not sure what other incidents you're referring to, and I'm directly opposed to the suggestion that our code of conduct is "ridiculous", but it doesn't really matter: the negative behaviors you note are full-stop unwelcome. If you have a code of conduct issue to raise, please follow the process outlined at https://docs.fedoraproject.org/en-US/project/code-of-conduct/ . All such reports _are_ dealt with, with considerable thought and effort. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Minimization Objective report
This is the Minimization Objective [0] update. Status: Discovery phase == Next phase proposed == The next phase has been proposed [1] [2] to the Council and feedback is being collected. A formal vote happens in two weeks. == PostgreSQL == Started talking to the maintainers about removing systemd, python2, and to consider skipping weak dependencies in the container use case. == How to get involved == See if there is anything interesting to you on action plan [42], or reach out with something you think is useful but is missing there. Open a ticket in the tracker [43] or discuss in #fedora-devel on IRC. Cheers, Adam [0] Objective: https://docs.fedoraproject.org/en-US/minimization/ [1] Next phase proposal (post): https://communityblog.fedoraproject.org/extending-the-minimization-objective/ [2] Next phase proposal (PR): https://pagure.io/Fedora-Council/council-docs/pull-request/64 [42] Action plan: https://docs.fedoraproject.org/en-US/minimization/action-plan/ [43] Issue tracker: https://pagure.io/minimization/issues -- Adam Šamalík --- Senior Software Engineer Red Hat ___ 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: Recommending proprietary software in Fedora
On 10/15/19 10:59 PM, Leigh Scott wrote: On Wed, Oct 16, 2019 at 12:44 AM, John M. Harris Jr Don't waste your time answering this troll, he isn't listening. This is gold. Red Hat and Fedora will happily enforce a ridiculous Code of Conduct on non Red Hat and Fedora members but Red Hat and Fedora contributors will readily engage in name calling, harassment, and intimidation both on and off the mailing lists. It's almost like Code of Conducts are only put into place to silence others that you don't agree with. Funny that. ___ 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
case sensitive problems building packages (this case, PyVISA)
Hi, I am trying to build PyVISA (https://pyvisa.readthedocs.io/en/latest/) using mock and the problem is, during the build it is looking for "/builddir/build/BUILDROOT/python-pyvisa-1.10.0-1.fc30.x86_64/usr/lib/python3.7/site-packages/pyvisa-1.10.0-py?.?.egg-info". But the real name if the directory is"/builddir/build/BUILDROOT/python-pyvisa-1.10.0-1.fc30.x86_64/usr/lib/python3.7/site-packages/PyVISA-1.10.0-py?.?.egg-info". So I think the developer was not aware of case sensitive systems. I tried to modify the specfile but with no different result. So original specfile was created using pyp2rpm. Besides PyVISA, I had this problem on some other python packages, too, so is there a way out of that except patching and rewriting stuff of the original python package? It seems to me like a common problem. I found [1] and pyvisa is mentioned there, but the problem seems to be the same (regardless to say I wonder how that guy there built this RPM of PyVISA). Best Regards Christopher [1]: https://github.com/fedora-python/pyp2rpm/issues/22 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: proposal to allow on-demand side tags in F32+
On Wed, Oct 16, 2019 at 10:02:12AM +, Zbigniew Jędrzejewski-Szmek wrote: > I submitted a Change for wrangling today, but I'm also putting it here > for discussion: > https://fedoraproject.org/wiki/Changes/OnDemandSideTags > > This is intended to be an alternative to modularity, in the sense > that it allows some rpms to be built against older or newer versions > of dependencies, but the details of this process are invisible for > end users, who get only normal rpms. > > The text is too long to paste here, so please take a look on the wiki. > I'm especially interested in feedback if this would work for *your* > use case and make *your* life easier. So... this is rawhide multibuild gating with some more stuff on top of it, unless I am misreading? (ie, much of this is already being implemented as part of that). And the stuff on top has to do with modules interaction. I don't understand how the 'newer or older' builds would work though. Say I built my rawhide foo stack against openssl-100. I merge it back, either it doesn't merge openssl-100 and all my foo that links against it is broken, or it does and it conflicts with the existing openssl version and breaks everything else. Or are you assuming no runtime older/newer? How is that checked? I guess if we have tests for it, gating could stop it. This is pretty much exactly how multibuild rawhide gating will work (very soon now!) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Failure creating Fedora ID
On Tue, 15 Oct 2019 at 19:53, wrote: > > I would like to log a serious issue with https://SoftwareCollections.org > > It says I need a Fedora ID. > OK first off, to log issues with SoftwareCollections, I don't see where having a Fedora ID would do anything (or asked for). On the bottom of the front page is where to ask on StackOverflow https://stackoverflow.com/questions/tagged/software-collections for help and problems. The rest of the problems you run into are technical debt problems which need to be worked on. I understand that it causes problems with new users, and we are hoping to get the resources to fix it in the near future. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 1:19 PM Przemek Klosowski via devel wrote: > > On 10/15/19 9:26 PM, Stephen Gallagher wrote: > > Module stream metadata would gain two new optional attributes, > > "upgrades:" and "obsoletes:". > > > > If the "upgrades: " field exists in the metadata, libdnf > > should switch to this stream if the following conditions are met: > > 1) Changing the stream would not introduce conflicts. > > 2) The stream is marked as `default_enabled` or `dep_enabled`. > > > > The "obsoletes: " field would be stronger. Its use > > should require a special exemption (with a strong justification) and > > it would cause libdnf to switch from that stream to this one > > *unconditionally* (failing the transaction if that transition would > > cause conflicts). This would essentially be an "emergency escape" if > > we need it. > > Modularity has multiple use cases: your proposal addresses the OS usage > where modularity manages installed distribution's dependency versioning > issues. What would happen if someone installed certain module stream to > manage their own version requirements? Presumably, they might want to > _never_ change the stream. How is that handled in your scheme? I think > the "upgrades:" case would be fine, because explicit installation would > not have the "default_enabled" attribute. However, if a new module > declared the "obsoletes:", it would replace them no matter what. Would > there be a way to prevent that, or are you arguing that such override > should not be allowed? I'm saying that the policy should forbid the use of that feature except for an absolute emergency, requiring approval from FESCo or similar. It would exist for cases like "Oh crap, it turns out we've been shipping patented content in this stream and we're obligated to remove it" or something like that. It should never be used in the general case. Not even for "This is so old we should force upgrades". For that we should just drop the stream entirely from the next release, which would result in the upgrade being impossible until the user took a manual action to get off that stream. It would be my hope that the "obsoletes:" would never actually get used, but I'm generally in favor of planning for the worst case ahead of time if we can see it coming. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04183e6fbf scapy-2.4.3-2.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1c488e885d python-ecdsa-0.13.3-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-942baf668f nsd-4.2.2-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing akmods-0.5.6-23.el8 google-authenticator-1.06-2.el8 perl-Crypt-DES-2.07-19.1.el8 perl-DBM-Deep-2.0016-3.el8 perl-Data-Section-Simple-0.07-17.el8 perl-DateTime-Calendar-Mayan-0.0601-27.el8 perl-DateTime-Format-MySQL-0.06-12.el8 perl-Declare-Constraints-Simple-0.03-36.el8 perl-Devel-OverloadInfo-0.005-7.el8 perl-Devel-PartialDump-0.20-8.el8 perl-Email-Address-1.912-5.el8 perl-Email-Simple-2.216-6.el8 perl-Locale-US-3.04-13.el8 perl-Module-Refresh-0.17-25.el8 perl-Net-CUPS-0.64-11.el8 perl-Spreadsheet-ParseExcel-0.6500-24.1.el8 perl-Test-CleanNamespaces-0.24-6.el8 perl-aliased-0.34-14.el8 pure-ftpd-1.0.49-2.el8 virglrenderer-0.8.0-1.20191002git4ac3a04c.el8 vpnc-script-20171004-6.git6f87b0f.el8 Details about builds: akmods-0.5.6-23.el8 (FEDORA-EPEL-2019-aece69e11d) Automatic kmods build and install tool Update Information: - Add requires kernel-abi-whitelists for RHEL - Build for epel8 References: [ 1 ] Bug #1760833 - Please Package akmods for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1760833 google-authenticator-1.06-2.el8 (FEDORA-EPEL-2019-ce9efe8b1a) One-time pass-code support using open standards Update Information: Initial release for EL8 References: [ 1 ] Bug #1759034 - google-authenticator not packaged for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1759034 perl-Crypt-DES-2.07-19.1.el8 (FEDORA-EPEL-2019-6afebf6916) Perl DES encryption module Update Information: Build perl-Crypt-DES for EPEL 8. References: [ 1 ] Bug #1761988 - perl-Crypt-DES for EL8 https://bugzilla.redhat.com/show_bug.cgi?id=1761988 perl-DBM-Deep-2.0016-3.el8 (FEDORA-EPEL-2019-0587d47f04) A pure perl multi-level hash/array DBM Update Information: This update consists of a collection of perl modules that are build-time and run-time dependencies of perl-Moose. These are the first EPEL-8 builds of these modules. perl-Data-Section-Simple-0.07-17.el8 (FEDORA-EPEL-2019-0587d47f04) Read data from __DATA__ Update Information: This update consists of a collection of perl modules that are build-time and run-time dependencies of perl-Moose. These are the first EPEL-8 builds of these modules. perl-DateTime-Calendar-Mayan-0.0601-27.el8 (FEDORA-EPEL-2019-0587d47f04) Mayan Long Count Calendar Update Information: This update consists of a collection of perl modules that are build-time and run-time dependencies of perl-Moose. These are the first EPEL-8 builds of these modules. perl-DateTime-Format-MySQL-0.06-12.el8 (FEDORA-EPEL-2019-0587d47f04) Parse and format MySQL dates and times Update Information: This update consists of a
[Bug 1761539] [RFE] Please build for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761539 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Net-CUPS-0.64-11.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-4f7883722e -- 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 1762268] perl-Email-Address for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762268 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Email-Address-1.912-5.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-51fed42813 -- 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 1758280] Please build perl-Spreadsheet-ParseExcel for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1758280 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- perl-Spreadsheet-ParseExcel-0.6500-24.1.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-b912a36fe9 -- 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 1762252] perl-Email-Simple for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762252 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Email-Simple-2.216-6.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-8204a4170c -- 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 1761988] perl-Crypt-DES for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761988 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Crypt-DES-2.07-19.1.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-6afebf6916 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Wed, Oct 16, 2019 at 12:11 PM Adam Williamson wrote: > > On Tue, 2019-10-15 at 12:25 -0400, Neal Gompa wrote: > > > > > So: I'm on board with most of what you say here, but there's no need to > > > say it means Modularity is "a failure". It means right now it's not > > > entirely baked and we're realizing the concept needs extending and > > > perhaps reworking a bit, just like we realized with the *first* cut at > > > Modularity which we abandoned between a Beta release and a Final > > > release. This is causing us to have to deal with some icky problems, > > > but again, that's not *new*. We had to deal with some fairly icky > > > problems when systemd showed up. We had to deal with some fairly icky > > > problems when grub2 showed up. It's a process we've dealt with before. > > > We know how to do it. We just need to hold our noses and fix the icky > > > problems, and then sit down and think about the design issues that have > > > become apparent in Modularity v2 through our actually implementing it > > > and using it (which is what Fedora is for, remember!) and figure out > > > how to address them in Modularity v3. > > > > Are we going to do a Modularity v3? Because people seemed to be > > *really* reluctant to go down that path because it would break > > compatibility with RHEL. > > Well, those are just the terms I use to think about it, they have no > official validity. So in a sense it's a pointless semantic question. > Let's put it this way: I'd be surprised if we don't wind up having to > make significant changes/enhancements to the modularity rules and/or > implementation to be able to resolve the issues we're dealing with > right now (Stephen, in some of his replies, seems to agree) and to me > it'd be valid to call that 'modularity v3'. Whether anyone else would > call it that or not doesn't seem too important :) I agree with everything Adam just said. I'd avoid the term "Modularity v3" in general, because it sounds like a total redesign (which is what the v1->v2 switch ended up being). So far, all of the things I've been proposing have been done with an aim of not causing any additional breakage and to ensure that an upgrade path exists. That said, as we've rolled this out, new information has come up that is requiring us to re-evaluate some of the original design decisions (the most obvious being the "changing default streams" case). The two different proposals for how to handle that have been offered up because they provide an upgrade path to get out of the current situation without significant manual intervention. Also, I want to reiterate this point, because it is central: There are three core issues from which most of the complaints in this thread ultimately stem: 1) Modular default streams are not available to the non-modular buildroot, so packages that want to build against them are forced to either become modules or vanish from Fedora (or use complex build-time workarounds). 2) Once a stream has been enabled on the system, users are bound to it - even across upgrades between releases. Since the purpose of default streams is to eliminate the need for users to understand module interactions if they want to continue operating the way they did pre-Modularity, they need to be able to follow stream changes on upgrades to match the intended defaults for the new system. 3) The policy on default streams was not clearly defined and communicated. The Modularity WG recently voted to affirm that all artifacts installable from default streams of a module must obey all of the rules of packages in non-modular Fedora (primarily Stable Updates policy and the expectation that they are treated as supported API for all purposes). This is the "Java/Maven Problem", where the Java team created a maven module that included stripped-down dependencies in the default stream, thus owning those package names with unsupported content. We have plans in place for how to deal with each of these critical problems (without resorting to throwing it all away). 1) This will be solved by the new Koji/MBS feature that we've codenamed "Ursa Prime" (as a replacement for the original "Ursa Major" tool that was built for RHEL 8). Unlike its predecessor, it requires no additional daemon service running to handle things. We will create a buildroot compose for each release that is created from the set of packages available from all of the default streams and both Koji (in infra) and mock (on packager systems) will be able to consume this. Koji will behave the same as mock, where it will rely on libdnf's default module stream handling to populate the buildroot, so we won't have to worry about disparities between the local and infrastructure packager experiences. 2) There is an entire email thread [1] dedicated to how we are going to solve this. I won't repeat it here. 3) We need to get the policy I described above written onto -stone tablets- the Packaging Guidelines and then we need to go and make any stream that
[Bug 1762246] perl-Unicode-Map8 for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762246 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-baabb1355a has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-baabb1355a -- 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 1762242] perl-Unicode-MapUTF8 for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762242 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18398 https://pagure.io/releng/fedora-scm-requests/issue/18399 -- 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: Modularity and the system-upgrade path
On 10/15/19 9:26 PM, Stephen Gallagher wrote: Module stream metadata would gain two new optional attributes, "upgrades:" and "obsoletes:". If the "upgrades: " field exists in the metadata, libdnf should switch to this stream if the following conditions are met: 1) Changing the stream would not introduce conflicts. 2) The stream is marked as `default_enabled` or `dep_enabled`. The "obsoletes: " field would be stronger. Its use should require a special exemption (with a strong justification) and it would cause libdnf to switch from that stream to this one *unconditionally* (failing the transaction if that transition would cause conflicts). This would essentially be an "emergency escape" if we need it. Modularity has multiple use cases: your proposal addresses the OS usage where modularity manages installed distribution's dependency versioning issues. What would happen if someone installed certain module stream to manage their own version requirements? Presumably, they might want to _never_ change the stream. How is that handled in your scheme? I think the "upgrades:" case would be fine, because explicit installation would not have the "default_enabled" attribute. However, if a new module declared the "obsoletes:", it would replace them no matter what. Would there be a way to prevent that, or are you arguing that such override should not be allowed? ___ 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: Unresponsive Package Maintainer drago01
Thanks Sérgio, It's been some time now and still no word. I can see on https://src.fedoraproject.org/rpms/libpar2 there is a co-maintainer by the name of maci. Perhaps he can take over the package? Alternatively I don't mind doing so either. Chris On Fri, Oct 4, 2019 at 10:36 PM Sérgio Basto wrote: > On Fri, 2019-10-04 at 21:11 -0400, Chris wrote: > > HI, > > I'm just following the process identified here: > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > > 1) I filled this issue back in June/2019: > https://bugzilla.redhat.com/show_bug.cgi?id=1720857 > 2) I created a non responsive maintainer a couple of weeks ago: > https://bugzilla.redhat.com/show_bug.cgi?id=1755999 > > I just thought I'd give the ol' mail list a try since that seems to be > what is suggested of me next :) > > Thoughts/Advice? > > > Adding him in CC ;) > > Chris > > ___ > > devel mailing list -- > > devel@lists.fedoraproject.org > > > To unsubscribe send an email to > > devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > -- > > Sérgio M. B. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: proposal to allow on-demand side tags in F32+
On Wed, Oct 16, 2019 at 09:06:19AM -0700, Adam Williamson wrote: > On Wed, 2019-10-16 at 10:02 +, Zbigniew Jędrzejewski-Szmek wrote: > > I submitted a Change for wrangling today, but I'm also putting it here > > for discussion: > > https://fedoraproject.org/wiki/Changes/OnDemandSideTags > > > > This is intended to be an alternative to modularity, in the sense > > that it allows some rpms to be built against older or newer versions > > of dependencies, but the details of this process are invisible for > > end users, who get only normal rpms. > > > > The text is too long to paste here, so please take a look on the wiki. > > I'm especially interested in feedback if this would work for *your* > > use case and make *your* life easier. > > To me it looks like it'd make some things harder. It makes reproducing > builds very difficult, as you need to dig through logs to figure out > exactly what build environment the packager set up. That is true. But that is a general issue inherent in any modularity-like setup where you allow people to tweak the build root. I think that the answer to this is not to disallow this, but to make it more transparent. In principle, koji could provide the information which packages were installed in the build root as structured data. A similar thing occurs with "dynamic buildrequires": and any package can request other packages dynamically, so recording and retrospecting the build root becomes quite important. > I already kinda hate dealing with buildroot overrides, but at least > those are identifiable artifacts you can relatively easily get a > start/end date for. This is like buildroot overrides on steroids in > some ways (though better in one way - it doesn't affect *every* build). Yeah, I think this would mostly replace buildroot overrides: usually we create them to rebuild some specific packages, and in this proposal, it'd be nicer to just rebuild everything in the side tag. If some of the builds don't go as planned, just discard the whole thing and start over. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762085] perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 --- Comment #6 from Fedora Update System --- perl-Term-Table-0.014-1.fc29 has been pushed to the Fedora 29 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-2019-f1e07a9eff -- 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 1757192] [RFE] EPEL-8 branch for perl-Test-Portability-Files
https://bugzilla.redhat.com/show_bug.cgi?id=1757192 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Test-Portability-Files ||-0.10-4.el8 Resolution|--- |ERRATA Last Closed||2019-10-16 16:44:24 --- Comment #4 from Fedora Update System --- perl-Test-Portability-Files-0.10-4.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
Re: s390x: glibc32 and gcc
On Wed, Oct 16, 2019 at 4:48 AM Florian Weimer wrote: > * Jerry James: > > Sorry for not cluing you in sooner. I sent email to the maintainers > > of all the packages I need to rebuild, but that didn't include you. > > I'll let you know as soon as these builds are tagged into Rawhide. > > Oh no, it's just bad luck. I didn't expect anyone besides Jakub > rebuilding gcc at that time, either. I would even say that it's > probably better to have such conflicts occasionally, rather than trying > to coordinate everything beforehand in detail. Thanks for understanding. In case you didn't see the email I sent to fedora-devel-list, the builds have been tagged into Rawhide, so you should be good to do whatever you need to do. Regards, -- 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
[Bug 1762269] perl-Email-Abstract for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762269 --- Comment #5 from Xavier Bachelot --- Thanks for the offer. The problem is I still need to be added to each package in order to push to the branch. Or I guess request to be added to provenpackager group, but I'm not sure I qualify. -- 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
FOSDEM
Hi All, I haven't heard anyone mention FOSDEM yet. Booth applications are due soon and I'd like to see us coordinate again with our friends in CentOS. Is there anyone interested in owning this? If so, can you put together a proposal for Mindshare? regards, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wednesday, October 16, 2019, Stephen Gallagher wrote: > On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr > wrote: > > > > On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > > given that we're talking about the need to migrate defaults > > > > To clarify, that has not been decided, and a prominent option mentioned > in > > this thread is the option to simply require that there is a non-modular > > package. > > An awful lot of people are repeating this as if it's a solution > without understanding the existing architecture. Believe it or not, > attempting to abandon default streams and go back to only non-modular > content available by default is a lot harder than it sounds (or should > be, but I noted that we're working on that in another reply elsewhere > in the thread). There is currently no path to upgrades that would get > back from the modular versions and the closest we could manage would > be to rely on the dist-upgrade distro-sync, but in that case we > *still* need to have DNF recognize that the default stream has changed > (in this case, been dropped) and handle that accordingly. > > It may be more work to go backwards than forwards at this point. > Modularity does provide some useful feature additions, so to my mind > it makes more sense to properly fix the issues we have with it rather > than expend enormous amounts of energy to remove those features and > revert to the old way of doing things. And, yes, reduce Fedora's value > to Red Hat in the process. > > I started this discussion to ask the community to help us identify the > best path *forward*. An endless barrage of "kill it off" replies is > not helpful or productive. If anyone has specific advice on how to > move forward (or, indeed, if you can figure out how to migrate back > without considerable release engineering and packager effort), that > would be productive. Just please keep in mind that we have to go to > war with the army we have, not the one we wish we had. > That's just oversimplified - if you find that the way you are on is the wrong one just moving forward is not necessary the correct thing to do. Going backwards to get a saner state is a worthwhile thing to do. I have yet to see an argument how replacing existing packages with modules or providing default streams by default helps to reach the objective of 'parallel availability' - by dropping the default modules by default you get pretty much that without the downsides. ___ 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 1762269] perl-Email-Abstract for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762269 --- Comment #4 from Tom "spot" Callaway --- (In reply to Xavier Bachelot from comment #3) > Btw, feel free to add me to any package I'm filing bug for and assign the > bug to me. My FAS username is xavierb. I don't have a lot of time right now to chase dependencies, but feel free to do anything you wish wrt epel8 for any of my perl packages. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Tue, 2019-10-15 at 12:25 -0400, Neal Gompa wrote: > > > So: I'm on board with most of what you say here, but there's no need to > > say it means Modularity is "a failure". It means right now it's not > > entirely baked and we're realizing the concept needs extending and > > perhaps reworking a bit, just like we realized with the *first* cut at > > Modularity which we abandoned between a Beta release and a Final > > release. This is causing us to have to deal with some icky problems, > > but again, that's not *new*. We had to deal with some fairly icky > > problems when systemd showed up. We had to deal with some fairly icky > > problems when grub2 showed up. It's a process we've dealt with before. > > We know how to do it. We just need to hold our noses and fix the icky > > problems, and then sit down and think about the design issues that have > > become apparent in Modularity v2 through our actually implementing it > > and using it (which is what Fedora is for, remember!) and figure out > > how to address them in Modularity v3. > > Are we going to do a Modularity v3? Because people seemed to be > *really* reluctant to go down that path because it would break > compatibility with RHEL. Well, those are just the terms I use to think about it, they have no official validity. So in a sense it's a pointless semantic question. Let's put it this way: I'd be surprised if we don't wind up having to make significant changes/enhancements to the modularity rules and/or implementation to be able to resolve the issues we're dealing with right now (Stephen, in some of his replies, seems to agree) and to me it'd be valid to call that 'modularity v3'. Whether anyone else would call it that or not doesn't seem too important :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: proposal to allow on-demand side tags in F32+
On Wed, 2019-10-16 at 10:02 +, Zbigniew Jędrzejewski-Szmek wrote: > I submitted a Change for wrangling today, but I'm also putting it here > for discussion: > https://fedoraproject.org/wiki/Changes/OnDemandSideTags > > This is intended to be an alternative to modularity, in the sense > that it allows some rpms to be built against older or newer versions > of dependencies, but the details of this process are invisible for > end users, who get only normal rpms. > > The text is too long to paste here, so please take a look on the wiki. > I'm especially interested in feedback if this would work for *your* > use case and make *your* life easier. To me it looks like it'd make some things harder. It makes reproducing builds very difficult, as you need to dig through logs to figure out exactly what build environment the packager set up. It would also make things like the meson issue we had a few months back: https://bugzilla.redhat.com/show_bug.cgi?id=1701012 even more of a pain to clear up, because you could no longer expect that simply 'all builds after date X but before date Y were built with the bad meson'. I already kinda hate dealing with buildroot overrides, but at least those are identifiable artifacts you can relatively easily get a start/end date for. This is like buildroot overrides on steroids in some ways (though better in one way - it doesn't affect *every* build). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1762085] perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 --- Comment #5 from Fedora Update System --- perl-Term-Table-0.014-1.fc30 has been pushed to the Fedora 30 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-2019-bcedaa8e47 -- 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 1762272] perl-Email-MIME for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762272 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2019-22348a08e1 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-22348a08e1 -- 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 1762245] perl-Test-Distribution for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762245 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-c87175fecf has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c87175fecf -- 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 1762246] perl-Unicode-Map8 for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762246 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|emman...@seyman.fr |p...@city-fan.org --- Comment #2 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18391 https://pagure.io/releng/fedora-scm-requests/issue/18392 -- 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
spot pushed to perl-Mail-Message (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild (..more)"
Notification time stamped 2019-10-16 15:16:43 UTC
From 4d5414ec291dbacf1b2f5be715f9f53209813877 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering
Date: Jul 26 2019 04:27:13 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
Signed-off-by: Fedora Release Engineering
---
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index 0e8f972..e055b0d 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,6 +1,6 @@
Name: perl-Mail-Message
Version: 3.008
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: MIME message handling
License: GPL+ or Artistic
URL: https://metacpan.org/release/Mail-Message
@@ -126,6 +126,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Jul 26 2019 Fedora Release Engineering -
3.008-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
+
* Sun Jun 02 2019 Jitka Plesnikova - 3.008-3
- Perl 5.30 re-rebuild of bootstrapped packages
https://src.fedoraproject.org/rpms/perl-Mail-Message/c/4d5414ec291dbacf1b2f5be715f9f53209813877?branch=epel8
___
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
spot pushed to perl-Mail-Message (epel8). "3.008"
Notification time stamped 2019-10-16 15:16:43 UTC
From 442e33cbd753578444e524f31df5baf41a26d6c6 Mon Sep 17 00:00:00 2001
From: Tom Callaway
Date: Feb 11 2019 21:17:12 +
Subject: 3.008
---
diff --git a/.gitignore b/.gitignore
index 86f401d..856f886 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
/Mail-Message-3.005.tar.gz
/Mail-Message-3.006.tar.gz
/Mail-Message-3.007.tar.gz
+/Mail-Message-3.008.tar.gz
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index a9ee534..dc40947 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,6 +1,6 @@
Name: perl-Mail-Message
-Version: 3.007
-Release: 2%{?dist}
+Version: 3.008
+Release: 1%{?dist}
Summary: MIME message handling
License: GPL+ or Artistic
URL: https://metacpan.org/release/Mail-Message
@@ -126,6 +126,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Feb 11 2019 Tom Callaway - 3.008-1
+- update to 3.008
+
* Fri Feb 01 2019 Fedora Release Engineering -
3.007-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
diff --git a/sources b/sources
index a58f9f5..cf2cf5b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Message-3.007.tar.gz) =
cd4a7fdd72ea94f50f147a68a589aff9c8e015e01f2ad8bd9d76d977da3501479fa8a6f6993d17f5ab9a7efb44071e9f2258d76f870726b1c55b67708c752c2a
+SHA512 (Mail-Message-3.008.tar.gz) =
4fd4d0d82e3bef47942509b8988a62ff027a9377cf87e6ca5d4c50880d16bdcdb5671cd3cb860043cb736efe52f31a1be300014788b0137f1fab4568b90e4002
https://src.fedoraproject.org/rpms/perl-Mail-Message/c/442e33cbd753578444e524f31df5baf41a26d6c6?branch=epel8
___
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
spot pushed to perl-Mail-Message (epel8). "Merge branch 'master' into epel8"
Notification time stamped 2019-10-16 15:16:43 UTC
From 2e8d5ef84323145164572f9c5a2a6c2a093f712a Mon Sep 17 00:00:00 2001
From: Tom Callaway
Date: Oct 16 2019 15:16:32 +
Subject: Merge branch 'master' into epel8
---
diff --git a/.gitignore b/.gitignore
index e69de29..856f886 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1,7 @@
+/Mail-Message-3.000.tar.gz
+/Mail-Message-3.001.tar.gz
+/Mail-Message-3.002.tar.gz
+/Mail-Message-3.005.tar.gz
+/Mail-Message-3.006.tar.gz
+/Mail-Message-3.007.tar.gz
+/Mail-Message-3.008.tar.gz
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
new file mode 100644
index 000..e055b0d
--- /dev/null
+++ b/perl-Mail-Message.spec
@@ -0,0 +1,192 @@
+Name: perl-Mail-Message
+Version: 3.008
+Release: 4%{?dist}
+Summary: MIME message handling
+License: GPL+ or Artistic
+URL: https://metacpan.org/release/Mail-Message
+Source0:
https://cpan.metacpan.org/authors/id/M/MA/MARKOV/Mail-Message-%{version}.tar.gz
+BuildRequires: perl-generators
+BuildRequires: perl-interpreter
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Date::Format)
+BuildRequires: perl(Date::Parse)
+%if !%{defined perl_bootstrap}
+BuildRequires: perl(Email::Abstract)
+%endif
+BuildRequires: perl(Email::Simple)
+BuildRequires: perl(Encode) >= 2.26
+BuildRequires: perl(Encode::Alias)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Spec) >= 0.7
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Font::Metrics::TimesRoman)
+BuildRequires: perl(HTML::FormatText) >= 2.01
+BuildRequires: perl(HTML::TreeBuilder) >= 3.13
+BuildRequires: perl(integer)
+BuildRequires: perl(IO::File)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IO::Lines)
+BuildRequires: perl(IO::Scalar)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Mail::Address) >= 2.17
+BuildRequires: perl(Mail::Header)
+BuildRequires: perl(Mail::Identity)
+BuildRequires: perl(Mail::Internet) >= 2.01
+%if !%{defined perl_bootstrap}
+BuildRequires: perl(Mail::Transport::Send)
+%endif
+BuildRequires: perl(MIME::Base64)
+BuildRequires: perl(MIME::Entity) >= 3.0
+BuildRequires: perl(MIME::Parser)
+BuildRequires: perl(MIME::QuotedPrint)
+BuildRequires: perl(MIME::Types) >= 1.004
+BuildRequires: perl(Net::Domain)
+BuildRequires: perl(overload)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Scalar::Util) >= 1.13
+BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
+BuildRequires: perl(Sys::Hostname)
+BuildRequires: perl(Test::More) >= 0.47
+BuildRequires: perl(Text::Autoformat)
+BuildRequires: perl(Time::HiRes) >= 1.51
+BuildRequires: perl(Time::Zone)
+BuildRequires: perl(URI) >= 1.23
+BuildRequires: perl(User::Identity) >= 0.94
+BuildRequires: perl(User::Identity::Collection::Emails)
+BuildRequires: perl(utf8)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+# Remember when we could assume build environments had common packages?
+# Pepperidge Farm remembers.
+BuildRequires: coreutils, make, glibc-common
+BuildArch: noarch
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+# Explicit run requires
+Requires: perl(Date::Parse)
+%if !%{defined perl_bootstrap}
+Requires: perl(Mail::Transport::Send)
+%endif
+Requires: perl(Time::Zone)
+
+# I'm not sure why these provides aren't getting picked up automatically.
+Provides: perl(Mail::Message::Body::Construct) = %{version}
+Provides: perl(Mail::Message::Construct) = %{version}
+Provides: perl(Mail::Message::Construct::Bounce) = %{version}
+Provides: perl(Mail::Message::Construct::Build) = %{version}
+Provides: perl(Mail::Message::Construct::Forward) = %{version}
+Provides: perl(Mail::Message::Construct::Read) = %{version}
+Provides: perl(Mail::Message::Construct::Rebuild) = %{version}
+Provides: perl(Mail::Message::Construct::Reply) = %{version}
+Provides: perl(Mail::Message::Construct::Text) = %{version}
+
+%description
+MIME message handling code, formerly part of the Mail::Box package.
+
+%prep
+%setup -q -n Mail-Message-%{version}
+# The licensing on these test files is unclear.
+# They seem to contain content posted publicly to usenet
+# so there is an argument that the content is distributable
+# but its not under a Free license.
+# We delete these files to resolve the issue.
+# https://rt.cpan.org/Public/Bug/Display.html?id=120149
+rm -rf t/203-mlfolder.mbox t/204-sgfolder.mbox
+rm -rf t/203head-listgroup.t t/204head-spamgroup.t
+
+%{?perl_default_filter}
+
+%build
+yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
+# Fix file encoding
+recode()
+{
+ iconv -f "$2" -t utf-8 < "$1" > "${1}_"
+ mv -f
