Excluding older builds of packages from Fedora when testing new ones
in Copr
by Miro Hrončok
Hello Copr users and developers.
When we update packages in Fedora, we regularly use Copr to test the impact of
the upgrade.
For me, the procedure usually goes like this:
1) create a new copr with Fedora rawhide x86_64 chroot (and added Koji repo)
$ copr create $COPR
--repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/'
--chroot fedora-rawhide-x86_64 --delete-after-days 30
2) define and build the updated package in the copr
$ copr add-package-distgit $COPR --name $PKG --webhook-rebuild on --commit
$BRANCH --namespace forks/$(whoami)
$ copr build-package $COPR --name $PKG
3) get the list of dependent packages
$ repoquery -q --repo=rawhide{,-source} [--whatrequires $spkg for each
subpackage] --recursive | grep src$ | pkgname
4) define and build the depended packages in the copr
$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit
rawhide --name -- $(repoquery from above ...)
$ parallel copr build-package $COPR --nowait --background --name --
$(repoquery from above ...)
5) analyze build failures, do a "control" rebuild in another copr if needed
However, this procedure has a flaw. Let's say I'm working on upgrading
python-click from 7.x to 8.x. And let's say a package (even transitively)
BuildRequires:
python3dist(click) < 8
The way that dnf dependency resolution works, that package will be built with
Rawhide's python3-click 7.x and it will be marked as successful. However, I'd
like to see a failure here to be notified that such package cannot be build and
will be negatively impacted by the update.
Is there a way to solve this? I have couple ideas, but none of them is fully
working:
A) Compose my own repo with the updated package and Rawhide content without it,
use that repo in the copr.
Pros:
- this is similar to what will happen in Koji once the package is updated
Cons:
- this requires tooling that I don't think exists
- this requires a place to put that repo to
- the repo creation could take a lot of time and would need to be repeated
on-demand each time rawhide changes
- Copr's Fedora chroots always include Fedora repos (maybe I can use
custom-1-x86_64 chroot?)
B) Create a Fedora side tag, explicitly block the package from it, use that
side tag's Koji repo.
Pros:
- same as (A)
Cons:
- I don't think on-demand side tags allow users to block packages
- Copr's Fedora chroots always include Fedora repos (same as (A))
- this wastes Koji's resources a bit
- requires waiting for the initial Koji regen-repo
C) Block (exclude) python3-click < 8 from the chroot.
Pros:
- no custom repos required
- no resources overhead
- no time overhead
Cons:
- There is no way exclude packages in chroot settings. Mock settings possibly
allow me to do this in config_opts['dnf.conf'].
- The exclude could obfuscate root.log resolution problems logs.
- Packager needs to figure out what exactly to exclude (possibly need to
exclude all subpackage's NEVRAs from rawhide compose (and Koji buildroot if
they differ))
Is there another way? If not, I think (C) is easiest to actually implement, if
the chroot settings page in copr gains an "excludes" option.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 week, 4 days
Oracle Linux chroots (temporarily) available in Fedora Copr
by Pavel Raiskup
Hello,
just a quick note - we enabled Oracle Linux chroots in Fedora Copr today,
this is temporarily needed by OAMG/LEAPP team for their CI/CD system.
Feel free to test those chroots, but please don't heavily depend on them
as we don't know when we'll again drop them (preferably use
epel/centos-stream chroots instead, they should provide similar build results).
Pavel
11 months, 3 weeks
rpkg-util v3 change, moving copr builders to F35
by Pavel Raiskup
Hello,
we are currently preparing Copr build system for migration to Fedora 35,
including the builder workers.
There's though, at least from the builder perspective, a major `rpkg-util`
behavior change [1] (removal of `auto_pack` feature) that many of the Copr
projects rely on. This is a bit unexpected as `auto_pack = True` has been
the default in Copr for a long time, and the rpkg-util upstream intentions
behind the feature were generally misunderstood (even in Copr team).
That being said, some of the currently working builds on F34 would fail
after the migration to F35.
In order to make the migration a bit less dramatic, we plan to migrate in
the following steps:
1. Document the feature drop and possible fixes/workarounds see [1], and
properly announce the change in advance (here we are _now_).
2. Change the default, and turn off the `auto_pack` feature for
relatively short period of time on the current F34 builders
(ie autopack=False). This will happen soon in December 2021.
The change will naturally trigger the build failures, but a bit
earlier so users will be informed sooner ... with a _temporary_
work-around in hand => everyone can provide the file
<git-root>/rpkg.conf upstream, and opt-in the old behavior with with
content like:
[rpkg]
# temporary work-around for rpkg-util v2, auto_pack is going to be
# removed soon! See:
# https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3
auto_pack = True
3. Migrate to Fedora 35, early in January 2022. This will make the
`auto_pack = True` work-around non-working, and users will have to
adapt, again, see [1].
Of course, anyone is encouraged to migrate to the new syntax **right now**,
sooner the better. If done correctly, package can be built both with rpkg-util
v2 and v3 [2].
Sorry for inconvenience! Any comment, idea or help is welcome!
[1] https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3
[2] https://pagure.io/copr/copr-hello/c/739ff9910ee8a9c76d7e97de2f6176106dc19...
Pavel
1 year, 4 months
Fedora Copr EPEL 8 being moved to RHEL+EPEL (and s390x native as bonus)
by Pavel Raiskup
Hello maintainers.
Currently, we build all EPEL variants against CentOS "base" in Fedora
Copr, i.e. epel-* configs means CentOS+EPEL. By the end of January 2022
CentOS 8 mirrors will start disappearing, pushing us to change the configs
to avoid build failures.
We would like to start the migration to the RHEL base as soon as possible,
so we are at least a bit "ahead" the change. So we can start resolving
the issues.
There doesn't seem to be a real blocker, or known issue.
- We got enough subscriptions from Red Hat for Fedora Copr purposes to
start building against official RHEL channels.
- The Mock + configs is stuck in Bodhi for now, but it doesn't block
Copr to apply for the change earlier. This is mostly about community
decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
broken.
- The remaining problem seemed to be the s390x architecture, as the
emulation being _currently_ done wouldn't work with Red Hat
subscriptions, see details in [1] discussion. But thanks to IBM
sponsoring us IBM Cloud access we should be OK to deploy the s390x
arch support in Fedora Copr at the same time with the EPEL change
(this will go in a separate announcement).
**So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.** If
everything works well at least.
Side note from me... Note that EPEL 9 in Fedora Copr is still CentOS
Stream 9 + EPEL 9 ATM. This will change to "RHEL 9 + EPEL 9" once RHEL 9
is generally available (subscribed content). Might seem as a
complication for users, but it's actually not - it is good thing we can
start working on EPEL 9 now. So I want to congratulate to EPEL community
here, the fact we have stream in place allows us to bring EPEL 9 up before
actually RHEL is available. That's an awesome step (jump) forward
compared to previous releases!
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Pavel
1 year, 4 months
my own copr-server
by Sérgio Basto
Hi,
I started to build my own copr , I follow
the http://frostyx.cz/posts/copr-docker-compose-without-supervisord
but can't pass the init-database.sh [1], I'm using
https://pagure.io/copr/copr.git 30 dec 2021 commit (f18faf4f)
any tip ?
[1]
docker exec -it copr_frontend_1 bash
cd /usr/share/copr/coprs_frontend/ && copr-frontend create-db --alembic
alembic.ini
[2022-01-03 23:01:38,665] INFO in log: logging configuration finished
/usr/share/copr/coprs_frontend/coprs/models.py:2445: SAWarning:
relationship 'Build.package' will copy column package.id to column
build.package_id, whichconflicts with relationship(s): 'Package.builds'
(copies package.id to build.package_id). If this is not the intention,
consider if these relationships should be linked with back_populates,
or if viewonly=True should be applied to one or more if they are read-
only. For the less common case that foreign keyconstraints are
partially overlapping, the orm.foreign() annotation can be used to
isolate the columns that should be written towards. To silence this
warning, add the parameter 'overlaps="builds"' to the 'Build.package'
relationship. (Background on this error at:
https://sqlalche.me/e/14/qzyx)
db.session.add(DistGitInstance(
Traceback (most recent call last):
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1802, in _execute_context
self.dialect.do_execute(
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/engine/default.py", line 732, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.UndefinedTable: relation "dist_git_instance" does not
exist
LINE 1: INSERT INTO dist_git_instance (name, clone_url, clone_packag...
^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/bin/copr-frontend", line 125, in <module>
app.cli()
File "/usr/lib/python3.10/site-packages/click/core.py", line 1137, in
__call__
return self.main(*args, **kwargs)
File "/usr/lib/python3.10/site-packages/click/core.py", line 1062, in
main
rv = self.invoke(ctx)
File "/usr/lib/python3.10/site-packages/click/core.py", line 1668, in
invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3.10/site-packages/click/core.py", line 1404, in
invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.10/site-packages/click/core.py", line 763, in
invoke
return __callback(*args, **kwargs)
File "/usr/bin/copr-frontend", line 99, in wrapper
sys.exit(bool(function(*args, **kwargs)))
File "/usr/share/copr/coprs_frontend/commands/create_db.py", line 18,
in create_db
db.create_all()
File "/usr/lib/python3.10/site-packages/flask_sqlalchemy/__init__.py",
line 1094, in create_all
self._execute_for_all_tables(app, bind, 'create_all')
File "/usr/lib/python3.10/site-packages/flask_sqlalchemy/__init__.py",
line 1086, in _execute_for_all_tables
op(bind=self.get_engine(app, bind), **extra)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/schema.py",
line 4785, in create_all
bind._run_ddl_visitor(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 3117, in _run_ddl_visitor
conn._run_ddl_visitor(visitorcallable, element, **kwargs)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 2113, in _run_ddl_visitor
visitorcallable(self.dialect, self, **kwargs).traverse_single(element)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/visitors.py",
line 524, in traverse_single
return meth(obj, **kw)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/ddl.py", line
849, in visit_metadata
self.traverse_single(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/visitors.py",
line 524, in traverse_single
return meth(obj, **kw)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/ddl.py", line
915, in visit_table
table.dispatch.after_create(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/event/attr.py",
line 343, in __call__
fn(*args, **kw)
File "/usr/share/copr/coprs_frontend/coprs/models.py", line 2451, in
insert_fedora_distgit
db.session.commit()
File "<string>", line 2, in commit
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 1431, in commit
self._transaction.commit(_to_root=self.future)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 829, in commit
self._prepare_impl()
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 808, in _prepare_impl
self.session.flush()
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 3363, in flush
self._flush(objects)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 3502, in _flush
with util.safe_reraise():
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
compat.raise_(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/util/compat.py",
line 207, in raise_
raise exception
File "/usr/lib64/python3.10/site-packages/sqlalchemy/orm/session.py",
line 3463, in _flush
flush_context.execute()
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/orm/unitofwork.py", line 456, in execute
rec.execute(self)
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/orm/unitofwork.py", line 630, in execute
util.preloaded.orm_persistence.save_obj(
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/orm/persistence.py", line 244, in save_obj
_emit_insert_statements(
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/orm/persistence.py", line 1221, in
_emit_insert_statements
result = connection._execute_20(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1614, in _execute_20
return meth(self, args_10style, kwargs_10style, execution_options)
File "/usr/lib64/python3.10/site-packages/sqlalchemy/sql/elements.py",
line 325, in _execute_on_connection
return connection._execute_clauseelement(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1481, in _execute_clauseelement
ret = self._execute_context(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1845, in _execute_context
self._handle_dbapi_exception(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 2026, in _handle_dbapi_exception
util.raise_(
File "/usr/lib64/python3.10/site-packages/sqlalchemy/util/compat.py",
line 207, in raise_
raise exception
File "/usr/lib64/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1802, in _execute_context
self.dialect.do_execute(
File "/usr/lib64/python3.10/site-
packages/sqlalchemy/engine/default.py", line 732, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedTable)
relation "dist_git_instance" does not exist
LINE 1: INSERT INTO dist_git_instance (name, clone_url, clone_packag...
^
--
Sérgio M. B.
1 year, 4 months