I'm sorry, but wyland is a disaster for me. I do work on lots
of different software platforms, and things are just not working well.
They kind-of-work, which is the really worst condition one can have.
My new video board won't work with wyland, my pixycam software won't
work with wyland, some other graphics have changed colors, or don't
fully resolve with wyland, and finding compatible third party products
which was tough enough on linux to begin with is now virtually
impossible. The web compatible products work, like MPLABX from
microchip, but occasionally crash. Gscheme crashes randomly, and there
are others I haven't tried recently, but which I expect to have issues
Whatever the impetus was to change, it must have been driven by
somebody that doesn't really use the system. I have tried starting as
an Xorg login, but somehow that seems less than operating for similar
reasons, all surrounding graphics I suspect. So whether it is wyland
or the new graphics driver, kind-of-working is not a good deal. Yes, I
can change distributions, and if that is the only solution, I will, but
isn't that contradictory to the idea of becoming the OS of choice?
I expected that all these nagging issues would be worked out by
now. But there is no sign of improvement. Worse I am not getting my
stuff done. Granted I am just a hobbyiest, but doesn't this also
affect your more professional users?
We are looking for interested people who are willing to write docs in person for one week. You don't have to be an existing docs team member to participate. It helps if you're familiar with AsciiDoc, but if you're not, it's easy to learn.
You'll hang out with other people interested in making Fedora documentation the best in the world. Fun will be had, but mostly it will be the sort of fun which involves sitting in a small room intensely focused on writing and editing. If that's *your* idea of a good time, this will be a good experience for you.
You can find details about the FAD, including the goals here: https://fedoraproject.org/wiki/FAD_Documentation_2018
The Fedora Council has approved funding and we will make selections based on the ability to the person asking and within our approved travel budget. https://pagure.io/Fedora-Council/tickets/issue/174
Interested? Open a Pagure ticket in the Fedora Docs tracker here: https://pagure.io/fedora-docs
- Your Name/FAS
- Why you want to come and what your background in writing (of any kind) is.
- Any specific areas of interest
- Location you will travel from
We will start picking people ASAP.
bex & Matthew
My name is Christian Glombek (or simply Chris :) and I'd like to join the
Fedora Packagers Group. I'm currently a student of Electrical Engineering
and Business Management at RWTH University in Aachen, Germany.
My FAS and IRC handle is `lorbus` and on GitHub and Twitter I'm
`LorbusChris`. I've been using Fedora for two or so years on my daily
drivers, very much to my satisfaction.
Fedora's focus on modern concepts, especially container technology,
intrigues me. Its community to me has always seemed open, friendly, diverse
I also feel that Fedora's sponsor Red Hat has established a symbiotic
relationship with this community, transparently supporting a quite
remarkable and rightfully successful business model.
I feel passionate about Open Source Technology and would like to
Over the past few months I've been feeding my interests in some corners of
the extended Fedora universe, mainly tinkering with RPM and Ansible
Playbook Bundle (APB) packaging and also trying out custom Atomic/OSTree
builds (love Atomic Workstation!).
I want to get some packages into Fedora proper and I need a sponsor for
I'd also hugely appreciate (unofficial) reviews or any other feedback for
the following packages:
NEEDREVIEW (later, WIP)
The frontend part of libreoffice-online, loleaflet, uses `npm install`
during build (versioned with a npm-shrinkwrap file). From what I've read
about packaging nodejs modules, I'll probably have to manually download and
add all module sources to the rpm. WIP.
NEEDREVIEW (later, WIP)
I'll have to gather some more info about bundled softwares, possibly split
out some existing dep packages.
ragel-rpm / colm-rpm:
I also did some work updating the already-existing Ragel (dep of Rspamd)
and Colm (dep of Ragel) rpms and was consequently asked by current repo
maintainer Jason Taylor (jtaylor) to take over the position, which I'll
gladly do once I've found a sponsor and get the privilege of joining the
I'd like to try out Modularity packaging for Ragel as it has two release
streams, stable and development, of which only the latter is in Fedora.
(I made a ragel-compat rpm for the stable release stream, which can be
found on COPR, but I believe Modularity's arbitrary branching would be a
perfect fit here!)
I also like the idea of the Kubernetes Service Catalog, in conjunction with
the Ansible Service Broker (and Ansible in general) and so I did some
tinkering with Ansible Playbook Bundles, the packaging format for the
APB to broker (provision/deprovision) Ansible AWX.
Can also be used as an alternative installer for AWX deployment on
Installer for https://github.com/tnozicka/openshift-acme
Non-standard privilged (cluster-admin) APB, can be used as installer, not
currently for brokering.
Eventually, I'd like to see FreeIPA, Dovecot, Postfix, Rspamd, Clamd,
NextCloud, LibreOffice Online, Prosody and Coturn all packaged for Fedora
as RPM and Docker and for K8s Service Catalog as APB for use in a little
pet project of mine:
Expect to see me around on the IRC, too! I'll be saying hello in the
relevant channels in the coming days.
If you have any questions or maybe have a task for me at hand, please let
In December I met up with Fedora Ambassador Till Maas (till) for tea here
in Aachen and was given answers to lots of my questions regarding Fedora.
Thanks again, Till!
He also encouraged me to attend conferences, which is why I will be at:
- DevConf.cz, Brno, Jan 26-28, that's this Weekend!
- CentOS Dojo, Brussels, Feb 2
- FOSDEM, Brussels, Feb 3
- Config Management Camp, Gent, Feb 5-7
I hope to meet some members of the community there in person! Please feel
free to ping me if you're there! :)
I'm looking forward to participating and contributing here!
= Proposed Self Contained Change: Removing ldconfig scriptlets =
* Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org,>
* Neal Gompa <ngompa13 AT gmail DOT com>
For many years, package maintainers were required to write scriptlets
which call ldconfig in %post/%postun if they package shared libraries.
== Detailed Description ==
Since time immemorial, Red Hat/Fedora packagers have been required to
add a stanza to spec files for packages containing libraries to update
the ldconfig cache.
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
To say this is annoying is to put it mildly. However, there was no
standard mechanism to make this boilerplate go away. Now with RPM
4.13+, we should change this to file triggers and make all of that go
With this change, these scriptlets can be removed and ldconfig would
be run just once per transaction.
If your package places shared libraries in special locations
referenced by ld.so.conf, you still need to run ldconfig manually.
For those who concerned about whether this is self-contained or
system-wide change: there is no overhead if packagers don't remove
ldconfig scriptlets in time, so completion doesn't depend whether
packagers remove them or not. We are just making it possible.
== Scope ==
* Proposal owners:
Make sure that DSO symlinks are being packagedcommit, add transaction
filetriggers to glibccommit + commit.
* Other developers:
Package maintainers are advised to remove ldconfig scriptlets in order
to achieve benefits specified above.
* Release engineering:
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Packaging guidelines need to be updated to reflect reality.
* Trademark approval:
N/A (not needed for this Change)
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
within the whole Meltdown and Spectre story I realized that Koji pushes
even security updates to batched only, not directly to stable. In
concrete case we have the firefox update , which already received 10
positive karma and many users complaining that it takes so long to get
it out as a stable update. Shouldn't we change that behaviour to get
such security updates out fast when maintainer relies on autopush when
karma threshold is reached?
Here's something I didn't expect from the new ABI gate. Which, before
I go further, I think will be a great idea nearly all of the time. I
think avoiding unintentional ABI breaks in stable releases is a worthy
But ... I maintain a package called gap. It provides what amounts to
a scripting language for doing certain types of math. It comes with a
bunch of addon packages that provide specific mathematical
capabilities. Most of them are written solely in the scripting
language, but a few have to interface with external libraries. When
that is required, these packages build a small internal-only shared
object to act as the glue between the external library and the
I've got a pending update for one of these packages that fixes some
bugs. It has been caught by the ABI gate:
There is no danger in pushing this to stable, since the only consumer
of the changed ABI is inside the same package. Now what do I do? Are
ABI changes completely disallowed in all circumstances? Is there a
button somewhere that says, "I am aware of the danger of pushing this
to stable and I have verified that nothing will break in this case"?
Trying to look on one of the top tickets found:
Looks like this ticket is about package which is no longer in Fedora.
Does it mean that current Fedora package orphaning process is not closing
all such package tickets in Bugzilla?
If yes it will be some number of the tickets which is possible to close now
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*