Binary in libxxx package
by Christopher Meng
Hi,
I'm packaging a library, but the problem is that this package will
generate a binary of its implementation.
I think libxxx packages should only contain .so.*/.h files, and I
cannot put it into devel package, so can I put it into main package? I
don't want to create a subpackage for this file.
Thanks.
Yours sincerely,
Christopher Meng
Always playing in Fedora Project
http://cicku.me
10 years, 9 months
Web Assets/JavaScript guideline drafts
by T.C. Hollingsworth
I'm getting rather sick of doing this by the seat of my pants and
arguing about various details in reviews, so it's high time something
got done about this. Plus, were working hard to actually get some JS
libraries (like jQuery, finally!) packaged properly, so it would be
nice to have some guidelines so that we can package them...properly.
So, down the rabbit hole we go...
I've drafted some JavaScript guidelines:
https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/JavaScript
And some guidelines for the other various shareable bits that aren't JavaScript:
https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/Web_Assets
And finally a F20 Change proposal that outlines the engineering component:
https://fedoraproject.org/wiki/Changes/Web_Assets
The most notable difference between these and previous efforts is that
I decided to go with One JavaScript Directory to Rule Them All.
Debian has already gone this route and I think it's much simpler than
the previous notion of requiring Apache configs for every JS library
under the sun. This way it's simple enough so it works with *any*
HTTP daemon.
I hope to submit the Change proposal to the Feature Wrangler/FESCo and
the drafts to FPC soonish, but I'd very much like to get some feedback
first. I'm sure there missing several details and could use some love
in certain areas, so please let me know what you think. (And feel
free to edit if necessary, it's a wiki after all!)
Thanks!
-T.C.
10 years, 9 months
Conflicts when data is moved to a sub-package
by Till Maas
Hi,
it seems to me that
https://fedoraproject.org/wiki/Packaging:Conflicts
does not cover a case for conflicts that might occur if a package is
split. Here is the bug report about the intended split:
https://bugzilla.redhat.com/show_bug.cgi?id=952326
Basically dvb-apps currently contains a plaintext file based database in
/usr/share/dvb/dvb-t/ which is supposed to provided by a new backage,
dtv-scan-tables. Since the individual files might differ, conflicts can
occur here, which is why it seems that the new dtv-scan-table package
should use "Conflict: dvb-apps < VERSION-RELEASE" for the
version/release that does not contain the database anymore to confclit
with all previous versions.
Since this does not seem to be covered by the guidelines, I ask for your
opinion.
Regards
Till
10 years, 9 months
systemd and privileged ports
by Daniel Pocock
Hi,
In my blog the other day, I noted that upcoming versions of my package
will be able to bind on port 443 (to provide TLS protected SIP over
WebSockets)
I've made upstream changes so the process can be started as root and
drop privileges after binding.
Somebody commented that I can use systemd to create the socket though.
Looking at the man pages very briefly, I have the impression that this
is only relevant to processes that spawn a new process to handle each
client and that processes handling multiple clients can't take advantage
of this.
Is that correct? Or can systemd pass in a listening socket that has not
received any connection yet?
Regards,
Daniel
10 years, 9 months
Question about upstream project aggregating source packages
by Simone Caronni
Hello,
I mantain the Guacamole stack [1] for Fedora.
Upstream has changed the way it packages sources; all the components have
been merged in 2 bigger source tarballs [2], one being guacamole-client for
the Java web application and the other one being guacamole-server for the
native server components.
Each new tarball will generate almost the same packages.
guacamole-server.src.rpm will generate only:
guacd
libguac
libguac-client-rdp
libguac-client-ssh
libguac-client-vnc
guacamole-client.src.rpm will generate only:
guacamole
The following are now integrated in guacamole:
guacamole-common
guacamole-common-js
guacamole-ext
What's the procedure here? I thought about this:
1- Create a new review request for guacamole-server
2- After having git access retire guacd and libguac*
3- Create a rename review for guacamole -> guacamole-client
4- After git access, make sure guacamole obsoletes
guacamole-{common,common-js,ext}
5- Retire guacamole-{common,common-js,ext}
This will give me only guacamole-client and guacamole-server in koji/git.
Is this correct?
[1]
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=*...
[2] http://guac-dev.org/pub/dist/source/
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
10 years, 9 months
Two packages that want to own the same parent directory
by Darryl L. Pierce
I have two separate pieces of Python code (one pure Python, one that is
C++ code that has a Swigged Python binding) that each want to live in a
package named qpid. (they're both Python bindings for the Qpid project)
Is it possible to have two different packages (they're not subpackages
of some other package) live in a directory like
/usr/lib64/python2.7/site-packages/qpid without either one explicitly
owning the directory qpid? A user can potentially install one or both.
Their code will all live inside of subdirectories of qpid (either
messaging or messagingc).
How do I handle that from a packaging perspective?
--
Darryl L. Pierce <mcpierce(a)gmail.com>
http://mcpierce.multiply.com/
"What do you care what people think, Mr. Feynman?"
10 years, 9 months
Summary/Minutes from today's FPC Meeting (2013-07-11 16:00 - 17:16 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by abadger1999 at 16:02:57 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-11/fpc.2013-07-...
.
Meeting summary
---------------
* Roll Call (abadger1999, 16:03:06)
* Bundling exception for nodejs-expect-js
https://fedorahosted.org/fpc/ticket/297 (abadger1999, 16:04:13)
* Bundling exception for nodejs-expect-js passes (+1:5, 0:0, -1:0)
(abadger1999, 16:14:05)
* Please deprecate usage of systemd-sysv-convert in the packaging
https://fedorahosted.org/fpc/ticket/308 (abadger1999, 16:14:47)
* Drop use of systemd-sysv-convert from the guidelines Approved (+1:5,
0:0, -1:0) (abadger1999, 16:33:18)
* Request review of httpd-itk https://fedorahosted.org/fpc/ticket/310
(abadger1999, 16:34:02)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=598860 (Rathann,
16:47:50)
* httpd-itk's bundling of apache is denied at this time (+1:5, 0:0,
-1:0) (abadger1999, 16:56:05)
* Open Floor (abadger1999, 16:57:37)
* geppetto will be unable to attend for the next two weeks
(abadger1999, 16:58:14)
* LINK: https://fedoraproject.org/wiki/FPC_meeting_process
(geppetto, 17:00:09)
* ACTION: tibbs|w will handle sending the meeting agenda next week.
(abadger1999, 17:02:25)
Meeting ended at 17:16:57 UTC.
Action Items
------------
* tibbs|w will handle sending the meeting agenda next week.
Action Items, by person
-----------------------
* tibbs|w
* tibbs|w will handle sending the meeting agenda next week.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* abadger1999 (56)
* tibbs|w (37)
* limburgher (36)
* Rathann (26)
* geppetto (21)
* tchol (6)
* zodbot (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 9 months
Re: [Fedora-packaging] Issue packaging python lib into RPM due to conflicting __init__.py
by Braddock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks Michael, that provides some clarity.
I think I probably need to coordinate with the maintainer of the
python-backports-ssl_match_hostname package, because he is clobbering
the backports/__init__.py* namespace files we both need. While I
could patch the __init__.py files to be identical, the compiled .pyc
files are never exactly the same. They need to be factored out into a
separate package somehow.
My newbie question is how do I find the maintainer? The RPM meta-data
only specifies "Fedora Project" as the maintainer.
- -braddock
> Date: Sun, 7 Jul 2013 20:48:59 +0200 From: Michael Schwendt
> <mschwendt(a)gmail.com> To: packaging(a)lists.fedoraproject.org
> Subject: Re: [Fedora-packaging] Issue packaging python lib into
> RPM due to conflicting __init__.py Message-ID:
> <20130707204859.10ed3776(a)faldor.intranet> Content-Type: text/plain;
> charset=utf-8
>
> On Sun, 07 Jul 2013 09:20:47 -0700, Braddock wrote:
>
>> file /usr/lib/python2.7/site-packages/backports/__init__.py from
>> install of backports.lzma-0.0.2-1.armv7hl conflicts with file
>> from package
>> python-backports-ssl_match_hostname-3.2-0.3.a3.fc18.noarch
>
> This means that both packages contain a file in that path, and
> either the file checksum or the file permissions are not the same.
>
>> I am uncertain how to resolve this. Is there a way for an RPM to
>> only create the backports/__init__.py file if it does not already
>> exist?
>
> No. When you create these packages, _you_ need to ensure that they
> don't include conflicting files. How do those __init__.py files
> differ in those multiple packages? Is it only a matter of different
> versions of the backports module? Remember, you've got full control
> over the package %{buildroot} at build-time, so you could delete
> files you don't want and which are included in a separate (shared!)
> package already.
>
>> There are a number of packages which would want to live under
>> the backports/ module.
>
> That's okay, but it's not okay if they all contain a differing
> backports/__init__.py file.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJR3cDuAAoJEHWLR/DQzlZuuFIH/08Y7qkxY01ZbRNV2aOLVZC+
mjI3+QcR2bKPadDD2BALNyUT/ct36i7u3+endu+j1A8HHj2ls9iEIRisvIM5S9QM
3QuvWcDUR3rkQSZlDcqSiuKDbo0qJU297n/HW1YJmGYLdXW6ClbSU5vt0WYvd5vw
77hHRF86mvyKsd30rGRLzmbksOIz4nO6gdauh3fAgd2bGLIgJgsExBTSwz9yoV8b
GVW66wfVREyFa3BmxvpoGnOczW/UoN1sNqDykVHx7EwXQAQ8HOlgB4poxsIY0AHu
Fqwmsgj74G0RKAwqnRxT91n1J2xYhUNULXUx9ngnM81RkfOjkygE7ewaisOgbpg=
=euFm
-----END PGP SIGNATURE-----
10 years, 9 months
