We (the Anaconda installer team) want to solve multiple problems by one
solution and we want
In short we are proposing to use custom repo files when configuring
Anaconda for image creation instead of adding even more complexity to
the kickstart repo command. For more details see the link below.
Purpose of this mail is to give everyone interested in the topic a
place to discuss our proposal to find out if we didn't miss something
or better case, if you agree with it :). It could be that this is not
applicable for Lorax / Pungi / live-cd tool in that case please write a
response to the document.
You can read details here:
Please, all the relevant comments should stay in the document if
possible. If that solution won't work because of higher traffic then we
will find a better solution but the point is to have everything on one
Have a great day everyone,
I'm Anaconda developer and I'm also taking care about our
infrastructure and this Fedora release brought me a plenty of
"unnecessary" work thanks to the fact that compose for Fedora 31 was
not available until a week before beta freeze. That is too late.
I wasn't the only one who had these problems, copr had issues for
Fedora 31 and couldn't enable chroot so they had to do changes to
correct these broken things. And I'm not talking about Fedora QA team
which couldn't test almost anything before beta freeze.
The problem is that when we don't have a compose we don't have packages
for testing and then more and more changes are getting in but we are
not able to check if they are working. If we don't have packages the
mock can't properly work and you are not able to do a system upgrade.
The only test point is compose but that is just a small portion. Not
being able to test Fedora for a few weeks is situation which should not
To make things even worse there was a switch to python 3.8 on Rawhide
which wasn't really prepared (pylint did not worked). So for a few days
we were with broken Fedora 31 and Rawhide too, so most of our tests
were not working. I would really said that we were programming in the
dark. No tests, no check that changes are working. It took me almost a
week to make everything working again not talking about time spend
waiting for the compose to be available.
I want to ask for an improvement here. Ideal solution for me would be
to add rule that there have to be compose to do the branching and if
the compose fails then the branching won't happen. Not sure if this is
doable or how hard it would be to implement a similar rule, however, it
would be an ultimate solution. Then, the compose blocker bugs had to be
solved on Rawhide where they should be solved.
Please tell me what should I do next. Should I file a FESCO ticket to
add this rule?
I've been taking a look at:
And I think that this is a very good idea to help us
focus on important issues.
I've already fixed:
1490490 Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS
From the "Unsolved bugs, previously approved as Prioritized and now removed from the list"
list and this bug has also been fixed already:
1750120 unable to paste/copy between host and guest
I was about to update the page for this, but then I noticed that it is
autogenerated, can someone please re-run the script which generates
it to get this updated.
Note I'm looking into:
1405539 changing the default keyboard layout changes also disk decryption in plymouth, but only after kernel update, long after
I've some ideas but this is going to be F32 material.
(Note that this was orignally submitted for Fedora 28)
== Summary ==
Update the MPFR package to version 4.0.2.
== Owner ==
* Name: [[User:jamesturner246| James Paul Turner]]
* Email: jamesturner246(a)fedoraproject.org
* Name: [[User:jjames| Jerry James]]
* Email: loganjerry(a)gmail.com
== Detailed Description ==
The purpose of this change is to update the Fedora MPFR package to the
latest version (4.0.2), released on the 31st January 2019. Due to a
soname bump, this change will rebuild all packages that depend on
== Benefit to Fedora ==
The MPFR team have released many optimisations, bugfixes and features
since the current version (3.1.6), released back on the 7th September
2017. This change will allow several important Fedora packages,
including the GCC, to take advantage of this.
Refer to http://www.mpfr.org/mpfr-4.0.0/#changes,
http://www.mpfr.org/mpfr-4.0.2/#changes for the complete list of
== Scope ==
* Proposal owners:
** Rebuild of packages that depend on MPFR
** Minor specfile corrections and testing
* Other developers:
** Testing and/or minor fixes of dependant packages
* Release engineering: [https://pagure.io/releng/issue/7247 #7247]
** Separate Koji tag for package rebuild will be needed.
of deliverables]]: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
All existing user binaries built against MPFR 3.1.6 will need to be
rebuilt against MPFR 4.0.2.
== How To Test ==
* No special hardware / data / etc. is needed.
* To test, install mpfr-4.0.2, then rebuild and test existing user binaries.
* Try to locally rebuild your packages with mpfr-4.0.2.
* Report failures and other problems to us.
== User Experience ==
The MPFR dependent packages should behave as they did with mpfr-3.1.6.
== Dependencies ==
dnf repoquery --whatrequires mpfr
== Contingency Plan ==
*Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with mpfr-4.0.2. If
anything goes wrong, the tag can be easily dropped, and previous
version of mpfr-3.1.6 and its dependencies stays intact. The tag would
be merged into F32 after everything is rebuilt.
* Contingency deadline: Mass Rebuild
* Blocks release? No
* Blocks product? No
== Documentation ==
Documentation can be found upstream at http://www.mpfr.org/mpfr-4.0.2.
He / Him / His
Fedora Program Manager
Are the aarch64 test systems running on real or emulated hardware? (Is
there a way to tell?)
I ask because I'm seeing bad numerical results from a test and would
like to know if I can eliminate qemu as a possible cause -- not that I
think that's likely.
On Fri, Sep 20, 2019 07:11:45 -0500, Vendaval wrote:
> Welcome, Alciregi
> thanks for helping a lot.
> P.D: Can I be sponsored too?
Yes---I was going to ask you and @dan1mal about joining up to
co-maintain the packages too since you two are managing the lab lab/spin
for us :).
Will you please ping me in the channel when you are online and I'll get
you set up also?
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London