packaging July 2015

packaging@lists.fedoraproject.org

34 participants
32 discussions

python34 packages for EPEL
by Orion Poplawski 15 Jul '15

15 Jul '15

Sorry for the cross posting - let's follow up on the EPEL list We now have python34 in EPEL (yay - thanks Matej and others!). Starting to look at packaging some modules. We have https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 as a starting point which looks pretty good. One wrinkle though is that we have a bunch of python2 packages provided by RHEL that we'll want to provide python3X versions for in EPEL, but not ship python2 versions. So a question becomes, where do they get maintained? Either: - epel7 branch of the python-blah package in Fedora? - a new python3X-blah package? And if in an epel7 branch of an existing package, is it conceivable to maintain a common spec across EPEL and Fedora? I think this is somewhat representative of the changes needed in a more complicated package (setuptools) which isn't actually too terrrible: diff --git a/python-setuptools.spec b/python-setuptools.spec index 7f37e90..cb96b9f 100644 --- a/python-setuptools.spec +++ b/python-setuptools.spec @@ -1,9 +1,9 @@ -%if 0%{?fedora} +%if 0%{?fedora} || 0%{?rhel} >= 7 %global with_python3 1 # This controls whether setuptools is build as a wheel or not, # simplifying Python 3.4 bootstraping process -%global build_wheel 1 +%global build_wheel 0 %else %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")} %endif @@ -44,10 +44,10 @@ BuildRequires: python-pip BuildRequires: python-wheel %endif %if 0%{?with_python3} -BuildRequires: python3-devel +BuildRequires: python%{python3_pkgversion}-devel %if 0%{?build_wheel} -BuildRequires: python3-pip -BuildRequires: python3-wheel +BuildRequires: python%{python3_pkgversion}-pip +BuildRequires: python%{python3_pkgversion}-wheel %endif %endif # if with_python3 # For unittests @@ -68,7 +68,7 @@ This package also contains the runtime components of setuptools, necessary to execute the software that requires pkg_resources.py. %if 0%{?with_python3} -%package -n python3-setuptools +%package -n python%{python3_pkgversion}-setuptools Summary: Easily build and distribute Python 3 packages Group: Applications/System @@ -76,7 +76,7 @@ Group: Applications/System # has been present since python3-3.2. We do not ship python3-3.0 or # python3-3.1 anywhere -%description -n python3-setuptools +%description -n python%{python3_pkgversion}-setuptools Setuptools is a collection of enhancements to the Python 3 distutils that allow you to more easily build and distribute Python 3 packages, especially ones that have dependencies on other packages. @@ -156,6 +156,9 @@ chmod +x %{buildroot}%{python3_sitelib}/setuptools/command/easy_install.py popd %endif # with_python3 +%if 0%{?epel} +rm %{buildroot}/%{_bindir}/easy_install +%else %if 0%{?build_wheel} pip2 install -I dist/%{python2_wheelname} --root %{buildroot} --strip-file-prefix %{buildroot} %else @@ -167,9 +170,11 @@ rm -rf %{buildroot}%{python_sitelib}/setuptools/tests sed -i '/^setuptools\/tests\//d' %{buildroot}%{python2_record} %endif -install -p -m 0644 %{SOURCE1} %{SOURCE2} . find %{buildroot}%{python_sitelib} -name '*.exe' | xargs rm -f chmod +x %{buildroot}%{python_sitelib}/setuptools/command/easy_install.py +%endif # 0%{?epel} + +install -p -m 0644 %{SOURCE1} %{SOURCE2} . %check %{__python} setup.py test @@ -184,15 +189,17 @@ popd rm -rf %{buildroot} +%if !0%{?epel} %files %defattr(-,root,root,-) %doc *.txt docs %{python_sitelib}/* %{_bindir}/easy_install %{_bindir}/easy_install-2.* +%endif %if 0%{?with_python3} -%files -n python3-setuptools +%files -n python%{python3_pkgversion}-setuptools %defattr(-,root,root,-) %doc psfl.txt zpl.txt docs %{python3_sitelib}/* One note - according to https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macr… %{python3_pkgversion} is supposed to be defined in Fedora, but I don't see it (at least not in F22). In the review (https://bugzilla.redhat.com/show_bug.cgi?id=1219411#c8) there seems to be some uncertainty as to where it will land? Comments? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

Github URL clarification
by Michael Cronenworth 15 Jul '15

15 Jul '15

