I am planning to orphan the IRC client ninja. One of the reasons to
orphan it is that there is a build system which has the same name.
In Fedora the ninja build system is called ninja-build which makes it
incompatible with most other Linux distributions. In addition the
current release is from 2002 and upstream does not exist anymore.
Most of the other Linux distributions do not even ship it, although
there are other packages which are called ninja. It seems the name ninja
is already taken multiple times and maybe not a good idea for future
I've added few packages last year using the new package process:
I'm not sure which fedora body (FPC or FESCO) is responsible for this
document, that's why that mail is sent here. In all cases, I'm
interested on other's feedback on that issue.
My experience with the new package process is that the review process in
Step 6 doesn't work. For some of my packages it took 3 months for a
reviewer to appear, some others more, some where reviewed faster. My
understanding is that it depends on how interesting the package is, how
many packagers you know, or whether you enter the review swap market.
In the first case I speculate it would be easier to review popular
end-user applications, in the second we make reviews possible only for
people who can ask other packagers for the review, and the latter
requires someone who brings a new package to do extra work. I've tried
all of these, and don't like any of them.
I don't have a solution to bring extra resources to reviewing (which
will be the ideal), but I'd like to propose an amendment to allow
bringing packages even if no reviewers are available (the typical case).
Step 6: ... If the proposed package is not reviewed for 2 months, the
package must be reviewed by the submitter, and a git module with the
master branch will be approved.
That is packages which are self reviewed will be added in the next
fedora release, but not the current or previous ones.
I don't like it, as it still sucks, but sucks much less from having a
list a long list such as:
= Proposed System Wide Change: Change xorg input stack to use libinput =
Change owner(s): Hans de Goede <hdegoede(a)redhat.com>
Replace the current (low-level) input xorg drivers with libinput using the
== Detailed Description ==
Currently xorg uses different input drivers depending on the device type. This
makes it impossible to do things like middle button scrolling on the
trackpoint on laptops where the trackpoint buttons are software-emulated
buttons on the touchpad. Besides this the xf86-input-synaptics driver was
never really designed for multi-touch touchpads and this causes various
For Wayland we've been working on a new improved input stack, which is to be
shared by all compositors and lives inside libinput. We plan to replace the
current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
== Scope ==
Besides xorg changes, this will also require changes to the control panel
applets for mouse / touchpad configuration in the various desktop environments,
as those all are hardcoded to use the xorg-x11-drv-synaptics specific
* Proposal owners:
Package libinput and xorg-drv-input-libinput (done), make sure that xorg-drv-
input-libinput has the necessary config interfaces for control panel
mouse/touchpad config applets (wip). Write patches for gnome-control-center
mouse/touchpad capplet. Coordinate with other desktop environments.
* Other developers:
GNOME: merge the gnome-control-center patches. KDE: limits itself to standard
X11 mouse config interfaces, no changes needed. Other Desktop Environments:
adjust control-panel code to deal with xorg-x11-drv-libinput, merge these
* Release engineering: N/A
* Policies and guidelines: N/A
devel-announce mailing list
So a friend of mine has been wrangling with suexec trying to configure it
for his needs, and he has become quite furious over the fact that suexec
Then he finds out that Debian actually has a version of suexec that lets
you use a conf file to configure suexec. My question is, why the heck isn't
this in Fedora? How is it that Debian can offer both versions, but
I'm honestly surprised that Fedora doesn't offer this little piece of
flexibility. I would think that this would be in Fedora and RHEL, because
of how useful this would be. So what's going on here?
真実はいつも一つ！/ Always, there's only one truth!
Fedora is probably the First to use OPENPGPKEY at a large scale.
Everyone[*] who added a GPG keyid in FAS has their key published now
using the OPENPGPKEY specification. You can obtain a key using the
openpgpkey command of the hash-slinger package:
paul@bofh:~$ openpgpkey --fetch pwouters(a)fedoraproject.org
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: pwouters(a)fedoraproject.org key obtained from DNS
Comment: key transfer was protected by DNSSEC
Version: GnuPG v1
Note that during FAS processing I found out that:
1) there are many nonsense values instead of keyid's in the fas field
(some put in their fingerprint, which is not useful without a key,
some had multiple keyids, and one person managed to unicode kill
python-gnupg by putting their name in there)
2) most people don't have their fedoraproject.org as uid on their key
3) a LOT of keys were expired - I still put these in the zone
4) the gpg/python-gnupg minimal export still caused some keys to be too
big for dns. I simple removed those keys from the zone data.
5) almost all these keys are old keys of which I could forge a fake
matching keyid and upload it to public key servers.
This last item is important because we sadly did not store the actual
public keys in FAS, but only their keyid. We should really change that.
Updating your key in fas does not yet automatically update the
OPENPGPKEY record in DNS.
If you are brave, you can install openpgpkey-milter on your mail server,
and it will start to automatically encrypt email to those
fedoraproject.org email addresses that have keys associated with them.
If you want to run this yourself in other domains, you can use the openpgpkey
command to generate these records for keys in your local gnupg keyring:
openpgpkey --create paul(a)nohats.ca
See further man openpgpkey
ps. thunderbird/enigmail support anyone? GSoC? :)
Since the modular X repackaging in FC5, we have limited X server updates
such that the ABI does not change. F20 shipped with xserver 1.14.4, for
example, so we might update it to 1.14.7 but not to 1.15.0. With the
reduced driver set in F21 it's now much more reasonable to push updates
to older releases as well.
With that in mind, I ask for feedback on how we'd actually like that to
work. The kernel rebase policy seems like a pretty reasonable model:
F21 would stay on 1.16.x until there's an upstream 1.17.1 release, and
(if F20 were to be affected by this policy) F20 would wait until 1.17.1
had been tested in F21.
One thing we might have to play by ear is the interaction with binary
drivers. The nvidia legacy driver, for instance, does not always have
builds available for arbitrarily new servers, which means updating the X
server might change you to an nvidia driver that no longer supports your
hardware. Depending on how severe that cutoff is, it might be cause to
pin a particular Fedora release at a given server version. I don't
think this is presently a problem, but it could be in the future.
This would also want some coordination with the various desktop
environments; the version of KDE in F21 might have latent bugs only
exposed by switching to F22's X, for example. I have a reasonable idea
of how to test Gnome for that kind of thing, but for the others I'd need
So what do we think? Good idea? Bad idea? Other things to watch for?
Lukáš 'Allo 'Allo
I see that some people are trying to "modernize" Fedora.
But what about RHEL relictum - initscripts, particularly now that we have NetworkManager/ModemManager and systemd-networkd,
when will this package "fall off"?
>From python-sphinx-1.2.2-6.fc22 onwards support for building LaTeX
documentation using Sphinx has been split off into the -latex subpackage
(so that Sphinx can be installed without pulling in TeXLive).
(There's also a bug discovered when doing this split -- the python3 build
wasn't shipping with locale files).
As we're not doing a mass rebuild this time round, this change should have
For maintainers of packages that use Sphinx for building documentation,
please check if you're generating PDFs -- and if so, add a BR on
Hat tip to Robert Kuska for the suggestion and feedback.
Michel Alexandre Salim
= Proposed System Wide Change: Systemd Package Split =
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Split systemd-units out of the main systemd package
== Detailed Description ==
Systemd contains many binaries and depends on a fairly large number of
libraries. Packages which carry systemd units currently have to depend on
systemd (through %post, %preun, %postun macros used to install and uninstall
systemd units), which grows the dependency tree and increases the size of
With this proposal systemd-units subpackages will be split out again:
This subpackage will contain the directories and binaries necessary to satisfy
%post, %preun, %postun macros for packages containing systemd units
(systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config
information (pkg-config files).
The main systemd package would require this package so it will be pulled in on
all existing systems. All packages which have BuildRequires:systemd will also
pull it in transitively.
Systemd previously had a -units subpackage and ~150 packages still depend on
it. Those packages would start using the reduced subpackage immediately. Other
packages wishing to use the reduced dependency, would have to change the
BuildRequires and Requires to systemd-units.
== Scope ==
* Proposal owners: Create the subpackage, test that macros work as expected.
* Other developers: Change the BuildRequires and Requires to systemd-units if
* Release engineering: None
* Policies and guidelines: s/systemd/systemd-units/ in the appropriate places.
== Contingency Plan ==
* Revert the packaging change and rebuild systemd. Main systemd package would
provide systemd-units, as it does now, so no other changes should be
* Contingency deadline: should be possible at any time.
* Blocks release? No.
* Blocks product? No.
devel-announce mailing list