Open Seat on the Fedora Packaging Committee
by Tom Callaway
The Fedora Packaging Committee has one open seat and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Rex Dieter for his service, as he is
stepping down after several years.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also rewriting drafts
(sometimes from scratch) to resolve the issue in a more acceptable
fashion. Additionally, the FPC reviews bundling exceptions (and UID/GID
soft static assignment). The FPC meets on IRC weekly, Wednesdays at 1600
UTC, for approximately an hour. FPC members serve for as long as they
are willing, there are currently no term limits. All decisions are voted
on using a +1 (for), 0 (abstain), and -1 (against) mechanism, and all
decisions must be approved by a majority (+5). FPC Meetings do not
happen if quorum (5) is not present.
Candidates who are interested should provide the following details to
the FPC for consideration, by emailing it directly to me
(tcallawa(a)redhat.com). The FPC will consider all candidates, but
strongly prefers candidates who have extensive experience packaging in
Fedora. We will accept applications for the next week (deadline
Wednesday Apr 24, 2013).
Name:
FAS Account:
Provenpackager? (Yes/No):
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
~tom
==
Fedora Project
10 years, 4 months
Lightworks video editor
by Michael Hall
The Lightworks video editor becomes available for Linux tomorrow
supposedly, but only for Ubuntu according to the developers.
http://www.lwks.com
Lightworks is a powerful, cross-platform professional video editor that has
been used to cut many big-name movies over the years. It is "sort of" open
source, not really at this point. But the point is that this is a really
important piece of software for anyone wanting to edit video or even full
4K movies ... current Linux video editors are buggy and unreliable,
Lightworks is true professional grade.
So, my question is, assuming that Lightworks is released as some kind of
.deb package, how likely is it that it could be converted to .rpm?
I have some basic experience building RPMs and would be up for helping with
this task.
Mike Hall
10 years, 4 months
Avoid a 32 bits package from being pushed into 64 bits repository
by Alejandro Alvarez Ayllon
Hello,
I co-maintain a package that contains a library that is used as module
for a server.
The 32 bits version of this library is pushed automatically into the 64
bits repositories (i.e. in epel6),
which doesn't make much sense, since the 64 bits version of the server
won't run with the 32 bits
libraries.
This wouldn't be a big problem, but the pushed 32 bits rpm has a dependency
on the 32 bits server, so then I will get complains (with reason) about
the broken package.
globus-gridftp-server-progs is the server, and dpm-dsi is the module.
So my question is: how should I approach this? I got some suggestions in
this ticket
https://bugzilla.redhat.com/show_bug.cgi?id=957588
Is there any way I can prevent this rpm from being copied into the 64
bits repositories?
Regards.
10 years, 5 months
Summary/Minutes from today's FPC Meeting (2013-04-24 16:00 - 16:45 UTC)
by James Antill
=============================================
#fedora-meeting-1: Fedora Packaging Committee
=============================================
Meeting started by spot at 15:59:56 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-24/fpc.2013-04-...
.
Meeting summary
---------------
* Roll Call (spot, 16:01:44)
* Bundling exception request for Cura -
https://fedorahosted.org/fpc/ticket/244 (spot, 16:08:02)
* ACTION: No bundling exception needed, this is a pure fork. (spot,
16:13:27)
* Bundling exception for libevent in openmpi -
https://fedorahosted.org/fpc/ticket/273 (spot, 16:16:52)
* ACTION: FPC is pretty universally against this bundling, spot will
try to make a libevent-nothread.so and update libevent. (spot,
16:26:38)
* Open Seat on the FPC (spot, 16:26:53)
* Open Floor (spot, 16:28:26)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=858841 (spot,
16:33:11)
Meeting ended at 16:44:15 UTC.
Action Items
------------
* No bundling exception needed, this is a pure fork.
* FPC is pretty universally against this bundling, spot will try to make
a libevent-nothread.so and update libevent.
Action Items, by person
-----------------------
* spot
* FPC is pretty universally against this bundling, spot will try to
make a libevent-nothread.so and update libevent.
* **UNASSIGNED**
* No bundling exception needed, this is a pure fork.
People Present (lines said)
---------------------------
* spot (39)
* limburgher (30)
* tibbs (22)
* abadger1999 (18)
* geppetto (16)
* Smoother1rOgZ (7)
* zodbot (4)
* Rathann (4)
* racor (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 5 months
Re: [Fedora-packaging] [fedora-java] Shipping of binaries in jar files
by Orion Poplawski
On 04/26/2013 03:39 AM, Stanislav Ochotnicky wrote:
> Quoting Andrew Haley (2013-04-26 11:11:41)
>> On 04/22/2013 11:01 PM, Orion Poplawski wrote:
>>> The eclipse PTP project that I package is starting to ship an executable in
>>> one of its plugins. The executable is packed into a jar file. This prevents
>>> debuginfo creation for the executable.
>>>
>>> I started taking a look at how this might be handled elsewhere and found:
>>>
>>> /usr/lib64/eclipse/dropins/cdt/eclipse/plugins/org.eclipse.cdt.core.linux.x86_64_5.2.0.201302132326.jar:
>>> 13327 Defl:X 3624 73% 02-13-2013 23:21 326488c7
>>> os/linux/x86_64/libpty.so
>>> 23720 Defl:X 7151 70% 02-13-2013 23:21 c26c2c94
>>> os/linux/x86_64/libspawner.so
>>>
>>> but no debuginfo package.
>>>
>>> Thoughts, comments?
>>
>> This is pretty obviously a breach of packaging guidelines. We shouldn't
>> be hiding DSOs in archives.
>
> Hmm, I am not aware of any guideline touching this topic (perhaps because it's
> not that common). But from practical perspective these jars are extremely
> practical because they don't have to deal with JNI file locations and similar
> things which ten to be quite variable.
>
> I don't consider this approach hiding, but we could surely improve the tooling
> support for it.
>
> WRT original question, I am not sure how to proceed. Even if you generate
> debuginfo packages I have to wonder how easy will it be to use in a debugger?
>
The workaround that I am employing for the moment in PTP is to install a
copy of the binary in %{_libdir}/ptp so that rpm can find it an generate
debuginfo. As for how useful that might be, I don't know. I *think*
gdb matches things up via hashes these days so it might work, and might
for the cdt shared libraries as well.
Whatever the solution, I think we need to improve our tooling to check
inside of archives for binaries. I'm CC'ing the packaging list as well.
--
Orion Poplawski
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
10 years, 5 months
%{macro} vs. %macro in spec files
by Alexey I. Froloff
There are two forms of using macros in spec files - %{macro} and
%macro. RPM supports second form since 4.0, IIRC.
In one of my packaged I used %_bindir macro and was told by
reviewer to change it to %{_bindir}. OTOH, %configure is also a
macro, but it is widely used without curly brackets.
What's the point of using %{macro} form for some, but not all
macros?
--
Regards, --
Sir Raorn. --- http://thousandsofhate.blogspot.com/
10 years, 5 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Another round of changes to the Fedora Packaging Guidelines have been made:
---
A new section on packaging cron jobs has been added:
https://fedoraproject.org/wiki/Packaging/CronFiles
---
The guidelines for migrating from sysv init scripts to systemd were
clarified to state that the migration triggers only need to be kept for
two releases (to cover the range of supported upgrades). For example, if
the package converted to systemd unit files in F18, the migration
support could be dropped in the F21. It is not mandatory that they drop
them, this is just to clarify that they have the option of dropping them
at that point.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migra...
---
If an update to your package resolves a known security concern (at the
time of the update) with a Common Vulnerabilities and Exposures (CVE)
number assigned to it, you should mention the CVE number in the RPM
changelog entry.
https://fedoraproject.org/wiki/Packaging:Guidelines#Security_Updates_To_R...
---
The Java Guidelines have been updated with macros that simplify
packaging on F19+, a specific circumstance where JAR files can be now
installed to %{_javadir}/%{name}/ under its usual name, and other
cleanups proposed by the Java SIG.
https://fedoraproject.org/wiki/Packaging:Java
---
The ruby gems guidelines have been updated to make use of the
%gem_install macro that is available in Fedora 19 and beyond.
https://fedoraproject.org/wiki/Packaging:Ruby
---
The packaging guidelines have been clarified to specify that RPM Macro
files stored in /etc/rpm/ are not to be marked %config.
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Addition...
---
A Bundling exception for nodejs-should to include the forked code
fragment from the Node.js "assert" module was approved.
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Jóhann B. Guðmundsson, Przemek Klosowski, David Malcolm,
Jamie Nguyen, Vit Ondruch, Michal Srb, and all of the members of the
FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
10 years, 5 months