FPC, Many packages are using the Github release URL. IE: github.com/foo/%{name}/archive/v%{version}.tar.gz http://pkgs.fedoraproject.org/cgit/cbootimage.git/tree/cbootimage.spec http://pkgs.fedoraproject.org/cgit/git-extras.git/tree/git-extras.spec http://pkgs.fedoraproject.org/cgit/jacoco.git/tree/jacoco.spec http://pkgs.fedoraproject.org/cgit/libepoxy.git/tree/libepoxy.spec Some are using a slightly different, but similar, URL. IE: github.com/foo/%{name}/archive/%{name}-%{version}.tar.gz http://pkgs.fedoraproject.org/cgit/json-c.git/tree/json-c.spec http://pkgs.fedoraproject.org/cgit/livecd-tools.git/tree/livecd-tools.spec http://pkgs.fedoraproject.org/cgit/python-meh.git/tree/python-meh.spec The list of packages using these URLs extends beyond these 7 packages. Can the Github URL wiki text be clarified to either include or exclude the release tarball provided by Github? Thank you, Michael

7 14

Wiki Packaging:FrequentlyMadeMistakes
by Michael Schwendt 14 Jul '15

14 Jul '15

https://fedoraproject.org/wiki/Packaging:FrequentlyMadeMistakes can still not be edited and is still out-of-date. At least delete the CVS related line in there, please.

2 1

github URLs?
by Dave Johansen 13 Jul '15

13 Jul '15

What's the right way to handle github URLs? Currently, I'm working on the spec file for breathe and the URL is https://github.com/michaeljones/breathe/archive/v4.0.0.tar.gz and the actual file that's downloaded is breathe-4.0.0.tar.gz. How do I make that play nice in the spec file and with rpmlint? Thanks, Dave

9 31

Packaging golang for secondary architectures, go-srpm-macros
by Jan Chaloupka 13 Jul '15

13 Jul '15

Hi, at the moment golang packages are built only on primary architectures (defined by %go_arches macro) due to golang compiler architecture support. For secondary architectures gcc-go is available. In order to provide an easy way for packagers to package golang projects for secondary architectures as well, go-srpm-macros packages is introduced. It provides basic macros that can be used within spec files. Currently golang package ships /usr/lib/rpm/macros.d/macros.golang file, which defines %gopath and %go_arches macros. As secondary architectures has no golang package these macros are not available. Thus I am proposing to move these macros to go-srpm-macros package and provide additional ones: # Define arches for PA and SA %golang_arches %{ix86} x86_64 %{arm} %gccgo_arches %{power64} s390x aarch64 %go_arches %{golang_arches} %{gccgo_arches} # Where to set GOPATH for builds %gopath %{_datadir}/gocode # Minimal version of gcc providing gcc-go %gccgo_min_vers 5.0.0 # Define commands for building %golang_build go build -compiler gc %gcc_go_build go build -compiler gccgo -gccgoflags "$RPM_OPT_FLAGS" # Define commands for testing %golang_test go test -compiler gc %gcc_go_test go test -compiler gccgo -gccgoflags "$RPM_OPT_FLAGS" Meaning of %golang_arches and %gccgo_arches is obvious. %go_arches is extended for secondary architectures. Spec files using %go_arches macros will not get touched by this change as it takes effect only on secondary architectures. %golang_build, resp. %golang_test and %gcc_go_build, resp. %gcc_go_test macros provides an easy way to run go build, resp. go test commands for golang and gcc-go compiler without typing the minimal list of options. The reason to define %golang_build and %gcc_go_build instead of %go_build for both compilers is to cover a case when gcc-go and golang have a different set of options. So packagers are aware of which compiler/command they use for building. The same holds for the 'go test' command. Recommended use in spec file: 1) To choose the correct compiler: %ifarch %{golang_arches} BuildRequires: golang %else BuildRequires: gcc-go >= %{gccgo_min_vers} %endif 2) To choose the correct command for building and testing: %ifarch %{golang_arches} %{golang_build} -o bin/binary %{import_path}/binary %{golang_test} %{import_path}/binary %else %{gcc_go_build} -o bin/binary %{import_path}/binary %{gcc_go_test} %{import_path}/binary %endif At the same time packaging guidelines for golang will be extended to provide information about secondary architectures. What are the steps to accomplish this task? 1) finish review of go-srpm-macros [1] 2) add go-srpm-macros as a run-time dependency of redhat-rpm-config for f21-f23 and el6 3) remove /usr/lib/rpm/macros.d/macros.golang from golang 4) update packaging guidelines I will fill all necessary bugs/tickets if needed and update packaging guidelines. Florian, I would like to make go-srpm-macros a run-time dependency of redhat-rpm-config. Thus I believe go-srpm-macros needs an extra caution so it does not break minimal buildroot. Can you check out the macros.go-srpm file in the package [1]? The file define only one line macros, no %if nor %ifarch. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1241156 Any feedback and questions are welcomed and appreciated. Thanks to all involved in helping us. Kind Regards Jan Chaloupka

