python34 packages for EPEL
by Orion Poplawski
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_Ma...
%{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
8 years, 9 months
Packaging golang for secondary architectures, go-srpm-macros
by Jan Chaloupka
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
8 years, 9 months
Re: [Fedora-packaging] [Guidelines change] Changes to the packaging guidelines
by Stephen Gallagher
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.
8 years, 9 months
Summary/Minutes from today's FPC Meeting (2015-07-09 16:00 - 17:10 UTC)
by James Antill
======================
#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-...
.
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
8 years, 9 months
Schedule for Thursday's FPC Meeting (2015-07-08 16:00 UTC)
by James Antill
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.
8 years, 9 months
Packages without a dist tag
by Martin Krizek
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
8 years, 9 months
dangling symlink vs file dependencies
by Vít Ondruch
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
8 years, 9 months
