devel-announce April 2017

devel-announce@lists.fedoraproject.org

9 participants
11 discussions

Alternative Arch update
by Dennis Gilmore 28 Apr '17

28 Apr '17

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/

1 0

Announcing Bugzilla 5 Public Beta!
by Christine Freitas 27 Apr '17

27 Apr '17

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/

1 0

Planned outage: koji database - 2017-04-27 00:00
by Kevin Fenzi 26 Apr '17

26 Apr '17

We will be rebooting the koji database server in order to add more virtual cpus to it. This outage should be just a minute or two and should not hopefully affect in progress builds. Sorry for the short notice of this outage, but we wanted to improve koji performance and this is an easy way to quickly do so. See: https://pagure.io/fedora-infrastructure/issue/6015 or #fedora-admin on irc.freenode.net for any questions or comments. kevin

1 0

OpenVPN, OpenSSL and Fedora 26+
by David Sommerseth 25 Apr '17

25 Apr '17

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

1 0

openQA test results for critpath updates now shown in Bodhi
by Adam Williamson 24 Apr '17

24 Apr '17

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-fun… -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

F27 Self Contained Change: Java 9
by Jan Kurik 19 Apr '17

19 Apr '17

= 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

1 0

Updating the Fedora Project Mission statement — please read and join the discussion
by Matthew Miller 14 Apr '17

14 Apr '17

I just posted in the council-discuss mailing list about the work we did last month towards an updated Fedora Project mission statement. Please see: https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedorap… and join the conversation there. Thank you! -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

Fedora CI effort/Interest Group
by Pierre-Yves Chibon 12 Apr '17

12 Apr '17

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

1 0

F27 System Wide Change: Switch libcurl back to OpenSSL
by Jan Kurik 06 Apr '17

06 Apr '17

= 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

1 0

Announcing the release of Fedora 26 Alpha
by Mohan Boddu 04 Apr '17

04 Apr '17

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_Al… 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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce April 2017