1 0

Re: [Fedora-packaging] [Guidelines change] Changes to the packaging guidelines
by Stephen Gallagher 10 Jul '15

10 Jul '15

On Wed, 2015-07-08 at 20:13 -0500, Jason L Tibbitts III wrote: > Here are the recent changes to the packaging guidelines. Note that > there is also a set of Python guideline changes pending which I will > send in a separate announcement. > > ----- > > Guidelines for making use of weak dependencies (Recommends:, > Suggests:, > etc.) have been added. > > *https://fedoraproject.org/wiki/Packaging:WeakDependencies > *https://fedorahosted.org/fpc/ticket/531 > Is there any case to allow Supplements: in the Fedora Collection? It seems to me like this could be problematic. (e.g. I write a plugin for a popular engine and package it, then add Supplements: so that it gets pulled in by default whenever that engine is installed. My plugin then causes things to crash.) I think it is reasonable for us to forbid Supplements: except with FPC exemption. It should be up to the owner of the primary package to decide to add Recommends: instead.

3 2

Summary/Minutes from today's FPC Meeting (2015-07-09 16:00 - 17:10 UTC)
by James Antill 09 Jul '15

09 Jul '15

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 16:00:06 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2015-07-09/fpc.2015-07-09… . Meeting summary --------------- * Roll Call (geppetto, 16:00:06) * LINK: https://fedorahosted.org/fpc/ticket/382 (tibbs|w, 16:11:18) * Schedule (geppetto, 16:17:32) * LINK: https://lists.fedoraproject.org/pipermail/packaging/2015-July/010808.html (geppetto, 16:17:34) * #550 Darktable and Rawspeed internal library (geppetto, 16:17:53) * LINK: https://fedorahosted.org/fpc/ticket/550 (geppetto, 16:17:53) * LINK: https://github.com/klauspost/rawspeed/issues/109 (Rathann, 16:22:36) * ACTION: Rawspeed is way too big/active to be a copylib. Make a static library. (geppetto, 16:32:45) * ACTION: Also rawspeed needs to unbundle pugixml (geppetto, 16:33:01) * #508 New GID for openstack-neutron (geppetto, 16:35:09) * LINK: https://fedorahosted.org/fpc/ticket/508 (geppetto, 16:35:09) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=902987 (Rathann, 16:40:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=845078 (Rathann, 16:41:48) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=732442 (Rathann, 16:42:39) * ACTION: Looking at previous openstack uid/gids we wouldn't have approved any of them, so look at filing a FESCo ticket to see if we should pass a lot more of these that don't really need it. (geppetto, 16:57:34) * Open Floor (geppetto, 16:57:39) Meeting ended at 17:10:35 UTC. Action Items ------------ * Rawspeed is way too big/active to be a copylib. Make a static library. * Also rawspeed needs to unbundle pugixml * Looking at previous openstack uid/gids we wouldn't have approved any of them, so look at filing a FESCo ticket to see if we should pass a lot more of these that don't really need it. Action Items, by person ----------------------- * **UNASSIGNED** * Rawspeed is way too big/active to be a copylib. Make a static library. * Also rawspeed needs to unbundle pugixml * Looking at previous openstack uid/gids we wouldn't have approved any of them, so look at filing a FESCo ticket to see if we should pass a lot more of these that don't really need it. People Present (lines said) --------------------------- * geppetto (110) * tibbs|w (84) * Rathann (32) * tomspur (19) * zodbot (9) * orionp (6) * Corey84 (1) * tibbs (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Thursday's FPC Meeting (2015-07-08 16:00 UTC)
by James Antill 08 Jul '15

08 Jul '15

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-07-08 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-07-08 10:00 Wed US/Pacific PDT 2015-07-08 13:00 Wed US/Eastern EDT 2015-07-08 17:00 Wed UTC <- 2015-07-08 18:00 Wed Europe/London BST 2015-07-08 19:00 Wed Europe/Paris CEST 2015-07-08 19:00 Wed Europe/Berlin CEST 2015-07-08 22:30 Wed Asia/Calcutta IST ------------------new day---------------------- 2015-07-09 01:00 Thu Asia/Singapore SGT 2015-07-09 01:00 Thu Asia/Hong_Kong HKT 2015-07-09 02:00 Thu Asia/Tokyo JST 2015-07-09 03:00 Thu Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 = New business = #topic #550 Darktable and Rawspeed internal library .fpc 550 https://fedorahosted.org/fpc/ticket/550 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 1

