Hi fedora-release maintainers and fellow developers,
The fedora-release package contains stuff that is tied to each Fedora
version and changes slowly, and it also contains the preset files for
systemd units, which change fairly often (a few requests per month).
Currently fedora-release has a fairly complicated maintenance
structure, with an "upstream" project at https://pagure.io/fedora-release
and "downstream" at https://src.fedoraproject.org/rpms/fedora-release.
"upstream" is only used for this single "downstream", and in fact changes
made in packaging "downstream" are sometimes lost when the next version
of "upstream" is imported.
I propose simplifying this and opening fedora-release releases to more
1. Let's drop "upstream" at https://pagure.io/fedora-release and
make the "downstream" the canonical source of the package,
2. Allow pull requests in src.fp.o/fedora-release,
3. With 1 and 2. implemented, it'll be easier for any fedora maintainer
to suggest improvements to the package (through PRs) and it'll also
be possible for proven packagers to do changes without stepping on
the toes of the maintainers and interfering with the separate "upstream"
repo. Let's agree to allow pps to update fedora-release as necessary
when the main maintainers are busy.
4. Release fedora-release quickly, so that when a preset change request
comes in , it can be handled in a few days or a week. (Having such
requests hanging usually blocks changes to the package in question,
so it's important to have the resolution of the preset status without
To implement this, not much action is required, mostly acceptance of the
maintainers to amend and open up the process. Concrete steps that do need
to be taken:
1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings
to allow PRs
2. push a commit to "upstream" that that repo is dead
3. make a README for "downstream" that PRs can be submitted and outline
I'll be happy to submit the PRs for 2 and 3. I'll also be applying for
co-maintainership in the fedora-release package, because I want to push
those changes forward.
What do you think?
While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h
was being picked up by the glob for kernel-headers. This is kind of unusual
because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both
come out of install from cpupower tools. This header really belongs in
kernel-tools-libs-devel for consistency and I'd like to move it. I don't
anticipate there being any problems but if anyone can think of an issue for
moving this header from kernel-headers to kernel-tools-libs-devel please
let me know. I don't plan on doing anything about this until next week at the
earliest (Thanksgiving here in the US).
I was playing with a toy server using Fedora 26 Server. I was running a simple configuration with httpd, nginx+php-fpm trying to install and serve some CMSs to test them before going live.
Of course, only one web server was running at a time, and they both had their root pointing at /var/www/html.
The CMSs that I tested so far were open source softwares, for example e107 and concrete5.
The main point here is that for the installation steps I needed a lot of extra configuration based on the fact that the owner of /var/www/html and subfolder was first root, then apache then nginx users. Would not be simpler to use a 'www', 'www_data' 'whatever' user account for accommodating those in an easier way?
I also had to reconfigure the php-fpm file, because otherwise configuration files in install step were not writable.
In fact, using mod_php with httpd does not create those problems, because everything is in the ownership of 'apache' user and mod_php is executed inside the httpd process.
If you switch to nginx, you actually have to run both nginx and php-fpm; because those are two different processes, you have to grant permissions to both on the same files, which to me seems unnecessary.
My situation before was:
/var/www/html -> owned by apache:apache
httpd -> running as apache:apache
php-fpm -> running as apache:apache
Switching to nginx, I had to :
/var/www/html -> chown nginx:nginx
php-fpm running -> as nginx:nginx
Do not get me wrong, it is a matter of three commands to be issued, but would not be better not to bother with those things at all? Again, my suggestion would be to have those running on the same user name.
Let me know what you think.
Is it possible to compile kQOAuth  with ssh2 by using openssl, as it always comes to conflict between compat-openssl10 and openssl.
I have already searched in the sources of kqoauth for the places where ssl is referenced.
$ grep -r ssl *
Makefile:LIBS = $(SUBLIBS) -lssl -lcrypto -lQt5Gui -lQt5Network -lQt5Core -lGL -lpthread
src.pro:LIBS += -lssl -lcrypto
i tink it isn't enough only to replace -lssl with -lssh2
Have somebody a idea ?
recently I've updated from FC24 to FC27. Since then remote X connections
don't work anymore. For my environment I'm typically starting an xterm
shell from another computer displaying on my workstation.
When using "gdm", remote X access is en-/disabled with the "DisallowTCP"
setting in "/etc/gdm/custom.conf".
Now, there is a trap door. Xorg changed the default for remote
connections a few releases ago.
Old releases listened on the network unless "-nolisten tcp" was
specified. Newer releases only listen on the network
if "-listen tcp" is specified on the command line to start the X server.
This means that gdm either needs to add "-nolisten tcp" (old server,
DisallowTCP=true) or "-listen tcp" (new server, DisallowTCP=false)
to the X server command line.
This is handled by conditional compilation in gdm (depending on a
The setting for this define is determined in configure.ac, lines
dnl - Check if Xorg is new enough to require '-listen tcp' (1.17)
if $PKG_CONFIG --atleast-version=1.17 xorg-server; then
AC_DEFINE([HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY], , [XServer
disables tcp access by default])
Now, my installed gdm seems to think that my Xserver doesn't default to
"local only". If I set DisallowTCP to true, it adds
a "-nolisten tcp" parameter to the X command line. While it shouldn't
add anything in this case. If I set DisallowTCP to false
it doesn't add anything to the command line (where it should add
On my system, running the test above returns correct results:
$ pkg-config --atleast-version=1.17 xorg-server ; echo $?
I've build the gdm RPM from source on my local machine, installed it,
and, hey, now everything works as expected.
So I guess that the machine used to build the official packages still
has an old X server installed. If that's true,
could this be fixed?