There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
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