Re: Deprecating intents in Modularity
by Kevin Kofler
Matthew Miller wrote:
> Or, for example, if we had a "personal productivity apps" module, and you
> had KDE Plasma installed, you'd get a KDE-flavored set of these apps,
> while if you had GNOME Shell you'd get gtk ones. :)
Indeed, intents sounds like something we would want in more places, not
fewer ones. (I am thinking of comps in particular.) But of course, if, as
seems to be the status quo, it only theoretically works for modules, does
not really work even for modules in practice, and is not actually used by
modules, then it does not make sense.
Kevin Kofler
1 year, 7 months
Re: [Modularity] XML format for in-repository modules
by Petr Pisar
V Wed, Dec 07, 2022 at 02:23:21PM +0100, Petr Pisar napsal(a):
>
> I'd be glad to hear any comments on the format.
>
I forgot to mention that I'm taking my vacation now until the very end of this
callendar year. So no rush, but do not expect my reponse until then.
-- Petr
1 year, 6 months
Re: [Modularity] XML format for in-repository modules
by Daniel Alley
I will always applaud any attempt at standardizing & documenting the metadata format, and I was never thrilled with glib, so this sounds great to me - I only wish that it had been this way from the beginning :)
In practice I am not certain that Satellite (and similar tools) can prefer the XML metadata precisely because it is cut down, so in repos which contain both Yaml and XML metadata it will not be possible to recreate the original Yaml from the metadata in the XML without losing the "packager" specific bits, should they exist. Perhaps that is actually fine, but it makes me uncomfortable, and we have to support the Yaml parsing anyway due to the distros which will only ever support Yaml, which unfortunately makes it is the greatest common denominator.
I presume there are no plans to remove the Yaml metadata from repos entirely?
1 year, 6 months
Re: When is dnf5 going to replace dnf4?
by Nico Kadel-Garcia
On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel
<devel(a)lists.fedoraproject.org> wrote:
>
> Are there still some outstanding bugs preventing this from happening?
Is there any one critical feature that justifies the update? Avoiding
the requirement of python is... OK, maybe understandable, but I don't
see it as a "must-have" improvement. And better modularity support....
My observation so far is that modularity simply destabilizes systems,
because the authors of the "modularized" tools do not build up the
full suites of likely necessary components. I'm running into that
right now with python310 back in RHEL 8 for ansible, the results are
not pretty.
1 year, 4 months
Re: When is dnf5 going to replace dnf4?
by Demi Marie Obenour
On 1/28/23 18:06, Nico Kadel-Garcia wrote:
> On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel
> <devel(a)lists.fedoraproject.org> wrote:
>>
>> Are there still some outstanding bugs preventing this from happening?
>
> Is there any one critical feature that justifies the update? Avoiding
> the requirement of python is... OK, maybe understandable, but I don't
> see it as a "must-have" improvement. And better modularity support....
> My observation so far is that modularity simply destabilizes systems,
> because the authors of the "modularized" tools do not build up the
> full suites of likely necessary components. I'm running into that
> right now with python310 back in RHEL 8 for ansible, the results are
> not pretty.
At this point it might be better to just containerize Ansible.
Containers may waste resources and require extra effort to keep
up-to-date, but they *work*, and that is important. They also
*massively* reduce the test burden.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1 year, 4 months
When is it better to just use containers?
by Demi Marie Obenour
On 1/28/23 18:43, Demi Marie Obenour wrote:
> On 1/28/23 18:06, Nico Kadel-Garcia wrote:
>> On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel
>> <devel(a)lists.fedoraproject.org> wrote:
>>>
>>> Are there still some outstanding bugs preventing this from happening?
>>
>> Is there any one critical feature that justifies the update? Avoiding
>> the requirement of python is... OK, maybe understandable, but I don't
>> see it as a "must-have" improvement. And better modularity support....
>> My observation so far is that modularity simply destabilizes systems,
>> because the authors of the "modularized" tools do not build up the
>> full suites of likely necessary components. I'm running into that
>> right now with python310 back in RHEL 8 for ansible, the results are
>> not pretty.
>
> At this point it might be better to just containerize Ansible.
> Containers may waste resources and require extra effort to keep
> up-to-date, but they *work*, and that is important. They also
> *massively* reduce the test burden.
To elaborate: if I am an upstream developer for something like Ansible,
my options are either:
1. Ship a whole bunch of packages for a whole bunch of distributions
and make sure everything works across all of the various
dependency versions. This also means that I have to restrict
myself to the packages that e.g. RHEL 8 has, which might be
quite old.
2. Ship a single container that only needs to be QA’d once, works
everywhere, and has no dependencies except for the Linux kernel.
I get to update dependencies when *I* want to, and don’t have
to worry about breaking user’s systems. I can even ship a
shell script wrapper so that the container can be invoked as
a binary.
3. Something that I am not aware of (suggestions welcome).
It’s pretty easy to see why someone would go with option 2.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1 year, 4 months
Test upgrades from F37 to F38 - it will take you just a minute
by Miroslav Suchý
Do you want to make Fedora 38 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
--assumeno distro-sync
This command does not replace `dnf system-upgrade`, but it will reveals potential problems.
You may also run `dnf upgrade` before running this command.
The `--assumeno` will just test the transaction, but does not make the actual upgrade.
In case you hit dependency issues, please report it against the appropriate package.
Or against fedora-obsolete-packages if that package should be removed in Fedora 38. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" (F38FailsToInstall) reports:
https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
Thank you
Miroslav
1 year, 3 months
Re: Test upgrades from F37 to F38 - it will take you just a minute
by Luna Jernberg
Did this 16th February and it worked then, other then a few packages
missing in F38 that was in F37 then mostly Google Fonts and RPM Fusion
stuff
On 2/22/23, Miroslav Suchý <msuchy(a)redhat.com> wrote:
> Do you want to make Fedora 38 better? Please spend 1 minute of your time and
> try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveals
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the
> actual upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate
> package.
>
> Or against fedora-obsolete-packages if that package should be removed in
> Fedora 38. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F38FailsToInstall)
> reports:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
>
> Thank you
>
> Miroslav
>
1 year, 3 months
Re: Test upgrades from F37 to F38 - it will take you just a minute
by Steve Cossette
I just tried on a second PC, and I see this too on this one:
Lmod x86_64 8.7.18-1.fc38
fedora 258 k
Seems Lmod is of a lower version on Fedora 38 as well, compared to Fedora
37.
Le mer. 22 févr. 2023, à 04 h 30, Miroslav Suchý <msuchy(a)redhat.com> a
écrit :
> Do you want to make Fedora 38 better? Please spend 1 minute of your time
> and try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveals
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
> The `--assumeno` will just test the transaction, but does not make the
> actual upgrade.
>
>
> In case you hit dependency issues, please report it against the
> appropriate package.
>
> Or against fedora-obsolete-packages if that package should be removed in
> Fedora 38. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F38FailsToInstall)
> reports:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
> Thank you
>
> Miroslav
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
1 year, 3 months
Re: Test upgrades from F37 to F38 - it will take you just a minute
by Nathanael D. Noblet
On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote:
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo --
> enablerepo=updates-testing-modular) \
> --assumeno distro-sync
I got
Error:
Problem: package msv-xsdlib-1:2013.6.1-19.fc33.noarch requires
mvn(relaxngDatatype:relaxngDatatype), but none of the providers can be
installed
- jaxb-relaxng-datatype-2.3.5-7.fc37.noarch does not belong to a
distupgrade repository
- problem with installed package msv-xsdlib-1:2013.6.1-19.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)
I don't know why those are installed (I don't recognize the packages
and they aren't dependencies of anything I know I need) and just
removed them and everything was good after that.
1 year, 3 months
