Re: Donate 1 minute of your time to test upgrades from F35 to F36
by Ian Laurie
On 3/12/22 04:43, Miroslav Suchý wrote:
>
> dnf --releasever=36 --setopt=module_platform_id=platform:f36 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
For me the only error I received was:
Error:
Problem: package VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64
requires libvpx.so.6()(64bit), but none of the providers can be installed
- libvpx-1.10.0-2.fc35.x86_64 does not belong to a distupgrade repository
- problem with installed package
VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
--
Ian Laurie
ilaurie(a)bigpond.net.au
2 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F35 to F36
by mark.e.fuller＠gmx.de
I have the following errors:
Error:
Problem 1: package avogadro-libs-1.2.0-35.fc35.x86_64 requires libGLEW.so.2.1()(64bit), but none of the providers can be installed
- libGLEW-2.1.0-10.fc35.x86_64 does not belong to a distupgrade repository
- problem with installed package avogadro-libs-1.2.0-35.fc35.x86_64
Problem 2: package julia-1.7.0.0-1.fc36.x86_64 requires libmbedcrypto.so.3()(64bit), but none of the providers can be installed
- package julia-1.7.0.0-1.fc36.x86_64 requires libmbedtls.so.12()(64bit), but none of the providers can be installed
- package julia-1.7.0.0-1.fc36.x86_64 requires libmbedx509.so.0()(64bit), but none of the providers can be installed
- problem with installed package julia-1.7.2-1.fc35.x86_64
- mbedtls-2.16.12-1.fc35.x86_64 does not belong to a distupgrade repository
- julia-1.7.2-1.fc35.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)
On 14/03/2022 5:39, Ian Laurie <ilaurie(a)bigpond.net.au> wrote:
> On 3/12/22 04:43, Miroslav Suchý wrote:
> >
> > dnf --releasever=36 --setopt=module_platform_id=platform:f36 \
> > --enablerepo=updates-testing \
> > $(rpm -q fedora-repos-modular >/dev/null && echo
> > --enablerepo=updates-testing-modular) \
> > --assumeno distro-sync
>
> For me the only error I received was:
>
> Error:
> Problem: package VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64
> requires libvpx.so.6()(64bit), but none of the providers can be installed
> - libvpx-1.10.0-2.fc35.x86_64 does not belong to a distupgrade
> repository
> - problem with installed package
> VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64
> (try to add '--skip-broken' to skip uninstallable packages)
>
>
>
2 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F35 to F36
by Luna Jernberg
Hey!
Have a hospital visit and some other stuff in 14 minutes, but will help to
do some testing when i get back home or later during the week
On Fri, Mar 11, 2022 at 6:43 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
> Do you want to make Fedora 36 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=36 --setopt=module_platform_id=platform:f36 \
> --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 reveal
> 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 36. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F36FailsToInstall)
> reports:
>
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1992487&bug_id_type=anddep...
>
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
2 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F35 to F36
by Richard Shaw
On Fri, Mar 11, 2022 at 11:43 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
> Do you want to make Fedora 36 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=36 --setopt=module_platform_id=platform:f36 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
I didn't run and upgrade/update first but I don't think it would affect
this problem:
Error:
Problem 1: lilv-0.24.10-4.fc35.i686 has inferior architecture
- lilv-0.24.10-4.fc35.x86_64 does not belong to a distupgrade repository
- problem with installed package lilv-0.24.10-4.fc35.i686
Problem 2: package openrgb-0.6-1.fc34.x86_64 requires
libmbedcrypto.so.3()(64bit), but none of the providers can be installed
- package openrgb-0.6-1.fc34.x86_64 requires libmbedtls.so.12()(64bit),
but none of the providers can be installed
- package openrgb-0.6-1.fc34.x86_64 requires libmbedx509.so.0()(64bit),
but none of the providers can be installed
- mbedtls-2.16.12-1.fc35.x86_64 does not belong to a distupgrade
repository
- problem with installed package openrgb-0.6-1.fc34.x86_64
The first problem is related to steam from RPM Fusion.
Second problem, looks like openrgb needs to be rebuilt?
Thanks,
Richard
2 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F35 to F36
by py0xc3
Works widely fine with me.
But some downgrades in dnf:
Downgrading:
python3-cffi x86_64 1.15.0-2.fc36
fedora 244 k
thunderbird x86_64 91*.4*.0-1.fc36
fedora 96 M
thunderbird-librnp-rnp x86_64 91*.4*.0-1.fc36
fedora 1.0 M
In Fedora 35, thunderbird & thunderbird-librnp-rnp are currently at
91*.6*.2-1.fc35. So this would be really a downgrade. I assume this is
not intended.
python3-cffi is just another build of the same version (1.15.0-2.fc36
<-> 1.15.0-4.fc35).
> On Fri, 11 Mar 2022 at 17:43, Miroslav Suchý <msuchy(a)redhat.com> wrote:
>
> Do you want to make Fedora 36 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=36 --setopt=module_platform_id=platform:f36 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
2 years, 2 months
Re: What has the PDC ever done for us?
by Petr Pisar
V Thu, Mar 17, 2022 at 04:13:44PM +0100, Tomas Hrcka napsal(a):
> On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar <ppisar(a)redhat.com> wrote:
> > Having the dist-git retirement as a primary source of truth has the problem
> > that you need to clone a dist-git branch to get the data. And then for each
> > package you are interested again and again. Whereas PDC, being a database
> > underneath, have the data centralized at one place, and readily available
> > in
> > no time.
> >
>
> distgit is basically pagure in it has a DB we were thinking about moving
> package-specific data like EOL to in information already stored in the DB
> for each repository.
I cannot parse your sentence. Does it mean there is one database which
stores all the data about all repositories, or does it mean that each
repository has its own database?
Is this Pagure/dist-git database publically accessible for reading?
> This would allow us to use specific EOL for modules.
>
In modularity I want to deliver the EOL dates to user's YUM repositories so
that "dnf module list" can list them and alert users about EOLed module stream
they use (bug #2054662).
We already have a mechanism for delivering the data to the YUM repositories
<https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/m...>.
But the mechanism relies on a manual input
<https://pagure.io/releng/fedora-module-defaults/blob/main/f/obsoletes>. It's
manual because one of the purposes if the mechanism is delivering which stream
replaces which one. But the EOL dates could be filled automaticaly.
That's why I'm so obsessed with PDC.
-- Petr
2 years, 2 months
Re: fedpkg request-branch doesn't work as expected
by Petr Pisar
V Wed, Mar 23, 2022 at 10:24:35AM -0600, Orion Poplawski napsal(a):
> When I do:
>
> [orion@vmrawhide-rufous zabbix (rawhide *+)]$ fedpkg request-branch
> --no-auto-module --sl rawhide:2027-06-01 -- 6.0
>
> It generates a request for a branch named "rawhide". I'm following:
>
> https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/a...
>
> fedpkg-1.42-1.fc36.noarch
>
> Is this a bug in fedpkg or an issue with the docs?
>
"fedpkg request-branch --help" recommends a different syntax:
Request a branch with service level tied to the branch. In this case branch
argument has to be before --sl argument, because --sl allows multiple values.
fedpkg request-branch branch_name --sl bug_fixes:2020-06-01 rawhide:2019-12-01
Especially note the "branch argument has to be before --sl argument" remark.
Maybe the "--" separator triggers a different parsing of the arguments.
I don't know the implementation details of fedpkg.
I would definitely recommend changing the Modularity documentation to follow
fedpkg help usage. Although I don't like the fedpkg syntax, we should not rely
on undocumented behaviour.
Try:
fedpkg request-branch 6.0 --no-auto-module --sl rawhide:2027-06-01
I would also like to hear an explanation of the various --sl types. I always
only used bug_fixes.
-- Petr
2 years, 1 month
[modules] 'fedpkg request-branch' - how ?
by Michal Schorm
Hello,
I want to create a new module stream.
All the RPMs repos and the Module repo exist. I just need new branches
in all of them.
However I've run into a deadlock.
Non-release branches require SL to be defined. And SL before it is
defined checks that such a branch exists.
| fedpkg request-branch 10.8
| Could not execute request_branch: You must provide SLs for
non-release branches (10.8)
|
| fedpkg request-branch 10.8 --sl 10.8:2030-12-01
| Could not execute request_branch: The SL "10.8" is not in PDC
--
Beside that, the
| fedpkg request-branch -h
doesn't explain what will be the content of the newly created branch.
In my case it would suit me best to call the command from inside of
repo and the new branch to be created as a copy of the currently
checked out branch.
(So it would be similar as 'git checkout -b ... ')
Should I rather use the '--no-git-branch' argument to create the
branch as I need ?
Can I actually do that, since SL needs the branch to exist first ??
I also don't understand what happens when in a case of module named
'X', consisting of RPMs named 'X' and 'Y', I go to the RPM 'Y' and
call the 'fedpkg-request branch' without '--no-auto-module'.
Will that create a new modular repo named 'Y' ?
Will that create a branch with a name I choosed in the modular repo 'X' ?
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
1 year, 11 months
Rawhide: gnome-software: "not a public key" for F39 GPG Key
by Marius Schwarz
Hi,
FYI: AARCH64 rawhide produces this output every now and than ...
Aug 17 10:18:16 fedorapine gnome-software[1203]: failed to refresh the
cache: PKI file
/var/cache/PackageKit/38/metadata/rawhide-modular-rawhide-aarch64.tmp/RPM-GPG-KEY-fedora-39-aarch64
is not a public key
Aug 17 10:18:16 fedorapine gnome-software[1203]: failed to refresh the
cache: PKI file
/var/cache/PackageKit/38/metadata/rawhide-modular-rawhide-aarch64.tmp/RPM-GPG-KEY-fedora-39-aarch64
is not a public key
best regards,
Marius Schwarz
1 year, 9 months
