= Proposed System Wide Change:Ruby on Rails 5.1 =
* Pavel Valena <pvalena AT redhat DOT com>
* Vít Ondruch <vondruch AT redhat DOT com>
* Jun Aruga <jaruga AT redhat DOT com>
Ruby on Rails 5.1 is the latest version of well known web framework
written in Ruby.
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 5.0 in Fedora 26 to 5.1 (latest version) in Fedora 27.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Scope ==
* Proposal owners:
- The whole Rails stack has to be updated
- Some dependencies of the Rails stack will need update
- Packages need to be created/updated
- - rubygem-actioncable
- - rubygem-actionmaile
- - rubygem-actionpack
- - rubygem-actionview
- - rubygem-activejob
- - rubygem-activemodel
- - rubygem-activerecord
- - rubygem-activesupport
- - rubygem-rails
- - rubygem-railties
- - rubygem-arel
* Other developers:
Update Rails dependent packages to be working with Ruby on Rails 5.1
* Release engineering:
* List of deliverables:
* Policies and guidelines:
* Trademark approval:
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Updating to 3.1, rebuilding ganglia and libftdi. If I missed anything,
please let me know.
in your fear, seek only peace
in your fear, seek only love
today, I've accidentally attested there are no stability guarantees
with the on-demand archives from common git hosting sites when preparing
a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec"
of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the
hashes, which (surprisingly to me) didn't match (they were at any similar
test in the past). Then I looked at the adiff output:
> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200
> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200
> @@ -1159,7 +1159,7 @@
> AC_PATH_PROGS(GIT, git false)
> AC_MSG_CHECKING(build version)
> if test != ":%h$"; then
> AC_MSG_RESULT(archive hash: )
for configure.ac that indeed has export-subst git attribute set
and the change itself arises from "$Format:%h$" substitution.
This likely means GitHub was internally updated to use equivalent
of git 2.11 feature of abbreviation length autoscaling within
last 14 days.
Hope this will be useful for some (e.g. fedora-review tool
has a check to redownload and diff sources against SRPM content,
fedora-review prints this in the ‘Issues’ section of the report:
‘- Package contains BR: python2-devel or python3-devel’
This has happened on a couple of reviews I have done recently. There
is no other information given about what this means or why it's bad.
Both were Python packages and the Python package guidelines mention
that you *should* have BR: python2-devel / python3-devel
So .. what does it mean?
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
You are kindly invited to the meeting:
Fedora 26 Beta Release Readiness Meeting on 2017-05-25 from 19:00:00 to 21:00:00 UTC
The meeting will be about:
We will meet to make sure we are coordinated and ready for the Beta
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.
You are kindly invited to the meeting:
Fedora 26 Beta Go/No-Go Meeting on 2017-05-25 from 17:00:00 to 19:00:00 UTC
The meeting will be about:
Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting. Verifying that
the Release criteria are met is the responsibility of the QA Team.
Release Candidate (RC) availability and good QA coverage are
prerequisites for the Go/No-Go meeting. If you have any bug on the
list, please help us with Beta release. If we won't be ready by
Thursday, we will use this meeting to review blockers and decide what
I am trying to use Skia static library in my system. The problem is it
depends on libglvnd.
14:06:45: Starting: "/usr/bin/cmake" --build . --target all
[1/1 7.3/sec] Linking CXX executable Chpp
: && /usr/bin/clang++ -rdynamic CMakeFiles/Chpp.dir/src/main.cpp.o -o
-Wl,-rpath,/home/navid/development/Chpp/lib:/usr/local/lib -lz -lglog
-lcryptopp /usr/local/lib/libre2.so -lprotobuf -lpthread -lfontconfig
-lfreetype -lpng -lz -ljpeg -lwebp -lwayland-client -lwayland-server
-lwayland-egl -lwayland-cursor -lGLEW -lvulkan ../lib/libskia.a -ldl
-lglog -lcryptopp /usr/local/lib/libre2.so -lprotobuf -lpthread
-lfontconfig -lfreetype -lpng -ljpeg -lwebp -lwayland-client
-lwayland-server -lwayland-egl -lwayland-cursor -lGLEW -lvulkan
../lib/libskia.a -ldl && :
undefined reference to symbol 'glXGetCurrentContext'
/usr/local/lib/libGL.so.1: error adding symbols: DSO missing from command line
clang-3.9: error: linker command failed with exit code 1 (use -v to
ninja: build stopped: subcommand failed.
14:06:45: The process "/usr/bin/cmake" exited with code 1.
Error while building/deploying project Chpp (kit: Desktop)
When executing step "CMake Build".
I did check the GLX package comes with fedora :
[navid@workstation skia]$ readelf -s /usr/lib64/libGL.so.1 | grep
664: 0000000000041460 19 FUNC GLOBAL DEFAULT 11 glXGetCurrentContext
It seems it does provide this function. But there is something wrong with it.
Although I fixed my problem with compiling libglvnd from upstream and
installing it myself. But I think it would be great if somebody more
familiar with these libraries can look at this problem and fix if
there is something wrong with this package in fedora.
Hi Devel list!
In case you weren't aware Flock CFP is open! Please start thinking
about your submissions and registration now. The focus this year
should be "do-ing", so there is a general preference for hackfests and
workshops. The Flock committee will send more details on the kind of
submissions they are looking for ASAP, but if you already have an idea
in mind submit it today!
At the moment users logging into Fedora on a text terminal (console, SSH,
etc.) get their locale environment variables (LANG, LC_ALL, etc.) set up by
the shell they use. I.e. the shell ultimately sources the /etc/locale.conf
file. This works fine in most cases.
However, if the user has his/her "shell" set to any program that is not one of
the traditional shells, i.e. it doesn't source any shell profiles, or even
doesn't understand any shell language at all, then that program doesn't get
Theoretical examples can include captive portals on jump-hosts, or
special-purpose systems with dedicated TUI instead of a shell. A practical
example that concerns me is a user session recording program  which needs
to run before user shell, and intercept all I/O going to and from the
I would like to know if it is possible to change Fedora to provide the locale
variables through the environment user "shell" inherits, instead of expecting
it to read /etc/locale.conf, which is distro-specific.
This is done in Debian already. During session setup in login/sshd/etc. they
use pam_env to read /etc/default/locale. Similar thing is possible to do in
Fedora too. E.g. just put this into /etc/pam.d/system-auth:
session required pam_env.so envfile=/etc/locale.conf
 Tlog - terminal I/O logger