For the next few meetings, NYC*BUG will be doing a collection for each
of the BSD projects.
Since our beginnings, we have contributed to a variety of fundraising
efforts for the BSD projects. Most significantly, the profits from each
of our conferences has been divided up between the BSD projects. We have
done a number of other activities for monetary donations, besides
connecting developers to hardware.
For the January meeting, the collection will go to OpenBSD, followed by
NetBSD in February, with FreeBSD and DragonFly BSD to follow.
There is no obligation to contribute, but even small donations
aggregated can matter. Of course we don't have a credit card machine,
but cash or checks made out to the respective BSD project (in this case
"the OpenBSD Foundation") are welcome.
If you want to use a credit card, won't be attending the meeting, or
just prefer to donate directly, these links provide the relevant
information:
https://www.dragonflybsd.org/donations/
https://www.freebsdfoundation.org/donate/
https://www.netbsd.org/donations/
https://www.openbsd.org/donations.html
_______________________________________________
announce mailing list
announce@lists.nycbug.org
http://lists.nycbug.org/mailman/listinfo/announce
Friday, December 29, 2017
[announce] NYC*BUG: Jan 3 on OpenBSD Porting and more
Upcoming NYC*BUG meetings plus Bryan Cantril speaking at Jane Street Jan
18. There is a February 7 meeting sorted out about Reproducible Builds,
but is not yet posted on the web site.
18. There is a February 7 meeting sorted out about Reproducible Builds,
but is not yet posted on the web site.
The CFP for BSDCan 2018 is open.
*****
Wednesday, January 3
OpenBSD Porting Workshop. Learn how to make ports!, Brian Callahan
18:45, LMHQ, 150 Broadway, 20th Floor, Manhattan
Writing ports is a crucial aspect of *BSD development. There is a lot of
software out in the world, and ports and packages make all our lives
much easier. All the non-base software you use passed through the
fingers of a porter.
Making your own ports is an easy and fun way to make your first
contributions to a *BSD project. Is there some piece of software you
just can't live without? Do you have some software of your own that you
would like to have readily available to *BSD users? Just interested in
learning about ports and package management? This is the workshop for
you! No experience necessary to participate. All set up, including an
OpenBSD virtual machine, will be available for participants.
We will be creating our own first ports for the OpenBSD project. This
workshop will be a step-by-step from identifying the software you want
to port through and including the final port ready for submission. By
the end of the workshop, you will have submitted a new port to the
OpenBSD ports@ mailing list!
Speaker Bio
Brian is a Ph.D. Candidate in the Department of Science & Technology
Studies at Rensselaer Polytechnic Institute in Troy, NY.
He is an OpenBSD developer, mostly working on ports.
*****
We generally do not post non-NYC*BUG/BSD events, but we'll make an
exception for this
Jan 18, 2018
The Hurricane's Butterfly: Debugging Pathologically Performing Systems
Speaker: Bryan Cantrill
18:15, Downtown Manhattan
Abstract
Despite significant advances in tooling over the past two decades,
performance debugging—finding and rectifying those limiters to systems
performance—remains a singular challenge in our production systems. This
challenge persists in part because of a butterfly effect in complicated
systems: small but ill-behaving components can have an outsized effect
on the performance of a system in aggregate.
This talk will explore this challenge, including why simple problems can
cause non-linear performance effects, how they can remain so elusive and
what we can do to better debug them.
Registration
As space is limited and building security requires visitor registration,
please register for this talk here.
(https://goo.gl/forms/uL3ME5T1UfGiexG22) We'll send you full location
details when you register.
https://www.janestreet.com/tech-talks/hurricanes-butterfly/
Speaker bio
Bryan Cantrill is CTO at Joyent, where since 2010 he has had
responsibility for Joyent's SmartOS, Triton and Manta technologies.
Previously a Distinguished Engineer at Sun Microsystems, Bryan led the
team that designed and implemented DTrace, a facility for dynamic
instrumentation of production systems that won the Wall Street Journal's
top Technology Innovation Award in 2006. He received
the ScB magna cum laude with honors in Computer Science from Brown
University.
_______________________________________________
announce mailing list
announce@lists.nycbug.org
http://lists.nycbug.org/mailman/listinfo/announce
Monday, December 25, 2017
[FreeBSD-Announce] FreeBSD Quarterly Status Report - Third Quarter 2017
FreeBSD Project Quarterly Status Report - 3rd Quarter 2017
This quarter's FreeBSD developments continue to provide excitement and
promise for further developments. I myself have a soft spot for manual
pages, so it is especially good to see that we have gained some
documentation for writing them (and I hope that this will translate to
more and improved manual pages in the future!). The core@ entry is also
of particular note, with the introduction of the FCP process and the
recognition of the first non-committer FreeBSD Project Member (and
more). Read on to find out more about these, as well as improved
support for the AMD Zen family of processors (e.g., Ryzen), and a whole
lot more!
--Benjamin Kaduk
__________________________________________________________________
The deadline for submissions covering the period from October to
December 2017 is January 14, 2017.
__________________________________________________________________
FreeBSD Team Reports
* FreeBSD Release Engineering Team
* Ports Collection
* The FreeBSD Core Team
* The FreeBSD Foundation
Projects
* FreeBSD CI
Kernel
* Intel 10G iflib Driver Update
* Intel iWARP Support
* pNFS Server Plan B
Architectures
* AMD Zen (family 17h) support
Userland Programs
* Updates to GDB
Ports
* FreeBSDDesktop
* OpenJFX 8
* Puppet
Documentation
* Absolute FreeBSD, 3rd Edition
* Manual Pages
Third-Party Projects
* The nosh Project
__________________________________________________________________
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in
the Administration Page.
FreeBSD Release Engineering Team
Links
FreeBSD 11.1-RELEASE Announcement
URL: https://www.FreeBSD.org/releases/11.1R/announce.html
FreeBSD 10.4-RELEASE Schedule
URL: https://www.FreeBSD.org/releases/10.4R/schedule.html
FreeBSD Development Snapshots
URL: https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/
Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>
The FreeBSD Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes, and maintaining the respective branches, among
other things.
The FreeBSD Release Engineering Team continued finalizing the
11.1-RELEASE cycle, with the final release builds starting on July 21
and the official release announcement email sent on July 26. Thank you
to everyone who helped test 11.1-RELEASE, ensuring its quality and
stability. [1]
FreeBSD 11.1-RELEASE is the second release from the stable/11 branch.
Additionally, the FreeBSD Release Engineering Team started the
10.4-RELEASE cycle, with the code slush starting on July 28. With the
final release build expected to start on September 29 and the official
announcement overlapping the end of the quarter, everything is on
schedule as of this writing. [2]
FreeBSD 10.4-RELEASE will be the fifth release from the stable/10
branch, and is planned to be the final release of the 10.x series.
This project was sponsored by The FreeBSD Foundation [1].
This project was sponsored in part by The FreeBSD Foundation [2].
__________________________________________________________________
Ports Collection
Links
About FreeBSD Ports
URL: https://www.FreeBSD.org/ports/
Contributing to Ports
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html
FreeBSD Ports Monitoring
URL: http://portsmon.freebsd.org/index.html
Ports Management Team Website
URL: https://www.freebsd.org/portmgr/index.html
FreeBSD portmgr on Twitter (@freebsd_portmgr)
URL: https://twitter.com/freebsd_portmgr/
FreeBSD Ports Management Team on Facebook
URL: https://www.facebook.com/portmgr
FreeBSD Ports Management Team on Google+
URL: https://plus.google.com/communities/108335846196454338383
Contact: René Ladan <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>
The Ports Collection now features over 31,600 ports. There are
currently 2671 problem reports, of which 718 are unassigned. This
quarter saw almost 5,900 commits from 175 committers. The number of
open PRs grew compared to last quarter, and outpaced the number of
changes.
This quarter, we welcomed Zach Leslie (zleslie@), Luca Pizzamiglio
(pizzamig@), Craig Leres (leres@), Adriaan de Groot (adridg@), and Dave
Cottlehuber (dch@) as new committers. The commit bits of the following
committers were taken in for safekeeping: alonso@ after 19 months of
inactivity, rpaulo@ per his request, and ache@ after he passed away.
Despite several tries and changing mentors, kami@ lacked interest in
completing his mentorship, so his commit bit was also taken in for
safekeeping.
On the infrastructure side, two USES values were removed because they
outlived their usefulness:
* execinfo: libexecinfo is now available in the base system of all
supported FreeBSD versions
* twisted: there is only one Twisted port left
The default version of GCC was bumped from 5 to 6. Firefox was updated
to version 56.0 and Chromium to version 61.0.3163.100. The version of
pkg itself was updated to 1.10.1.
During this quarter, antoine@ performed 28 exp-runs to test version
updates of major ports, improving USE_GITHUB and SHEBANG_FILES, and API
changes to the base system. This quarter, the foundation for ports
"flavors" was committed, though more development and testing will be
performed in the coming quarter before it goes live.
Open tasks:
1. The PR load needs more attention, as the number of open PRs has
started to increase again.
__________________________________________________________________
The FreeBSD Core Team
Contact: FreeBSD Core Team <core@FreeBSD.org>
The new "FreeBSD Community Process" was drafted during BSDCan earlier
this year. The first such document, FCP 0, defines how the whole
process works. After some time for discussion and revision, FCP 0 was
voted on and accepted by core, following the procedure laid down within
that document. Currently the use of FCPs is entirely optional; we shall
see how the community begins to adopt their usage and evolve the
process based on experience.
A draft update to the Code of Conduct has been prepared by the advisory
committee. Core is currently reviewing the text, and will soon vote on
accepting it. Core is keen to avoid the trap of "rules lawyering". At
the moment, the feeling is that we need to add a preamble to the CoC to
articulate the goals of the project and to act as a general guide to
the exercise of the code.
This quarter has been quite a busy one concerning changes to the roster
of committers and project members. We have elected our first new
Project Member: John Hixson, who will be familiar from many conferences
where he has given presentations and ably represented iXsystems. A
second proposed Project Member was not accepted by core, but only
because core felt that Fedor Uporov really deserved a commit bit
instead.
In addition to Fedor Uporov, please also welcome (in no particular
order) Matt Joras, Marcin Wojtas, Chuck Tuffli, Ilya Bakulin and Alex
Richardson as brand-new committers. We have also awarded Steven Hurd
and Eugene Grosbein src commit bits to go with their existing ports
bits. Welcome back Gordon Tetlow as a src committer, essential for his
new role within secteam. Eric Davis and Rui Paulo have both decided to
hang up their commit bits: we wish them well in their future
endeavours. Finally, we must report the sad death of Andrey Chernov,
who will be sorely missed by his colleagues and collaborators.
Andrey's death has highlighted another question which is only going to
become more complex over time. Keeping track of copyrights is already
hard enough within a mature source tree with many contributors, such as
the FreeBSD sources. Now we need to consider trying to keep track of
the heirs and beneficiaries of contributors who have sadly passed away.
Core will consult with the Foundation legal team to discuss possible
approaches to alleviate this.
There have been complaints that the workings of Core are being kept
overly confidential, and that consequently the majority of the project
has too little idea of what is going on. This is certainly not
intentional by Core, and we are keen to open up Core's business to more
general community scrutiny as far as seems reasonable.
Core dealt with a number of licensing questions:
* When upstreaming patches and other original works to VirtualBox or
other Oracle properties, pragmatically it works best to provide
them under the terms of the MIT license (one of two opensource
licenses accepted by Oracle). Of course, this only applies to work
upstreamed by or with the permission of the original author.
* The Viking software license is sufficiently BSD-like that magic
constants from their drivers can be used in FreeBSD code.
* There is no separate register of deviations from the allowed
BSD-like licenses in the source tree: any code in the tree under
other than BSD-like license terms can be assumed to have been
approved by core.
* At the moment the FreeBSD copyright requirement to include the
copyright notice in redistributions in binary form is satisfied by
making the FreeBSD sources, with all of the detailed copyright
information included in the different source code files, available
alongside pre-compiled system images. However, this does not
necessarily meet the needs of downstream projects based on FreeBSD,
and given the new "packaged base", adding per-package licensing
metadata in a way similar to how the Ports Collection works is
under consideration as an alternative mechanism.
Concerns were raised regarding the pending HardenedBSD entry in the
previous quarterly report prior to publication. The FreeBSD project
welcomes reports from separate (but derived) projects in quarterly
reports and has included similar reports in the past from other
projects (such as TrueOS and pfSense). The HardenedBSD report was
edited for length and to concentrate on activities during the quarter
in question.
Amazon is proposing to set up mirrors of the freebsd-update and pkg
servers within AWS in order to provide faster access for EC2 users.
These mirrors will be publicly accessible, but the expectation is that
use will primarily be from within EC2. FreeBSD AMIs will have a preset
configuration that references the Amazon servers.
The old, long-deprecated, and insecure "r-commands" (rsh, rlogin, rcp)
are being removed from the base system for 12.0-RELEASE. Notice of this
was added to the man pages and release notes in time for 11.1-RELEASE
and 10.4-RELEASE. Anyone requiring these commands for backwards
compatibility can use the new net/bsdrcmds port.
Work to replace Heimdal Kerberos in base with the more widely
compatible MIT Kerberos has begun in a new projects/krb5 branch. This
should not fall afoul of any US cryptography export regulations: the
project is required to notify the US government that cryptographic
software can be downloaded from FreeBSD servers, and this already
covers MIT Kerberos, already available within ports.
A number of Bay Area FreeBSD User Group-related domain names are being
given up by their original owner. The current BAFUG organisers have
been made aware.
Core has voted on a change to the Doceng voting rules to provide for a
"did not vote" status during doceng voting similar to how portmgr and
core voting operates. The current requirement for all five members of
doceng to register a vote on issues was proving to be a significant
bottleneck.
__________________________________________________________________
The FreeBSD Foundation
Links
FreeBSD Foundation Website
URL: https://www.FreeBSDFoundation.org/
FreeBSD Foundation Quarterly Newsletter
URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/08/FreeBSD-Foundation-July-August-2017-Update.pdf
Contact: Deb Goodkin <deb@FreeBSDFoundation.org>
The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
to supporting and promoting the FreeBSD Project and community
worldwide. Funding comes from individual and corporate donations and is
used to fund and manage software development projects, conferences and
developer summits, and provide travel grants to FreeBSD contributors.
The Foundation purchases and supports hardware to improve and maintain
FreeBSD infrastructure and provides full-time Release Engineering
support; publishes marketing material to promote, educate, and advocate
for the FreeBSD Project; facilitates collaboration between commercial
vendors and FreeBSD developers; and finally, represents the FreeBSD
Project in executing contracts, license agreements, and other legal
arrangements that require a recognized legal entity.
Here are some highlights of what we did to help FreeBSD last quarter:
Fundraising Efforts
Our work is 100% funded by your donations. This year we have raised
over $860,000 from over 500 donors. Our 2017 fundraising goal is
$1,250,00 and we are continuing to work hard to meet and exceed this
goal! Please consider making a donation to help us continue and
increase our support for FreeBSD:
https://www.FreeBSDfoundation.org/donate/.
We also have a new Partnership Program, to provide more benefits for
our larger commercial donors. Find out more information at
https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/
and share with your companies!
OS Improvements
The Foundation improves the FreeBSD operating system by employing our
technical staff to maintain and improve critical kernel subsystems, add
features and functionality, and fix problems. This also includes
funding separate project grants like the arm64 port, blacklistd access
control daemon, and the integration of VIMAGE support, to make sure
that FreeBSD remains a viable solution for research, education,
computing, products and more.
We kicked off or continued the following projects last quarter:
* OpenZFS RAID-Z Expansion project
* Broadcom Wi-Fi infrastructural improvements (bhnd(4) driver)
* Headless mode out-of-the-box for the Beaglebone Black
* Extending bhyve/ARMv7 features
* Porting bhyve/ARM to an ARMv8 platform
Having software developers on staff has allowed us to jump in and work
directly on projects to improve FreeBSD like:
* ZFS improvements
* New Intel server support
* kqueue(2) updates
* 64-bit inode support
* Stack guard
* Kernel Undefined Behavior Sanitizer
* Toolchain projects
* i915 driver investigation
* NVDIMM support in acpiconf(8)
* Continuous integration dashboard (web page and physical hardware)
* FAT filesystem support in makefs(8)
Staff and board members continued hosting bi-weekly conference calls to
facilitate efforts for individuals to collaborate on different
technologies.
Release Engineering
The Foundation provides a full-time staff member to lead the release
engineering efforts. This has provided timely and reliable releases
over the last few years.
Last quarter, our full-time staff member worked with the FreeBSD
Release Engineering and Security Teams to finalize 11.1-RELEASE. He
also supported the 10.4 release effort, and has continued producing
10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds
throughout the quarter. At the vBSDCon Developer Summit, he gave a
presentation on the state of the release engineering team.
You can find out more about the support we provided to the Release
Engineering Team by reading their status update in this report.
Supporting FreeBSD Infrastructure
The Foundation provides hardware and support to improve the FreeBSD
infrastructure. Last quarter, we continued supporting FreeBSD hardware
located around the world.
FreeBSD Advocacy and Education
A large part of our efforts are dedicated to advocating for the
Project. This includes promoting work being done by others with
FreeBSD; producing advocacy literature to teach people about FreeBSD
and help make the path to starting using FreeBSD or contributing to the
Project easier; and attending and getting other FreeBSD contributors to
volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD
presentations.
The FreeBSD Foundation sponsors many conferences, events, and summits
around the globe. These events can be BSD-related, open source, or
technology events geared towards underrepresented groups. We support
the FreeBSD-focused events to help provide a venue for sharing
knowledge, to work together on projects, and to facilitate
collaboration between developers and commercial users. This all helps
provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD
in different applications, and to recruit more contributors to the
Project.
Here is a list highlighting some of the advocacy and education work we
did last quarter:
* Organized and ran the Essen FreeBSD Hackathon in Essen Germany
* Sponsored and participated in the FreeBSD Developer Summit BSDCam,
in Cambridge, England
* Represented FreeBSD at the ARM Partner Meeting
* Presented and taught about FreeBSD at SdNOG 4 in Khartoum, Sudan
* Sponsored and gave presentations and tutorials at EuroBSDCon in
Paris, France
* Organized and ran the Paris FreeBSD Developer Summit
* Organized and ran the FreeBSD Developer Summit at vBSDCon
* Sponsored and attended vBSDCon
* Proved travel grants to FreeBSD contributors to attend the above
events.
* Sponsored the 2017 USENIX Security Symposium in Vancouver BC as an
Industry Partner
* Provided FreeBSD advocacy material
* Sponsored the 2017 USENIX Annual Technical Conference in Santa
Clara, CA as an Industry Partner
We continued producing FreeBSD advocacy material to help people promote
FreeBSD around the world.
We help educate the world about FreeBSD by publishing the
professionally produced FreeBSD Journal. Last quarter we published the
July/August issue that you can find at
https://www.FreeBSDfoundation.org/journal/.
You can find out more about events we attended and upcoming events at
https://www.FreeBSDfoundation.org/news-and-events/.
Legal/FreeBSD IP
The Foundation owns the FreeBSD trademarks, and it is our
responsibility to protect them. We also provide legal support for the
core team to investigate questions that arise.
Go to http://www.FreeBSDfoundation.org to find out how we support
FreeBSD and how we can help you!
__________________________________________________________________
Projects
Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.
FreeBSD CI
Links
freebsd-ci Repository
URL: https://github.com/freebsd/freebsd-ci
freebsd-testing Mailing List
URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing
FreeBSD Jenkins Instance
URL: http://ci.FreeBSD.org
Contact: Jenkins Admins <jenkins-admin@FreeBSD.org>
The FreeBSD CI team runs various continuous integration solutions for
FreeBSD, regularly checking that the current state of the Subversion
repository can successfully build, and performing various tests and
analysis upon the build results.
We have introduced a DTrace test pipeline, with the results and
artifacts available at:
* https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/
* https://artifact.ci.FreeBSD.org/dtrace-test/
We had team meetings at two developer summits during Q3:
* BSDcam
* EuroBSDCon
Open tasks:
1. Fix the failing test cases and builds.
2. Create builds for additional architectures.
3. Add more tests.
4. The additional TODO items listed at
https://wiki.FreeBSD.org/Jenkins/TODO .
__________________________________________________________________
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and
more.
Intel 10G iflib Driver Update
Links
ixgbe iflib Conversion
URL: https://reviews.FreeBSD.org/D11727
Contact: Chris Galazka <krzysztof.galazka@intel.com>
Contact: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
The ix and ixv network interface drivers support a variety of Intel
network interfaces, with line speeds at 10 Gbit/second.
This quarter, with the help of Matt Macy and Sean Bruno (among others),
we have submitted a review in Phabricator for the conversion of the
ixgbe driver to use the new (and evolving) iflib framework.
Stay tuned for the conversion of the 40G driver (ixl), as it is
currently being ported to use iflib.
Open tasks:
1. Additional testing.
__________________________________________________________________
Intel iWARP Support
Links
iWARP for ixl
URL: https://reviews.FreeBSD.org/D11378
Contact: Bartosz Sobczak <bartosz.sobczak@intel.com>
iWARP is a protocol suite that enables efficient movement of data
across the network, building on Remote Direct Memory Access, Direct
Data Placement, and Marker PDU Aligned Framing. It endeavors to avoid
unnecessary (local) data copies and to offload work from the main CPU
to dedicated hardware.
An initial commit adding iWARP support for the Intel X722 family of
network adapters is under review. This is an important step towards
introducing full iWARP support on systems equipped with Intel C620
Series Chipsets. Currently, with the iw_ixl driver, only the kVerbs API
is supported.
Open tasks:
1. Additional testing.
__________________________________________________________________
pNFS Server Plan B
Links
Instructions for Testing
URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt
Contact: Rick Macklem <rmacklem@FreeBSD.org>
A pNFS server allows an NFS service to be spread over multiple servers,
separating the MetaData operations from the Data operations (Read and
Write). This project will add the ability to use FreeBSD systems to
create a pNFS service consisting of a single MetaData Server plus a set
of Data Servers. The Data Servers can be mirrored, so that redundant
copies of the file data are maintained.
The support for non-mirrored Data Servers is now believed to be
complete. Support for mirrored Data Servers using the Flexible File
Layout, which will soon be published as an RFC, is implemented.
However, there is still significant work to be done, since the current
implementation of mirrored Data Servers does not handle failed Data
Servers or their resilvering/recovery. It is hoped that support for
failure/recovery of Data Servers will be implemented in the next six
months.
The patched FreeBSD sources may now be accessed for testing via either
Subversion or downloading a gzipped tarball. They consist of a patched
kernel and nfsd and can be used on any FreeBSD 11 or later system. The
installation procedure is covered in the linked document.
Open tasks:
1. Testing by others will be needed, now that the implementation is
available.
2. Implementation and testing of mirror failure/recovery.
__________________________________________________________________
Architectures
Updating platform-specific features and bringing in support for new
hardware platforms.
AMD Zen (family 17h) support
Contact: Conrad Meyer cem@FreeBSD.org <>
This quarter, a bit of work was done to enhance platform support for
AMD Zen (Ryzen, Threadripper, Epyc) processors:
* The CPU topology detection code was enhanced to properly detect Zen
dies and CPU Complexes. This gives the scheduler more locality
information to use when making scheduling decisions.
* The x86 topology analysis was enhanced to report dies and CPU
Complexes, in addition to the existing reporting on packages,
cores, and threads. An example of the new output is FreeBSD/SMP: 1
package(s) x 2 groups x 2 cache groups x 4 core(s) x 2 hardware
threads.
* The amdsmn(4) driver for accessing SMN (System Management Network)
registers was added.
* CPU temperature monitoring support for Zen was added to amdtemp(4).
* In cpufreq(4):
+ Added support for decoding Zen P-state information from
Machine State Registers (which is usually not necessary, since
it is largely redundant with ACPI P-state information, but is
potentially useful)
+ Work around the apparent Ryzen inability to achieve the P1
state by not busying cores waiting to transition to it
* The intpm(4) smbus driver was fixed to attach to the AMD FCH
(Fusion Controller Hub).
* All MCA banks are now enabled and monitored on Zen CPUs.
* Feature-bit decoding was added for: CLZERO, SVM features, and RAS
capabilities.
* SHA intrinsic support was added to the aesni(4) driver. Ryzen is
currently the only desktop processor to feature these intrinsics.
Support for these intrinsics is also present in Intel's Goldmont
line of low-end SoCs.
Overall, Zen is now a very usable platform for x86 workstations and
servers.
This project was sponsored by Dell EMC Isilon.
Open tasks:
1. Add HWPMC support for the new performance counters avilable on the
Zen architecture.
2. Add support for the CCP (Crypto Co-Processor).
__________________________________________________________________
Userland Programs
Changes affecting the base system and programs in it.
Updates to GDB
Contact: John Baldwin <jhb@FreeBSD.org>
Contact: Luca Pizzamiglio <pizzamig@FreeBSD.org>
The devel/gdb port has been updated to GDB 8.0.1.
Support for FreeBSD/aarch64 userland binaries has been committed
upstream. These patches, along with support for debugging
FreeBSD/aarch64 kernels, have been committed to the port.
Upstream patches adding improved support for FreeBSD/arm userland
binaries are currently in review. FreeBSD 12 has recently grown support
for debugging VFP registers via ptrace() and core dumps as part of this
work. Support for FreeBSD/arm kernels will be added to the port after
the upstream patches are added to the port.
Support for $_siginfo has been committed upstream. This uses the
recently added NT_LWPINFO note to extract signal information from
process cores.
Hangs that occured when GDB's kill command was used were fixed in
FreeBSD in r313992.
Open tasks:
1. Figure out why the powerpc kgdb targets are not able to unwind the
stack past the initial frame.
2. Test support for sparc64 binaries and kernels.
3. Add support for debugging powerpc vector registers.
4. Implement info proc commands.
5. Implement info os commands.
__________________________________________________________________
Ports
Changes affecting the Ports Collection, whether sweeping changes that
touch most of the tree, or individual ports themselves.
FreeBSDDesktop
Links
FreeBSDDesktop on GitHub
URL: https://github.com/FreeBSDDesktop/
Contact: Johannes Dieterich <jmd@freebsd.org>
Contact: Mark Johnston <markj@freebsd.org>
Contact: Hans Petter Selasky <hselasky@freebsd.org>
Contact: Matthew Macy <mmacy@nextbsd.org>
The FreeBSDDesktop team is happy to announce the availability of
graphics/drm-next-kmod. This port for FreeBSD-CURRENT (amd64) provides
support for the amdgpu, i915, and radeon DRM modules using the linuxkpi
compatibility framework. The port currently corresponds to the DRM from
Linux 4.9 and is in an experimental state. It works reliably for many
testers with modern GPU hardware (AMD HD7000 series/Tahiti to Polaris
and Intel HD3000/Sandy Bridge to Skylake). Broader testing and
reporting/fixing of bugs is appreciated.
Open tasks:
1. Resolve issues that cause radeonkms and amdgpu to fail with EFI
boot (though there is a workaround available).
2. Upgrade to Linux 4.10 and higher DRM versions.
3. Get feedback from broader testing.
__________________________________________________________________
OpenJFX 8
Links
OpenJFX Wiki
URL: https://wiki.openjdk.java.net/display/OpenJFX/Main
java/openjfx8-devel
URL: https://www.freshports.org/java/openjfx8-devel
java/openjfx8-scenebuilder
URL: https://www.freshports.org/java/openjfx8-scenebuilder
AsciidocFX
URL: https://github.com/asciidocfx/AsciidocFX
Contact: Tobias Kortkamp <tobik@FreeBSD.org>
OpenJFX is an open source, next generation, client application platform
for desktop and embedded systems, based on JavaSE. This quarter, the
OpenJFX port was reworked and has received some significant
improvements.
More modules are being built. With the new web module we gain support
for applications that have their own builtin web browser such as
AsciidocFX. The new media module allows JavaFX applications to play
audio and video files.
A port of the JavaFX scenebuilder, a RAD tool for building JavaFX
scenes, was added to the ports tree.
The OpenGL Prism backend for GPU acceleration was enabled by default.
From a mainainer's and contributor's perspective, the port was
simplified by moving all FreeBSD-local patches to the ports tree and
fetching the upstream sources directly, instead of using a separate
repository for them.
Open tasks:
1. Upstream some of the patches in the Ports Collection.
__________________________________________________________________
Puppet
Links
Puppetlab's FreeBSD Slack Channel
URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/
Contact: Puppet Team <puppet@FreeBSD.org>
This summer has seen the creation of a puppet@ team to help maintain
the approximately 30 Puppet-related ports in the FreeBSD Ports
Collection. These ports were previously maintained by various
committers, and from time to time the distributed maintainership
introduced some delays when updating a port, due to the need to wait
for a maintainer's approval for a related change to a different port.
Puppet 5 is now in the ports tree (as sysutils/puppet5). The C++
version of Facter (sysutils/facter) got a lot of attention and is now a
drop-in replacement for the previous Ruby version
(sysutils/rubygem-facter); it is the default facts source for the
Puppet 5 port.
Work continues on bringing in Puppetserver 5 to the ports tree, and on
keeping all the ports up-to-date.
Open tasks:
1. The pkg package provider has some minor issues (it breaks things
when no repos are configured, and is not working properly from the
context of the MCollective package agent).
2. The databases/puppetdb[345] and sysutils/puppetserver[45] ports
rely on Clojure and Java, and download compiled jar files instead
of building them from source.
__________________________________________________________________
Documentation
Noteworthy changes in the documentation tree or new external
books/documents.
Absolute FreeBSD, 3rd Edition
Links
Official Announcement
URL: https://blather.michaelwlucas.com/archives/3020
Contact: Michael Lucas <mwlucas@michaelwlucas.com>
The first draft of the third edition of Absolute FreeBSD is finished.
It is 220,200 words, or roughly enough to stun a medium-sized ox. It's
on target to be in print before BSDCan 2018.
Open tasks:
1. Stare at the wall blankly for a few days.
2. Fix all the problems pointed out by dozens of community reviewers.
3. Fix all the problems pointed out by John Baldwin, tech reviewer
extraordinaire.
4. Editing. Copyediting. Page layout. Page editing. Re-editing.
Indexing. Edits discovered by indexer.
5. Pre-orders should open some time next year.
6. Restrain myself from strangling people who ask when the fourth
edition is coming.
__________________________________________________________________
Manual Pages
Links
FreeBSD Documentation Project Primer
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/
Contact: Warren Block <wblock@FreeBSD.org>
Over the last year, interest has increased in manual pages, in large
part due to excellent infrastructure work by Baptiste Daroussin and
others, and promotion by George Neville-Neil and others. This increased
interest has been both gratifying and problematic. Our man pages are
underappreciated gems, but we have sadly lacked any substantial
documentation on how to write new ones.
In September, I added a new chapter to the FreeBSD Documentation
Project Primer describing the basics of creating a man page. It
includes descriptions of the markup, section structure, recommended
optional material such as examples, and sample templates for the most
common types of man pages. The Resources section includes links to
several external resources, including the excellent Practical UNIX
Manuals: mdoc.
While this chapter is not a full tutorial, it does begin to fill in a
large gap in our documentation resources and provide a starting point
from which to grow.
Open tasks:
1. Add more explanation and examples of markup usage.
2. Expand the sample templates with additional desired standard
features, like an EXAMPLES section.
3. Add more sample templates.
__________________________________________________________________
Third-Party Projects
Many projects build upon FreeBSD or incorporate components of FreeBSD
into their project. As these projects may be of interest to the broader
FreeBSD community, we sometimes include brief updates submitted by
these projects in our quarterly report. The FreeBSD project makes no
representation as to the accuracy or veracity of any claims in these
submissions.
The nosh Project
Links
Introduction
URL: http://jdebp.eu./Softwares/nosh/
FreeBSD Binary Packages
URL: http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html
Installation How-To
URL: http://jdebp.eu./Softwares/nosh/timorous-admin-installation-how-to.html
Roadmap
URL: http://jdebp.eu./Softwares/nosh/roadmap.html
A Slightly Outdated User Guide
URL: http://jdebp.eu./Softwares/nosh/guide/index.html
Archnosh
URL: http://framagit.org/taca/archnosh
Contact: Jonathan de Boyne Pollard
<J.deBoynePollard-newsgroups@NTLWorld.COM>
The nosh project is a suite of system-level utilities for initializing,
running, and shutting down BSD systems; and for managing daemons,
terminals, and logging. It attempts to supersede BSD init, the Mewburn
rc.d system, and OpenRC as used on FreeBSD and TrueOS, drawing
inspiration from Solaris SMF for named milestones, daemontools-encore
for service control/status mechanisms, UCSPI, and IBM AIX for separated
service and system management. It includes a range of compatibility
mechanisms, including shims for familiar commands from other systems,
and an automatic import mechanism that takes existing configuration
data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere,
applying them to its native service definitions and creating additional
native services. It is portable (including to Linux) and composable, it
provides a migration path from the world of systemd Linux, and it does
not require new kernel APIs. It provides clean service environments,
orderings and dependencies between services, parallelized startup and
shutdown (including fsck), strictly size-capped and autorotated
logging, the service manager as a "subreaper", and uses kevent(2) for
event-driven parallelism.
Since the last status report, in December 2015, the project has seen:
restructured and finer-grained packaging that has fewer conflicts with
other toolsets; the addition of zsh completion files; improvements to
the virtual terminal subsystem, keyboard map, mouse support, and ugen
and DECSCUSR support; RFC 5424/5426 remote logging support; replacement
of libkqueue and the C library's environment handling functions;
several new helper commands; support for Java VM autolocation; improved
socket-passing code; an extended status API and "one-shot" service
support; additional pre-supplied service bundles; support for service
aliases; improved handling of per-user D-Bus services; improved
importing of MySQL, MariaDB, Percona, and OpenVPN services; improved
configuration import support; and extensive additions to the nosh
Guide.
On the recently updated roadmap you can see plans for even more
documentation, continuing the work to extend the capabilities of the
networking subsystem, and the scant handful of rc.d-related items
remaining. There are also some ideas still in the speculative or
planning phases, including work that may depend on incorporating nosh
support into other software.
Open tasks:
1. Improve Ansible and SaltStack integration (the maintainer of the
Arch Linux nosh integration has some ideas).
2. Command-line completions are still needed for bash, csh, and fish.
3. Document convert-systemd-units for use by port maintainers in
making packaged service bundles from systemd unit files.
4. nosh could take advantage of several proposed features for the base
system:
+ the boot loader signaling "emergency" and "rescue" modes of
operation
+ adding machine-readable status output to fsck
+ adding runtime support for more clang-compilable languages in
the early bootstrap stage
+ adding hooks for invoking external configuration import
mechanisms
__________________________________________________________________
This quarter's FreeBSD developments continue to provide excitement and
promise for further developments. I myself have a soft spot for manual
pages, so it is especially good to see that we have gained some
documentation for writing them (and I hope that this will translate to
more and improved manual pages in the future!). The core@ entry is also
of particular note, with the introduction of the FCP process and the
recognition of the first non-committer FreeBSD Project Member (and
more). Read on to find out more about these, as well as improved
support for the AMD Zen family of processors (e.g., Ryzen), and a whole
lot more!
--Benjamin Kaduk
__________________________________________________________________
The deadline for submissions covering the period from October to
December 2017 is January 14, 2017.
__________________________________________________________________
FreeBSD Team Reports
* FreeBSD Release Engineering Team
* Ports Collection
* The FreeBSD Core Team
* The FreeBSD Foundation
Projects
* FreeBSD CI
Kernel
* Intel 10G iflib Driver Update
* Intel iWARP Support
* pNFS Server Plan B
Architectures
* AMD Zen (family 17h) support
Userland Programs
* Updates to GDB
Ports
* FreeBSDDesktop
* OpenJFX 8
* Puppet
Documentation
* Absolute FreeBSD, 3rd Edition
* Manual Pages
Third-Party Projects
* The nosh Project
__________________________________________________________________
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in
the Administration Page.
FreeBSD Release Engineering Team
Links
FreeBSD 11.1-RELEASE Announcement
URL: https://www.FreeBSD.org/releases/11.1R/announce.html
FreeBSD 10.4-RELEASE Schedule
URL: https://www.FreeBSD.org/releases/10.4R/schedule.html
FreeBSD Development Snapshots
URL: https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/
Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>
The FreeBSD Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes, and maintaining the respective branches, among
other things.
The FreeBSD Release Engineering Team continued finalizing the
11.1-RELEASE cycle, with the final release builds starting on July 21
and the official release announcement email sent on July 26. Thank you
to everyone who helped test 11.1-RELEASE, ensuring its quality and
stability. [1]
FreeBSD 11.1-RELEASE is the second release from the stable/11 branch.
Additionally, the FreeBSD Release Engineering Team started the
10.4-RELEASE cycle, with the code slush starting on July 28. With the
final release build expected to start on September 29 and the official
announcement overlapping the end of the quarter, everything is on
schedule as of this writing. [2]
FreeBSD 10.4-RELEASE will be the fifth release from the stable/10
branch, and is planned to be the final release of the 10.x series.
This project was sponsored by The FreeBSD Foundation [1].
This project was sponsored in part by The FreeBSD Foundation [2].
__________________________________________________________________
Ports Collection
Links
About FreeBSD Ports
URL: https://www.FreeBSD.org/ports/
Contributing to Ports
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html
FreeBSD Ports Monitoring
URL: http://portsmon.freebsd.org/index.html
Ports Management Team Website
URL: https://www.freebsd.org/portmgr/index.html
FreeBSD portmgr on Twitter (@freebsd_portmgr)
URL: https://twitter.com/freebsd_portmgr/
FreeBSD Ports Management Team on Facebook
URL: https://www.facebook.com/portmgr
FreeBSD Ports Management Team on Google+
URL: https://plus.google.com/communities/108335846196454338383
Contact: René Ladan <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>
The Ports Collection now features over 31,600 ports. There are
currently 2671 problem reports, of which 718 are unassigned. This
quarter saw almost 5,900 commits from 175 committers. The number of
open PRs grew compared to last quarter, and outpaced the number of
changes.
This quarter, we welcomed Zach Leslie (zleslie@), Luca Pizzamiglio
(pizzamig@), Craig Leres (leres@), Adriaan de Groot (adridg@), and Dave
Cottlehuber (dch@) as new committers. The commit bits of the following
committers were taken in for safekeeping: alonso@ after 19 months of
inactivity, rpaulo@ per his request, and ache@ after he passed away.
Despite several tries and changing mentors, kami@ lacked interest in
completing his mentorship, so his commit bit was also taken in for
safekeeping.
On the infrastructure side, two USES values were removed because they
outlived their usefulness:
* execinfo: libexecinfo is now available in the base system of all
supported FreeBSD versions
* twisted: there is only one Twisted port left
The default version of GCC was bumped from 5 to 6. Firefox was updated
to version 56.0 and Chromium to version 61.0.3163.100. The version of
pkg itself was updated to 1.10.1.
During this quarter, antoine@ performed 28 exp-runs to test version
updates of major ports, improving USE_GITHUB and SHEBANG_FILES, and API
changes to the base system. This quarter, the foundation for ports
"flavors" was committed, though more development and testing will be
performed in the coming quarter before it goes live.
Open tasks:
1. The PR load needs more attention, as the number of open PRs has
started to increase again.
__________________________________________________________________
The FreeBSD Core Team
Contact: FreeBSD Core Team <core@FreeBSD.org>
The new "FreeBSD Community Process" was drafted during BSDCan earlier
this year. The first such document, FCP 0, defines how the whole
process works. After some time for discussion and revision, FCP 0 was
voted on and accepted by core, following the procedure laid down within
that document. Currently the use of FCPs is entirely optional; we shall
see how the community begins to adopt their usage and evolve the
process based on experience.
A draft update to the Code of Conduct has been prepared by the advisory
committee. Core is currently reviewing the text, and will soon vote on
accepting it. Core is keen to avoid the trap of "rules lawyering". At
the moment, the feeling is that we need to add a preamble to the CoC to
articulate the goals of the project and to act as a general guide to
the exercise of the code.
This quarter has been quite a busy one concerning changes to the roster
of committers and project members. We have elected our first new
Project Member: John Hixson, who will be familiar from many conferences
where he has given presentations and ably represented iXsystems. A
second proposed Project Member was not accepted by core, but only
because core felt that Fedor Uporov really deserved a commit bit
instead.
In addition to Fedor Uporov, please also welcome (in no particular
order) Matt Joras, Marcin Wojtas, Chuck Tuffli, Ilya Bakulin and Alex
Richardson as brand-new committers. We have also awarded Steven Hurd
and Eugene Grosbein src commit bits to go with their existing ports
bits. Welcome back Gordon Tetlow as a src committer, essential for his
new role within secteam. Eric Davis and Rui Paulo have both decided to
hang up their commit bits: we wish them well in their future
endeavours. Finally, we must report the sad death of Andrey Chernov,
who will be sorely missed by his colleagues and collaborators.
Andrey's death has highlighted another question which is only going to
become more complex over time. Keeping track of copyrights is already
hard enough within a mature source tree with many contributors, such as
the FreeBSD sources. Now we need to consider trying to keep track of
the heirs and beneficiaries of contributors who have sadly passed away.
Core will consult with the Foundation legal team to discuss possible
approaches to alleviate this.
There have been complaints that the workings of Core are being kept
overly confidential, and that consequently the majority of the project
has too little idea of what is going on. This is certainly not
intentional by Core, and we are keen to open up Core's business to more
general community scrutiny as far as seems reasonable.
Core dealt with a number of licensing questions:
* When upstreaming patches and other original works to VirtualBox or
other Oracle properties, pragmatically it works best to provide
them under the terms of the MIT license (one of two opensource
licenses accepted by Oracle). Of course, this only applies to work
upstreamed by or with the permission of the original author.
* The Viking software license is sufficiently BSD-like that magic
constants from their drivers can be used in FreeBSD code.
* There is no separate register of deviations from the allowed
BSD-like licenses in the source tree: any code in the tree under
other than BSD-like license terms can be assumed to have been
approved by core.
* At the moment the FreeBSD copyright requirement to include the
copyright notice in redistributions in binary form is satisfied by
making the FreeBSD sources, with all of the detailed copyright
information included in the different source code files, available
alongside pre-compiled system images. However, this does not
necessarily meet the needs of downstream projects based on FreeBSD,
and given the new "packaged base", adding per-package licensing
metadata in a way similar to how the Ports Collection works is
under consideration as an alternative mechanism.
Concerns were raised regarding the pending HardenedBSD entry in the
previous quarterly report prior to publication. The FreeBSD project
welcomes reports from separate (but derived) projects in quarterly
reports and has included similar reports in the past from other
projects (such as TrueOS and pfSense). The HardenedBSD report was
edited for length and to concentrate on activities during the quarter
in question.
Amazon is proposing to set up mirrors of the freebsd-update and pkg
servers within AWS in order to provide faster access for EC2 users.
These mirrors will be publicly accessible, but the expectation is that
use will primarily be from within EC2. FreeBSD AMIs will have a preset
configuration that references the Amazon servers.
The old, long-deprecated, and insecure "r-commands" (rsh, rlogin, rcp)
are being removed from the base system for 12.0-RELEASE. Notice of this
was added to the man pages and release notes in time for 11.1-RELEASE
and 10.4-RELEASE. Anyone requiring these commands for backwards
compatibility can use the new net/bsdrcmds port.
Work to replace Heimdal Kerberos in base with the more widely
compatible MIT Kerberos has begun in a new projects/krb5 branch. This
should not fall afoul of any US cryptography export regulations: the
project is required to notify the US government that cryptographic
software can be downloaded from FreeBSD servers, and this already
covers MIT Kerberos, already available within ports.
A number of Bay Area FreeBSD User Group-related domain names are being
given up by their original owner. The current BAFUG organisers have
been made aware.
Core has voted on a change to the Doceng voting rules to provide for a
"did not vote" status during doceng voting similar to how portmgr and
core voting operates. The current requirement for all five members of
doceng to register a vote on issues was proving to be a significant
bottleneck.
__________________________________________________________________
The FreeBSD Foundation
Links
FreeBSD Foundation Website
URL: https://www.FreeBSDFoundation.org/
FreeBSD Foundation Quarterly Newsletter
URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/08/FreeBSD-Foundation-July-August-2017-Update.pdf
Contact: Deb Goodkin <deb@FreeBSDFoundation.org>
The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
to supporting and promoting the FreeBSD Project and community
worldwide. Funding comes from individual and corporate donations and is
used to fund and manage software development projects, conferences and
developer summits, and provide travel grants to FreeBSD contributors.
The Foundation purchases and supports hardware to improve and maintain
FreeBSD infrastructure and provides full-time Release Engineering
support; publishes marketing material to promote, educate, and advocate
for the FreeBSD Project; facilitates collaboration between commercial
vendors and FreeBSD developers; and finally, represents the FreeBSD
Project in executing contracts, license agreements, and other legal
arrangements that require a recognized legal entity.
Here are some highlights of what we did to help FreeBSD last quarter:
Fundraising Efforts
Our work is 100% funded by your donations. This year we have raised
over $860,000 from over 500 donors. Our 2017 fundraising goal is
$1,250,00 and we are continuing to work hard to meet and exceed this
goal! Please consider making a donation to help us continue and
increase our support for FreeBSD:
https://www.FreeBSDfoundation.org/donate/.
We also have a new Partnership Program, to provide more benefits for
our larger commercial donors. Find out more information at
https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/
and share with your companies!
OS Improvements
The Foundation improves the FreeBSD operating system by employing our
technical staff to maintain and improve critical kernel subsystems, add
features and functionality, and fix problems. This also includes
funding separate project grants like the arm64 port, blacklistd access
control daemon, and the integration of VIMAGE support, to make sure
that FreeBSD remains a viable solution for research, education,
computing, products and more.
We kicked off or continued the following projects last quarter:
* OpenZFS RAID-Z Expansion project
* Broadcom Wi-Fi infrastructural improvements (bhnd(4) driver)
* Headless mode out-of-the-box for the Beaglebone Black
* Extending bhyve/ARMv7 features
* Porting bhyve/ARM to an ARMv8 platform
Having software developers on staff has allowed us to jump in and work
directly on projects to improve FreeBSD like:
* ZFS improvements
* New Intel server support
* kqueue(2) updates
* 64-bit inode support
* Stack guard
* Kernel Undefined Behavior Sanitizer
* Toolchain projects
* i915 driver investigation
* NVDIMM support in acpiconf(8)
* Continuous integration dashboard (web page and physical hardware)
* FAT filesystem support in makefs(8)
Staff and board members continued hosting bi-weekly conference calls to
facilitate efforts for individuals to collaborate on different
technologies.
Release Engineering
The Foundation provides a full-time staff member to lead the release
engineering efforts. This has provided timely and reliable releases
over the last few years.
Last quarter, our full-time staff member worked with the FreeBSD
Release Engineering and Security Teams to finalize 11.1-RELEASE. He
also supported the 10.4 release effort, and has continued producing
10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds
throughout the quarter. At the vBSDCon Developer Summit, he gave a
presentation on the state of the release engineering team.
You can find out more about the support we provided to the Release
Engineering Team by reading their status update in this report.
Supporting FreeBSD Infrastructure
The Foundation provides hardware and support to improve the FreeBSD
infrastructure. Last quarter, we continued supporting FreeBSD hardware
located around the world.
FreeBSD Advocacy and Education
A large part of our efforts are dedicated to advocating for the
Project. This includes promoting work being done by others with
FreeBSD; producing advocacy literature to teach people about FreeBSD
and help make the path to starting using FreeBSD or contributing to the
Project easier; and attending and getting other FreeBSD contributors to
volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD
presentations.
The FreeBSD Foundation sponsors many conferences, events, and summits
around the globe. These events can be BSD-related, open source, or
technology events geared towards underrepresented groups. We support
the FreeBSD-focused events to help provide a venue for sharing
knowledge, to work together on projects, and to facilitate
collaboration between developers and commercial users. This all helps
provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD
in different applications, and to recruit more contributors to the
Project.
Here is a list highlighting some of the advocacy and education work we
did last quarter:
* Organized and ran the Essen FreeBSD Hackathon in Essen Germany
* Sponsored and participated in the FreeBSD Developer Summit BSDCam,
in Cambridge, England
* Represented FreeBSD at the ARM Partner Meeting
* Presented and taught about FreeBSD at SdNOG 4 in Khartoum, Sudan
* Sponsored and gave presentations and tutorials at EuroBSDCon in
Paris, France
* Organized and ran the Paris FreeBSD Developer Summit
* Organized and ran the FreeBSD Developer Summit at vBSDCon
* Sponsored and attended vBSDCon
* Proved travel grants to FreeBSD contributors to attend the above
events.
* Sponsored the 2017 USENIX Security Symposium in Vancouver BC as an
Industry Partner
* Provided FreeBSD advocacy material
* Sponsored the 2017 USENIX Annual Technical Conference in Santa
Clara, CA as an Industry Partner
We continued producing FreeBSD advocacy material to help people promote
FreeBSD around the world.
We help educate the world about FreeBSD by publishing the
professionally produced FreeBSD Journal. Last quarter we published the
July/August issue that you can find at
https://www.FreeBSDfoundation.org/journal/.
You can find out more about events we attended and upcoming events at
https://www.FreeBSDfoundation.org/news-and-events/.
Legal/FreeBSD IP
The Foundation owns the FreeBSD trademarks, and it is our
responsibility to protect them. We also provide legal support for the
core team to investigate questions that arise.
Go to http://www.FreeBSDfoundation.org to find out how we support
FreeBSD and how we can help you!
__________________________________________________________________
Projects
Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.
FreeBSD CI
Links
freebsd-ci Repository
URL: https://github.com/freebsd/freebsd-ci
freebsd-testing Mailing List
URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing
FreeBSD Jenkins Instance
URL: http://ci.FreeBSD.org
Contact: Jenkins Admins <jenkins-admin@FreeBSD.org>
The FreeBSD CI team runs various continuous integration solutions for
FreeBSD, regularly checking that the current state of the Subversion
repository can successfully build, and performing various tests and
analysis upon the build results.
We have introduced a DTrace test pipeline, with the results and
artifacts available at:
* https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/
* https://artifact.ci.FreeBSD.org/dtrace-test/
We had team meetings at two developer summits during Q3:
* BSDcam
* EuroBSDCon
Open tasks:
1. Fix the failing test cases and builds.
2. Create builds for additional architectures.
3. Add more tests.
4. The additional TODO items listed at
https://wiki.FreeBSD.org/Jenkins/TODO .
__________________________________________________________________
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and
more.
Intel 10G iflib Driver Update
Links
ixgbe iflib Conversion
URL: https://reviews.FreeBSD.org/D11727
Contact: Chris Galazka <krzysztof.galazka@intel.com>
Contact: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
The ix and ixv network interface drivers support a variety of Intel
network interfaces, with line speeds at 10 Gbit/second.
This quarter, with the help of Matt Macy and Sean Bruno (among others),
we have submitted a review in Phabricator for the conversion of the
ixgbe driver to use the new (and evolving) iflib framework.
Stay tuned for the conversion of the 40G driver (ixl), as it is
currently being ported to use iflib.
Open tasks:
1. Additional testing.
__________________________________________________________________
Intel iWARP Support
Links
iWARP for ixl
URL: https://reviews.FreeBSD.org/D11378
Contact: Bartosz Sobczak <bartosz.sobczak@intel.com>
iWARP is a protocol suite that enables efficient movement of data
across the network, building on Remote Direct Memory Access, Direct
Data Placement, and Marker PDU Aligned Framing. It endeavors to avoid
unnecessary (local) data copies and to offload work from the main CPU
to dedicated hardware.
An initial commit adding iWARP support for the Intel X722 family of
network adapters is under review. This is an important step towards
introducing full iWARP support on systems equipped with Intel C620
Series Chipsets. Currently, with the iw_ixl driver, only the kVerbs API
is supported.
Open tasks:
1. Additional testing.
__________________________________________________________________
pNFS Server Plan B
Links
Instructions for Testing
URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt
Contact: Rick Macklem <rmacklem@FreeBSD.org>
A pNFS server allows an NFS service to be spread over multiple servers,
separating the MetaData operations from the Data operations (Read and
Write). This project will add the ability to use FreeBSD systems to
create a pNFS service consisting of a single MetaData Server plus a set
of Data Servers. The Data Servers can be mirrored, so that redundant
copies of the file data are maintained.
The support for non-mirrored Data Servers is now believed to be
complete. Support for mirrored Data Servers using the Flexible File
Layout, which will soon be published as an RFC, is implemented.
However, there is still significant work to be done, since the current
implementation of mirrored Data Servers does not handle failed Data
Servers or their resilvering/recovery. It is hoped that support for
failure/recovery of Data Servers will be implemented in the next six
months.
The patched FreeBSD sources may now be accessed for testing via either
Subversion or downloading a gzipped tarball. They consist of a patched
kernel and nfsd and can be used on any FreeBSD 11 or later system. The
installation procedure is covered in the linked document.
Open tasks:
1. Testing by others will be needed, now that the implementation is
available.
2. Implementation and testing of mirror failure/recovery.
__________________________________________________________________
Architectures
Updating platform-specific features and bringing in support for new
hardware platforms.
AMD Zen (family 17h) support
Contact: Conrad Meyer cem@FreeBSD.org <>
This quarter, a bit of work was done to enhance platform support for
AMD Zen (Ryzen, Threadripper, Epyc) processors:
* The CPU topology detection code was enhanced to properly detect Zen
dies and CPU Complexes. This gives the scheduler more locality
information to use when making scheduling decisions.
* The x86 topology analysis was enhanced to report dies and CPU
Complexes, in addition to the existing reporting on packages,
cores, and threads. An example of the new output is FreeBSD/SMP: 1
package(s) x 2 groups x 2 cache groups x 4 core(s) x 2 hardware
threads.
* The amdsmn(4) driver for accessing SMN (System Management Network)
registers was added.
* CPU temperature monitoring support for Zen was added to amdtemp(4).
* In cpufreq(4):
+ Added support for decoding Zen P-state information from
Machine State Registers (which is usually not necessary, since
it is largely redundant with ACPI P-state information, but is
potentially useful)
+ Work around the apparent Ryzen inability to achieve the P1
state by not busying cores waiting to transition to it
* The intpm(4) smbus driver was fixed to attach to the AMD FCH
(Fusion Controller Hub).
* All MCA banks are now enabled and monitored on Zen CPUs.
* Feature-bit decoding was added for: CLZERO, SVM features, and RAS
capabilities.
* SHA intrinsic support was added to the aesni(4) driver. Ryzen is
currently the only desktop processor to feature these intrinsics.
Support for these intrinsics is also present in Intel's Goldmont
line of low-end SoCs.
Overall, Zen is now a very usable platform for x86 workstations and
servers.
This project was sponsored by Dell EMC Isilon.
Open tasks:
1. Add HWPMC support for the new performance counters avilable on the
Zen architecture.
2. Add support for the CCP (Crypto Co-Processor).
__________________________________________________________________
Userland Programs
Changes affecting the base system and programs in it.
Updates to GDB
Contact: John Baldwin <jhb@FreeBSD.org>
Contact: Luca Pizzamiglio <pizzamig@FreeBSD.org>
The devel/gdb port has been updated to GDB 8.0.1.
Support for FreeBSD/aarch64 userland binaries has been committed
upstream. These patches, along with support for debugging
FreeBSD/aarch64 kernels, have been committed to the port.
Upstream patches adding improved support for FreeBSD/arm userland
binaries are currently in review. FreeBSD 12 has recently grown support
for debugging VFP registers via ptrace() and core dumps as part of this
work. Support for FreeBSD/arm kernels will be added to the port after
the upstream patches are added to the port.
Support for $_siginfo has been committed upstream. This uses the
recently added NT_LWPINFO note to extract signal information from
process cores.
Hangs that occured when GDB's kill command was used were fixed in
FreeBSD in r313992.
Open tasks:
1. Figure out why the powerpc kgdb targets are not able to unwind the
stack past the initial frame.
2. Test support for sparc64 binaries and kernels.
3. Add support for debugging powerpc vector registers.
4. Implement info proc commands.
5. Implement info os commands.
__________________________________________________________________
Ports
Changes affecting the Ports Collection, whether sweeping changes that
touch most of the tree, or individual ports themselves.
FreeBSDDesktop
Links
FreeBSDDesktop on GitHub
URL: https://github.com/FreeBSDDesktop/
Contact: Johannes Dieterich <jmd@freebsd.org>
Contact: Mark Johnston <markj@freebsd.org>
Contact: Hans Petter Selasky <hselasky@freebsd.org>
Contact: Matthew Macy <mmacy@nextbsd.org>
The FreeBSDDesktop team is happy to announce the availability of
graphics/drm-next-kmod. This port for FreeBSD-CURRENT (amd64) provides
support for the amdgpu, i915, and radeon DRM modules using the linuxkpi
compatibility framework. The port currently corresponds to the DRM from
Linux 4.9 and is in an experimental state. It works reliably for many
testers with modern GPU hardware (AMD HD7000 series/Tahiti to Polaris
and Intel HD3000/Sandy Bridge to Skylake). Broader testing and
reporting/fixing of bugs is appreciated.
Open tasks:
1. Resolve issues that cause radeonkms and amdgpu to fail with EFI
boot (though there is a workaround available).
2. Upgrade to Linux 4.10 and higher DRM versions.
3. Get feedback from broader testing.
__________________________________________________________________
OpenJFX 8
Links
OpenJFX Wiki
URL: https://wiki.openjdk.java.net/display/OpenJFX/Main
java/openjfx8-devel
URL: https://www.freshports.org/java/openjfx8-devel
java/openjfx8-scenebuilder
URL: https://www.freshports.org/java/openjfx8-scenebuilder
AsciidocFX
URL: https://github.com/asciidocfx/AsciidocFX
Contact: Tobias Kortkamp <tobik@FreeBSD.org>
OpenJFX is an open source, next generation, client application platform
for desktop and embedded systems, based on JavaSE. This quarter, the
OpenJFX port was reworked and has received some significant
improvements.
More modules are being built. With the new web module we gain support
for applications that have their own builtin web browser such as
AsciidocFX. The new media module allows JavaFX applications to play
audio and video files.
A port of the JavaFX scenebuilder, a RAD tool for building JavaFX
scenes, was added to the ports tree.
The OpenGL Prism backend for GPU acceleration was enabled by default.
From a mainainer's and contributor's perspective, the port was
simplified by moving all FreeBSD-local patches to the ports tree and
fetching the upstream sources directly, instead of using a separate
repository for them.
Open tasks:
1. Upstream some of the patches in the Ports Collection.
__________________________________________________________________
Puppet
Links
Puppetlab's FreeBSD Slack Channel
URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/
Contact: Puppet Team <puppet@FreeBSD.org>
This summer has seen the creation of a puppet@ team to help maintain
the approximately 30 Puppet-related ports in the FreeBSD Ports
Collection. These ports were previously maintained by various
committers, and from time to time the distributed maintainership
introduced some delays when updating a port, due to the need to wait
for a maintainer's approval for a related change to a different port.
Puppet 5 is now in the ports tree (as sysutils/puppet5). The C++
version of Facter (sysutils/facter) got a lot of attention and is now a
drop-in replacement for the previous Ruby version
(sysutils/rubygem-facter); it is the default facts source for the
Puppet 5 port.
Work continues on bringing in Puppetserver 5 to the ports tree, and on
keeping all the ports up-to-date.
Open tasks:
1. The pkg package provider has some minor issues (it breaks things
when no repos are configured, and is not working properly from the
context of the MCollective package agent).
2. The databases/puppetdb[345] and sysutils/puppetserver[45] ports
rely on Clojure and Java, and download compiled jar files instead
of building them from source.
__________________________________________________________________
Documentation
Noteworthy changes in the documentation tree or new external
books/documents.
Absolute FreeBSD, 3rd Edition
Links
Official Announcement
URL: https://blather.michaelwlucas.com/archives/3020
Contact: Michael Lucas <mwlucas@michaelwlucas.com>
The first draft of the third edition of Absolute FreeBSD is finished.
It is 220,200 words, or roughly enough to stun a medium-sized ox. It's
on target to be in print before BSDCan 2018.
Open tasks:
1. Stare at the wall blankly for a few days.
2. Fix all the problems pointed out by dozens of community reviewers.
3. Fix all the problems pointed out by John Baldwin, tech reviewer
extraordinaire.
4. Editing. Copyediting. Page layout. Page editing. Re-editing.
Indexing. Edits discovered by indexer.
5. Pre-orders should open some time next year.
6. Restrain myself from strangling people who ask when the fourth
edition is coming.
__________________________________________________________________
Manual Pages
Links
FreeBSD Documentation Project Primer
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/
Contact: Warren Block <wblock@FreeBSD.org>
Over the last year, interest has increased in manual pages, in large
part due to excellent infrastructure work by Baptiste Daroussin and
others, and promotion by George Neville-Neil and others. This increased
interest has been both gratifying and problematic. Our man pages are
underappreciated gems, but we have sadly lacked any substantial
documentation on how to write new ones.
In September, I added a new chapter to the FreeBSD Documentation
Project Primer describing the basics of creating a man page. It
includes descriptions of the markup, section structure, recommended
optional material such as examples, and sample templates for the most
common types of man pages. The Resources section includes links to
several external resources, including the excellent Practical UNIX
Manuals: mdoc.
While this chapter is not a full tutorial, it does begin to fill in a
large gap in our documentation resources and provide a starting point
from which to grow.
Open tasks:
1. Add more explanation and examples of markup usage.
2. Expand the sample templates with additional desired standard
features, like an EXAMPLES section.
3. Add more sample templates.
__________________________________________________________________
Third-Party Projects
Many projects build upon FreeBSD or incorporate components of FreeBSD
into their project. As these projects may be of interest to the broader
FreeBSD community, we sometimes include brief updates submitted by
these projects in our quarterly report. The FreeBSD project makes no
representation as to the accuracy or veracity of any claims in these
submissions.
The nosh Project
Links
Introduction
URL: http://jdebp.eu./Softwares/nosh/
FreeBSD Binary Packages
URL: http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html
Installation How-To
URL: http://jdebp.eu./Softwares/nosh/timorous-admin-installation-how-to.html
Roadmap
URL: http://jdebp.eu./Softwares/nosh/roadmap.html
A Slightly Outdated User Guide
URL: http://jdebp.eu./Softwares/nosh/guide/index.html
Archnosh
URL: http://framagit.org/taca/archnosh
Contact: Jonathan de Boyne Pollard
<J.deBoynePollard-newsgroups@NTLWorld.COM>
The nosh project is a suite of system-level utilities for initializing,
running, and shutting down BSD systems; and for managing daemons,
terminals, and logging. It attempts to supersede BSD init, the Mewburn
rc.d system, and OpenRC as used on FreeBSD and TrueOS, drawing
inspiration from Solaris SMF for named milestones, daemontools-encore
for service control/status mechanisms, UCSPI, and IBM AIX for separated
service and system management. It includes a range of compatibility
mechanisms, including shims for familiar commands from other systems,
and an automatic import mechanism that takes existing configuration
data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere,
applying them to its native service definitions and creating additional
native services. It is portable (including to Linux) and composable, it
provides a migration path from the world of systemd Linux, and it does
not require new kernel APIs. It provides clean service environments,
orderings and dependencies between services, parallelized startup and
shutdown (including fsck), strictly size-capped and autorotated
logging, the service manager as a "subreaper", and uses kevent(2) for
event-driven parallelism.
Since the last status report, in December 2015, the project has seen:
restructured and finer-grained packaging that has fewer conflicts with
other toolsets; the addition of zsh completion files; improvements to
the virtual terminal subsystem, keyboard map, mouse support, and ugen
and DECSCUSR support; RFC 5424/5426 remote logging support; replacement
of libkqueue and the C library's environment handling functions;
several new helper commands; support for Java VM autolocation; improved
socket-passing code; an extended status API and "one-shot" service
support; additional pre-supplied service bundles; support for service
aliases; improved handling of per-user D-Bus services; improved
importing of MySQL, MariaDB, Percona, and OpenVPN services; improved
configuration import support; and extensive additions to the nosh
Guide.
On the recently updated roadmap you can see plans for even more
documentation, continuing the work to extend the capabilities of the
networking subsystem, and the scant handful of rc.d-related items
remaining. There are also some ideas still in the speculative or
planning phases, including work that may depend on incorporating nosh
support into other software.
Open tasks:
1. Improve Ansible and SaltStack integration (the maintainer of the
Arch Linux nosh integration has some ideas).
2. Command-line completions are still needed for bash, csh, and fish.
3. Document convert-systemd-units for use by port maintainers in
making packaged service bundles from systemd unit files.
4. nosh could take advantage of several proposed features for the base
system:
+ the boot loader signaling "emergency" and "rescue" modes of
operation
+ adding machine-readable status output to fsck
+ adding runtime support for more clang-compilable languages in
the early bootstrap stage
+ adding hooks for invoking external configuration import
mechanisms
__________________________________________________________________
Thursday, December 21, 2017
[CentOS-announce] CEBA-2017:3488 CentOS 7 java-1.8.0-openjdk BugFix Update
CentOS Errata and Bugfix Advisory 2017:3488
Upstream details at : https://access.redhat.com/errata/RHBA-2017:3488
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
88b9407e3fa3e414d3f5c58054436d913a684f2418243d1a80f62360d490b3e1 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.i686.rpm
05149beeef9d964630c315fb1f1ef789e6a13f91650b9a5f15512ed7932ce405 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.x86_64.rpm
fd3402a60e2655776a4f1397a27d0dabe9b6fe1a091a8bd9e26d44904ff95030 java-1.8.0-openjdk-accessibility-1.8.0.151-5.b12.el7_4.i686.rpm
831d088e4c4376526b8fe2b898b640d7d5cc9343ed445a81f63de3a9a73c927f java-1.8.0-openjdk-accessibility-1.8.0.151-5.b12.el7_4.x86_64.rpm
5465474e5f28a5a827559cf1e1d1f50f4c34e786c1d9674e132325cde996dc9d java-1.8.0-openjdk-accessibility-debug-1.8.0.151-5.b12.el7_4.i686.rpm
6e98a2aa798a8d947ce79330ae3d76e17818e88c7387049e3c962f9894c05b6c java-1.8.0-openjdk-accessibility-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
fa0e91cd0ffbe8063798267db48b7539bfd538949f658340c08423b4cd46e3ac java-1.8.0-openjdk-debug-1.8.0.151-5.b12.el7_4.i686.rpm
3abc411f2ef77dff9d4dd9029ba73f2388bc1615b48e36c58fdceef70c27f715 java-1.8.0-openjdk-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
66a38fbcdd258f4476a763ab78a2521ba8b16bdefac4092c895ffe06a89750ca java-1.8.0-openjdk-demo-1.8.0.151-5.b12.el7_4.i686.rpm
fc6f2ad0b5b0cc9f8006b0563318e67ee3b5d946c77164aad7804232e373291a java-1.8.0-openjdk-demo-1.8.0.151-5.b12.el7_4.x86_64.rpm
5ef918b503b2157b884a67afd008a5305318e252763025127aa4f88dbc97dfed java-1.8.0-openjdk-demo-debug-1.8.0.151-5.b12.el7_4.i686.rpm
53b8ae44f13c7a301aec5a86d615d7fe456a1a8b885eeb725f93d859d83a0d01 java-1.8.0-openjdk-demo-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
69309f73b87778acefd461386e0ec3e38789072062df5d86b948e2002e3fa735 java-1.8.0-openjdk-devel-1.8.0.151-5.b12.el7_4.i686.rpm
e000185c393464cef260cf2ad09006dbec57a5d0af3ab07ddf660e63d85d8dcf java-1.8.0-openjdk-devel-1.8.0.151-5.b12.el7_4.x86_64.rpm
8cc915795a1e2c1e5360fb7dee840e1ee313e54ab8478da0b17febb1a8e0223f java-1.8.0-openjdk-devel-debug-1.8.0.151-5.b12.el7_4.i686.rpm
7cf96429bc9ace0baa790e39515a0caa62879d90f1a2c434b559ea91f56ea427 java-1.8.0-openjdk-devel-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
966737cdc9dbfc16a7ea4fdff949778d166f011b326c86bad319dfd3daf0b200 java-1.8.0-openjdk-headless-1.8.0.151-5.b12.el7_4.i686.rpm
2901045d49e3d933b17ad111999fdbf16b72824f0e56fe99789d944da054a1ac java-1.8.0-openjdk-headless-1.8.0.151-5.b12.el7_4.x86_64.rpm
c7efb4aa1a5e2a9011bc943f94a5b4989488436292222dfb6613eafbfe712b1b java-1.8.0-openjdk-headless-debug-1.8.0.151-5.b12.el7_4.i686.rpm
29a773df8073a7f388e6d598c7ca0b7b6373be48b5954b7598bf88d4c4cd6eb9 java-1.8.0-openjdk-headless-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
2660fdc8dd1ef01bdaef92042cdeff1e9ffb973aae07b1560d72c395eec4c3f4 java-1.8.0-openjdk-javadoc-1.8.0.151-5.b12.el7_4.noarch.rpm
6bf58e3312f317b05b104410814cd75b596a1399d5289dba2c49af3cce8bb89e java-1.8.0-openjdk-javadoc-debug-1.8.0.151-5.b12.el7_4.noarch.rpm
e5f9c92f82916404e3755a074a28362ab1504d4b021d259f6b4edc953f9d6926 java-1.8.0-openjdk-javadoc-zip-1.8.0.151-5.b12.el7_4.noarch.rpm
fce1b975ec219f230047c87c0bf23262d9065b3a0b9a3c8e6072317c4ec70fc4 java-1.8.0-openjdk-javadoc-zip-debug-1.8.0.151-5.b12.el7_4.noarch.rpm
2e41900e72c7e6740f8a68a5292530473fdc42b820a9c72fc2b889ec55d0e27e java-1.8.0-openjdk-src-1.8.0.151-5.b12.el7_4.i686.rpm
f644bf21f724dfe4865a33941710ef78d790bd55710254cce2572b3b35e1f4e8 java-1.8.0-openjdk-src-1.8.0.151-5.b12.el7_4.x86_64.rpm
de5140dfbccb73bba874a7c1895f4657e3aac5e5c9c1bbb03e638470eedfafb3 java-1.8.0-openjdk-src-debug-1.8.0.151-5.b12.el7_4.i686.rpm
863b8b64536c0d8ea90367901097d46c3e94fee36c034cca52fb2e1801e2dc02 java-1.8.0-openjdk-src-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
Source:
8439a79f2aa0f8c64fc9dda350fba575c3bb8119e56a2db8b1afcc2f04e4b597 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHBA-2017:3488
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
88b9407e3fa3e414d3f5c58054436d913a684f2418243d1a80f62360d490b3e1 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.i686.rpm
05149beeef9d964630c315fb1f1ef789e6a13f91650b9a5f15512ed7932ce405 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.x86_64.rpm
fd3402a60e2655776a4f1397a27d0dabe9b6fe1a091a8bd9e26d44904ff95030 java-1.8.0-openjdk-accessibility-1.8.0.151-5.b12.el7_4.i686.rpm
831d088e4c4376526b8fe2b898b640d7d5cc9343ed445a81f63de3a9a73c927f java-1.8.0-openjdk-accessibility-1.8.0.151-5.b12.el7_4.x86_64.rpm
5465474e5f28a5a827559cf1e1d1f50f4c34e786c1d9674e132325cde996dc9d java-1.8.0-openjdk-accessibility-debug-1.8.0.151-5.b12.el7_4.i686.rpm
6e98a2aa798a8d947ce79330ae3d76e17818e88c7387049e3c962f9894c05b6c java-1.8.0-openjdk-accessibility-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
fa0e91cd0ffbe8063798267db48b7539bfd538949f658340c08423b4cd46e3ac java-1.8.0-openjdk-debug-1.8.0.151-5.b12.el7_4.i686.rpm
3abc411f2ef77dff9d4dd9029ba73f2388bc1615b48e36c58fdceef70c27f715 java-1.8.0-openjdk-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
66a38fbcdd258f4476a763ab78a2521ba8b16bdefac4092c895ffe06a89750ca java-1.8.0-openjdk-demo-1.8.0.151-5.b12.el7_4.i686.rpm
fc6f2ad0b5b0cc9f8006b0563318e67ee3b5d946c77164aad7804232e373291a java-1.8.0-openjdk-demo-1.8.0.151-5.b12.el7_4.x86_64.rpm
5ef918b503b2157b884a67afd008a5305318e252763025127aa4f88dbc97dfed java-1.8.0-openjdk-demo-debug-1.8.0.151-5.b12.el7_4.i686.rpm
53b8ae44f13c7a301aec5a86d615d7fe456a1a8b885eeb725f93d859d83a0d01 java-1.8.0-openjdk-demo-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
69309f73b87778acefd461386e0ec3e38789072062df5d86b948e2002e3fa735 java-1.8.0-openjdk-devel-1.8.0.151-5.b12.el7_4.i686.rpm
e000185c393464cef260cf2ad09006dbec57a5d0af3ab07ddf660e63d85d8dcf java-1.8.0-openjdk-devel-1.8.0.151-5.b12.el7_4.x86_64.rpm
8cc915795a1e2c1e5360fb7dee840e1ee313e54ab8478da0b17febb1a8e0223f java-1.8.0-openjdk-devel-debug-1.8.0.151-5.b12.el7_4.i686.rpm
7cf96429bc9ace0baa790e39515a0caa62879d90f1a2c434b559ea91f56ea427 java-1.8.0-openjdk-devel-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
966737cdc9dbfc16a7ea4fdff949778d166f011b326c86bad319dfd3daf0b200 java-1.8.0-openjdk-headless-1.8.0.151-5.b12.el7_4.i686.rpm
2901045d49e3d933b17ad111999fdbf16b72824f0e56fe99789d944da054a1ac java-1.8.0-openjdk-headless-1.8.0.151-5.b12.el7_4.x86_64.rpm
c7efb4aa1a5e2a9011bc943f94a5b4989488436292222dfb6613eafbfe712b1b java-1.8.0-openjdk-headless-debug-1.8.0.151-5.b12.el7_4.i686.rpm
29a773df8073a7f388e6d598c7ca0b7b6373be48b5954b7598bf88d4c4cd6eb9 java-1.8.0-openjdk-headless-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
2660fdc8dd1ef01bdaef92042cdeff1e9ffb973aae07b1560d72c395eec4c3f4 java-1.8.0-openjdk-javadoc-1.8.0.151-5.b12.el7_4.noarch.rpm
6bf58e3312f317b05b104410814cd75b596a1399d5289dba2c49af3cce8bb89e java-1.8.0-openjdk-javadoc-debug-1.8.0.151-5.b12.el7_4.noarch.rpm
e5f9c92f82916404e3755a074a28362ab1504d4b021d259f6b4edc953f9d6926 java-1.8.0-openjdk-javadoc-zip-1.8.0.151-5.b12.el7_4.noarch.rpm
fce1b975ec219f230047c87c0bf23262d9065b3a0b9a3c8e6072317c4ec70fc4 java-1.8.0-openjdk-javadoc-zip-debug-1.8.0.151-5.b12.el7_4.noarch.rpm
2e41900e72c7e6740f8a68a5292530473fdc42b820a9c72fc2b889ec55d0e27e java-1.8.0-openjdk-src-1.8.0.151-5.b12.el7_4.i686.rpm
f644bf21f724dfe4865a33941710ef78d790bd55710254cce2572b3b35e1f4e8 java-1.8.0-openjdk-src-1.8.0.151-5.b12.el7_4.x86_64.rpm
de5140dfbccb73bba874a7c1895f4657e3aac5e5c9c1bbb03e638470eedfafb3 java-1.8.0-openjdk-src-debug-1.8.0.151-5.b12.el7_4.i686.rpm
863b8b64536c0d8ea90367901097d46c3e94fee36c034cca52fb2e1801e2dc02 java-1.8.0-openjdk-src-debug-1.8.0.151-5.b12.el7_4.x86_64.rpm
Source:
8439a79f2aa0f8c64fc9dda350fba575c3bb8119e56a2db8b1afcc2f04e4b597 java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CEEA-2017:3489 CentOS 7 kmod-redhat-qed Enhancement Update
CentOS Errata and Enhancement Advisory 2017:3489
Upstream details at : https://access.redhat.com/errata/RHEA-2017:3489
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
9683e58225c1778e171043227dc376241a55ba74aec9f4579cf30f4fa4090dbf kmod-redhat-qed-8.10.10.21_dup7.4-2.el7_4.x86_64.rpm
6c962b2d384c8bf7dd7e8b92e24fa1c1235bbe6212f7be70665ab3f13b66ebf6 kmod-redhat-qede-8.10.10.21_dup7.4-2.el7_4.x86_64.rpm
ed6c9515bcfa965d45397f017418f568594046d85a2075316593989275a8b2af kmod-redhat-qedf-8.10.7.0_dup7.4-2.el7_4.x86_64.rpm
01f8ae75160adfac3d286b1c410bd38bca5a2afd99ad2e70536b30dc20f18fdb kmod-redhat-qedi-8.10.4.0_dup7.4-3.el7_4.x86_64.rpm
96ebbaffa522fee78b45e1e4d7ac461314d2d87e585eb1670617808843f9f1ed kmod-redhat-qedr-8.10.10.0_dup7.4-2.el7_4.x86_64.rpm
Source:
a42ac424ad1fa43269d891ac23bc276cef7bcdd25e7660c9ecf29788f691229c kmod-redhat-qed-8.10.10.21_dup7.4-2.el7_4.src.rpm
25130fca8c3dc270affb3c1d43df0b12e8161924a204edd8db273842ad50f369 kmod-redhat-qede-8.10.10.21_dup7.4-2.el7_4.src.rpm
43bae084122db338174961b0a6b4a7265504f8be486a77db70838f00cc30ded9 kmod-redhat-qedf-8.10.7.0_dup7.4-2.el7_4.src.rpm
cc3cbeb63ed45f2598b3ccf8c04344135e5785a0b9be1c84ba8dd0e5ecae559f kmod-redhat-qedi-8.10.4.0_dup7.4-3.el7_4.src.rpm
f9c105b0f845d0722618d3eb867e94e26d3b1ae4164522a8727d677a7e998be7 kmod-redhat-qedr-8.10.10.0_dup7.4-2.el7_4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHEA-2017:3489
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
9683e58225c1778e171043227dc376241a55ba74aec9f4579cf30f4fa4090dbf kmod-redhat-qed-8.10.10.21_dup7.4-2.el7_4.x86_64.rpm
6c962b2d384c8bf7dd7e8b92e24fa1c1235bbe6212f7be70665ab3f13b66ebf6 kmod-redhat-qede-8.10.10.21_dup7.4-2.el7_4.x86_64.rpm
ed6c9515bcfa965d45397f017418f568594046d85a2075316593989275a8b2af kmod-redhat-qedf-8.10.7.0_dup7.4-2.el7_4.x86_64.rpm
01f8ae75160adfac3d286b1c410bd38bca5a2afd99ad2e70536b30dc20f18fdb kmod-redhat-qedi-8.10.4.0_dup7.4-3.el7_4.x86_64.rpm
96ebbaffa522fee78b45e1e4d7ac461314d2d87e585eb1670617808843f9f1ed kmod-redhat-qedr-8.10.10.0_dup7.4-2.el7_4.x86_64.rpm
Source:
a42ac424ad1fa43269d891ac23bc276cef7bcdd25e7660c9ecf29788f691229c kmod-redhat-qed-8.10.10.21_dup7.4-2.el7_4.src.rpm
25130fca8c3dc270affb3c1d43df0b12e8161924a204edd8db273842ad50f369 kmod-redhat-qede-8.10.10.21_dup7.4-2.el7_4.src.rpm
43bae084122db338174961b0a6b4a7265504f8be486a77db70838f00cc30ded9 kmod-redhat-qedf-8.10.7.0_dup7.4-2.el7_4.src.rpm
cc3cbeb63ed45f2598b3ccf8c04344135e5785a0b9be1c84ba8dd0e5ecae559f kmod-redhat-qedi-8.10.4.0_dup7.4-3.el7_4.src.rpm
f9c105b0f845d0722618d3eb867e94e26d3b1ae4164522a8727d677a7e998be7 kmod-redhat-qedr-8.10.10.0_dup7.4-2.el7_4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
LibreSSL 2.6.4 Released (fixed)
We have released LibreSSL 2.6.4, the first stable maintenance release from the
2.6.x series. It contains the following changes from the 2.6.3 release:
* Made tls_config_parse_protocols() work correctly when passed a NULL
pointer for a protocol string. Issue found by semarie@, who also
provided the diff.
* Corrected TLS extensions handling when no extensions are present.
If no TLS extensions are present in a client hello or server hello,
omit the entire extensions block, rather than including it with a
length of zero. Thanks to Eric Elena <eric at voguemerry dot com> for
providing packet captures and testing the fix.
* Fixed portable builds on older Android systems, and systems without
IPV6_TCLASS support.
The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.
2.6.x series. It contains the following changes from the 2.6.3 release:
* Made tls_config_parse_protocols() work correctly when passed a NULL
pointer for a protocol string. Issue found by semarie@, who also
provided the diff.
* Corrected TLS extensions handling when no extensions are present.
If no TLS extensions are present in a client hello or server hello,
omit the entire extensions block, rather than including it with a
length of zero. Thanks to Eric Elena <eric at voguemerry dot com> for
providing packet captures and testing the fix.
* Fixed portable builds on older Android systems, and systems without
IPV6_TCLASS support.
The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.
Tuesday, December 19, 2017
Modularity is Dead, Long Live Modularity!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Modularity is Dead, Long Live Modularity! ========================================= See this post in glorious technicolor at: https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/ Summary - ------- Fedora's Modularity initiative aims to make it easy for packagers to create alternative versions of software and for users to consume those streams simply. We've been working on this for several years, resulting in the "Boltron" prototype this summer and the recent Fedora Modular Server beta. Feedback shows that these test releases didn't meet the goal, and we're incorporating that in a modified design which we think _will_. We plan to demo the new approach by DevConf.cz and FOSDEM. Retrospective - ------------- As you have probably read, the members of the Modularity Working Group and the Server Working Group decided that the current implementation of Modularity would not meet Fedora's standard of excellence in time for a release in Fedora 27 — even with the extra time that the Fedora Council granted to the project. In particular, feedback received from the Fedora 27 Modular Server Beta release alerted us to several serious problems in the design. The most common feedback from users was: "How do I install package `foo` in Modular Server?". In this case, `foo` ranged across a wide variety of software, including everything from the screen package to complex third-party applications. In that version of Modularity, a system was either all Modular or none of it was. To make software available in the fully-modular system, its packages needed to be part of a module — and unfortunately, we didn't succeed in making many of those. The lack of available modules was a symptom of a larger problem with packager involvement. Some of this problem was due to disagreements with the implementation or design, and some of it was because creating modules turned out to be more time-consuming and had a steeper learning curve than we wanted. Additionally, the whole process was not obvious or well-socialized. The team produced a lot of documentation, but packagers needed to understand a whole lot of it before even getting started. As a result, all of the modules slated for delivery in F27 Modular Server were being developed by the Modularity team, a group that had limited expertise around many of the packages we desired to ship. There were other problems, of course. We didn't really have a strong plan for how to handle upgrades from traditional deployments. We lacked a story for how third-party software should be loaded onto the system. And, we never got away from needing a "bootstrap" module (as explained below). So, we decided not to ship Modular Server in Fedora 27, and we activated our fallback plan of releasing Fedora 27 Server Edition in its classic incarnation at https://getfedora.org/server/. Moving Forward - -------------- With all of this in mind, we took Modularity back to the drawing board (or perhaps "chopping board"). We analyzed the various functionality that the design offered us and made some trade-offs. First and foremost, we gave up on the idea of a strictly-maintained, stable buildroot. Traditional Fedora builds are performed by building an RPM in a buildroot containing the latest packages available in the stable updates repository for a release (plus the overrides repo when needed to allow building against pre-release packages). With modularity, we hoped that we could define a small and specific buildroot which would be stable and maintained for the life of a release. We would then build every module against it. It turned out when we tried to implement this that it was basically impossible. It required us to find a point at which the entire buildroot could be used to build _itself_, a feat which has not been accomplished in Fedora for many years (if ever). Fedora packages are really only guaranteed to build successfully against a buildroot for which they have _already_ been built. If it builds against any other buildroot, this is a happy accident. There are many reasons for this; something in the dependency chain for one of the build dependencies may have broken, a bug may have been introduced in the compiler or linker resulting in an inability to continue, new default compiler flags may have been added that result in warnings becoming errors and so on. This was the easiest requirement to drop as it had never worked. We used a kludgy "bootstrap" module to work around this which provided a set of packages copied from non-Modular Fedora to be able to build the platform. In its place, **we will now build modules against the standard Fedora buildroot**. Since our buildroot now has access to everything that has been built for Fedora, we reconsidered another of our original goals that of providing a module to be the base platform upon which all of the other modules would depend. Originally, this was intended to define the provided API of the Base and indicate which portions of it should be considered stable. However, Fedora already has a stable updates policy for how things must act within a release. This policy has only a few outliers (Kernel, KDE, etc.), but for the most part, once we release the Beta, the platform API is stable for the life of the Fedora release. By relaxing this requirement, we realized that we could eliminate (or at least postpone) the requirement for having a defined platform module. What we decided instead is to treat Fedora's "Everything" repository (essentially, the complete set of software available within a Fedora release) as the "platform module", though the tooling will not report this content as a module. In practical terms, this means that **creators of modules will no longer need to go through the very painful process of tracking down which modules provide a dependency that they need**. Instead, they will be able to depend on the system version available in the Everything repo. If that version does not meet their needs, they will have several options described later. This provides us with several advantages, including **a straightforward upgrade path from a traditional deployment**, because we will retain the traditional repositories as well as a set of default modules. This means it will be possible to upgrade from a current Fedora 27 system to a modular Fedora 28 system without any special steps. In fact, this approach will also mean that modularity need not be limited to the Server Edition. Another practical advantage to this change is that **module-creation will become _significantly_ simpler**. Instead of a complex collection of a package and all of its dependencies, modules will now only need to describe the parts that differ from the base repository. For example, Fedora 28 will ship with the Node.js 8.x LTS release in the standard repository, and a module could be built to provide the 9.x experimental release as an option. We could also easily provide the older 6.x LTS release to support older applications. In these cases, we can ship very simple module definitions which just lists the dist-git branches matching the desired upstream releases. In fact, this will now be so simple that **we plan to provide tools to automate the creation of these modules**. Since most modules will now only require a single source package be in the components list, we plan to enable support for automatically building a single branch in dist-git for all active Fedora (and EPEL) releases. Even for more complex multi-package modules, the automatically-created module definitions provide an easy and obvious starting point. What Will It Look Like? - ----------------------- From an end-user's perspective, **Fedora will ship with two sets of repositories.** One will be the traditional Fedora repositories (fedora, updates, and updates-testing) and the other will be a new set of repositories providing alternative and supplementary modules. We haven't decided on a final name for these yet, so we will use the placeholder terms modular, modular-updates, and modular-updates-testing. With this design, **anyon who does not wish to access the additional versions of software provided by modules can disable the modular and modular-updates repositories and their system will function exactly as it does today**. Packages built with Fedora's traditional process will be installed and managed from the regular fedora repository, as will default versions of packages which use the new process behind the scenes. **For anyone who wants access to additional versions of packages, these new module repositories will make them available**. Users will be able to interact with these new repositories by taking advantage of some new syntax in DNF, the same as was used in the Modular Server Beta. If a user wants to install a particular module stream, they can do `dnf install module[:stream[/profile]]` (e.g. `dnf install @nodejs:6`, which will install the default profile containing the nodejs and npm packages). If the user just wants to install whatever version is the default for this system, a `dnf install package` will continue to work as it always has. Conclusion - ---------- This refined plan offers an understandable, approachable, and deliverable future for Modularity. Packagers who don't want to produce modules will be able to continue packaging exactly as they always have with **no modification** to their workflows. Those who want to provide alternative versions of software in a single release or to easily provide the same version across multiple releases will have new tools to simplify this. As the number of available modules grows, users of Fedora will have a much easier access to the exact version of software they want to accomplish their tasks. People doing rapid-prototyping can more easily access newer versions of packages and at the same time people running older applications can continue to access the older streams that they need. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.1.0 Comment: https://www.mailvelope.com wkYEAREIABAFAlo5f/YJEHolVWI2uqOjAAD5RgCfeRL8DcETF34kmCOT5pXJ yzL0LLYAmwVmmd2DPHf1gzKZOjUfxiHlbuML =ZnhF -----END PGP SIGNATURE-----
Monday, December 18, 2017
[USN-3382-2] PHP vulnerabilities
==========================================================================
Ubuntu Security Notice USN-3382-2
December 18, 2017
php5 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in PHP.
Software Description:
- php5: HTML-embedded scripting language interpreter
Details:
USN-3382-1 fixed several vulnerabilities in PHP. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that the PHP URL parser incorrectly handled certain
URI components. A remote attacker could possibly use this issue to
bypass hostname-specific URL checks. (CVE-2016-10397)
It was discovered that PHP incorrectly handled certain boolean
parameters when unserializing data. A remote attacker could possibly
use this issue to cause PHP to crash, resulting in a denial of
service. (CVE-2017-11143)
Sebastian Li, Wei Lei, Xie Xiaofei, and Liu Yang discovered that PHP
incorrectly handled the OpenSSL sealing function. A remote attacker
could possibly use this issue to cause PHP to crash, resulting in a
denial of service. (CVE-2017-11144)
Wei Lei and Liu Yang discovered that the PHP date extension
incorrectly handled memory. A remote attacker could possibly use this
issue to disclose sensitive information from the server.
(CVE-2017-11145)
It was discovered that PHP incorrectly handled certain PHAR archives.
A remote attacker could use this issue to cause PHP to crash or
disclose sensitive information. This issue only affected Ubuntu 14.04
LTS. (CVE-2017-11147)
Wei Lei and Liu Yang discovered that PHP incorrectly handled parsing
ini files. An attacker could possibly use this issue to cause PHP to
crash, resulting in a denial of service. (CVE-2017-11628)
It was discovered that PHP mbstring incorrectly handled certain
regular expressions. A remote attacker could use this issue to cause
PHP to crash, resulting in a denial of service, or possibly execute
arbitrary code. (CVE-2017-9224, CVE-2017-9226, CVE-2017-9227, CVE-
2017-9228, CVE-2017-9229)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libapache2-mod-php5 5.3.10-1ubuntu3.28
php5 5.3.10-1ubuntu3.28
php5-cgi 5.3.10-1ubuntu3.28
php5-cli 5.3.10-1ubuntu3.28
php5-fpm 5.3.10-1ubuntu3.28
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3382-2
https://www.ubuntu.com/usn/usn-3382-1
CVE-2016-10397, CVE-2017-11143, CVE-2017-11144, CVE-2017-11145,
CVE-2017-11147, CVE-2017-11628, CVE-2017-9224, CVE-2017-9226,
CVE-2017-9227, CVE-2017-9228, CVE-2017-9229
Ubuntu Security Notice USN-3382-2
December 18, 2017
php5 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in PHP.
Software Description:
- php5: HTML-embedded scripting language interpreter
Details:
USN-3382-1 fixed several vulnerabilities in PHP. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that the PHP URL parser incorrectly handled certain
URI components. A remote attacker could possibly use this issue to
bypass hostname-specific URL checks. (CVE-2016-10397)
It was discovered that PHP incorrectly handled certain boolean
parameters when unserializing data. A remote attacker could possibly
use this issue to cause PHP to crash, resulting in a denial of
service. (CVE-2017-11143)
Sebastian Li, Wei Lei, Xie Xiaofei, and Liu Yang discovered that PHP
incorrectly handled the OpenSSL sealing function. A remote attacker
could possibly use this issue to cause PHP to crash, resulting in a
denial of service. (CVE-2017-11144)
Wei Lei and Liu Yang discovered that the PHP date extension
incorrectly handled memory. A remote attacker could possibly use this
issue to disclose sensitive information from the server.
(CVE-2017-11145)
It was discovered that PHP incorrectly handled certain PHAR archives.
A remote attacker could use this issue to cause PHP to crash or
disclose sensitive information. This issue only affected Ubuntu 14.04
LTS. (CVE-2017-11147)
Wei Lei and Liu Yang discovered that PHP incorrectly handled parsing
ini files. An attacker could possibly use this issue to cause PHP to
crash, resulting in a denial of service. (CVE-2017-11628)
It was discovered that PHP mbstring incorrectly handled certain
regular expressions. A remote attacker could use this issue to cause
PHP to crash, resulting in a denial of service, or possibly execute
arbitrary code. (CVE-2017-9224, CVE-2017-9226, CVE-2017-9227, CVE-
2017-9228, CVE-2017-9229)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libapache2-mod-php5 5.3.10-1ubuntu3.28
php5 5.3.10-1ubuntu3.28
php5-cgi 5.3.10-1ubuntu3.28
php5-cli 5.3.10-1ubuntu3.28
php5-fpm 5.3.10-1ubuntu3.28
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3382-2
https://www.ubuntu.com/usn/usn-3382-1
CVE-2016-10397, CVE-2017-11143, CVE-2017-11144, CVE-2017-11145,
CVE-2017-11147, CVE-2017-11628, CVE-2017-9224, CVE-2017-9226,
CVE-2017-9227, CVE-2017-9228, CVE-2017-9229
Friday, December 15, 2017
Elections in January 2018 to FESCo, Council, Mindshare - the schedule
Hi,
I have published schedule for elections in January 2018 on the
Elections [1] wiki page. The schedule is as follows:
* Dec 15 - Jan 02: Selection of questions from Questionnaire
* Jan 03 - Jan 10: Nomination period
* Jan 11 - Jan 15: Interviews
* Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews
* Jan 17 - Jan 24: Voting period
* Jan 25: Result Announcement
Please check the Election page [1] for more details on how the
Elections (and interviews) are going to be organized.
I am going to be on vacations, mostly off-grid, until January 4th, so
if you need any help, please contact Bex [2] (and CC me, please).
[1] https://fedoraproject.org/wiki/Elections
[2] https://fedoraproject.org/wiki/User:Bex
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
I have published schedule for elections in January 2018 on the
Elections [1] wiki page. The schedule is as follows:
* Dec 15 - Jan 02: Selection of questions from Questionnaire
* Jan 03 - Jan 10: Nomination period
* Jan 11 - Jan 15: Interviews
* Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews
* Jan 17 - Jan 24: Voting period
* Jan 25: Result Announcement
Please check the Election page [1] for more details on how the
Elections (and interviews) are going to be organized.
I am going to be on vacations, mostly off-grid, until January 4th, so
if you need any help, please contact Bex [2] (and CC me, please).
[1] https://fedoraproject.org/wiki/Elections
[2] https://fedoraproject.org/wiki/User:Bex
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
[USN-3509-3] Linux kernel regression
==========================================================================
Ubuntu Security Notice USN-3509-3
December 15, 2017
linux, linux-aws, linux-kvm, linux-raspi2 regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 LTS
Summary:
USN-3509-1 introduced a regression in the Linux kernel for Ubuntu 16.04 LTS.
Software Description:
- linux: Linux kernel
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-kvm: Linux kernel for cloud environments
- linux-raspi2: Linux kernel for Raspberry Pi 2
Details:
USN-3509-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. Unfortunately, it also introduced a regression that prevented the
Ceph network filesystem from being used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 LTS:
linux-image-4.4.0-1013-kvm 4.4.0-1013.18
linux-image-4.4.0-104-generic 4.4.0-104.127
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127
linux-image-4.4.0-104-lowlatency 4.4.0-104.127
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127
linux-image-4.4.0-1044-aws 4.4.0-1044.53
linux-image-4.4.0-1080-raspi2 4.4.0-1080.88
linux-image-aws 4.4.0.1044.46
linux-image-generic 4.4.0.104.109
linux-image-generic-lpae 4.4.0.104.109
linux-image-kvm 4.4.0.1013.13
linux-image-lowlatency 4.4.0.104.109
linux-image-powerpc-e500mc 4.4.0.104.109
linux-image-powerpc-smp 4.4.0.104.109
linux-image-powerpc64-emb 4.4.0.104.109
linux-image-powerpc64-smp 4.4.0.104.109
linux-image-raspi2 4.4.0.1080.80
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-3
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux/4.4.0-104.127
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1044.53
https://launchpad.net/ubuntu/+source/linux-kvm/4.4.0-1013.18
https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1080.88
Ubuntu Security Notice USN-3509-3
December 15, 2017
linux, linux-aws, linux-kvm, linux-raspi2 regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 LTS
Summary:
USN-3509-1 introduced a regression in the Linux kernel for Ubuntu 16.04 LTS.
Software Description:
- linux: Linux kernel
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-kvm: Linux kernel for cloud environments
- linux-raspi2: Linux kernel for Raspberry Pi 2
Details:
USN-3509-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. Unfortunately, it also introduced a regression that prevented the
Ceph network filesystem from being used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 LTS:
linux-image-4.4.0-1013-kvm 4.4.0-1013.18
linux-image-4.4.0-104-generic 4.4.0-104.127
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127
linux-image-4.4.0-104-lowlatency 4.4.0-104.127
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127
linux-image-4.4.0-1044-aws 4.4.0-1044.53
linux-image-4.4.0-1080-raspi2 4.4.0-1080.88
linux-image-aws 4.4.0.1044.46
linux-image-generic 4.4.0.104.109
linux-image-generic-lpae 4.4.0.104.109
linux-image-kvm 4.4.0.1013.13
linux-image-lowlatency 4.4.0.104.109
linux-image-powerpc-e500mc 4.4.0.104.109
linux-image-powerpc-smp 4.4.0.104.109
linux-image-powerpc64-emb 4.4.0.104.109
linux-image-powerpc64-smp 4.4.0.104.109
linux-image-raspi2 4.4.0.1080.80
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-3
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux/4.4.0-104.127
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1044.53
https://launchpad.net/ubuntu/+source/linux-kvm/4.4.0-1013.18
https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1080.88
[USN-3509-4] Linux kernel (Xenial HWE) regression
==========================================================================
Ubuntu Security Notice USN-3509-4
December 15, 2017
linux-lts-xenial, linux-aws regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
USN-3509-2 introduced a regression in the Linux HWE kernel for Ubuntu 14.04 LTS.
Software Description:
- linux-lts-xenial: Linux hardware enablement kernel from Xenial for Trusty
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
Details:
USN-3509-2 fixed vulnerabilities in the Linux Hardware Enablement
kernel for Ubuntu 14.04 LTS. Unfortunately, it also introduced a
regression that prevented the Ceph network filesystem from being
used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
linux-image-4.4.0-1006-aws 4.4.0-1006.6
linux-image-4.4.0-104-generic 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-lowlatency 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127~14.04.1
linux-image-aws 4.4.0.1006.6
linux-image-generic-lpae-lts-xenial 4.4.0.104.87
linux-image-generic-lts-xenial 4.4.0.104.87
linux-image-lowlatency-lts-xenial 4.4.0.104.87
linux-image-powerpc-e500mc-lts-xenial 4.4.0.104.87
linux-image-powerpc-smp-lts-xenial 4.4.0.104.87
linux-image-powerpc64-emb-lts-xenial 4.4.0.104.87
linux-image-powerpc64-smp-lts-xenial 4.4.0.104.87
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-4
https://www.ubuntu.com/usn/usn-3509-2
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1006.6
https://launchpad.net/ubuntu/+source/linux-lts-xenial/4.4.0-104.127~14.04.1
Ubuntu Security Notice USN-3509-4
December 15, 2017
linux-lts-xenial, linux-aws regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
USN-3509-2 introduced a regression in the Linux HWE kernel for Ubuntu 14.04 LTS.
Software Description:
- linux-lts-xenial: Linux hardware enablement kernel from Xenial for Trusty
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
Details:
USN-3509-2 fixed vulnerabilities in the Linux Hardware Enablement
kernel for Ubuntu 14.04 LTS. Unfortunately, it also introduced a
regression that prevented the Ceph network filesystem from being
used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
linux-image-4.4.0-1006-aws 4.4.0-1006.6
linux-image-4.4.0-104-generic 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-lowlatency 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127~14.04.1
linux-image-aws 4.4.0.1006.6
linux-image-generic-lpae-lts-xenial 4.4.0.104.87
linux-image-generic-lts-xenial 4.4.0.104.87
linux-image-lowlatency-lts-xenial 4.4.0.104.87
linux-image-powerpc-e500mc-lts-xenial 4.4.0.104.87
linux-image-powerpc-smp-lts-xenial 4.4.0.104.87
linux-image-powerpc64-emb-lts-xenial 4.4.0.104.87
linux-image-powerpc64-smp-lts-xenial 4.4.0.104.87
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-4
https://www.ubuntu.com/usn/usn-3509-2
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1006.6
https://launchpad.net/ubuntu/+source/linux-lts-xenial/4.4.0-104.127~14.04.1
Wednesday, December 13, 2017
[CentOS-announce] Announcing the release for Gluster 3.13 on CentOS Linux 6 x86_64
I am happy to announce the General Availability of Gluster 3.13 for
CentOS 6 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 6 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects.
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
CentOS 6 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 6 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects.
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
[CentOS-announce] Announcing the release for Gluster 3.13 on CentOS Linux 7 x86_64
I am happy to announce the General Availability of Gluster 3.13 for
CentOS 7 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 7 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects (possibly for oVirt, there may be others).
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
CentOS 7 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 7 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects (possibly for oVirt, there may be others).
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
[USN-3513-2] libxml2 vulnerability
==========================================================================
Ubuntu Security Notice USN-3513-2
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
USN-3513-1 fixed a vulnerability in libxml2. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libxml2 2.7.8.dfsg-5.1ubuntu4.20
libxml2-utils 2.7.8.dfsg-5.1ubuntu4.20
python-libxml2 2.7.8.dfsg-5.1ubuntu4.20
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-2
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
Ubuntu Security Notice USN-3513-2
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
USN-3513-1 fixed a vulnerability in libxml2. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libxml2 2.7.8.dfsg-5.1ubuntu4.20
libxml2-utils 2.7.8.dfsg-5.1ubuntu4.20
python-libxml2 2.7.8.dfsg-5.1ubuntu4.20
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-2
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
[USN-3513-1] libxml2 vulnerability
==========================================================================
Ubuntu Security Notice USN-3513-1
December 13, 2017
Ubuntu Security Notice USN-3513-1
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 17.10
- Ubuntu 17.04
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 17.10:
libxml2 2.9.4+dfsg1-4ubuntu1.2
libxml2-utils 2.9.4+dfsg1-4ubuntu1.2
python-libxml2 2.9.4+dfsg1-4ubuntu1.2
python3-libxml2 2.9.4+dfsg1-4ubuntu1.2
Ubuntu 17.04:
libxml2 2.9.4+dfsg1-2.2ubuntu0.3
libxml2-utils 2.9.4+dfsg1-2.2ubuntu0.3
python-libxml2 2.9.4+dfsg1-2.2ubuntu0.3
python3-libxml2 2.9.4+dfsg1-2.2ubuntu0.3
Ubuntu 16.04 LTS:
libxml2 2.9.3+dfsg1-1ubuntu0.5
libxml2-utils 2.9.3+dfsg1-1ubuntu0.5
python-libxml2 2.9.3+dfsg1-1ubuntu0.5
Ubuntu 14.04 LTS:
libxml2 2.9.1+dfsg1-3ubuntu4.12
libxml2-utils 2.9.1+dfsg1-3ubuntu4.12
python-libxml2 2.9.1+dfsg1-3ubuntu4.12
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
Package Information:
https://launchpad.net/ubuntu/+source/libxml2/2.9.4+dfsg1-4ubuntu1.2
https://launchpad.net/ubuntu/+source/libxml2/2.9.4+dfsg1-2.2ubuntu0.3
https://launchpad.net/ubuntu/+source/libxml2/2.9.3+dfsg1-1ubuntu0.5
https://launchpad.net/ubuntu/+source/libxml2/2.9.1+dfsg1-3ubuntu4.12
Tuesday, December 12, 2017
Fedora 27 Server classic release after all — and Modularity goes back to the drawing board
You may remember reading about our plans for Fedora 27 Server. The
working group decided not to release that at the same time as the
general F27 release, and instead provided a beta of Fedora 27
Modular Server. Based on feedback from that beta, they decided to
take a different approach, and the Modularity subproject is going
back to the drawing board.
Fortunately, there is a contingency plan: Fedora's release
engineering team made a "classic" version of Fedora 27 Server —
very similar to F26 Server, but with F27's updated package set. The
quality assurance ran this version through validation testing, and
it's being released, so:
Quick Summary
-------------
* You can now download Fedora 27 Server from the Get Fedora site.
https://getfedora.org/server/
This is the "classic" Fedora Server, without Modularity.
* The Modularity Working Group is going back to the drawing
board. Plans are still in progress, but it will likely produce a
separate package repository which will build on top of and coexist
with the traditional Fedora operating systems.
Modularity Past and Future
--------------------------
Modularity has a very straightforward mission: to enable Fedora to
deliver multiple versions of components on different lifecycles
across multiple base OS releases. It includes some other ideas
about improving packager and user experiences in the process, but
that's the basic thing. Every Linux user has some things they want
to move quickly, and others they want to not worry about. Fedora
wants to give you that choice.
The approach in last summer's "Boltron" and the recent beta
envisioned an entirely new distribution of Fedora software, with
the base operating system itself composed as a module. This offers
some interesting benefits — in particular, it keeps the build
dependencies of a piece of software well-defined and
well-contained. But it has a huge drawback: if some random piece of
software isn't contained in a module, it wouldn't be available on
that edition of Fedora at all. Also, the definition files for
modules were another layer of complication, and it became clear
that wouldn't get to an acceptable level of available software for
real use.
So, the Modularity Working Group and Server Working Group together
decided, rather than offer users and early adopters another
iteration down that path, to release the traditional Fedora 27
Server you can find above and take a different approach. The teams
are still working out what exactly that will look like, but the
most promising involves adding an entirely separate package
repository which can be layered on top of traditional Fedora,
rather than building a new modular base operating system. This will
make it easy for users to opt-in when they want to, and greatly
reduces the complication for packagers.
"First" is one of the core foundations of the Fedora Project. At
the leading edge of innovation, every step Fedora takes advances
the state of the art, even when it's not directly successful. And,
if every try succeeds, Fedora's not trying hard enough. Sometimes
experiments produce negative results. That's okay — the project
learns even when trying a path that doesn't work out, and it
iterates to something better. That process is happening now, and if
you're interested, please join the conversation on the devel
mailing list or watch for updates on the Fedora Community Blog in
the Modularity Category.
https://communityblog.fedoraproject.org/category/modularity/
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
announce mailing list -- announce@lists.fedoraproject.org
To unsubscribe send an email to announce-leave@lists.fedoraproject.org
working group decided not to release that at the same time as the
general F27 release, and instead provided a beta of Fedora 27
Modular Server. Based on feedback from that beta, they decided to
take a different approach, and the Modularity subproject is going
back to the drawing board.
Fortunately, there is a contingency plan: Fedora's release
engineering team made a "classic" version of Fedora 27 Server —
very similar to F26 Server, but with F27's updated package set. The
quality assurance ran this version through validation testing, and
it's being released, so:
Quick Summary
-------------
* You can now download Fedora 27 Server from the Get Fedora site.
https://getfedora.org/server/
This is the "classic" Fedora Server, without Modularity.
* The Modularity Working Group is going back to the drawing
board. Plans are still in progress, but it will likely produce a
separate package repository which will build on top of and coexist
with the traditional Fedora operating systems.
Modularity Past and Future
--------------------------
Modularity has a very straightforward mission: to enable Fedora to
deliver multiple versions of components on different lifecycles
across multiple base OS releases. It includes some other ideas
about improving packager and user experiences in the process, but
that's the basic thing. Every Linux user has some things they want
to move quickly, and others they want to not worry about. Fedora
wants to give you that choice.
The approach in last summer's "Boltron" and the recent beta
envisioned an entirely new distribution of Fedora software, with
the base operating system itself composed as a module. This offers
some interesting benefits — in particular, it keeps the build
dependencies of a piece of software well-defined and
well-contained. But it has a huge drawback: if some random piece of
software isn't contained in a module, it wouldn't be available on
that edition of Fedora at all. Also, the definition files for
modules were another layer of complication, and it became clear
that wouldn't get to an acceptable level of available software for
real use.
So, the Modularity Working Group and Server Working Group together
decided, rather than offer users and early adopters another
iteration down that path, to release the traditional Fedora 27
Server you can find above and take a different approach. The teams
are still working out what exactly that will look like, but the
most promising involves adding an entirely separate package
repository which can be layered on top of traditional Fedora,
rather than building a new modular base operating system. This will
make it easy for users to opt-in when they want to, and greatly
reduces the complication for packagers.
"First" is one of the core foundations of the Fedora Project. At
the leading edge of innovation, every step Fedora takes advances
the state of the art, even when it's not directly successful. And,
if every try succeeds, Fedora's not trying hard enough. Sometimes
experiments produce negative results. That's okay — the project
learns even when trying a path that doesn't work out, and it
iterates to something better. That process is happening now, and if
you're interested, please join the conversation on the devel
mailing list or watch for updates on the Fedora Community Blog in
the Modularity Category.
https://communityblog.fedoraproject.org/category/modularity/
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
announce mailing list -- announce@lists.fedoraproject.org
To unsubscribe send an email to announce-leave@lists.fedoraproject.org
Subscribe to:
Posts (Atom)