in the past we have had a tradition of sponsoring EMEA contributors that would like to attend Flock but are not going to receive funding as speakers.
The allocated budget for this year was only $800, initially. The adjusted budget is even less. As we wish to assist as many contributors in need as possible, we are going to try and raise that budget. However, no promises made at this point.
This program is intended for contributors that currently reside in EMEA. Other regions may feel free to come up with similar programs for their contributors as they see fit. Priority will be given to contributors that have recently maintained a record of activity and also have some kind of work agenda for the conference (e.g. meet with fellow contributors, actively contribute on site).
In any case, the budget we are going to end up with will be limited. Most likely we will be able to offer only -partial- subsidies. Do not apply if you are not okay with that. If you are able to receive funding from other sources (e.g. your employer), please do so.
To request for sponsorship, file a ticket on the EMEA Trac, state the reason(s) for applying and what you expect to accomplish by attending the conference. Deadline should be July 5, 23:59:59 UTC +0. All tickets will be later evaluated by FAmSCo, same as last time.
We will get back to you once we have more information regarding the budget. Please spread the news to your fellow Fedorians.
Thank you and good luck!
giannisk on irc.freenode.net
At a recent QA meeting I raised the idea of a better way for
maintainers to find out when their package is a release blocking bug.
Better is vaguely defined by me as: not email based, and not adamw
based (Adam Williamson is in fact a person not a bot).
Currently, the ways a maintainer finds out a bug is release blocking:
1. Bugzilla email. When QA determines a bug is a blocker, it's noted
in the bug as a comment, and bugzilla emails (most) everyone on the
The problem with email is self-explanatory. If the bugzilla
notification email isn't being registered in a useful way, probably
more emails won't help either.
2. The very nifty Fedora Blocker Bug Tracking app
The problem with this is, it's passive. You need to check it. So it's
mainly used by QA folks to get a bird's eye view of the status of
blocker bugs, and freeze exceptions.
3. The illustrious, humorous, verbose, would have been cloned by now
were it affordable and timely enough, adamw, who sends out an email
summary of blocking bugs to devel@.
Problem, more email.
4. Adamw (or less often another human within QA) takes it upon
themselves to inquire via IRC. These are effective. Unknown is if
slips would have resulted if they didn't happen. But it seems at least
plausible that it would increase slips without this form of nagging
The problem is, I think it's inappropriate for any one person to have
to nag other people about their bugs. It's also tedious and manual.
The time and interest for any QA person to do this is low.
The questions then, are:
- Have we reached the pinnacle notification method of blocker bugs to
maintainers? Or is there a better way to do this?
- Would it help to have a nagbot (or enhance zodbot) to ping
maintainers on IRC? Is the nagbot more or less likely to be ignored,
or would it be about the same? Of course there are lower level
questions about whether it's possible, what work it entails, would it
be opt in or opt out, could notifications happen outside IRC, but for
now I think the "in general" high level context is more useful.
per Build Root Without Perl Fedora 25 change
<https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl>, I'm ready to
implement the most visible part of this change.
I'm going to inject perl-devel and perl-generators build-requires into Fedora
specification files tomorrow. That's necessary not to break building the
packages when Perl will have been removed from the build root.
There are 3292 packages that should build-require perl-generators,
there are 491 packages that should build-require perl-devel.
Some of them already contain the dependency.
There are 3129 packages that miss one of them and they will be edited.
The edit will consist of one commit with this commit message:
Mandatory Perl build-requires added <https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl>
The commit will add:
or both into a spec file. There will be no revision bump, no RPM changelog
entry, no rebuild in the Koji.
I expect pulling the source repositories, commiting the changes and pushing
them back to the dist-git will take at least 2 hours. Package maintainers and
people with watch-commit role will receive an e-mail notification about the
commit as usually.
Thank you for your understanding.
To keep this off-list as much as possible, the rant is here:
(The blame lies elsewhere. I wish I had the network and social cred to
get a real movement started, away from the current faceless CA system
and towards a different identity assurance system that depends on
actual, existing day-to-day trust relationships.)
we were talking about this item for some time, so let's start a thread
for it to have the discussion and hopefully also a solution documented.
This is meant as discussion initiation based on the situation in
Fedora on POWER. I would like to ask the bigger experts than me to fill
the missing details and options.
Currently we set a minimal CPU level for an architecture (or use the
toolchain default) on the distribution level
(/usr/lib/rpm/redhat/rpmpc owned by redhat-rpm-config ). It allows
the distro to run on such CPU and any newer evolution of it (omitting
any kernel or hw issues), but it also means it doesn't generally take
advantage of features and improvements in the newer CPUs.
For ppc64 (the big endian POWER) the base is set by the toolchain
default which is Power4/ppc970. When Power7 came we were asked what are
the options to take the advantage of these CPUs, 3 generations newer
than the base. The solution was the introduction of ppc64p7 subarch into
the packaging and release engineering tools. But it showed more as a
hack than a solution, touching rpm, yum, koji, .... The list of packages
is manually maintained, requires manual updates to the buildsystem for
new releases, seems new packaging tools (dnf) don't understand it
correctly. Is there a way to make the subarch mechanism generic and
integrated with the other tools? So we could have ppc64p8 and ppc64p9
inside Fedora for POWER ...
Now I'm getting to an area where others are the experts :-) Glibc
allows to build and install multiple per-cpu optimized runtimes that
are selected based on the CPU. There is the IFUNC mechanism and
function multi-versioning in GCC (user-friendly IFUNC)  to allow
multiple implementations inside one library/binary.
Some packages do the CPU detection during runtime and select the
optimized functions themselves.
There is also an option to introduce a "tertiary architecture" and
rebuild everything for the new CPU, but keeping the rpm arch the same.
But it has its own costs too.
What do you think? Are there any recommendations for both the distro
and package maintainers and upstream developers? I suppose even primary
architectures are facing the same problem.
Does anyone have a good/working autoconf test for checking for
deprecated readdir_r (for Fedora 25) ?
I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.
I've been trying to contact Salimma, Michel Alexandre Salim, for the last
month. I've been trying to update python-sphinx which hasn't had an update
since last fall. Worked through all of the issues, but maintainer hasn't
responded to commit request, email, or bug reports.
Bug report for newest version of Sphinx with needinfo flag.
Anyone have any info?
dnf has issues at honoring conditional levels written on comps.xml.
As a result, some packages will not be installed by either anaconda or
livemedia build system.
I have already submitted a bug report on the subject  but it was too
deep to fix for Fedora 24.
By the time of applying the workaround, the freeze was in the process
and the suggested change to manually update the kickstart and some
comps.xml came too late. That was the case with Design Suite and
surprisingly other groups. Currently, the document from fedora-comps
fails to take account that problem caused by dnf.
Now the focus is for Fedora 25, will be fix come in time so such problem
will not occur again?
Graphic & Web Designer
I submitted a bugzilla report with a patch that implements an
improvement of the hadoop package in Fedora, extending the current
incomplete Fedora integration patch that only supports ix86 and x86_64
to more architectures. The maintainer is unwilling to apply it, but
says that if a proven packager would apply it he would be extatic.
Since I am not a proven packager myself, I am looking for one that can
perform this task.
I'll be updating hdf5, netcdf, and libdap in rawhide tomorrow and doing
rebuilds of dependent packages.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com