Missing expected images:
Cloud_base qcow2 x86_64
Server boot x86_64
Atomic qcow2 x86_64
Server dvd i386
Server dvd x86_64
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64
Failed openQA tests: 1/2 (arm)
Old failures (same test failed in 25-20161030.n.0):
ID: 45129 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
Passed openQA tests: 22/22 (x86_64), 2/2 (i386)
New passes (same test did not pass in 25-20161030.n.0):
ID: 45117 Test: x86_64 KDE-live-iso desktop_update_graphical
Skipped openQA tests: 1 of 26
Mail generated by check-compose:
tl;dr: different packages own /usr/lib/pythonX/site-packages/tests and
different files with the same name inside that directory.
I was going through a package review and realized the package under
and some files inside the directory.
since there were no subdirectories and there were no namespaces for the
file names inside the directory, I went further and realized that the
following packages are doing the same:
what's the problem with that? Well what if we would have a package named
python-tests? shouldn't it own that directory? Also, since there are no
namespaces inside that directory for each package owning files in there,
they could end up owning different files with the same name. Actually,
the following packages own /usr/lib/python3.5/site-packages/tests/__init__.py
Is that all really a problem or am I missing something in the guidelines?
In F26 with the openssl 1.1.0 rebase libp11/engine_pkcs11 will be
compiled only for openssl 1.1.0. That means that there will be no
engine_pkcs11 for the packages linking to openssl 1.0.x. For that I've
created the compat-openssl10-libp11 package which is intended to
provide just that (engine_pkcs11). It will not provide libp11-devel for
these packages, and the shipped libp11 will have different versioned
symbols and soname.
Any objections or issues found with this approach? Otherwise who would
like to review this compat package?
I use docker-compose extensively for local development. On F24 all I had
to do to make it play well with selinux was something like this:
sudo chcon -Rt svirt_sandbox_file_t project_folder
After updating to F25 this doesn't work anymore. Did something changed
on selinux policies (besides that label been renamed to
container_file_t) or I should file a bug?
Specifically I cannot start a mariadb container with compose.
On a related note, I opened a bug on our developer portal, since it
lacks any mention on SELinux
I recall some reports that configure scripts are really slow in recent
Fedora versions due to pervasive use of BIND_NOW.
Has anyone investigated this further? Is there a bug report somewhere?