Alternative Arch update
by Dennis Gilmore
Hi All,
Just letting you all know that as part of the redefinition of
Alternative Architectures[1] we have just enabled the building of s390x
in primary koji. this is the last new architecture we are planning to
enable at this point. s390x will be added to rawhide composes early
next week. If you have any questions or experience any issues and wan
releng to provide assistance, please contact us by one of the
documented channels[2].
With the import being done now, it has been decided that s390x is too
late for Fedora 26, as such it will be built and shipped from
s390.koji.fedoraproject.org in the Fedora 26 cycle we brought in
aarch64, ppc64 and ppc64le to primary koji. This means that the arm and
ppc koji's will be used for updates until Fedora 25 goes End of Life
and will be shut down at that point. The s390 koji will live on until
Fedora 26 goes EOL.
Regards
Dennis
[1] https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArc
hitectures
[2] https://docs.pagure.org/releng/
6 years, 5 months
Announcing Bugzilla 5 Public Beta!
by Christine Freitas
Hello All,
We are pleased to announce Red Hat's Bugzilla 5 beta [1]! We’re inviting
all of you to participate.
We encourage you to test your current scripts against this new version and
take part in the beta discussions on the Fedora development list [2].
Partners and customers may also use their existing communications channels
to share feedback or questions. We ask that you provide feedback or
questions by Wednesday, May 17th.
Here is a short list of some of the changes in Bugzilla 5:
-
Major improvements in the WebServices interface, including a new
REST-like endpoint, allowing clients to access data using standard HTTP
calls for easy development.
-
The UI has been significantly overhauled for a modern browsing
experience.
-
Performance improvements, including caching improvements to allow faster
access to certain types of data.
-
Red Hat Associates, Customers and Fedora Account System users can now
log in using SAML.
-
The addition of some of the Bayoteers extensions allowing features such
as inline editing of bugs in search results, team management and scrum
tools, etc.
-
Ye Olde diff viewer has been replaced with the modern diff2html diff
viewer
-
Improved, updated documentation including a rewrite using the
reStructuredText format, which allows documentation to be more easily
converted into different formats such as HTML and PDF, etc
The official release date for Bugzilla 5 will be determined based on the
beta feedback. We will communicate to you as the beta progresses.
For more information refer to:
https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html
https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html
https://beta-bugzilla.redhat.com/page.cgi?id=faq.html
https://beta-bugzilla.redhat.com/docs/en/html/using/index.html
https://beta-bugzilla.redhat.com/docs/en/html/api/index.html
Cheers, the Red Hat Bugzilla team.
1: https://beta-bugzilla.redhat.com/
2: https://lists.fedoraproject.org/archives/list/devel%40lists.
fedoraproject.org/
6 years, 5 months
OpenVPN, OpenSSL and Fedora 26+
by David Sommerseth
Hi,
This is actually just a very late heads-up about challenges with OpenVPN
in Fedora 26.
Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and
good step forward. Unfortunately, that gives OpenVPN a real challenge.
The OpenSSL v1.1 support is not completed. Patches have been sent to
the upstream devel mailing list for review, but only half of them have
been processed and applied so far.
So, to be able to provide OpenVPN in Fedora 26 it was decided to switch
to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have
revealed several issues:
- mbed TLS 2.3+ does by default not support certificates hashes
"older" than SHA1. And RSA keys must be 2048 bits or more.
This have been fixed by a couple of additional patches on top
of the upstream OpenVPN code base. It supports now RSA keys
of 1024 bits or more. In addition for OpenSSL support of the
OPENSSL_ENABLE_MD5_VERIFY, a quirk have been added to also enable
MD5 support if that environment variable have been set.
- mbed TLS build in Fedora lacked PKCS#11 support. This have
been resolved. But there are concerns how well this plays along
with another dependency OpenVPN have, pkcs11-helper. This is being
investigated and tested. Feel free to help out on bz #1432152 if
you depend on PKCS#11/Smart Card functionality. Your feedback is
valuable!
- mbed TLS completely lacks support for PKCS#12 files.
Now, there is kind of an alternative by using compat-openssl-10. But
that does not play well with pkcs11-helper; which is compiled against
OpenSSL v1.1.
Currently the plan is to stay with mbed TLS support until PKCS#11
support is fully confirmed working or not working at all. If not
working, we can at least move to compat-openssl10 without PKCS#11
support, which enables PKCS#12 support again. If PKCS#11 support works
with mbed TLS, then we will stay on mbed TLS for now as I value that
support more important than PKCS#12.
Once OpenVPN have released a version with full OpenSSL v1.1 support (or
at least have all the needed patches reviewed and applied to their
upstream git repos), then I will switch back to the default openssl
package again.
This is far from ideal. But I do consider this the best compromise than
not having an OpenVPN package in Fedora 26 at all.
For those of you having PKCS#12 files, there is a kind of workaround
where you can split up that file into CA, Certificate and Private Key
PEM files - which OpenVPN can use directly.
$ openssl pkcs12 -nokeys -cacerts -in $PKCS12FILE > ca-cert.pem
$ openssl pkcs12 -nokeys -clcerts -in $PKCS12FILE > cert.pem
$ openssl pkcs12 -nocerts -nodes -in $PKCS12FILE > private-key.pem
If switching from '-nodes' with for example '-aes256' on the last line,
the private key will be encrypted and password protected; similar to
what your PKCS#12 files may already use today.
I am sorry for not having sent this heads-up earlier. I took over
package maintenance mid-March, and I've taken this package through a
very much needed overhaul to align the packaging with improvements in
the upstream packaging. The previous maintainers have done a good job
keeping this package alive, but the gap against upstream began to be a
bit too big. There are still a few things which needs to be ironed out.
But once the mbed TLS/OpenSSL issue and a few other more minor issues
gets resolved, I'd say we're pretty much in a reasonable shape.
If you have questions, issues or comments ... feel free to reach out!
--
kind regards,
David Sommerseth
6 years, 5 months
openQA test results for critpath updates now shown in Bodhi
by Adam Williamson
Hi folks! I thought this was worth sending out an announcement about so
as many packagers and testers as possible are aware of it.
With the rollout of Bodhi 2.6.0 to production today, openQA test
results for critpath updates now appear in the Bodhi webUI! Click the
'Automated Tests' tab on any critical path update (from the last two
months or so) and you should see, as well as the 'dist.*' tests you're
probably familiar with that are run by Taskotron, results for several
'update.*' tests. These are the openQA test results.
Clicking any result will take you to the openQA webUI page for that
job. If you're investigating a failure, look for thumbnails with a
*red* border. Usually, the first one of these will be the attempted
image match or console command that did not give the expected result.
If you can't understand a failure, please do come ask on test@ or in
#fedora-qa . Myself and garretraziel (Jan Sedlak) should be able to
explain.
This isn't a perfect test system, yet; there have been and will
continue to be 'false' failures, where something goes wrong in the test
process itself or the test just hits some transient bug that isn't
actually caused by the update. Because of this, we wrote an openQA
plugin that automatically retries all failed update tests one time, but
sometimes we get unlucky and a false failure happens again on the
retry.
This is quite common for Fedora 26 updates; there seem to be several of
these transient bugs in F26 at present, meaning sometimes the test VM
just doesn't boot successfully, sometimes GNOME crashes, and so on. If
you see a 'red' screenshot which is just a partially-completed
bootsplash screen, or the GDM login screen, this may be what happened.
Notably, *any* failure before the _advisory_update step cannot possibly
be a bug in the update, as nothing from the update is actually
installed until near the end of that step.
It's not currently possible for anyone but openQA admins to re-run
individual tests. You can cause *all* the openQA tests for your update
to be re-run by editing the update in any way (*any* edit event
triggers a re-run of the tests, not just changes to the update's
package manifest), but please be a bit sparing with this, as openQA
doesn't have unlimited capacity. For now you can, again, ask Jan or I
to re-run a single test if you'd like this. We will endeavour to set up
some kind of re-run request system in future.
Just like the taskotron results, at present these results are entirely
advisory. They do not have any effect on whether or when you can push
your update stable. But we set up this system to help out packagers, so
I hope you'll find it useful to keep an eye on the results and take a
look at any failures to see if they may indicate a bug in the update.
Once again, please do ask for any help you need in interpreting or
understanding the results. And please do send any suggestions, comments
or complaints our way!
And just to be clear, these tests are currently run only on *critical
path* updates. If your update does not include a critical path package,
the tests will not be run. I'm thinking of implementing some sort of
'whitelist' system for listing or otherwise marking non-critpath
packages for which we want to run some or all of the tests; for
instance, it would make a lot of sense to run the FreeIPA tests for any
package in the FreeIPA stack. But that's not implemented yet. We don't
just run the tests on *all* updates because we simply don't have the
capacity to do so at present.
I have written a blog post about this, with some more information,
including a brief explanation of what the current set of update tests
covers, here:
https://www.happyassassin.net/2017/04/24/automated-critical-path-update-f...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years, 5 months
F27 Self Contained Change: Java 9
by Jan Kurik
= Proposed Self Contained Change: Java 9 =
https://fedoraproject.org/wiki/Changes/Java9TechPreview
Change owner(s):
* Jiri Vanek <jvanek at redhat dot com>
Add a tech preview preview of the the upcoming version of Java
(OpenJDK9) to Fedora 27
== Detailed Description ==
The current Java implementation in Fedora comes from OpenJDK.
Java 9 (and OpenJDK9) are tentatively scheduled for release in
2017-07-27. Fedora 27 will most likely be out just a few months after
that, and is therefore positioned to receive a tech preview version of
the latest OpenJDK9 candidates. This preview should be released
version of Java 9, will contain new Java 9 APIs, but may not be
supported by many applications directly, therefore it have to warm up
as techpreview.
== Scope ==
The current version of OpenJDK 9 will be packaged and added to Fedora.
It will be a stand alone package and will not impact existing OpenJDK
8 packages.
Since this will be a tech preview, the primary JDK in Fedora 27 will
continue to be OpenJDK8. OpenJDK9 is not expected to be the primary
Java until Fedora 28 at least.
Two problems would generally be expected with a major JDK update based
on past experience:
FTFBS failures due to packages having a hard-coded JDK version dependency.
This was dealt with when both OpenJDK8 and OpenJDK7 were introduced
over Fedora 16/17 and Fedora 19/21. Now all Java dependent packages
should require java >= 1.6.0, and therefore this issue will not be a
problem any more.
There may be packages that rely on API that is deprecated in Java 9
Such packages cannot be identified until we actually start to build
with Java 9. Since Java 8 will continue to remain the primary version
of Java in Fedora 26, any API deprecation issues will be a secondary
problem as the main JVM will continue to be able to run everything
correctly. We expect to have everything resolved well before Java 9 is
to become the primary Java version in Fedora (F28 or later).
* Proposal owners:
providing java-9-openjdk package to main repositories
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
only the inclusion of new package is needed
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 5 months
Fedora CI effort/Interest Group
by Pierre-Yves Chibon
Dear all,
A small team of people interested in working on a Continuous Integration has
started looking into what it would take to add Continous Integration (CI) to our
current packaging and releasing workflow.
The current idea is to use fedora-atomic as a prototype product to port into
this workflow while keeping in mind other use-cases so that we could eventually
use this approach for the entire distribution (as opt-in).
Since there might be more people interested than the people who expressed their
interest, I invite anyone interested to join the mailing list:
https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/
and/or the IRC channel: #fedora-ci on irc.freenode.net
We're working to start this with as few changes to the current Fedora
infrastructure as possible. And with a very specific set of requirements.
Ultimately, I hope we can make this workflow work for not only fedora-atomic
(though it is the current target) and this should help improving the stability
of rawhide (and thus will also help the no-more-alpha change proposal [1]).
I have put together a wiki page making this a change proposal:
https://fedoraproject.org/wiki/Changes/FedoraAtomicCI
Thanks for your attention and welcome aboard,
Pierre
[1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
6 years, 5 months
F27 System Wide Change: Switch libcurl back to OpenSSL
by Jan Kurik
= Proposed System Wide Change: Switch libcurl back to OpenSSL =
https://fedoraproject.org/wiki/Changes/libcurlBackToOpenSSL
Change owner(s):
* Kamil Dudka <kdudka AT redhat DOT com>
libcurl in Fedora currently uses the NSS (Network Security Services)
library for TLS and cryptography. After implementing this change,
libcurl will use OpenSSL instead of NSS.
== Detailed Description ==
In order to make even smaller Fedora base images, it was proposed to
switch libcurl back to OpenSSL. The Fedora Crypto Consolidation
project, which motivated the switch of libcurl from OpenSSL to NSS ten
years ago, is now deprecated and libcurl is the only package that
pulls NSS as its dependency into the Fedora base image. Hence, by
switching libcurl back to OpenSSL, we could create Fedora base image
that contains fewer crypto libraries inside.
== Scope ==
* Proposal owners:
kdudka (will push the following patch:
https://src.fedoraproject.org/cgit/rpms/curl.git/commit/?id=7c3b67bb
and rebuild curl)
* Other developers:
psabata, ignatenko, sgallagh (will help to resolve possible breakages
caused by the patch)
* Release engineering:
No action from release engineering is needed for this change (libcurl
ABI is kept).
* Policies and guidelines:
unaffected
* Trademark approval:
not needed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 5 months
Announcing the release of Fedora 26 Alpha
by Mohan Boddu
The Fedora Project is pleased to announce the immediate availability of
the Fedora 26 Alpha, an important milestone on the road to our Fedora 26
release in June.
Download the prerelease from our Get Fedora site:
- Get Fedora 26 Alpha Workstation
- Get Fedora 26 Alpha Server
Or, check out one of our popular variants:
- Get Fedora 26 Alpha Spins
- Get Fedora 26 Alpha Labs
- Get Fedora 26 Alpha ARM
Alternative Architectures
-------------------------
We are also simultaneously releasing the F26 Alpha for Power64 and
64-bit ARM (AArch64). These are available from:
https://download.fedoraproject.org/pub/fedora-secondary/releases/test/26_...
What is the Alpha release?
--------------------------
The Alpha release contains all the features of Fedora 26's editions in a
form that anyone can help test. This testing, guided by the Fedora QA
team, helps us target and identify bugs. When these bugs are fixed, we
make a Beta release available. A Beta release is code-complete and bears
a very strong resemblance to the third and final release. The final
release of Fedora 26 is expected in June. If you take the time to
download and try out the Alpha, you can check and make sure the things
that are important to YOU are working. Every bug you find and report
doesn't just help you, it improves the experience of millions of Fedora
users worldwide! Together, we can make Fedora rock-solid. We have a
culture of coordinating new features and pushing fixes upstream as much
as we can, and your feedback improves not only Fedora, but Linux and
Free software as a whole.
- https://fedoraproject.org/wiki/Releases/26/Schedule
Issues and Details
------------------
Since this is an alpha release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact
the Fedora QA team via the mailing list or in #fedora-qa on Freenode. As
testing progresses, common issues are tracked on the Common F26 Bugs
page.
- https://fedoraproject.org/wiki/Common_F26_bugs
For tips on reporting a bug effectively, read "how to file a bug
report."
- https://fedoraproject.org/wiki/How_to_file_a_bug_report
Release Schedule
----------------
The full release schedule is available on the Fedora wiki:
- https://fedoraproject.org/wiki/Releases/26/Schedule
The current schedule calls for a beta release in late May, and the
final release in June. Be aware that these dates are development
targets. Some projects release on a set date regardless of feature
completeness or bugs; others wait until certain thresholds for
functionality or testing are met. Fedora uses a hybrid model, with
milestones subject to adjustment. This allows us to make releases with
new features and newly-integrated and updated upstream software while
also retaining high quality.
6 years, 5 months