[Modularity] BPO - the great UI that shows you everything
by Adam Samalik
Hi everyone,
I would like to hear your opinion/need your help!
I am working on a component of the Fedora Modularity[1] project, called
Build Pipeline Overview (BPO). It will be a single user interface (probably
both web and API) that would give you information about "everything". And
I would like your help with defining what that "everything" means.
To make the definition of "everything" easier, we are using a concept of
personas. These are basically groups of people that would use the BPO UI
that will help us to identify possible use-cases.
@threebean have identified four personas:
- Engineers/packagers
- Release Engineering
- QA
- Project Management
I have put them into an Etherpad document [2].
What I'm asking from you: Could you please discuss here or in the document
what would you like to see in the BPO UI? Or what do you think should be
there. I would like to get as much input as possible.
Thanks!
Adam
[1] https://fedoraproject.org/wiki/Modularization
[2] http://piratepad.nl/3h3lMUwld3
--
Adam Šamalík
---------------------------
Associate Software Engineer
Red Hat
7 years, 9 months
EMEA Sponsorship Program for Flock
by Giannis Konstantinidis
Hello everyone,
in the past we have had a tradition of sponsoring EMEA contributors that would like to attend Flock[0] 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[1], 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!
-Giannis
[0] https://flocktofedora.org/
[1] https://fedorahosted.org/emea-swag-tracking/
--
Giannis Konstantinidis
giannis(a)konstantinidis.cc
http://konstantinidis.cc
giannisk on irc.freenode.net
7 years, 9 months
Maintainer preferred method of blocker bug notification?
by Chris Murphy
Hi,
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
cc.
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
https://qa.fedoraproject.org/blockerbugs/
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
(reminding).
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.
--
Chris Murphy
7 years, 9 months
Injecting perl-devel and perl-generators build-requires
by Petr Pisar
Hello,
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:
BuildRequires: perl-devel
or
BuildRequires: perl-generators
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.
-- Petr
7 years, 9 months
multi-CPU optimization inside a distribution
by Dan Horák
Hi all,
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 [1]). 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) [2] 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.
[1] http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/tree/rpmrc
[2] https://lwn.net/Articles/691932/
Dan
7 years, 9 months
autoconf test for deprecated readdir_r
by Kaleb S. KEITHLEY
Hi,
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
things.)
Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.
Thanks,
--
Kaleb
7 years, 9 months
About dnf failing to honore conditional level in comps.xml
by Luya Tshimbalanga
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 [1] 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[2]
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?
Reference
--------------
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1336879
[2] https://pagure.io/fedora-comps
--
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
7 years, 9 months
Looking for a proven packager
by Mattias Ellert
Hi!
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1328076
Since I am not a proven packager myself, I am looking for one that can
perform this task.
Mattias
7 years, 9 months
