Summary/Minutes from today's FPC Meeting (2018-10-04 16:00 - 17:00 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:02 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-04/fpc.2018-
10-04-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:02)
* I have fixed markup on
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
(ignatenkobrain, 16:04:13)
* Schedule (geppetto, 16:04:38)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/PCK2NLJADBXFXBR43BVQIYXGSLTKLMIR/
(geppetto, 16:04:42)
* #775 Allow to have %{?suse_version} condition in spec
file (geppetto,
16:07:06)
* ACTION: FPC prefers you don't do it, but there's nothing stopping
you. (+1:6, 0:1, -1:0) (geppetto, 16:16:32)
* #693 Wiki:Packaging:RPMMacros (geppetto, 16:17:26)
* ACTION: decathorpe will clean up the page (geppetto, 16:28:03)
* #784 forbid globs for shared libraries as it conceals sonames
(geppetto, 16:28:33)
* PR was merged this week (geppetto, 16:29:35)
* LINK:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing
_shared_library_files
(ignatenkobrain, 16:31:07)
* LINK:
https://pagure.io/packaging-committee/c/2051d0c7dcd7f062e2c8571f19a
8cf7eea8b0ce6?branch=master
(decathorpe, 16:31:19)
* Open Floor (geppetto, 16:33:31)
* LINK:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packag
er_group
(mhroncok, 16:37:46)
* LINK: https://paste.fedoraproject.org/paste/Af6Zb~cirGwiyAc6JaNIxA
(ignatenkobrain, 16:49:29)
* LINK:
https://www.math.uh.edu/~tibbs/greasemonkey/Widen_pagure.user.js
(tibbs, 16:56:56)
* LINK: https://github.com/greasemonkey/greasemonkey (tibbs,
17:00:09)
Meeting ended at 17:00:20 UTC.
Action Items
------------
* FPC prefers you don't do it, but there's nothing stopping you. (+1:6,
0:1, -1:0)
* decathorpe will clean up the page
Action Items, by person
-----------------------
* decathorpe
* decathorpe will clean up the page
* **UNASSIGNED**
* FPC prefers you don't do it, but there's nothing stopping you.
(+1:6, 0:1, -1:0)
People Present (lines said)
---------------------------
* tibbs (70)
* geppetto (61)
* decathorpe (24)
* ignatenkobrain (22)
* mhroncok (19)
* limburgher (17)
* zodbot (16)
* redi (16)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
5 years, 6 months
Re: [Fedora-join] My experience as a wannabe contributor
by Brian (bex) Exelbierd
+packaging list
Thank you for taking the time to describe your challenges. I am
adding the packaging list as they are in a position to help with some
of these issues and to consider where more docs may be useful.
I am not sure how to help on the package reviews side. I personally
only have one package in Fedora and my role in the project made it
easy to find a reviewer. But, you shouldn't have to be the FCAIC to
make getting a reviewer easy. I know that we are working on more
automation in these areas to make review less human-labor intensive.
However, that doesn't help you today.
I hope we will hear some news from FPC about this.
regards,
bex
On Thu, Sep 27, 2018 at 10:40 PM Alain Vigne <alain.vigne.14(a)gmail.com> wrote:
>
> Hi, I am Alain, FAS: avigne
>
> As discussed today in #fedora-devel, here is some feedback about my experience trying to join Fedora as a contributor -> packager.
>
> TLDR: Adding a new package and become a Fedora packager is NOT easy.
>
> I am not a computer scientist, but as an Integrated Circuit designer, I am using eCAD proprietary tools heavily.
> With my years of experience, I came up to know how to use Fedora, and I like this distro because it is reliable, and fairly up to date with software technologies.
>
> When Fedora FEL spin was alive, I picked up some tools, and slowly learn how to use them. gEDA, PCB, NGspice, GerbV, etc...
> At some point, 2 years ago, I thought Open Source world gave me a lot, it was time to give back... So I contacted the pcb-rnd project [1], and started to contribute code around GTK, and GUI aspects of the application.
>
> Naturally, as I am developing with a Fedora system, I thought it could be nice to have pcb-rnd for Fedora... I had no clue on how to proceed, and first, I tried to find someone who can do that for me...
> Found no one. (I should have known :).
>
> Time passes by, and one day a pcb-rnd Mageia contributor showed me the .spec file he wrote for Mageia. I was curious about what was behind all those commands and how this "recipe" (the .spec file) can lead to a package.
> So I dug into the documentation (mainly Fedora wiki) learning how to first build an RPM, then after a successful local "mock", my curiosity was satisfied. I thought I understood the purpose of those tools (rpmbuild, rpmlint, mock).
>
> That is when I started to think about contributing this package to Fedora. "It should be easy, I have the recipe, I just need to find where to check-in the .spec file..." Easy thought, no ?
> Unfortunately, no, this is not easy.
>
> First, there are tons of pages describing the process, and what to do. In theory the process is well described.
> In practice, I got stuck in the "need a sponsor" phase where I think there is kinda chicken-and-egg problem for a new contributor.
>
> I might detail that, later, if someone is interested in this list.
>
> My feeling today, 6 months after I jumped in the unknown is not very much positive:
> I had to register, open accounts, leave traces on many systems before being able to .... get nothing at the moment
>
> Bugzilla
> FAS
> COPR
> mailing list
> Freenode registration
>
> etc...
> I feel like someone who has a complicated map under the eyes, walk, try and error to make sense of the map, up to a point where the map says: next step is "find a sponsor" and I have no idea how this is being done.
> And time passes by... Slowly. I am silently ignored.
>
> Somebody says today : "Do informal reviews [a suggestion on the wiki, but what can I suggest ? I have no experience ->chicken and egg problem], make some mails, fill some bugs and you will get noticed".
> I think this is the problem: nobody noticed, it seems nobody cares having a new volunteer.
>
> So, I am concluding: Fedora = too big ship, mainly automated, with a lot of processes (procedures, way of working) and a community not open to new contributors [I recall, my experience is only about contributing a new package], because this is too complicated (which I agree and understand).
>
> That said, I am a patient man, and I have done all this travel not to being stop by a wall. I spent my life trying to get around, over, across... so many walls, so, I won't surrender here !
> Thanks for reading till that point, and let us open the debate.
>
> Kind regards
> Alain
> PS: I am French, not EN native speaker, pardon my language if it does not make sense to you.
>
> [1] http://repo.hu/projects/pcb-rnd/
>
>
> --
> Alain V.
> _______________________________________________
> fedora-join mailing list -- fedora-join(a)lists.fedoraproject.org
> To unsubscribe send an email to fedora-join-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/fedora-join@lists.fedorapro...
--
Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
5 years, 6 months
Spec file fixes for prefix=/app Flatpak builds
by Owen Taylor
As some of you are aware, I've been working on a project to make it
possible to build Flatpaks out of Fedora RPMs within the Fedora
infrastructure. One of the key elements of this is rebuilding RPMs with
prefix=/app. The way that Flatpak works is that at runtime, two filesystems
are mounted:
/usr- the "runtime" - standard Fedora libraries shared by multiple Flatpaks
/app - the application and libraries distributed inside the app container
To rebuild a package with prefix=/app, it is rebuilt in a module that has
the 'flatpak-rpm-macros' package installed in the buildroot (this is
automatically done when your package depends on the flatpak-runtime
module.) The flatpak-rpm-macros package overrides %{_prefix}, %{_datadir},
etc, and points them to /app.
About 90% of packages just work without any changes at all, but other
packages need some (mostly minor) changes.
Generally, I'd consider most changes that are needed things that make the
packages more compliant with the packaging guidelines - we expect packages
to honor %{_prefix}. But there is one assumption some of the changes make
that Petr Pisar pointed out to me that everybody might not agree with:
%{_prefix} and related macros specify the install location of this
package, they
should not be used for paths to tools used as BuildRequires.
So I wanted to run that idea past the packaging list for comment. In many
cases, that assumption can be fixed inside installed RPM macros (meson,
ninja, and qt5 macros have already been fixed.) But in a few cases a spec
file does make that assumption.
I've made a wiki pages that has all the changes I've needed so far:
https://fedoraproject.org/wiki/Flatpak:Fixes
Everything marked with a checkmark is already in Fedora - either because I
committed a fix directly (mostly workstation related packages), or more
commonly, because I've submitted a pull-request that the maintainer
accepted.
Regards,
Owen
5 years, 6 months
