Re: dnf repoquery and installed module problem
by Miro Hrončok
On 12. 04. 21 14:23, Richard Shaw wrote:
> I'm trying to collect the provides from the openexr package so I know what needs
> to be rebuilt in Rawhide but the repoquery command fails due to a module I have
> installed:
>
> $ dnf repoquery --repoid rawhide --provides openexr > provides
> Fedora - Rawhide - Developmental packages for t 12 MB/s | 57 MB 00:04
> Last metadata expiration check: 0:00:14 ago on Mon 12 Apr 2021 07:17:08 AM CDT.
> Modular dependency problem:
>
> Problem: conflicting requests
> - nothing provides module(platform:f33) needed by module
> nodejs:12:3320210223224147:601d93de.x86_64
>
> If I'm trying to do a repoquery of another release, in this case rawhide, I
> really don't care about anything I have installed on my f33 machine. Am I going
> to have to start doing this in mock?
Enabled modular streams break repoquery for other repos, but it is designed that
way, so the bug was closed:
https://bugzilla.redhat.com/show_bug.cgi?id=1806204
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 2 months
Re: RPM name collisions
by Matthew Miller
On Thu, May 06, 2021 at 08:56:47AM +0200, Daniel Mach wrote:
> To be clear, I like the idea of vendor/repo stickiness turned on by
> default, it could solve a lot of problems and eventually provide a
> very simple alternative to modularity. I'm just not convinced that
I'm glad you mentioned this, because that's my thought too. DNF 5 with
modularity 2.0 :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 years, 1 month
Re: [ELN] Creating a process for ELN-specific changes
by Stephen Gallagher
On Fri, May 14, 2021 at 11:25 AM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
>
> On Fri, May 14, 2021 at 11:21:26AM -0400, Stephen Gallagher wrote:
> > > Can we provide these things as modules and make them available in both?
> > > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora
> > > Linux wanting the option and if the ELN folks are maintaining a package
> > > _anyway_....
> > That's going to be up to the individual maintainers; I don't want to
> > sidetrack the ELN discussion too much.
>
> OK, so let me generalize: isn't "make it a module" the general answer when
> different versions of the package are desired?
ELN's purpose is to be a staging ground for the next major release of
enterprise linux. If this is a package that is intended to be in the
non-modular set for EL N+1, then it needs to be non-modular in ELN (so
we can calculate the dependencies properly). If it is intended to be a
module in EL N+1, then ideally it should be a module in ELN (if we can
figure out how to get that to work properly; there are technical
issues there that make modules built for Fedora not directly
importable to CentOS Stream/RHEL).
3 years, 1 month
Re: [ELN] Creating a process for ELN-specific changes
by Matthew Miller
On Fri, May 14, 2021 at 06:38:33PM +0200, Miro Hrončok wrote:
> I wouldn't say so. I'd say "package both versions as separate
> non-modular RPM packages with unique names" is the general answer
> when different versions of the package are desired.
>
> However, the problem here is different. We don't want 2 different
> versions packaged in Rawhide AND 2 different versions packaged in
> ELN. We want to allow package versions in ELN and Rawhide to be
> different.
This is exactly a case that modularity is supposed to handle. Two different
versions packaged only one time each, built for both targets automatically,
with one the default on target A and the other the default on target B,
output, but with either version selectable in either target.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 years, 1 month
Re: package maintainer email aliases, now with more epel
by Kevin Fenzi
On Tue, Jun 22, 2021 at 03:00:48PM +0200, Miro Hrončok wrote:
> On 21. 06. 21 23:05, Kevin Fenzi wrote:
> > Greetings.
> >
> > As a reminder, if you need to reach package maintainers for a specific
> > package in private, you can email:
> > packagename-maintainers(a)fedoraproject.org
> >
> > You can also now mail:
> > packagename-maintainers-fedora(a)fedoraproject.org to just reach the
> > fedora branch(es) maintainer(s).
> >
> > or
> >
> > packagename-maintainers-epel(a)fedoraproject.org to just reach the epel
> > branch(es) maintainer(s).
>
> Hey, Kevin. I don't think I understand how does the "just the fedora/epel
> branch(es) maintainer(s)" definition work.
>
> Suppose we have a package like this:
>
> main admin:
> anna
>
> co-maintainers:
> bob (admin)
> cora (commit)
> dave (ticket)
> emma (collaborator for epel branches only)
> zodiac (collaborator for the modular stream branches only)
>
> Bugzilla Assignee:
> Fedora:
> anna
> EPEL:
> emma
>
> Who gets what email? I suppose we can assume that emma is the main EPEL
> maintainer here, but is anna also maintaining the epel branch or does she
> not? And what about the others?
The script is here:
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/packager_alias/f...
But my understanding is:
packagename-maintainers: anna, bob, cora
packagename-maintainers-fedora: anna, bob, cora
packagename-maintainers-epel: emma
ie, admin, commit only for these aliases, not tickets and modular isn't
taken into account.
I'm sure we could improve it more...
kevin
2 years, 12 months
Re: building against epel8 modules
by Nico Kadel-Garcia
On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
>
>
>
> On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
> > Welcome to RHEL-8 modularity and the joy it brings anyone trying to
> > port software to 8. The problem is not with EPEL but with the way
>
> hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in twilight :-)
I can't find *anyone* who likes modularity. I'm devoutly hoping that
it is discarded for RHEL 9.
2 years, 12 months
Re: building against epel8 modules
by Josh Boyer
On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
> >
> >
> >
> > On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
>
> > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to
> > > port software to 8. The problem is not with EPEL but with the way
> >
> > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore
> darkness in twilight :-)
>
> I can't find *anyone* who likes modularity. I'm devoutly hoping that
> it is discarded for RHEL 9.
>
For the record, it is not being discarded in RHEL 9.
josh
2 years, 11 months
Re: Donate 1 minute of your time to test upgrades from F34 to F35
by Marcin Juszkiewicz
On 07.09.2021 18:14, Miroslav Suchý wrote:
> Do you want to make Fedora 35 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 '*'
>
> sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \
>
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>
> distro-sync
[root@puchatek hrw]# LANGUAGE=C LC_ALL=C LANG=C dnf --releasever=35
--setopt=module_platform_id=platform:f35 --enablerepo=updates-testing
--enablerepo=updates-testing-modular distro-sync
Last metadata expiration check: 0:28:08 ago on Tue Sep 7 20:16:12 2021.
Error:
Problem: package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64 requires
qt5-qtbase(x86-64) = 5.15.2-16.fc34, but none of the providers can be
installed
- qt5-qtbase-5.15.2-16.fc34.x86_64 does not belong to a distupgrade
repository
- problem with installed package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Removed "qt5-qtbase-ibase" package and distrosync command went fine:
Install 118 Packages
Upgrade 4434 Packages
Remove 3 Packages
Downgrade 14 Packages
Total download size: 4.3 G
Is this ok [y/N]:
2 years, 9 months
Re: Donate 1 minute of your time to test upgrades from F34 to F35
by Otto Urpelainen
Miroslav Suchý kirjoitti 7.9.2021 klo 19.14:
>
> sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \
>
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>
> distro-sync
Error:
Problem 1: package arduino-core-1:1.8.13-5.fc34.noarch requires
mvn(org.ow2.asm:asm-all), but none of the providers can be installed
- objectweb-asm-8.0.1-2.fc34.noarch does not belong to a distupgrade
repository
- problem with installed package arduino-core-1:1.8.13-5.fc34.noarch
Already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2001333
Problem 3: problem with installed package gnuradio-3.9.0.0-5.fc34.x86_64
- package gnuradio-3.9.2.0-5.fc35.x86_64 requires
libcodec2.so.0.9()(64bit), but none of the providers can be installed
- gnuradio-3.9.0.0-5.fc34.x86_64 does not belong to a distupgrade
repository
- codec2-0.9.2-7.fc34.x86_64 does not belong to a distupgrade repository
This is already discussed in this thread, but was not in Bugzilla, so I
reported it there:
https://bugzilla.redhat.com/show_bug.cgi?id=2002142
Problem 4: problem with installed package gqrx-2.14.4-1.fc34.x86_64
- package gqrx-2.14.4-5.fc35.x86_64 requires
libboost_thread.so.1.75.0()(64bit), but none of the providers can be
installed
- gqrx-2.14.4-1.fc34.x86_64 does not belong to a distupgrade repository
- boost-thread-1.75.0-4.fc34.x86_64 does not belong to a distupgrade
repository
Reported twice already:
https://bugzilla.redhat.com/show_bug.cgi?id=1991876
https://bugzilla.redhat.com/show_bug.cgi?id=2002104
Problem 5: package postgresql-server-devel-13.4-1.fc35.x86_64 requires
postgresql-private-devel, but none of the providers can be installed
- package postgresql-private-devel-13.4-1.fc35.i686 conflicts with
libpq-devel provided by libpq-devel-13.4-1.fc35.x86_64
- package postgresql-private-devel-13.4-1.fc35.x86_64 conflicts with
libpq-devel provided by libpq-devel-13.4-1.fc35.x86_64
- problem with installed package
postgresql-server-devel-13.4-1.fc34.x86_64
- problem with installed package libpq-devel-13.4-1.fc34.x86_64
- postgresql-server-devel-13.4-1.fc34.x86_64 does not belong to a
distupgrade repository
- libpq-devel-13.4-1.fc34.x86_64 does not belong to a distupgrade
repository
- package
postgresql-private-devel-13.4-1.module_f35+12619+a275bc38.x86_64 is
filtered out by modular filtering
This is apparently a case where the user just has to pick one or the other:
https://src.fedoraproject.org/rpms/postgresql/blob/f35/f/postgresql.spec#...
2 years, 9 months
Re: Modularity: New modulemd-packager format for building modules
by Neal Gompa
On Fri, Sep 10, 2021 at 8:26 AM Petr Pisar <ppisar(a)redhat.com> wrote:
>
> Good news, module maintainers.
>
> I'm relieved to announce an availability of the new module packaging format,
> modulemd-packager, version 3.
>
So this certainly solves a lot of issues, but it's still frustrating
to see that we *need* to declare the platform and that we couldn't
inherit the platform from the build environment. This means that at
branching time, we need to make a commit to change the requested
platform.
That being said, does the platform value influence how the final
modulemd is generated? That is, if I made a system that accepted this
YAML file as input but *ignored* the platform value (and the platform
was forced by other means), would a module build still produce working modules?
--
真実はいつも一つ！/ Always, there's only one truth!
2 years, 9 months
