On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>> f-r currently fails to build (#1603956), it has a bunch of bugs open 
>> and many issues and unhandled pull requests in the upstream repo [2, 3].
>> The last upstream commit was 2 years ago.
>> f-r has is annoyingly outdated and gives often outright bad advice
>> (for example about BR:gcc or BR:g++). The situation would be
>> improved if the outstanding PRs were merged.
>> f-r is also python2-only now, which will be a problem soon since
>> support for python2 is waning .
>> Is there any hope of upstream and downstream activity on f-r?
> I was thinking about getting the fedora-review checks rewritten into the
> standard Test interface
> so that they
> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> might take a little bit of time.
I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
Once this is fully automated, we can then *also* add the same checks to CI
(taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
Historically, we've had human review mainly to protect against two things,
bundling and unacceptable licenses. In both of these cases, I'd like for us
to move towards a culture of assuming goodwill on behalf of our packagers.
Most of the packagers in Fedora have been doing it for a long time and know
what is and is not acceptable. Optimizing for the minority case is
wasteful, especially when it adds hurdles and delays to getting software
I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
I feel strongly that automated, continuous review would be of far greater
value to Fedora than front-loading the review process the way we have been
doing (which serves mostly to discourage people from even starting).
From time to time I have to submit a ticket with 'fedpkg request-repo' or
'fedpkg request-branch', and I have feeling that I have to regenerate the API
key very often (since 2018-02-17 I have 5th key already?!).
How do you work-around this requirement to re-generate the key all the
time? Is this necessary requirement for 'fedpkg' to work if when we have
gssapi support in Fedora?
Got an e-mail from Koschei  with a notice that camotics package is starting to fail to build. The reason for this seems to be that something that used to pull mesa-libEGL-devel doesn't do so anymore.
/usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not camotics I think it would be more appropriate to put the dependency there. Thoughts?
Here's an extra early reminder due to the holidays coming up. Several
Change proposal deadlines for Fedora 30 are approaching:
* 2019-01-02 — Changes requiring infrastructure changes
* 2019-01-08 — Changes requiring mass rebuild
* 2019-01-08 — System-Wide changes
* 2019-01-29 — Self-Contained changes
For more information on Changes, see the Changes Policy page on the
Fedora Program Manager
as you may already know, MongoDB is now licensed under SSPLv1 as of
Since SSPLv1 doesn't meet Fedora's license requirements, I'd like to
start a conversation
on MongoDB's future in Fedora.
Theoretically, we could maintain versions prior to October 15,
however, the new license
doesn't allow backporting (due to incompatibility with AGPLv3 - see
related thread on
fedora legal list). Therefore, I'd suggest dropping MongoDB from Fedora.
I intend to file a FESCo ticket, and let them make the final decision,
however, any thoughts
or suggestions are welcome.
Associate Software Engineer