#6184: suitesparse can't be installed in ppc64 el6 buildroots
-----------------------------+------------------------
Reporter: rmattes | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 23 Final | Component: epel
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
I'm running into trouble building GeographicLib in epel6. GeographicLib
requires octave, which in turn requires suitesparse. It looks like
suitesparse was in epel for a while, but got absorbed into rhel at some
point and blocked from the buildroots. Since centos doesn't provide ppc64
packages, the ppc64 octave package in epel now has missing dependencies on
suitesparse libraries and can't be installed in koji.
What's the best way forward for this issue? Is it to:
- Unblock the epel6 suitesparse and make it exclusivearch ppc64?
- Rebuild all of the dependencies of suitesparse to excludearch ppc64?
- Make octave-GeographicLib excludearch ppc64 and ignore the issue
entirely?
Please advise.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6184>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6183: RPMs from rhel-7-workstation-rpms not mentioned in pkg_el7.json
-----------------------------+------------------------
Reporter: robert | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: epel
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
According to my knowledge,
https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json is the
base for checking if a package is already part of RHEL 7 (if it's listed
there it's in RHEL 7). However, the packages libisofs and libburn are not
mentioned there at all, even they are in RHEL 7 (rhel-7-workstation-rpms).
But why?
As result, branching the package for epel7, building and submitting as an
update was possible. Fortunately somebody mentioned in the Bodhi update
that the package is part of CentOS 7 (and thus likely of RHEL 7).
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6183>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6187: glibc32 should be tagged as f23-build
-----------------------------+------------------------
Reporter: mjw | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 23 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Without this package builds, like valgrind, requiring (fake) 32bit glibc
libraries on 64bit arches that are multilib cannot be build because their
BuildRequires fail.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6187>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Hello all,
Now that pungi has been moved to pagure[0], I wanted to bring up a
small proposal to help add to the development cycle for community
contributors, new comers, and even those on the team who do this
regularly to hopefully make lives easier.
First off I've submitted a small contributors README[1] file (which
dgilmore said on irc he'll +1 and merge once a pagure issue is sorted
out to allow it), and I wanted to continue to grow on that and add to
it.
I would like to propose the use of tito[2] for at least development
processes (the tool offers nice features for release management also
but I'd at least like to use it for development/testing). Tito is
already in the Fedora repos and actively maintained upstream, it
allows for simple rpm creation based on the contents of a git repo.
The following is an example of using tito to build an rpm from within
my local branch/clone of pungi (with a lot of output removed for
brevity):
$ tito build --rpm --test
WARNING: unable to lookup latest package tag, building untagged test project
WARNING: rel-eng/packages/pungi doesn't exist in git, using current directory
Building package [pungi-4.0-0.8]
Wrote: /tmp/tito/pungi-git-0.72088e1.tar.gz
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.JUdy4S
+ umask 022
+ cd /tmp/tito/rpmbuild-pungi0I1laX/BUILD
+ cd /tmp/tito/rpmbuild-pungi0I1laX/BUILD
+ rm -rf pungi-git-0.72088e1
+ /usr/bin/gzip -dc
/tmp/tito/rpmbuild-pungi0I1laX/SOURCES/pungi-git-0.72088e1.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd pungi-git-0.72088e1
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.vDb7VM
+ umask 022
+ cd /tmp/tito/rpmbuild-pungi0I1laX/BUILD
+ cd pungi-git-0.72088e1
+ /usr/bin/python setup.py build
......... OUTPUT REMOVED FOR BREVITY .........
Successfully built: /tmp/tito/pungi-4.0-0.8.git.0.72088e1.fc22.src.rpm
/tmp/tito/noarch/pungi-4.0-0.8.git.0.72088e1.fc22.noarch.rpm
The WARNINGs are because I haven't done a 'tito tag' action which
creates a git tag and creates a file in rel-eng/packages/ and stores
versioning information that tracks to a git tag. This is useful to
using tito to auto manage releases and the like but I don't entirely
know that it's necessary for the use case I'm after. I mostly just
like the idea of allowing a developer to easily/quickly build from
their topic branch, install and test.
Also, tito can use mock as the builder for good measure:
$ tito build --builder mock --arg mock=fedora-rawhide-x86_64 --test --rpm
## NOTE: This actually showed me that we're missing BuildRequires: in
the pungi spec file :)
All that would re required to add this functionality would be the
following patch to the git repo:
diff --git a/rel-eng/packages/.readme b/rel-eng/packages/.readme
new file mode 100644
index 0000000..8999c8d
--- /dev/null
+++ b/rel-eng/packages/.readme
@@ -0,0 +1,3 @@
+the rel-eng/packages directory contains metadata files
+named after their packages. Each file has the latest tagged
+version and the project's relative directory.
diff --git a/rel-eng/tito.props b/rel-eng/tito.props
new file mode 100644
index 0000000..eab3f19
--- /dev/null
+++ b/rel-eng/tito.props
@@ -0,0 +1,5 @@
+[buildconfig]
+builder = tito.builder.Builder
+tagger = tito.tagger.VersionTagger
+changelog_do_not_remove_cherrypick = 0
+changelog_format = %s (%ae)
Beyond that I would also add more notes and documentation to the pungi
contributors README file.
In the current proposal, this leaves tito as an optional tool that can
be used or ignored at the discretion of the individual contributor
since I'm not suggesting we use it for release management but simply
for dev/test purposes.
I look forward to feedback and if this is something that is agreed
upon, I already have a topic branch ready for a pull request[3]
Thank you,
-AdamM
[0] - https://pagure.io/pungi
[1] - https://pagure.io/pungi/pull-request/2
[2] - https://github.com/dgoodwin/tito
[3] - https://pagure.io/fork/maxamillion/pungi/branch/add_tito