Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
by Kevin Fenzi
On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
> Also a couple of notes on modularity here:
>
> # By default, module stream name is derived from the branch name
> If we have any "master" modules, those will get unexpectedly renamed
> as soon as they get rebuilt. This might impact tagging or updates and
> cause confusion in general. We should check if there are any like that
> and decide on further steps.
Good thing to check yes. I can try and do so.
> # Modules might be pulling components from their master branches to
> build Rawhide artifacts
> There are various use cases for this, too long to list. If the master
> ref is no longer available, these will not build. Modulemd files that
> pull components from master need to be updated after Phase 2.
Yep. +1
> # The modulemd component ref is optional and defaults to master
> Unless this got changed later, if the ref field is omitted, the value
> defaults to "master". This is part of the specification and is handled
> by libmodulemd. Not sure how to proceed here.
Can we change the default?
> And besides modularity:
>
> There are people and teams who use bots to autobuild their upstream
> projects in Rawhide. If they have a bot account (and I hope they do),
> they should be notified to update their tooling.
We don't have much tracking on bot accounts. People make them and sign
up for fas for them, etc.
We can try and find things that are obvious, but we are likely to miss
some. We can definitely help people who notice breakage tho.
kevin
3 years, 4 months
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make
Fedora CoreOS a Fedora Edition (System-Wide Change))
by Michael Catanzaro
On Sat, Dec 5, 2020 at 7:33 am, James Szinger <jszinger(a)gmail.com>
wrote:
> Undelivered -devel packages and modularity are killer anti-features of
> EL 8—it is way too hard to build the software I need.
Honestly I don't think modularity is a serious problem for end users.
Missing -devel packages is unbelievably frustrating, though. And EPEL
just doesn't contain as much as Fedora does, in general.
So for personal servers... well, I've never seen Fedora Server broken
by automatic updates. I don't think I would use Fedora Server for
critical business infrastructure, but it works well enough for my
personal needs. The odds of encountering problems with Fedora are
simply way lower than the odds of discovering that EPEL lacks something
that I want, or an essential -devel package that doesn't exist.
Michael
3 years, 4 months
GPG check FAILED for libuv on F32
by Endi Sukma Dewata
Hi, there seems to be a problem with libuv on F32.
It doesn't seem to be happening on F33. Is anybody
familiar with this? Thanks.
# podman run --rm -it fedora:32 dnf install libuv -y
Fedora 32 openh264 (From Cisco) - x86_64 1.5 kB/s | 2.5 kB 00:01
Fedora Modular 32 - x86_64 250 kB/s | 4.9 MB 00:20
Fedora Modular 32 - x86_64 - Updates 351 kB/s | 4.3 MB 00:12
Fedora 32 - x86_64 - Updates 466 kB/s | 28 MB 01:02
Fedora 32 - x86_64 533 kB/s | 70 MB 02:14
Dependencies resolved.
============================================================================================================================================================================================================================
Package Architecture Version Repository Size
============================================================================================================================================================================================================================
Installing:
libuv x86_64 1:1.40.0-1.fc32 updates 152 k
Transaction Summary
============================================================================================================================================================================================================================
Install 1 Package
Total download size: 152 k
Installed size: 393 k
Downloading Packages:
libuv-1.40.0-1.fc32.x86_64.rpm 202 kB/s | 152 kB 00:00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 100 kB/s | 152 kB 00:01
Package libuv-1.40.0-1.fc32.x86_64.rpm is not signed
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
--
Endi S. Dewata
3 years, 3 months
Re: Update on Modular Obsoletes and EOL change
by Matthew Miller
On Tue, Feb 09, 2021 at 09:48:28AM +0100, Petr Pisar wrote:
> If you wanted to implememt the aligned EOL, you would have to wait on a new
> Fedora release (because the exact day of EOL is not knows until a release is
> made), include the to-be-EOLed streams in the new release, then set the EOL,
> and publish it through updates. A user experience would be: At G.A. -- I have
> a new F33 with perl:5.28. A week after -- perl:5.28 EOLs in 4 weeks. If you
> wanted to prevent from this experience, relengs would have to clean up Beta
> and G.A. composes from the to-be-EOLed streams.
I'd rather fix this by pinning the EOL dates in advance. That's better for
people's planning anyway. We've hit our release targets enough times in a
row that I think we can be confident in doing this. If the release happens
to slip, we can extend the EOL in practice to match to give the needed extra
time.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 years, 2 months
Re: Strategy for staying on Rawhide
by Nico Kadel-Garcia
On Sun, Feb 14, 2021 at 2:41 PM Ron Olson <tachoknight(a)gmail.com> wrote:
>
> Hey all-
>
> I have a VM that I want to always keep on Rawhide. That was F34 until
> this past week or so and now I want to update it track F35. Can I
> basically just follow the instructions at
> https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ and
> pass it —releasever=rawhide; I did this when I went from F33 to
> Rawhide, but I wasn’t sure if I could do a “rawhide” to
> “rawhide” upgrade.
"It works, except when it doesn't". There can be some fundamental
changes in the boot loader, or in the filesystems, that are not
necessarily compatible. In particular you won't get the new default
filesystems or partitioning as those evolve, and you may encounter
brutal regressive bugs in features like SELinux or PAM, or
unanticipated changes in the UID's of commonplace users as Fedora
evolves. You can also encounter incompatible package naming
conventions. And modularity, well modularity is likely to *completely*
futz up upgrades. So it's a risk, and one that is difficult to
quantify.
3 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F33 to F34
by Sven Kieske
On Sa, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 34 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=34 --setopt=module_platform_id=platform:f34 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
--enablerepo=updates-testing --enablerepo=updates-testing-modular \
distro-sync
Fedora 34 openh264 (From Cisco) -
x86_64 365 B/s |
271 B 00:00
Errors during downloading metadata for repository 'fedora-cisco-openh264':
- Status code: 404 for https://codecs.fedoraproject.org/openh264/34/x86_64/repodata/repomd.xml (IP: 38.145.60.21)
Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Mhm, that was short:
Does that repo not exist anymore?
I can see it on the server, but the path has changed, is there no upgrade package available which fixes wrong repo files?for the record, I'm running this on fully up to date Fedora 32:
https://codecs.fedoraproject.org/openh264/34/x86_64/os/repodata/
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systementwickler
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 4-6
32339 Espelkamp
Tel.: 05772 / 293-900
Fax: 05772 / 293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer, Florian Jürgens
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit
gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.
3 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F33 to F34
by Adrian Reber
On Mon, Feb 22, 2021 at 09:10:27AM +0000, Sven Kieske wrote:
> On Sa, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote:
> > Do you want to make Fedora 34 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=34 --setopt=module_platform_id=platform:f34 \
> > --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> > distro-sync
>
> sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
> Fedora 34 openh264 (From Cisco) -
> x86_64 365 B/s |
> 271 B 00:00
> Errors during downloading metadata for repository 'fedora-cisco-openh264':
> - Status code: 404 for https://codecs.fedoraproject.org/openh264/34/x86_64/repodata/repomd.xml (IP: 38.145.60.21)
> Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
> Mhm, that was short:
>
>
> Does that repo not exist anymore?
> I can see it on the server, but the path has changed, is there no upgrade package available which fixes wrong repo files?for the record, I'm running this on fully up to date Fedora 32:
>
> https://codecs.fedoraproject.org/openh264/34/x86_64/os/repodata/
You probably have an outdated repository definition in /etc/yum.repos.d.
Your /etc/yum.repos.d/fedora-cisco-openh264.repo should have following
line:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-ope...
Maybe there is a .rpmnew file and you are still using the old baseurl
based repository definition.
Adrian
3 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F33 to F34
by Miroslav Suchý
Dne 22. 02. 21 v 23:52 Zbigniew Jędrzejewski-Szmek napsal(a):
>>> Error: Unknown repo: 'updates-testing-modular'
> That's not an error really. You don't have 'fedora-repos-modular'
> package installed, so this repository is not available. Miroslav's
> command simply assumes that you have modules enabled.
>
*nod* Previously, it was part of fedora-repos and you could not remove it. Just disable.
Now you can remove it.
I will ammend fedora-upgrade script and next time the email.
Nice catch.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
3 years, 2 months
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
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
2 years, 12 months
