Self Introduction: Patrik Novotný
by Patrik Novotny
Hi Everyone,
Since I've just got sponzored - thank you jskarvad :) - it's time for me to
introduce myself. So here's my attempt :) .
I've discovered Linux, programming and the whole open source world about
7-8 years ago when I was at high school and immediately fell in love with
it. Even though I've studied electrical engineering I was much more
interested in software from the beginning. Driven mainly by my curiosity
and fascination by the concept of open source I've learned enough of coding
and Linux administration to get a job as a sysadmin at a smaller company in
Brno (Czech Republic). After roughly two and a half years I was given an
opportunity to challenge myself and to gain experience more towards
development at Red Hat.
So here I am taking this opportunity and starting as a packager. I'm about
to be focused mainly on containers and databases and my very first package
is timescaledb but more should come soon.
I'm very excited to be a part of this community and looking forward for the
ongoing cooperation.
Have a great day everyone!
--
Patrik Novotný
Associate Software Engineer
Red Hat <https://www.redhat.com>
panovotn(a)redhat.com
<https://red.ht/sig>
5 years, 7 months
RFC: Flatpak application versioning: rolling stable
by Owen Taylor
The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:
https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles
For Flatpaks, the future is now - as soon as we start building them, I'd
like to start immediately in a model where the application lifecycle is not
tied to the traditional release cadence.
My basic idea is that applications consumed as Flatpaks should have a
"rolling stable" model - there is a *single* default version of the
application for all Fedora users, and that version is the latest upstream
stable release (once the Fedora Flatpak has passed automatic and manual
testing.)
In more detail:
* The rolling stable version is maintained as the master branch of
modules/MyApp (this git repository contains both the module definition and
the container definition) - this also ends up as the stream of the built
module
* It should use the Flatpak runtime corresponding to the latest stable
release of Fedora - e.g., flatpak-runtime:f28 at the moment.
* The Flatpak branch name should be "stable", to correspond to Flatpak
conventions
Questions, possible answers
======================
Isn't 'master' == 'rawhide' == unstable?
This is certainly the Fedora tradition, but since the stable branch is
the *default* branch, and since it will often be the *only maintained
branch*, I think it works better on master.
What about packaging *unstable* upstream releases?
If the packager desires, they can create a 'devel' branch, but they need
to rename the application in the desktop file and rename the application
ID, so that the devel releases can be parallel installed with the standard
releases. [There's some work that needs to be done to enable this either in
Bodhi since currently both branches of MyApp will end up tagged by Bodhi as
MyApp:latest with the latest updated one winning.]
What about packaging old stable upstream releases?
This should be done only in exceptional circumstances, such as a
complete rewrite upstream that produces a new stable version that (at least
originally) doesn't have all the features of the old stable version. In
this case you would use a upstream-versioned branch in dist-git, and also
be expected to change the desktop file name and application ID to enable
parallel installs.
How does this affect rpms/MyApp
The branch structure of rpms/MyApp does *not* have to match that of
modules/MyApp. If a new major release of MyApp comes out in the middle of
F29, the package maintainer would have various choices a) ask for a stream
branch of rpms/MyApp to put the new version on and change their module to
reference the stream branch b) update the f29 branch to the new major
version and upgrade rpm consumers as well c) update the master branch to
the new major version and change the module to reference the master branch
- the spec file would need to work against both the f29 and f30 platforms,
but that usually isn't hard.
How does this relate to server containers?
I registry.fedoraproject.org/MyContainer:latest should be "rolling stable"
in the same sense. It should be the latest upstream revision, and should be
based on the latest Fedora release. But server admin's often don't want to
wake up one morning with their apps upgraded to a different major version
(or wake up one middle of the night to a phone call), so perhaps we need to
have stream branches and tags *up front* - so that you can use
MyContainer:10 [needs the same Bodhi work referenced above to avoid
fighting over 'latest' and 'testing']. We'd also need to figure out when
it's permissible for a stream branch to rebase to a different Fedora base
image.
Do you have documentation for how Flatpaks will work?
Nothing very up-to-date. I hope to have comprehensive Flatpak packager
docs posted within the next few days, hopefully they will clarify this a bit
5 years, 7 months
libipt SONAME bump - 2.0
by Sergio Durigan Junior
Hi,
libipt v2.0 has been released yesterday and there was an SONAME bump
(from 1.6 to 2.0). According to 'dnf repoquery --whatrequires libipt',
only two packages depend on it:
- GDB
- Insight
I am the Fedora GDB maintainer and will rebuild it now. I am also
Cc'ing the insight maintainer in this message.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
5 years, 7 months
F29 System Wide Change: uEFI for ARMv7
by Jan Kurik
= Proposed System Wide Change: uEFI for ARMv7 =
https://fedoraproject.org/wiki/Changes/uEFIforARMv7
Owner(s):
* Peter Robinson <pbrobinson at fedoraproject dot org>
Move to uEFI as the default boot mechanism for ARMv7 devices.
== Detailed description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
aarch64.
== Scope ==
* Proposal owners:
Patches, updates to the process, testing
* Other developers:
System component owners will need to review and merge patches for
certain components.
* Release engineering:
#7606 [https://pagure.io/releng/issue/7606]
** List of deliverables:
N/A
* Policies and guidelines:
N/A I don't believe this changes any policies or guidelines
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 7 months
Reliability test for hard drives and SSD
by Andrey Ponomarenko
Hi there!
Good news for all interested in hardware compatibility and reliability.
I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool!
The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors.
Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation.
Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and others who had made this work possible by contribution to the database!
5 years, 7 months