Eike Rathke and I are working on updating ICU from 57.x to 60.x in rawhide/F28. It includes a soname bump and has a few API changes. We'll do an ABI compat package to avoid breaking the world while rebuilds are ongoing.
We'll import it some time this week and I'll be coordinating rebuilds through my provenpackager powers.
We have been getting bounced emails from Axel Thimm for a while and I
don't have any other way to contact him. He was an early maintainer of
packages but has not been seen in fas since 2013.
He is the co-maintainer of the following packages:
rpms/apt -- Debian's Advanced Packaging Tool with RPM support ( master f26 f25 )
rpms/arpack -- Fortran 77 subroutines for solving large scale
eigenvalue problems ( master f26 f25 )
rpms/chrpath -- Modify rpath of compiled programs ( master f26 f25 )
rpms/courier-unicode -- A library implementing algorithms related to
the Unicode Standard ( master f26 f25 )
rpms/fail2ban -- Daemon to ban hosts that cause multiple
authentication errors ( master f26 f25 )
rpms/fakechroot -- Gives a fake chroot environment ( master f26 f25 )
rpms/fakeroot -- Gives a fake root environment ( master f26 f25 )
rpms/fedora-package-config-apt -- Fedora configuration files for the
apt-rpm package manager ( master f26 f25 )
rpms/freenx-server -- Free Software (GPL) Implementation of the NX
Server ( master f26 f25 )
rpms/ivtv-firmware -- Firmware for the Hauppauge PVR
250/350/150/500/USB2 model series ( master f26 f25 )
rpms/libcdaudio -- Control operation of a CD-ROM when playing audio
CDs ( master f26 f25 )
rpms/maildrop -- Mail delivery agent with filtering abilities ( master f26 f25 )
rpms/perl-Text-CharWidth -- Get number of occupied columns of a string
on terminal ( master f26 f25 )
rpms/perl-Text-WrapI18N -- Line wrapping with support for several
locale setups ( master f26 f25 )
rpms/php-pear-Auth-OpenID -- PHP OpenID ( master f26 f25 )
rpms/po4a -- A tool maintaining translations anywhere ( master f26 f25 )
rpms/synaptic -- Graphical frontend for APT package manager. ( master f26 f25 )
rpms/vtk -- The Visualization Toolkit - A high level 3D visualization
library ( master f26 f25 )
If anyone has had contact with him could he see if can fix his email?
Stephen J Smoogen.
This is a reminder that the webkitgtk and webkitgtk3 packages will be
retired from rawhide shortly after F26 is branched from rawhide. This
is due to numerous security issues affecting those packages (I just
counted 204 CVEs), many of which could allow remote code execution.
Bugs have already been filed against all directly-affected packages
Note: to count the vulnerabilities, I just manually added up the CVEs
listed at , ignoring the oldest advisory WSA-2015-0001, and
discounting five of the older vulnerabilities in WSA-2015-0002.
Reading logs from yesterdays FPC meeting , I think we should discuss
what is actually purpose of packaging guidelines and which version of
Fedora/EPEL/RHEL they actually targets.
Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
1) single version of .spec file to cover the whole Red Hat ecosystem.
2) clean .spec file following the latest and greatest packaging practices.
I personally belong to the group (2) and that is for several reasons:
a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
changes in older Fedoras, then it is typically just bug fixes and
honestly, that does not happen often (I am POC of ~200 packages and I
submitted just 40 updates during last year ). And in fact, this is
official philosophy of updates , not just mine.
b) I spent time developing features which should simplify packaging (for
example in F27+, the RPM %setup macro can expand the .gem packages) and
I want to use these technologies to simplify my life and life of others.
c) As a proven packager and person who typically does rebuild of Ruby
packages, I really hate the branched .spec files where nobody knows what
was the purpose of the branches, most of the branches are for obsolete
and unsupported releases etc. It is quite hard to apply any improvements
into such packages. Moreover it is not realistic to test them. If they
were maintained, it would be different story, but the reality is different.
Don't get me wrong, I understand that there are packagers who has just
handful of packages and it is better for them to maintain just single
.spec file with all the branches and I don't mind them as long as the
packages are really actively maintained. But this approach just don't
scale and should be exception and not recommended practice.
To sum this up, my take on packaging guidelines is that *the guidelines
should document the most recent practices available in Rawhide and this
should be documented*. Covering all the exceptions necessary for older
Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
and what is worse, they slow down entire development of Fedora.
I'm on a Fedora 27 Workstation system, dnf system-upgrade(d) from
Fedora 26. I've got a few crashes that gnome-abrt (Problem Reporting)
I've clicked on to report, but I get this message for all three of
Retrace job failed
Retrace failed. Try again later and if the problem persists report
this issue please.
The main problem with this is the message itself: I'm not sure where
to report it or what information to include.
This is an example from one of their log windows (I've already
downloaded all the
debuginfos and separately filed bugs for these crashes with coredumpctl gdb
output, but maybe there's an issue with the retrace server (?)
2017-11-28 04:18:12 Analyzing crash data
2017-11-28 04:18:28 WARNING:fedora.client.openidbaseclient:Unable to
create /usr/share/retrace-server/.fedora: [Errno 13] Permission
ERROR:faf:Unable to import plugin
pyfaf.actions.create_problems_gnome_mmarusak: cannot import name
INFO:faf.Coredump2Packages:Mapping build-ids into debuginfo packages
INFO:faf.Coredump2Packages:Getting binary packages from debuginfos
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 ?