Phoronix recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
Best regards / S pozdravem,
== Summary ==
Ruby 2.6 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.5 in Fedora 29 to
Ruby 2.6 in Fedora 30, Fedora becomes the superior Ruby development
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondruch(a)redhat.com, pvalena(a)redhat.com
== Detailed Description ==
Ruby 2.6 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== JIT ===
Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler.
JIT compiler aims to improve performance of any Ruby program
execution. Unlike ordinary JIT compilers for other languages, Ruby’s
JIT compiler does JIT compilation in a unique way, which prints C code
to a disk and spawns common C compiler process to generate native
The main purpose of this JIT release is to provide a chance to check
if it works for your platform and to find out security risks before
the 2.6 release. JIT compiler is supported when Ruby is built by GCC,
Clang, or Microsoft VC++, which needs to be available on runtime.
Otherwise you can’t use it for now.
As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than
Ruby 2.5 on CPU-intensive non-trivial benchmark workload called
Optcarrot. The performance on memory-intensive workload like Rails
application are going to be improved as well.
=== RubyVM::AST [Experimental] ===
Ruby 2.6 introduces `RubyVM::AST` module.
This module has `parse` method which parses a given ruby code of
string and returns AST (Abstract Syntax Tree) nodes, and `parse_file`
method which parses a given ruby code file and returns AST nodes.
`RubyVM::AST::Node` class is also introduced. You can get location
information and children nodes from `Node` objects. This feature is
experimental. Compatibility of the structure of AST nodes are not
=== New Features ===
* Add a new alias `then` to `Kernel#yield_self`.
* Add `Random.bytes`.
* Add `Binding#source_location`. This method returns the source
location of binding, a 2-element array of __FILE__ and __LINE__.
* Add `:exception` option to let `Kernel.#system` raise error instead
of returning `false`.
* Add a new alias then to `Kernel#yield_self`.
* `else` without `rescue` now causes a syntax error. [EXPERIMENTAL]
* Constant names may start with a non-ASCII capital letter.
* An endless range, (1..), is introduced. It works as it has no end.
=== Performance improvements ===
* Speedup `Proc#call` because we don’t need to care about $SAFE any
more. With `lc_fizzbuzz` benchmark it makes x1.4 speed improvement.
* Speedup `block.call` where block is passed block parameter. Ruby 2.6
improves the performance of passed block calling. There can observed
2.6x improvement with micro-benchmarks.
* Transient Heap (theap) is introduced. theap is managed heap for
short-living memory objects which are pointed by specific classes. For
example, making small and short-living Hash object is x2 faster. With
rdoc benchmark, 6-7% performance improvement is observed.
=== Other notable changes since 2.5 ===
* `$SAFE` is a process global state and we can set `0` again.
* Passing `safe_level` to `ERB.new` is deprecated. `trim_mode` and
`eoutvar` arguments are changed to keyword arguments.
* Merged RubyGems 3.0.0.beta2.
* Merge Bundler as default gem.
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 2.6. Current changes available in PR
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 2.6 properly.
* Release engineering: [https://pagure.io/releng/issue/7936 #7936]
** Separate Koji tag for package rebuild will be needed.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 2.6. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 2.6.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
== Contingency Plan ==
* Contingency deadline: Mass Rebuild
* Blocks release? No
* Blocks product? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
* [https://github.com/ruby/ruby/blob/v2_6_0_preview3/NEWS Ruby
== Release Notes ==
* The Ruby 2.6 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
Fedora Program Manager
I'm new on this list. I work on Qubes OS, where Fedora is used as a base
While trying to build the installation image in reproducible manner,
I found the current installation image have unusual layout. Quoting
dracut.cmdline manual page:
squashfs.img | Squashfs from LiveCD .iso downloaded via network
|- rootfs.img | Filesystem image to mount read-only
/bin | Live filesystem
This rootfs.img layer makes the image build very much unreproducible.
Why is it even there? Bare squashfs.img layer should be enough. Then,
mount overlayfs over it (I see there is even some partial support for it
in dmsquash-live). Most other Live systems I've seen use just squashfs +
overlayfs (or aufs if kernel is older), so it's commonly tested
configuration. I *guess* it's there for historical reason, from before
aufs/overlayfs being available. Is there any other reason for that?
If there is no other reason, I propose to drop this and have
installer/live filesystem directly in squashfs.img. This have multiple
- it's much easier to make the image build process reproducible (see
- less complexity, both in the build and in the boot (the whole
dmsquash-live dracut module can be replaced with <20 line
- smaller initramfs (which is extremely important if needed to be
included in efiboot.img, which can't be larger than 32MB)
- slightly faster boot time (device-mapper is slow)
What do you think?
As for the reproducibility, I've made changes to lorax (including
dropping rootfs.img layer), anaconda, pungi and createrepo and this all
allows to build bit-by-bit identical image, given the same input (rpm
packages, pungi configuration, $SOURCE_DATE_EPOCH variable). Well,
almost - there is an issue with efiboot.img, but I already have a
solution, just not pushed it yet.
You can find all the pull requests collected here:
I'll work further to make the changes merged upstream.
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
For a long time now updates are pushed manually everyday. It was
troublesome and someone has to own it for a week and look after it.
Now, the pushes are automated and are pushed everyday at 00:00 UTC. If
anything fails there will be an oncall person (same person who used to do
the pushes) who will take care of the failure.
During release freezes these automated pushes are disabled and are manually
pushed by RelEng/Infra. Since freezes should be handled differently this
will give RelEng more control over the pushes.
Please let us know if you have any questions or contact us on
#fedora-releng on Freenode.
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
I worked with FPL Matthew Miller and our engineering manager Jim
Perrin, among others, to define the various problems we want to solve
in diversifying the Fedora lifecycle. We're seeking review and
feedback from community members. The most salient feedback will be
from those involved in the efforts we describe, but we welcome all
Here's the summary from the page, which proposes we pause the release
after F30 for these efforts:
* * *
Fedora’s singular lifecycle has been in place for almost a decade and
a half. During that time, technology users have changed how they
consume platform and applications. Fedora needs to be more toward the
forefront of these changes. But more importantly, Fedora needs to be
more hospitable to community management of lifecycle.
Currently Fedora can’t scale for more community ownership of the
things we release: (1) Only a few people can build and push out
releases; and (2) we manage releases largely based on that staffing.
The Fedora community should be able to run releases of content
themselves, using tools that work well, with only minimal oversight,
and determine their own schedule for doing so.
This implies a great deal of both redesign and reworking of tools and
processes. To unblock the community, several things need to happen. We
need a faster, more scalable compose to enable CI/CD operations; we
need to automate more testing and quality measures; and we need to
update our delivery tools and processes. We also need to track and
coordinate this work across teams, since it involves collaboration
among Fedora infrastructure, QA, applications, release engineering,
CentOS CI, maintainers, and more.
We should skip the F31 release cycle and leave F30 in place longer in
order to focus on improving the tooling and testing changes. These
tooling changes will improve the overall reliability of Fedora, and
will decrease the manual effort and complexities involved in producing
the distribution artifacts. Although we’ve done this before to make
“editions” happen, the intent is to track this multi-team effort more
actively so we can (1) use the time as well as possible, and (2) give
the work maximum transparency.
* * *
The full page is here, with a set of problems, solutions, and actions
proposed. I invite you to take time to read it in detail:
I also attached that page to the main Lifecycle objective page here,
which was previously approved by the Council:
Rather than try to spin this one email into a thread of doom that
people will give up on reading, I encourage those with feedback to
open a thread for any particular topic. That way the community
discussion should be more useful for all.
I'll collect input and use it both for responses and to help tweak
plans for (hopefully) optimal results. I'm on vacation next week, for
which timing I apologize. But I'll try to look at mail here from time
to time and when I return.
One of the key parts of making a decision to delay/skip F31 is
figuring out, ahead of the decision, what the expected experience is
for users and packagers. Does F30 have normal stability, or do we try
to keep users happy by moving things forward with ad-hoc updates and
cross-our-fingers and hope nothing breaks?
I tend to think about this in terms of GNOME - would we rebase to
GNOME 3.34 in the middle of F30 or not? But there's a lot of other
pieces of software where similar considerations apply: container
tools, cockpit, NetworkManager, etc.
And if we did do updates like that, would we consider respinning media
and making a "F30.1"?
I haven't seen any posts about this but is anyone else having problem
with audio after an upgrade? - it happens with both PulseAudio and with
just basic ALSA. I have a relatively simple setup:
description: Audio device
product: 200 Series PCH HD Audio
vendor: Intel Corporation
physical id: 1f.3
bus info: pci@0000:00:1f.3
width: 64 bits
capabilities: pm msi bus_master cap_list
configuration: driver=snd_hda_intel latency=32
resources: irq:133 memory:df140000-df143fff
The audio is bearable for spoken stuff but for music it is not . . very
staticky - like a recording done with a very old, cheap microphone . .
PO Box 896
Cowra NSW 2794
On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>> f-r currently fails to build (#1603956), it has a bunch of bugs open 
>> and many issues and unhandled pull requests in the upstream repo [2, 3].
>> The last upstream commit was 2 years ago.
>> f-r has is annoyingly outdated and gives often outright bad advice
>> (for example about BR:gcc or BR:g++). The situation would be
>> improved if the outstanding PRs were merged.
>> f-r is also python2-only now, which will be a problem soon since
>> support for python2 is waning .
>> Is there any hope of upstream and downstream activity on f-r?
> I was thinking about getting the fedora-review checks rewritten into the
> standard Test interface
> so that they
> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> might take a little bit of time.
I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
Once this is fully automated, we can then *also* add the same checks to CI
(taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
Historically, we've had human review mainly to protect against two things,
bundling and unacceptable licenses. In both of these cases, I'd like for us
to move towards a culture of assuming goodwill on behalf of our packagers.
Most of the packagers in Fedora have been doing it for a long time and know
what is and is not acceptable. Optimizing for the minority case is
wasteful, especially when it adds hurdles and delays to getting software
I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
I feel strongly that automated, continuous review would be of far greater
value to Fedora than front-loading the review process the way we have been
doing (which serves mostly to discourage people from even starting).
The Linux-Hardware.org database has been divided recently into a set of databases, one per each Linux distro. The one for Fedora is available at:
Everyone can contribute to the database with the help of https://github.com/linuxhw/hw-probe (various packages are available: AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to simplify collecting of hardware info and logs necessary for investigating hardware related problems. You need to execute only one simple command to collect all system logs at once:
sudo hw-probe -all -upload
Hardware failures are highlighted in the collected logs (important SMART attributes, errors in dmesg and xorg.log, etc.). Also it's handy to search for particular hardware configurations in the community and review errors in logs to check operability of devices on board (for some devices this is done automatically by hw-probe — see statuses of devices in your probe).
Hardware stats and raw data are dumped to Github repositories: https://github.com/linuxhw