Fedora-Cloud-33-20211016.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211015.0): ID: 1030009 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1030009 ID: 1030010 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1030010 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ImageMagick update
I have rebuild eom yesterday for rawhide. Untaging would force me another rebuild of eom. I hope the update won't push to stable branches. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Removal of quagga from Fedora
On Tue, Oct 12, 2021 at 01:53:28PM +0200, Michal Ruprich wrote:
> Hi,
>
> I am planning to start a retirement process for quagga in Fedora. The
> package is very outdated since the upstream is dead for a couple of
> years. There is a replacement in the form of FRR that can be used in a
> very similar fashion and it has active upstream with a lot of
> development going on.
>
> This is more of an FYI message to let you know and to see if anyone
> would miss quagga.
I actually thought they were the same project but renamed.
I notice the current spec (correctly) Obsoletes: quagga < 1.2.4-17.
Should it not also Provides: quagga = %{version} so that updates
happen transparently? I'm going to guess if not it's something to do
with the configuration files have a different name.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: crypto-policies and a certain usage of SHA-1
Michael Catanzaro wrote: > SHA-1 is blocked in certificate signatures because those can be > attacked offline. Signatures in the TLS handshake are entirely > different. I'm hardly an expert, but I think the attacker only has a > few seconds to generate a hash collision before the user gives up and > closes the browser tab. Spending several months trying to find a > collision is not an option here. Am I wrong? Probing the server repeatedly I get the same value in the Pubkey field several times in a row. Some time later the value changes. The server seems to replace the key every few hours or days. The Signature field is different every time though. Thus I'm not sure whether the attacker's time limit is the lifetime of the key (which Fedora can't control) or the TCP timeout. Björn Persson pgptnItUABZ9M.pgp Description: OpenPGP digital signatur ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi wrote:
>
> On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> > On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia wrote:
> > >
> > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Ansible5
> > > >
> > > > == Summary ==
> > > >
> > > > The ansible project has re-organized how they release and distribute
> > > > ansible. This change moves Fedora to be in sync with those changes and
> > > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > > 'ansible' package that pulls in ansible-core (the engine) and includes
> > > > all the collections in upstream ansible releases.
> > >
> > > I wrote to the various upstream bugtrackers about this already. The
> > > re-org upstream is confusing and unwelcome, and creates a stack of
> > > problems.
>
> Yeah, it's been confusing to people for sure, but it does also help out
> a lot with other problems. :(
it could have made good sense, and still would, for the "ansible"
package to be what is now being colloquially referred to as
"ansible-core", but for which the published upstream git repo is still
https://github.com/ansible/ansible, and which is and will remain
accessible as a github release tarball with the old numbering. The
pypi.org published "ansible-core" is a republication of that repo with
a new name duck-taped on it. Fragmenting out the bulky and potentially
dynamic set of tools that are now in the "galaxy collections" suite
makes some sense, but the result is that to get any of the core
modules like "ansible.posix" we wind up including 573 Megabytes of
unneeded and unwelcome debris in
/usr/lib/python3.6/site-packages/ansible_collections. Very few of us
need more than 10% of the list
There is no specific source repository for the "ansible_collections"
tarball, as best I can tell. The list of modules selected from the
galaxy collection is very large, but incomplete and I've not seen any
criteria for what goes in that tarball and what does not. Have you
seen any?
I'd suggest that discarding the pypi.org renaming and instead using
the raw tarballs from github as sources for individual galaxy
collection modules helps resolve. This would keep the numbering of the
"ansible" RPM consistent, and its core functionality. The modules
which have been shifted to the galaxy collection, such as the "ec2"
and "cisco" modules, could and should be bundled individually as
Fedora has been doing quite effectively. I did some tests: an RPM of
the current pypi.org tarball mislabeled as "ansible" occupies more
than 570 MBytes of local disk. If you want a lightweight Ansible
setup, say for applying some playbooks to your localhost, it's an
unreasonable burden.
Those numbers do not include the documentation: The sphinx build of
the HTML docs is something I've tried, but so far is not working with
my test SRPM. As it is, I've had to rename doc or license files that
have " " in the filename because the '%doc' and '%license' macros do
not like whitespace in filenames, and split them up because a
'%license' or '%doc' that have so many hundreds of entries overwhelms
SRPM scripting. Packaging up the individual modules or sets of modules
individually avoids this unwelcome burden.
> > > I would publish ansible-core as just that, with a "Provides: ansible
> > > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
>
> That would radically diverge from upstream and cause _more_ confusion.
Upstream already confused people. I don't think it justifies repeating
their bundling mistakes, mistakes that are not reflected in the
upstream source code for the software but only in intermediate
repackaging and which Fedora has so far effectively avoided.
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Tue, Oct 12, 2021 at 01:52:01PM -0400, Neal Gompa wrote: > Hey all, > > I'm working on extending quickemu[1] to be able to easily spin up > Fedora VMs, but our lack of a static URL formula for fetching ISOs > makes this a bit difficult. > > Do we have some kind of API endpoint that has the necessary > information for this? It'd be nice to be able to fetch some kind of > JSON file with the necessary information so that tools can fetch it > programmatically... > > Thanks in advance and best regards! > > [1]: https://github.com/wimpysworld/quickemu Virt-builder also has metadata for the images we release (which are disk templates, not ISOs). https://builder.libguestfs.org/index.asc https://libguestfs.org/virt-builder.1.html#sources-of-templates Looks like several people have reinvented wheels here because Fedora doesn't really offer this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora minimum hardware requirements
On Fri, Oct 15, 2021 at 04:13:34AM +0200, Michal Schorm wrote: > Thinking about this more, I always get to a question: > "Who are the consumers of that information and what do they actually > use it for?" One consumer is libosinfo. Tools which use libosinfo (of which there are quite a few) will use it for ensuring there is enough space when provisioning VMs. Currently: https://gitlab.com/libosinfo/osinfo-db/-/blob/226b19fd3e5401c0554ba3df563d49465b59b1cf/data/os/fedoraproject.org/fedora-34.xml.in#L236 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Potential Bugs - Where/What to file against
Hello, I recently updated from F34 to F35 on an MSI laptop. I've noticed two 'regressions' and I'm not sure where to file bugs. #1 - The first one is if I close the lid and the device suspends (I assume as it used to do this fine), when I re-open the lid, the keyboard lights up, fans start, but the screen never turns on and I don't know if the device is running and the screen is blank or if its just not waking up. Is this a kernel/systemd bug? What steps/info is required to file a bug here? #2 - In F34 Gnome control center -> battery I could choose the laptops power profile (performance, balanced, powersave). This seems to be gone. https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon seems like its supposed to be supplying this, but systemd says the service is masked. Looks like it is masked by TLP. TLP has the benefit of being able to configure that setting between when on AC and when on BAT which is nice but I'm wondering is it a bug that I can no longer change that setting in gnome control panel? Is this expected behaviour? Otherwise the upgrade has gone well. Sincerely, -- Nathanael ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libcurl-minimal
On Thu, Oct 14, 2021 at 09:52:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi Kamil and everyone,
>
> what is the plan with introduction of libcurl-minimal in Fedora?
> IIUC, libcurl and libcurl-minimal both have the same Provides, so
> libcurl-minimal
> can be used to satisfy automatically generated dependencies:
>
> $ dnf repoquery --provides libcurl-minimal
> libcurl = 7.78.0-3.fc35
> libcurl(x86-32) = 7.78.0-3.fc35
> libcurl(x86-64) = 7.78.0-3.fc35
> libcurl-minimal = 7.78.0-3.fc35
> libcurl-minimal(x86-32) = 7.78.0-3.fc35
> libcurl-minimal(x86-64) = 7.78.0-3.fc35
> libcurl.so.4
> libcurl.so.4()(64bit)
> $ dnf repoquery --provides libcurl
> libcurl = 7.78.0-3.fc35
> libcurl(x86-32) = 7.78.0-3.fc35
> libcurl(x86-64) = 7.78.0-3.fc35
> libcurl-full = 7.78.0-3.fc35
> libcurl-full(x86-32) = 7.78.0-3.fc35
> libcurl-full(x86-64) = 7.78.0-3.fc35
> libcurl.so.4
> libcurl.so.4()(64bit)
What's the aim here? Small size on disk? General fear of having
insecure but unused protocols linked with programs?
It's a shame it has to be packaged this way. I got half way through
writing a curl handler (which I really must finish) and my impression
is that at a code level they are quite modular, so maybe upstream
would be interested in turning them into real loadable modules. Then
we could package each protocol ("curl-http.so") as a separate RPM
which is really best of all worlds.
In the meantime I'd like to encourage every program in Fedora that
uses curl to call CURLOPT_PROTOCOLS(3). This is a real defence
against remote exploits (CVE-2013-0249 was one that happened in qemu).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Potential Bugs - Where/What to file against
On Sat, Oct 16, 2021 at 09:21:57AM -0600, Nathanael D. Noblet wrote: > Hello, > > I recently updated from F34 to F35 on an MSI laptop. I've noticed two > 'regressions' and I'm not sure where to file bugs. > > #1 - The first one is if I close the lid and the device suspends (I > assume as it used to do this fine), when I re-open the lid, the > keyboard lights up, fans start, but the screen never turns on and I > don't know if the device is running and the screen is blank or if its > just not waking up. Is this a kernel/systemd bug? What steps/info is > required to file a bug here? Try pressing ctrl-alt-f8 to switch to a text console. If the text login appears, then the issue was most likely in the graphics stack. If still blank, try pressing ctrl-alt-del. On a text console this should result in a reboot. If it reboots, you should be able to see logs with 'journalctl -b-1'. If it doesn't respond to ctrl-alt-del, then it's a kernel driver issue. Further debugging is possible, but let's check the easy things first. > #2 - In F34 Gnome control center -> battery I could choose the > laptops power profile (performance, balanced, powersave). This seems to > be gone. https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon > seems like its supposed to be supplying this, but systemd says the > service is masked. Looks like it is masked by TLP. TLP has the benefit > of being able to configure that setting between when on AC and when on > BAT which is nice but I'm wondering is it a bug that I can no longer > change that setting in gnome control panel? Is this expected behaviour? One of the reasons to introduce power-profiles-daemon was the dbus API that gnome knows how to use. TLP and others do not provide the same API. power-profiles-daemon.service conflicts with tlp.service, probably because they'd both try to set the same settings. So if you want p-p-d.service, then make sure it is enabled and disable tlp.service. > Otherwise the upgrade has gone well. Great to hear that. I'd say that this cycle seems pretty smooth so far. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Potential Bugs - Where/What to file against
On Sat, 2021-10-16 at 15:40 +, Zbigniew Jędrzejewski-Szmek wrote:
> Try pressing ctrl-alt-f8 to switch to a text console. If the text
> login
> appears, then the issue was most likely in the graphics stack. If
> still
> blank, try pressing ctrl-alt-del. On a text console this should
> result
> in a reboot. If it reboots, you should be able to see logs with
> 'journalctl -b-1'. If it doesn't respond to ctrl-alt-del, then it's a
> kernel driver issue. Further debugging is possible, but let's check
> the
> easy things first.
Yeah, I tried ctrl-alt-{f2, f1} but nothing like f8 so will try that
next time. I did manually tell the system to suspend twice and then
closed the lid and it successfully resumed when I opened the lid the
next time. However I'll see if f8 or rebooting works.
>
> > #2 - In F34 Gnome control center -> battery I could choose the
> > laptops power profile (performance, balanced, powersave). This
> > seems to
> > be gone.
> > https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon
> > seems like its supposed to be supplying this, but systemd says the
> > service is masked. Looks like it is masked by TLP. TLP has the
> > benefit
> > of being able to configure that setting between when on AC and when
> > on
> > BAT which is nice but I'm wondering is it a bug that I can no
> > longer
> > change that setting in gnome control panel? Is this expected
> > behaviour?
>
> One of the reasons to introduce power-profiles-daemon was the dbus
> API
> that gnome knows how to use. TLP and others do not provide the same
> API. power-profiles-daemon.service conflicts with tlp.service,
> probably
> because they'd both try to set the same settings. So if you want
> p-p-d.service, then make sure it is enabled and disable tlp.service.
>
Right, that's kinda what I'm wondering though. I may have originally
installed tlp but don't recall. To be clearer about what I'm asking
about is, if p-p-d is the new default (and using this laptop with F34
had the options in control center). Why is p-p-d masked? Should it be?
how come the power options were available in gnome-control-center in
F34 when presumably both services existed there as well? Basically, it
was there in F34 and now its gone, but I'm told p-p-d is default in F35
so why did the option disappear and is it a bug?
--
Nathanael
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Can we disable the Fedora CI tests on pull requests?
On 15. 10. 21 7:37, Tom Stellard wrote: Hi, The Zuul CI for pull requests does everything that the Fedora CI does (scratch builds and tmt/standard tests) and more. Is there any reason to keep Fedora CI on pull requests? I like that we have a redundancy. When Zuul doesn't work, we look at the other one. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 8:04 AM Nico Kadel-Garcia wrote:
> On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi wrote:
> >
> > On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> > > On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia
> wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton
> wrote:
> > > > >
> > > > > https://fedoraproject.org/wiki/Changes/Ansible5
> > > > >
> > > > > == Summary ==
> > > > >
> > > > > The ansible project has re-organized how they release and
> distribute
> > > > > ansible. This change moves Fedora to be in sync with those changes
> and
> > > > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > > > 'ansible' package that pulls in ansible-core (the engine) and
> includes
> > > > > all the collections in upstream ansible releases.
> > > >
> > > > I wrote to the various upstream bugtrackers about this already. The
> > > > re-org upstream is confusing and unwelcome, and creates a stack of
> > > > problems.
> >
> > Yeah, it's been confusing to people for sure, but it does also help out
> > a lot with other problems. :(
>
> it could have made good sense, and still would, for the "ansible"
> package to be what is now being colloquially referred to as
> "ansible-core", but for which the published upstream git repo is still
> https://github.com/ansible/ansible, and which is and will remain
> accessible as a github release tarball with the old numbering. The
> pypi.org published "ansible-core" is a republication of that repo with
> a new name duck-taped on it. Fragmenting out the bulky and potentially
> dynamic set of tools that are now in the "galaxy collections" suite
> makes some sense, but the result is that to get any of the core
> modules like "ansible.posix" we wind up including 573 Megabytes of
> unneeded and unwelcome debris in
> /usr/lib/python3.6/site-packages/ansible_collections. Very few of us
> need more than 10% of the list
>
> There is no specific source repository for the "ansible_collections"
> tarball, as best I can tell. The list of modules selected from the
> galaxy collection is very large, but incomplete and I've not seen any
> criteria for what goes in that tarball and what does not. Have you
> seen any?
>
> I'd suggest that discarding the pypi.org renaming and instead using
> the raw tarballs from github as sources for individual galaxy
> collection modules helps resolve. This would keep the numbering of the
> "ansible" RPM consistent, and its core functionality. The modules
> which have been shifted to the galaxy collection, such as the "ec2"
> and "cisco" modules, could and should be bundled individually as
> Fedora has been doing quite effectively. I did some tests: an RPM of
> the current pypi.org tarball mislabeled as "ansible" occupies more
> than 570 MBytes of local disk. If you want a lightweight Ansible
> setup, say for applying some playbooks to your localhost, it's an
> unreasonable burden.
>
Why not have both?
* In my experience and anecdotally, most Ansible users want to do a `dnf
install ansible` and get the entire 570 MB worth of plugins. Therefore, it
makes sense for Fedora to provide such an RPM named `ansible`. And this is
what other distributions are doing.
* But as you point out, there are many use cases (small device, edge, low
bandwidth, low disk space) where having an `ansible-core` package + the
ability to install just the needed collections is preferable.
I think the `ansible-core` package should not `Provides: ansible` because
ansible-core is most definitely not the historical `ansible` package. It
is misleading at best, dangerous at worst.
> Those numbers do not include the documentation: The sphinx build of
> the HTML docs is something I've tried, but so far is not working with
> my test SRPM. As it is, I've had to rename doc or license files that
> have " " in the filename because the '%doc' and '%license' macros do
> not like whitespace in filenames, and split them up because a
> '%license' or '%doc' that have so many hundreds of entries overwhelms
> SRPM scripting. Packaging up the individual modules or sets of modules
> individually avoids this unwelcome burden.
>
> > > > I would publish ansible-core as just that, with a "Provides: ansible
> > > > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> >
> > That would radically diverge from upstream and cause _more_ confusion.
>
> Upstream already confused people. I don't think it justifies repeating
> their bundling mistakes, mistakes that are not reflected in the
> upstream source code for the software but only in intermediate
> repackaging and which Fedora has so far effectively avoided.
> ___
> 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_g
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On 10/15/21 16:29, Nico Kadel-Garcia wrote:
I would publish ansible-core as just that, with a "Provides: ansible
%{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
...
The "ansible" package could be a
meta package with "Requires: ansible-core ansible_collections" to
avoid the versioning confusion.
Those two things can't both be done, though, can they? If the
"ansible-core" package provides and obsoletes "ansible", then users
wouldn't be able to install the "ansible" package that requires
ansible_collections.
As a practical matter, I don't see any functional difference between the
proposed change (publishing an ansible-core package, and an ansible
package that contains collections) and your suggested alternative
(publishing an ansible-core package, and an ansible package that
requires collections), unless we disregard the meta package.
Publishing an ansible-core package that provides "ansible" (or more
specifically python3.Xdist(ansible)) wouldn't be compatible with the
updated Python packaging policy, which requires PyPI parity. Anything
that provides python3.Xdist(ansible) needs to provide at least a
complete compatible interface with the package from PyPI, and an
"ansible-core" package wouldn't.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora minimum hardware requirements
Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek: I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people The smallest device Fedora runs on, will propably be the Pinephone. ATM..it has 3 GB Ram and a 32 GB storage. A 20 GB base install + taking journald logsizes into account, gives 8 GB of usable space. I think any new reevaluation of "minimum" should really take mobil devices into account. Best regards, Marius Schwarz ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer wrote:
>
> On 10/15/21 16:29, Nico Kadel-Garcia wrote:
> >
> > I would publish ansible-core as just that, with a "Provides: ansible
> > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> ...
> > The "ansible" package could be a
> > meta package with "Requires: ansible-core ansible_collections" to
> > avoid the versioning confusion.
>
>
> Those two things can't both be done, though, can they? If the
> "ansible-core" package provides and obsoletes "ansible", then users
> wouldn't be able to install the "ansible" package that requires
> ansible_collections.
They *can* physically, but doing both together would get very silly.
I'd meant "do one or the other". The current model of "install
ansible, get a few Megabytes of material you actually use that is
almost entirely in ansible-core and 576 Megabytes of bulky material,
more than 90% of which you will never use" is awkward, and I'd much
rather see the galaxy collection packages published, and remain,
distinct. Discard the "ansible" package as an unwelcome approach, it's
too big and too confusing.
It does make me wish I'd been on the IRC channels that came up with
this bundling to walk through the concerns much earlier. In practical
terms and the relationship between Red Hat sponsored software like
Ansible, and Fedora development, I acknowledge that it may be too
late to revise. But that "too late" is a political and social issue,
not necessarily a technical one.
> As a practical matter, I don't see any functional difference between the
> proposed change (publishing an ansible-core package, and an ansible
> package that contains collections) and your suggested alternative
> (publishing an ansible-core package, and an ansible package that
> requires collections), unless we disregard the meta package.
It distinguishes the newly bundled ansible-core, which OK, that made
sense to fragment, from an extremely bulky and therefore brittle
bundle that is mostly unwelcome, even dangerous.
> Publishing an ansible-core package that provides "ansible" (or more
> specifically python3.Xdist(ansible)) wouldn't be compatible with the
> updated Python packaging policy, which requires PyPI parity.
If that's the locked in policy, and no exceptions. then I'd agree that
we as Fedora and as RHEL users are stuck with following PyPi and
ansible off the cliff in this case.
What, then, about the existing
ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the
like? Would those be swept up as part of the "ansible" package? I'd
dislike that, and if we or the current maintainers can keep them
separate, it presrves the groundwork for a much more modular and much,
much smaller ansible deployment.
> Anything
> that provides python3.Xdist(ansible) needs to provide at least a
> complete compatible interface with the package from PyPI, and an
> "ansible-core" package wouldn't.
That is a potential problem. Upstream broke it with the renumbering
without generating a distinct package. I don't think anyone or
anything will "Requires:" the new ansible package in RPM except as a
legacy entry for software that really relies on python components in
"ansible-core". I think they'll specifically need to import from
'ansible_collections' to get those individual python modules. It's
very messy.
There were a stack of options when ansible split up. Fedora is going
to have to deal with this peculiar layout one way or another. For
anyone who packages the new pypi "ansible" modules, I've some notes,
such as "rename the files with whitespace in their names", "Exchange
'#!/usr/bin/python' for '#!/usr/bin/python3'" and "#!/usr/bin/python'
for '#!/usr/bin/python3' for better cross-platform behavior, and
beware excessively long '%doc' and '%license' files with hundreds of
quite long entries.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 05:45:47PM -0400, Nico Kadel-Garcia wrote: > > They *can* physically, but doing both together would get very silly. > I'd meant "do one or the other". The current model of "install > ansible, get a few Megabytes of material you actually use that is > almost entirely in ansible-core and 576 Megabytes of bulky material, > more than 90% of which you will never use" is awkward, and I'd much > rather see the galaxy collection packages published, and remain, > distinct. Discard the "ansible" package as an unwelcome approach, it's > too big and too confusing. Then don't install it? For others it's comforting and welcome. "Hey, I can install all this stuff and it will be available if I want to use it, great!" ...snip... > What, then, about the existing > ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the > like? Would those be swept up as part of the "ansible" package? I'd no. > dislike that, and if we or the current maintainers can keep them > separate, it presrves the groundwork for a much more modular and much, > much smaller ansible deployment. collections can be packaged seperately. If you install 'ansible' and some seperate collections thats just fine. The seperate collections will be the version that gets used. So you can even up/downgrade from the version in 'ansible' if you want. If you want to install ansible-core and seperate specific collections you need, great, do that. ...snip... 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211016.n.1 changes
OLD: Fedora-Rawhide-20211015.n.0 NEW: Fedora-Rawhide-20211016.n.1 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 2 Dropped packages:1 Upgraded packages: 110 Downgraded packages: 2 Size of added packages: 1.38 MiB Size of dropped packages:9.25 MiB Size of upgraded packages: 1.85 GiB Size of downgraded packages: 4.37 MiB Size change of upgraded packages: -1.20 MiB Size change of downgraded packages: -189.65 KiB = ADDED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20211016.n.1.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20211016.n.1.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20211016.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: dwm-6.0-1.module_f36+13217+06e4c2f2 Summary: Dynamic window manager for X RPMs:dwm dwm-user Size:1.36 MiB Package: rust-devicemapper-sys-0.1.1-1.fc36 Summary: Low level bindings for devicemapper RPMs:rust-devicemapper-sys+default-devel rust-devicemapper-sys-devel Size:22.71 KiB = DROPPED PACKAGES = Package: quagga-1.2.4-20.fc36 Summary: Routing daemon RPMs:quagga quagga-contrib quagga-devel Size:9.25 MiB = UPGRADED PACKAGES = Package: Carla-1:2.4.1-1.fc36 Old package: Carla-1:2.4.0-1.fc36 Summary: Audio plugin host RPMs: Carla Carla-devel Carla-vst lv2-carla Size: 60.94 MiB Size change: -197.65 KiB Changelog: * Sat Oct 16 2021 Martin Gansser - 1:2.4.1-1 - Update to 2.4.1 Package: adobe-mappings-cmap-20190730-2.fc36 Old package: adobe-mappings-cmap-20190730-1.fc36 Summary: CMap resources for Adobe's character collections RPMs: adobe-mappings-cmap adobe-mappings-cmap-deprecated adobe-mappings-cmap-devel Size: 2.22 MiB Size change: 1.27 KiB Changelog: * Thu Oct 14 2021 Benjamin A. Beasley - 20190730-2 - Add Provides/Obsoletes to support ???cmap-resources??? retirement Package: analitza-21.08.2-1.fc36 Old package: analitza-21.04.3-1.fc35 Summary: Library of mathematical features RPMs: analitza analitza-devel Size: 3.34 MiB Size change: 82.78 KiB Changelog: * Fri Oct 15 2021 Rex Dieter - 21.08.2-1 - 21.08.2 Package: ansible-core-2.11.6-1.fc36 Old package: ansible-core-2.11.5-1.fc36 Summary: A radically simple IT automation system RPMs: ansible-core ansible-core-doc Size: 3.70 MiB Size change: 1.28 KiB Changelog: * Thu Oct 14 2021 Maxwell G - 2.11.6-1 - Update to 2.11.6. Package: artikulate-21.08.2-1.fc36 Old package: artikulate-21.04.3-1.fc35 Summary: Improve your pronunciation by listening to native speakers RPMs: artikulate artikulate-libs Size: 6.32 MiB Size change: -13.97 KiB Changelog: * Fri Oct 15 2021 Rex Dieter - 21.08.2-1 - 21.08.2 Package: autotrace-0.31.1-62.fc36 Old package: autotrace-0.31.1-61.fc36 Summary: Utility for converting bitmaps to vector graphics RPMs: autotrace autotrace-devel Size: 963.70 KiB Size change: -812 B Changelog: * Fri Oct 15 2021 Gwyn Ciesla - 0.31.1-62 - ImageMagick rebuild. Package: awscli-1.20.63-1.fc36 Old package: awscli-1.20.62-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.11 MiB Size change: 224 B Changelog: * Fri Oct 15 2021 Gwyn Ciesla - 1.20.63-1 - 1.20.63 Package: baloo-widgets-21.08.2-1.fc36 Old package: baloo-widgets-21.08.1-1.fc36 Summary: Widgets for Baloo RPMs: baloo-widgets baloo-widgets-devel Size: 917.31 KiB Size change: 760 B Changelog: * Fri Oct 15 2021 Rex Dieter - 21.08.2-1 - 21.08.2 Package: blinken-21.08.2-1.fc36 Old package: blinken-21.04.3-1.fc35 Summary: Memory Enhancement Game RPMs: blinken Size: 11.47 MiB Size change: 3.78 KiB Changelog: * Fri Oct 15 2021 Rex Dieter - 21.08.2-1 - 21.08.2 Package: chafa-1.8.0-2.fc36 Old package: chafa-1.8.0-1.fc36 Summary: Image-to-text converter for terminal RPMs: chafa chafa-devel chafa-doc chafa-libs chafa-static Size: 1.80 MiB Size change: 13.21 KiB Changelog: * Fri Oct 15 2021 Miro Hron??ok - 1.8.0-2 - Rebuilt for ImageMagick 6.9.12 Package: cinnamon-5.0.6-1.fc36 Old package: cinnamon-5.0.5-5.fc36 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8.64 MiB Size change: 114 B Changelog: * Fri Oct 15 2021 Leigh Scott - 5.0.6-1 - Update to 5.0.6 release Package: cjs-1:5.0.1-1.fc36 Old package: cjs-1:5.0.0-3.fc35 Summary: Javascript Bindings for Cinnamon RPMs: cjs cjs-devel cjs-tests Size: 3.38 MiB Size change: -852 B Changelog: * Fri Oct 15 2021 Leigh Scott - 1:5.0.1-1 - Update to 5.0.1 release Pa
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote: > > it could have made good sense, and still would, for the "ansible" > package to be what is now being colloquially referred to as > "ansible-core", but for which the published upstream git repo is still > https://github.com/ansible/ansible, and which is and will remain > accessible as a github release tarball with the old numbering. The > pypi.org published "ansible-core" is a republication of that repo with > a new name duck-taped on it. Fragmenting out the bulky and potentially > dynamic set of tools that are now in the "galaxy collections" suite > makes some sense, but the result is that to get any of the core > modules like "ansible.posix" we wind up including 573 Megabytes of > unneeded and unwelcome debris in > /usr/lib/python3.6/site-packages/ansible_collections. Very few of us > need more than 10% of the list If you don't need more, don't install 'ansible'. Just install ansible-core and use galaxy or seperate packaged collections to install just what you need. > There is no specific source repository for the "ansible_collections" > tarball, as best I can tell. The list of modules selected from the > galaxy collection is very large, but incomplete and I've not seen any > criteria for what goes in that tarball and what does not. Have you > seen any? Yes, but I can't seem to find it now. ;( Basically it was agreeing to use symantic versioning and agreeing to release on the same schedule as the rest, etc. I don't know if there's further requirements now. I'll find that doc and post it, but kinda weekending now. ;) ...snip... 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi, On Sat, 2021-10-16 at 15:33 -0700, Kevin Fenzi wrote: > On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote: > > > > it could have made good sense, and still would, for the "ansible" > > package to be what is now being colloquially referred to as > > "ansible-core", but for which the published upstream git repo is > > still > > https://github.com/ansible/ansible, and which is and will remain > > accessible as a github release tarball with the old numbering. The > > pypi.org published "ansible-core" is a republication of that repo > > with > > a new name duck-taped on it. Fragmenting out the bulky and > > potentially > > dynamic set of tools that are now in the "galaxy collections" suite > > makes some sense, but the result is that to get any of the core > > modules like "ansible.posix" we wind up including 573 Megabytes of > > unneeded and unwelcome debris in > > /usr/lib/python3.6/site-packages/ansible_collections. Very few of us > > need more than 10% of the list > > If you don't need more, don't install 'ansible'. Just install > ansible-core and use galaxy or seperate packaged collections to install > just what you need. > > > There is no specific source repository for the "ansible_collections" > > tarball, as best I can tell. The list of modules selected from the > > galaxy collection is very large, but incomplete and I've not seen any > > criteria for what goes in that tarball and what does not. Have you > > seen any? > > Yes, but I can't seem to find it now. ;( > Basically it was agreeing to use symantic versioning and agreeing to > release on the same schedule as the rest, etc. I don't know if there's > further requirements now. I'll find that doc and post it, but kinda > weekending now. ;) > > ...snip... > > kevin Here[1] is a link to the rules that collections must follow in order to be included in the `ansible` bundle. Here[2] is a link to the build data repository for the `ansible` package. This includes which versions of the collections exist in each version of the `ansible` package, as well as which versions of `ansible-core` each `ansible` package depends on. The Ansible team uses antsibull[3] to compile these releases. Thanks, Maxwell [1]: https://github.com/ansible-collections/ansible-inclusion [2]: https://github.com/ansible-community/ansible-build-data [3]: https://github.com/ansible-community/antsibull -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email signature.asc Description: This is a digitally signed message part ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 35 compose report: 20211016.n.1 changes
OLD: Fedora-35-20211015.n.0 NEW: Fedora-35-20211016.n.1 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 2 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 3.61 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 67.32 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-35-20211015.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: jq-1.6-10.fc35 Old package: jq-1.6-9.fc35 Summary: Command-line JSON processor RPMs: jq jq-devel Size: 1.20 MiB Size change: 62.64 KiB Changelog: * Wed Sep 29 2021 Davide Cavalca - 1.6-10 - Backport PR#1752 to fix an integer logic issue (rhbz#2008979) Package: wireplumber-0.4.3-3.fc35 Old package: wireplumber-0.4.3-1.fc35 Summary: A modular session/policy manager for PipeWire RPMs: wireplumber wireplumber-devel wireplumber-libs Size: 2.41 MiB Size change: 4.68 KiB Changelog: * Fri Oct 08 2021 Wim Taymans - 0.4.3-1 - wireplumber 0.4.3 * Mon Oct 11 2021 Peter Hutterer - 0.4.3-2 - Fix segfault due to a typo (#2012606) * Wed Oct 13 2021 Neal Gompa - 0.4.3-3 - Fix config setup in file list (#2013861) = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi Nico,
I understand your frustration about the Ansible reorganization, and I
agree that they could have documented it better, but I think that you
are missing the context surrounding this decision.
Oct 16, 2021 4:46:43 PM Nico Kadel-Garcia :
> On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer
> wrote:
> >
> > On 10/15/21 16:29, Nico Kadel-Garcia wrote:
> > >
> > > I would publish ansible-core as just that, with a "Provides:
> > > ansible
> > > %{version{-%{release}" and even "Obsoletes: ansible >=
> > > %{version}".
> > ...
> > > The "ansible" package could be a
> > > meta package with "Requires: ansible-core ansible_collections" to
> > > avoid the versioning confusion.
> >
> >
> > Those two things can't both be done, though, can they? If the
> > "ansible-core" package provides and obsoletes "ansible", then users
> > wouldn't be able to install the "ansible" package that requires
> > ansible_collections.
>
> They *can* physically, but doing both together would get very silly.
> I'd meant "do one or the other". The current model of "install
> ansible, get a few Megabytes of material you actually use that is
> almost entirely in ansible-core and 576 Megabytes of bulky material,
> more than 90% of which you will never use" is awkward, and I'd much
> rather see the galaxy collection packages published, and remain,
> distinct.
>
Fedora is not deprecating the current ansible-collection-* packages. If
you don't like the PyPi `ansible` package, then install the `ansible-
core` package and install the collections you want using the ansible-
collection-* Fedora packages or with `ansible-galaxy collection
install`, as the change description explains and Kevin reiterated.
> Discard the "ansible" package as an unwelcome approach, it's
> too big and too confusing.
I recommend you reread the initial post; it provides a good explanation
for why Ansible split most of the modules away from the core engine and
how the new packages (ansible-core and ansible) compare to the old
package (ansible 2.9). The new `ansible` package just contains the
collections that themselves contain the modules that, prior to Ansible
2.9, were hosted at github.com/ansible/ansible. The reason Ansible
created this new package was to avoid breaking existing workflows that
relied on those modules. Now, users can choose between installing the
collections manually or installing the `ansible` bundle.
>
>
> It does make me wish I'd been on the IRC channels that came up with
> this bundling to walk through the concerns much earlier. In practical
> terms and the relationship between Red Hat sponsored software like
> Ansible, and Fedora development, I acknowledge that it may be too
> late to revise. But that "too late" is a political and social issue,
> not necessarily a technical one.
I don't think this decision has anything to do with Fedora and RedHat's
relationship. All Fedora is really doing with this change is updating
the `ansible` package to the latest version available on PyPI. If you
were already using the `ansible-core` package, you can continue using
that. Fedora is not making any significant changes to that package with
this change.
> > As a practical matter, I don't see any functional difference
> > between the
> > proposed change (publishing an ansible-core package, and an ansible
> > package that contains collections) and your suggested alternative
> > (publishing an ansible-core package, and an ansible package that
> > requires collections), unless we disregard the meta package.
>
> It distinguishes the newly bundled ansible-core, which OK, that made
> sense to fragment, from an extremely bulky and therefore brittle
> bundle that is mostly unwelcome, even dangerous.
I don't think the `ansible` bundle is dangerous or unwelcome. The new
bundle is very helpful for people who don't want to deal with separate
dependencies and want to continue using Ansible as it used to be --
where all of the modules are included in one monolithic package.
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax@e.email
signature.asc
Description: This is a digitally signed message part
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: bodhi updates skipping updates-testing entirely
Fabio Valentini wrote:
> There seems to be some inconsistency with how our update workflow
> currently works. When an update gets enough positive karma "pre-push"
> (still in "pending → testing" state) so that it can be pushed to
> stable, bodhi changes its state to ("pending → stable"), making it
> skip the "updates-testing" repository entirely.
And that is a feature. We already have too many bureaucratic (minimum karma
requirements) and technical (at most one push per day) delays for updates.
Why can't a tested update go out to stable?
> That isn't that big of a problem most of the time, since "fedora" /
> "updates" and "updates-testing" repositories are composed daily, but
> during freezes, this leads to the weird problem that possibly
> important updates get stuck in a state where they are available from
> *no repository at all*.
That is the real problem that needs fixing, and the fix for that would be
for Bodhi to:
* if an update is in pending → stable state for Fedora n, AND
* if Fedora n is currently in a freeze (and ONLY in that case), THEN
1. push the update to testing instead AND
2. keep it queued for stable, i.e., put it into testing → stable state.
But there is no valid reason to do that for releases that are not frozen and
where the update can just go out directly to stable.
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
spdrs60: package review swap
Hello all, I have a new package request: https://bugzilla.redhat.com/show_bug.cgi?id=2011964 , which needs to be reviewed. If anyone is interested in a review swap — feel free to take it, and I can review another package in return. Thanks! -- wbr, Denis. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, 2021-10-15 at 16:31 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Ansible5 > > == Summary == > > The ansible project has re-organized how they release and distribute > ansible. This change moves Fedora to be in sync with those changes > and > retires the old 'ansible classic/2.9.x' package in favor of a > 'ansible' package that pulls in ansible-core (the engine) and > includes > all the collections in upstream ansible releases. Hi everyone, I have a couple comments/questions about this change. How will this effect EPEL? Is the plan to keep Ansible 2.9 there for now? Could we also consider making Ansible a modular package on both Fedora and EPEL? Then, it would be possible to install any of the currently supported versions of the Ansible core/engine (ansible 2.9, ansible- base 2.10, and ansible-core 2.11). Will the new `ansible` package have virtual provides for the collections it provides? While there is not a good reason to, it will still be possible to install both the new `ansible` package and any of the ansible-collection-* packages, right? Also, I would be happy to help with Ansible packaging in Fedora; however, I am not yet part of the packager group and still need a sponsor. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email signature.asc Description: This is a digitally signed message part ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20211016.n.1 compose check report
Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 12/141 (aarch64), 2/206 (x86_64) New failures (same test not failed in Fedora-Rawhide-20211015.n.0): ID: 1030161 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1030161 ID: 1030263 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1030263 ID: 1030321 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/1030321 ID: 1030325 Test: aarch64 universal install_package_set_minimal@uefi URL: https://openqa.fedoraproject.org/tests/1030325 ID: 1030361 Test: aarch64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/1030361 Old failures (same test failed in Fedora-Rawhide-20211015.n.0): ID: 1030114 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1030114 ID: 1030202 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1030202 ID: 1030203 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1030203 ID: 1030217 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1030217 ID: 1030228 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1030228 ID: 1030319 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1030319 ID: 1030324 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1030324 ID: 1030328 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1030328 ID: 1030358 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1030358 Soft failed openQA tests: 2/141 (aarch64), 4/206 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20211015.n.0): ID: 1030213 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1030213 Old soft failures (same test soft failed in Fedora-Rawhide-20211015.n.0): ID: 1030095 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1030095 ID: 1030134 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1030134 ID: 1030135 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1030135 ID: 1030140 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1030140 ID: 1030230 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1030230 Passed openQA tests: 200/206 (x86_64), 127/141 (aarch64) New passes (same test not passed in Fedora-Rawhide-20211015.n.0): ID: 1030071 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1030071 ID: 1030180 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1030180 ID: 1030255 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/1030255 ID: 1030261 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1030261 ID: 1030296 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1030296 ID: 1030350 Test: aarch64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/1030350 ID: 1030362 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1030362 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.36 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/1028728#downloads Current test data: https://openqa.fedoraproject.org/tests/1030019#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.11 to 0.28 Previous test data: https://openqa.fedoraproject.org/tests/1028735#downloads Current test data: https://openqa.fedoraproject.org/tests/1030026#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.26 to 0.40 Previous test data: https://openqa.fedoraproject.org/tests/1028749#downloads Current test data: https://openqa.fedoraproject.org/tests/1030040#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.31 to 0.13 Previous test data: https://openqa.fedoraproject.org/tests/1028785#downloads Current test data: h
Re: Fedora minimum hardware requirements
Marius Schwarz wrote: > Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek: >> I think that those numbers (20GB+2GB) are quite reasonable for the >> stated purpose of "install and run successfully". I think that people > The smallest device Fedora runs on, will propably be the Pinephone. > > ATM..it has 3 GB Ram and a 32 GB storage. A 20 GB base install + taking > journald logsizes into account, > gives 8 GB of usable space. > > I think any new reevaluation of "minimum" should really take mobil > devices into account. I think that what really needs to happen is that we stop just accepting and shrugging off that these requirements keep growing over time, all the time. If you compare with the requirements of Fedora Core 1: https://fedoramagazine.org/celebrate-fifteen-years-fedora/ the minimum RAM requirement has increased by a factor of more than 10 (compared to the minimum for graphical installation – there was also the Anaconda text mode that required 32 times less memory! And once installed, it was actually possible to use graphical desktop environments to some extent with even that). Disk space requirements have also increased around tenfold (8.33 times if you compare the current "Fedora Workstation" to the old "Workstation", 10.53 times if you compare it to the old "Personal Desktop"). There are several contexts in which bloat is a problem: older hardware, mobile devices, cloud servers, etc., but also simply for the time it takes to download an ISO. Unfortunately, most of the minimization efforts we had so far were focused only on one specific use case (mostly the cloud one) and relied on hacks completely stripping out functionality that other use cases need. Even as far as deleting the RPM database, which is an option only for a throwaway cloud image that never gets updated in place (i.e., a new image gets built instead). I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy! 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libcurl-minimal
Steve Grubb wrote: > I'd like to suggest making libcurl-minimal very minimal for security > reasons. The main curl package has many security issues (CVE's) > constantly. But usually, the problem is in some obscure feature/protocol. > Looking at the packages that depend on libcurl with rpmreaper, most would > use http(s). There might be some that use another protocol. But clear text > protocols like telnet and ftp really don't have a use in today's internet. > Too many threats for clear text. I suspect that disabling FTP in libcurl is going to break a lot of stuff. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 08:51:46PM -0500, Maxwell G via devel wrote: > > Hi everyone, > > I have a couple comments/questions about this change. > > How will this effect EPEL? Is the plan to keep Ansible 2.9 there for > now? For now yes, but 2.9 will go EOL at the end of the year (last I heard). > Could we also consider making Ansible a modular package on both Fedora > and EPEL? Then, it would be possible to install any of the currently > supported versions of the Ansible core/engine (ansible 2.9, ansible- > base 2.10, and ansible-core 2.11). No thanks. It would be a ton of effort, and those will all EOL soon or already have... (from the ansible 4.7.0 release announcement: "* Except for ansible-2.9.x, older versions of ansible are no longer seeing maintenance releases." > Will the new `ansible` package have virtual provides for the > collections it provides? While there is not a good reason to, it will > still be possible to install both the new `ansible` package and any of > the ansible-collection-* packages, right? I don't think we will do provides, that would cause problems installing the stand alone collections. So, yeah, we want to be able to install the stand alone collections along with or in addition to the bundle. > Also, I would be happy to help with Ansible packaging in Fedora; > however, I am not yet part of the packager group and still need a > sponsor. Thanks. I appreciate the PR's... :) 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-35-20211016.n.1 compose check report
No missing expected images. Failed openQA tests: 5/204 (x86_64), 8/141 (aarch64) New failures (same test not failed in Fedora-35-20211015.n.0): ID: 1030433 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/1030433 ID: 1030439 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/1030439 ID: 1030502 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/1030502 ID: 1030562 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1030562 ID: 1030572 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1030572 ID: 1030586 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1030586 ID: 1030620 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1030620 ID: 1030748 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/1030748 Old failures (same test failed in Fedora-35-20211015.n.0): ID: 1030519 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1030519 ID: 1030565 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1030565 ID: 1030605 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1030605 ID: 1030666 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1030666 ID: 1030722 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1030722 Soft failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211015.n.0): ID: 1030500 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1030500 ID: 1030539 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1030539 ID: 1030540 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1030540 ID: 1030549 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1030549 ID: 1030616 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1030616 ID: 1030633 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1030633 Passed openQA tests: 131/141 (aarch64), 195/204 (x86_64) New passes (same test not passed in Fedora-35-20211015.n.0): ID: 1030583 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1030583 ID: 1030724 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/1030724 ID: 1030736 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1030736 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.01 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/1029203#downloads Current test data: https://openqa.fedoraproject.org/tests/1030424#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.07 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/1029260#downloads Current test data: https://openqa.fedoraproject.org/tests/1030481#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) added since previous compose: biosdevname 1 services(s) added since previous compose: fwupd.service System load changed from 0.83 to 0.69 Previous test data: https://openqa.fedoraproject.org/tests/1029263#downloads Current test data: https://openqa.fedoraproject.org/tests/1030484#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 packages(s) added since previous compose: biosdevname Previous test data: https://openqa.fedoraproject.org/tests/1029276#downloads Current test data: https://openqa.fedoraproject.org/tests/1030497#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used mem changed from 818 MiB to 922 MiB Used swap changed from 2 MiB to 7 MiB 1 services(s) removed since previous compose: fwupd.service System load changed from 0.29 to 0.74 Previous test data: https://openqa.fedoraproject.org/tests/1029307#downloads Current test data: https://openqa.fedoraproject.org/tests/1030528#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used mem changed from 814 MiB to 937 MiB Used sw
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 10:22 PM Kevin Fenzi wrote: > > On Sat, Oct 16, 2021 at 08:51:46PM -0500, Maxwell G via devel wrote: > > > > Hi everyone, > > > > I have a couple comments/questions about this change. > > > > How will this effect EPEL? Is the plan to keep Ansible 2.9 there for > > now? > > For now yes, but 2.9 will go EOL at the end of the year (last I heard). I think someone is being very, very optimistic. It's especially tricky because EPEL does not keep previously released versions of software in their primary repos. If ansible the github tagged ansible 2.10, rebundled as ansible-core > > Could we also consider making Ansible a modular package on both Fedora > > and EPEL? Then, it would be possible to install any of the currently > > supported versions of the Ansible core/engine (ansible 2.9, ansible- > > base 2.10, and ansible-core 2.11). > > No thanks. It would be a ton of effort, and those will all EOL soon > or already have... Don't count on it. The python 3.8 requirement for ansible-core 2.12 and ansible 5.0, as described at Installing Ansible — Ansible Documentation is going to case difficulties porting it to RHEL especially RHEL 7. There are no "python38" or "python310" packages I've found for RHEL 7, except the SCLO packages which are awkward to use. Many people have been very, very reluctant to update to RHEL 8 and CentOS 8 for various reasons, so I expect to see some demand for ansible to roll back that pending required python update, or perhaps EPEL to organize a python310 suite of python components. > (from the ansible 4.7.0 release announcement: > > "* Except for ansible-2.9.x, older versions of ansible are no longer > seeing maintenance releases." > > > Will the new `ansible` package have virtual provides for the > > collections it provides? While there is not a good reason to, it will > > still be possible to install both the new `ansible` package and any of > > the ansible-collection-* packages, right? > > I don't think we will do provides, that would cause problems installing > the stand alone collections. So, yeah, we want to be able to install the > stand alone collections along with or in addition to the bundle. I'd prefer "instead of". That might require a more complete set of collection components, to avoid installing "ansible" and potentially conflicting. > > Also, I would be happy to help with Ansible packaging in Fedora; > > however, I am not yet part of the packager group and still need a > > sponsor. You'll also need a stiff drink. The process is slow because of the size of the monolithic collection, and the cleanups needed to get all the docs and licenses packaged. > Thanks. I appreciate the PR's... :) > > kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