Packages without a dist tag
by Martin Krizek 07 Jul '15

07 Jul '15

According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing? The reason why I am asking is that we'd like to know if Taskotron can count on NVR's to have a dist tag in them. Thanks! Martin [1] https://fedoraproject.org/wiki/Packaging:DistTag [2] $ repoquery -qa --disablerepo=\* --enablerepo=fedora --enablerepo=fedora-updates | sort | grep -v -F '.fc' bbkeys-0:0.9.0-20.x86_64 bouml-doc-0:4.3.2-9.noarch compat-libgfortran-41-0:4.1.2-45.i686 compat-libgfortran-41-0:4.1.2-45.x86_64 compat-libstdc++-296-0:2.96-146.1.i686 compat-libstdc++-33-0:3.2.3-68.12.i686 compat-libstdc++-33-0:3.2.3-68.12.x86_64 csmash-0:0.6.6-29.x86_64 fedora-package-config-apt-0:16.00-6.noarch fedora-release-0:22-1.noarch fedora-release-cloud-0:22-1.noarch fedora-release-server-0:22-1.noarch fedora-release-workstation-0:22-1.noarch fedora-repos-0:22-1.noarch fedora-repos-rawhide-0:22-1.noarch generic-release-0:22-0.4.noarch generic-release-cloud-0:22-0.4.noarch generic-release-nonproduct-0:22-0.4.noarch generic-release-notes-0:22-0.4.noarch generic-release-server-0:22-0.4.noarch generic-release-workstation-0:22-0.4.noarch gkrellm-aclock-0:0.3.4-14.x86_64 gkrellm-moon-0:0.6-16.x86_64 gnome-screensaver-frogs-0:0.2-13.noarch gtweakui-0:0.4.0-16.x86_64 kcbench-0:0.3-12.1.noarch kcc-0:2.3-37.x86_64 lmarbles-0:1.0.7-19.x86_64 mj-0:1.14-1.x86_64 oflb-riordonfancy-fonts-0:4-10.noarch python-autopep8-0:0.9.2-1.noarch python-ogg-0:1.3-21.x86_64 python-ogg-devel-0:1.3-21.i686 python-ogg-devel-0:1.3-21.x86_64 python-vorbis-0:1.5-0.15.a.x86_64 reinteract-0:0.5.9-10.noarch sbd-0:1.2.1-1.x86_64 shim-0:0.8-8.x86_64 torcs-data-0:1.3.3-5.noarch torcs-data-cars-extra-0:1.3.3-5.noarch torcs-data-tracks-dirt-0:1.3.3-5.noarch torcs-data-tracks-oval-0:1.3.3-5.noarch torcs-data-tracks-road-0:1.3.3-5.noarch websec-0:1.9.0-16.1.noarch wvs-data-0:0.0.20020219-11.noarch xhtml1-dtds-0:1.0-20020801.11.noarch xml2dict-0:0-0.7.2008.6.1.noarch xmms-acme-0:0.4.3-18.x86_64 xmms-arts-0:0.7.1-16.x86_64 xmms-lirc-0:1.4-21.x86_64 xmms-skins-1:1.2.10-28.noarch xmms-speex-0:0.9.1-21.x86_64

14 31

dangling symlink vs file dependencies
by Vít Ondruch 03 Jul '15

03 Jul '15

Hi, I am trying to update rubygem-apipie-rails and on that occasion, I'm going to unbundle the jquery. I did that by specifying "Requires: js-jquery1" and replacing the original file by symlink. And now rpmlint complains: rubygem-apipie-rails.noarch: W: dangling-symlink /usr/share/gems/gems/apipie-rails-0.3.4/app/public/apipie/javascripts/bundled/jquery-1.7.2.js /usr/share/javascript/jquery/1/jquery.js The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain. I could resolve this by "Requires: %{_jsdir}/jquery/1/jquery.js" and I'd love to do it, but this practice is discouraged by guidelines. Now I am wondering: 1) Is this reasonable to use the file dependnecy in this case, although it is outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin directories? 2) Does this reasoning: "Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency." still holds with recent move to DNF? Isn't time to drop this paragraph? Isn't this "large xml" downloaded anyway for some reason? Do we know what is the real benefit, if there is some? Thanks Vít [1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies

6 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2015