I was starting to setup CI for one of my packages in Fedora (cscope),
which requires that I have access to the sources to run my test (cscope uses its
own source tree to search for various symbols to confirm that its working
properly). Getting the sources in the CI environment is a bit of a pain, so I
started working on trying to do this by creating a test subpackage (specifically
named -citest) to package up the sources solely for the purpose of getting them
installed and available during CI runs. It occured to me that this offers
several advantages, among them:
1) the ability to codify dependencies within the ame spec file, rather than
having to copy them to the test.yml file, and keep them in sync
2) The ability to use a file format (rpm spec files) that I'm more familiar with
3) Easy access to tests that are embedded in the source tree
4) minimizing the test harness setup in test.yml
For anyone interested, I've got a pull request started here:
If anyone wants to take a look at the changes I had to make to do this (fair
warning, its still very rough).
That all said, I was wondering if perhaps there was general interest in making
this kind of test model somewhat more formal (i.e. creating an rpm macro library
to make test package generation a bit easier, creating a standard entry point to
run tests, etc).
= MariaDB 10.4 =
== Summary ==
Update of MariaDB ('mariadb' package) in Fedora from 10.3 to 10.4 version.
== Owner ==
* Name: [[User:mschorm| Michal Schorm]]
* Email: mschorm(a)redhat.com
== Detailed Description ==
Update of MariaDB package in Fedora from 10.3 version to 10.4 version.
== Benefit to Fedora ==
I'm cooperating with the upstream to bring the latest stable software
to Fedora users.
10.4 series introduces number of enhancements, which cannot be found
in previous series.
Apart from that, MariaDB Galera Cluster has been significantly
reworked and enhanced. (galera 3 updated to galera 4)
== Scope ==
* Proposal owners:
**Prepare MariaDB 10.4 as a module for Rawhide and atleast one stable
Fedora release (done)
**Prepare MariaDB 10.3 as a module for Rawhide, so there would be a
failover in case of problems (done)
**Release MariaDB 10.4 to Rawhide (blocked by #1724283; solving with upstream)
**Check software that requires or depends on 'mariadb' or 'galera'
package for incompatibilities
**Gather user input on the changes between MariaDB 10.3 and 10.4
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The MariaDB client library is compatible, so the shouldn't be any
issues and / or need for rebuild of dependent packages.
Galera package bumped version from 25.3 to 25.4 which introduces
bigger changes. However since no other project in Fedora than MariaDB
use Galera, I don't expect any issue here.
== How To Test ==
Usual testing as when upgrading between major MariaDB versions.
Test that all other software runs well with MariaDB 10.4.
Report any issues, so I can reach the different upstreams and check if
they plan update their software to support MariaDB 10.4 and when.
== User Experience ==
The users will have to upgrade their databases the same way as between
major MariaDB versions.
If the users want to stick with MariaDB for a little longer, I provide
MariaDB 10.3 module.
If the users want to test it beforehand, I provide MariaDB 10.4 module.
== Dependencies ==
There should be absolute minimum amountof packages, that use MariaDB
as a BuildRequires. Since the separation of MariaDB client library,
only packages that build server plugins may use MariaDB as a
Since the client library ('mariadb-connector-c') is not changing,
dependent software should work fine.
== Contingency Plan ==
Modules will provide the functional version of MariaDB 10.3, available
to all users.
* Contingency mechanism: Fedora Modules available
* Contingency deadline: beta freeze
== Documentation ==
Upgrading and incompatibilities:
== Release Notes ==
Release notes for each release:
Overall overview of the changes and improvements:
He / Him / His
Fedora Program Manager
I upgraded to F31 recently, and I now I noticed that the gnome top
bar is always black. I miss the old translucent blue bar that would
only go black if window was moved adjacent. I'm not sure though when
What to I need to do to be able to push to the repo of something I've
got un-orphaned? I currently see:
$ fedpkg push
Counting objects: 10, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 877 bytes | 0 bytes/s, done.
Total 7 (delta 4), reused 0 (delta 0)
remote: Branch refs/heads/master is unsupported
remote: Denied push for ref 'refs/heads/master' for user 'loveshack'
remote: All changes have been rejected
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://firstname.lastname@example.org/rpms/powerman'
Could not execute push: Failed to execute command.
Although I haven't changed them, none of the hooks under the project
settings show as active.