packaging July 2013

packaging@lists.fedoraproject.org

43 participants
26 discussions

Setting CFLAGS when building python packages
by Sergio Pascual 09 Jul '13

09 Jul '13

Hello, I was wandering if it is still needed to put set CFLAGS before compilling python extensions, like this: CFLAGS="%{optflags}" %{__python} setup.py build There is nothing about it in the guidelines, altough I recall reading about it, so perhaps it was removed from the wiki? When comparing the compilation lines with and without setting CFLAGS, I see lots of repeated switches but nothing clearly different. Regards, Sergio

3 3

Issue packaging python lib into RPM due to conflicting __init__.py
by Braddock 07 Jul '13

07 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, I'm attempting to make an RPM of the Python package backports.lzma for a One Laptop Per Child project using bdist_rpm. tar xzf backports.lzma-0.0.2.tar.gz cd backports.lzma-0.0.2 python setup.py bdist_rpm My problem is that more than one python library wants to live under the "backports" directory, resulting in a backports/__init__.py file conflict on SOME platforms as each RPM attempts to create the backports/__init__.py file in its parent directory. For example, backports.lzma RPM conflicts with python-backports-ssl_match_hostname 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 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? There are a number of packages which would want to live under the backports/ module. Any advice appreciated. Thanks, Braddock Gaskill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR2ZVfAAoJEHWLR/DQzlZuh/wH/R8Mj/+O4uMpNhC205TPWSx7 Ure0MAten13uALy7IVfwPS/IdtfWQhj5vdgXkv/BZLjHk26DerIZP2Wwyo/IKMw9 ZEYmouf10CF9uaDBNXmWEgXCrmgknMDqLdHYZvAuQmwrai95BUy4zTrj9PoFzKuT h6Hx56UfpLFDeQsGaU5o2k9sR/aW356LQoQ26jNYOfUQuaWx3eJ4n64nFtfH5oPu PDVTrWtWoCilOnLR/kerHcBWZoNxuHtOANZafyF7se0hQP4aQs1DF6Bqv6mChCOM w/zM5wEjBb+nwUJE+/cEMJTuxMQv67rIjo+yYn8cSg06NpOUtD1Q4Azz2bmSx80= =Gpvi -----END PGP SIGNATURE-----

2 1

perl(strict)
by Christopher Meng 04 Jul '13

04 Jul '13

Hi, Do we need to split out this dep from perl in RPM spec? Someone says it's needed and someone doesn't support this idea. Thanks. Yours sincerely, Christopher Meng Always playing in Fedora Project http://cicku.me

5 11

Re: [Fedora-packaging] Packaging Go libraries for Fedora
by Richard W.M. Jones 01 Jul '13

01 Jul '13

On Mon, Jul 01, 2013 at 04:14:10PM +0200, Florian Weimer wrote: > On 07/01/2013 03:39 PM, Richard W.M. Jones wrote: > >But for libraries that aren't bundled with the Go compiler, it looks > >like the Go designers intended you to keep them in your home directory: > > > >http://golang.org/doc/code.html#Organization > > It's also expected that you keep around source code and recompile > from source each time something in the dependency tree changes. > There's no ABI stability whatsoever because internal implementation > details (struct sizes and offsets, say) bubble up due to inlining. Also, it'll try to recompile stuff in the %_libdir/golang directory if it thinks it's out of date. And fail, obviously. Joy. https://bugzilla.redhat.com/show_bug.cgi?id=973842#c23 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

1 0

Packaging Go libraries for Fedora
by Richard W.M. Jones 01 Jul '13

01 Jul '13

(The same topic came up on this list about a month ago, with no particular resolution). Fedora 18+ now has a proper Go compiler, and if you get the version in updates-testing, it's even a working Go compiler :-) Go seems to have a "unique" approach to packaging libraries. It looks as if everything revolves around there being a Go compiler + lots of bundled libraries that come with that Go compiler. On Fedora this gets installed into %_libdir/golang. But for libraries that aren't bundled with the Go compiler, it looks like the Go designers intended you to keep them in your home directory: http://golang.org/doc/code.html#Organization This is of course not so great from a packaging/security/updates point of view. Now as far as I can tell, we can just ignore the $GOPATH stuff, and instead drop files into the right places in %_libdir/golang. It works in my single, limited experiment, but I've no idea if this is the Right Thing to do. I think we should leave the $GOPATH environment variable alone. If users want to install things in their home directory too, they can set up $GOPATH and the directory structure themselves. Thoughts on this? (especially from anyone who knows what they're talking about, which is not necessarily me ...) I have a small cgo library which I'd like to package for Fedora, so this discussion is not entirely theoretical. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

1 0

alternative packaging
by Christopher Meng 01 Jul '13

01 Jul '13

Hi all, Can I use %postun instead of %preun to remove alternatives? Thanks. Yours sincerely, Christopher Meng Always playing in Fedora Project http://cicku.me

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2013