Some of you may have seen me around before under my preferred nick of badone as
I've lurked in open source and software circles in general for countless eons.
I started doing software support and development during the late Permian period
working on a couple of DG systems and then HP 9000s. I started using Red Hat
Linux some time in the Triassic period and have been involved in some way or
another ever since. During the Jurassic period I was an IT journeyman working in
various places and picking up way too much information on way too many things
including hardware, cabling, telecommunications, radio, etc.
In the early Cretaceous I began working for Red Hat and currently work as a
Software Engineer in the Ceph project and contribute to it, and several other
projects, on github, etc. C++ is the weapon of choice when available. I have no
idea why it has taken many millennia to get around to becoming a packager, but
it has. I would like ultimately to become more involved in the ceph-related
packages and perhaps the CentOS storage SIG and the Fedora equivalent but I've
decided to get my feet wet with a nice vim personal wiki plugin I found.
Anyway, this is me, checkin' in.
My name is Mike Miller and I have been a software developer for almost ten
years. I am fairly new as a committer to the Open Source Community but I
have developed software using many different free and open source tools. I
frequently use Linux systems, mainly CentOS and am interested in working
with Fedora more closely. I am currently a committer on the Apache Accumulo
project. On a more personal level, I live on the East coast of the United
States and love watching sports and movies and playing video games with
friends. My GitHub username is milleruntime.
I am looking forward to being a part of the community!
Yep, it's Test Day time again - most likely the final Test Day of the
Fedora 25 cycle. This Thursday, 2016-11-03, will be [switchable
graphics Test Day]!
'Switchable graphics' refers to the fairly common current practice of
laptops having two graphics adapters, one low-power one for general
purpose use, one more powerful one for use with applications that
require more oomph (e.g. games or 3D rendering applications). NVIDIA
brands this as 'Optimus', and AMD just as 'Switchable Graphics' or
'Dynamic Switchable Graphics'.
There are some [enhancements] to Fedora's support for such systems
in Fedora 25, and part of the Test Day's purpose is to test those
enhancements. The other part of the Test Day's purpose is to ensure
that support for switchable graphics on Fedora 25 Workstation with
[Wayland by default] is as good as it can be, and that in some cases
where we know Wayland support is not sufficient, fallback to X.org
works as expected.
If you're not sure whether you have a system with switchable graphics,
you can run `xrandr --listproviders`. If the output from this command
lists more than one 'provider', you likely have switchable graphics. If
you do, please come along to the Test Day and help us test, if you can
spare the time. If you believe your system has switchable graphics, but
the command only lists one provider, please come join the Test Day chat
on the day - we may be able to investigate and figure out what's going
The [Test Day page] and the test cases are still being revised and
tweaked as I write this, but as the week goes along, all the
instructions you need to run the tests will be present there. As
always, the event will be in #fedora-test-day on Freenode IRC. If you
don’t know how to use IRC, you can read [these instructions], or
just use [WebIRC].
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
EPEL6 - MongoDB 2.4.x
EPEL7 - MongoDB 2.6.x
Upstream supports only upgrade to next major version. So from 2.4 it is
supported only to 2.6.
Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are
But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in
EPEL7 will be unsupported.
How to solve this - what EPEL/Fedora guidelines says about upgrades?
Upgrade EPEL6 to EPEL7? Or keep unsupported version in EPEL7?
What is the "Payload Hash" in koji?
It looks like an MD5, but of what? It's not the rpm... I've checked.
Should koji be providing verification hashes for manual downloads of built
RPMs? I think this would be useful for testing.
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?