Custom Query (325 matches)


Show under each result:

Results (43 - 45 of 325)

Ticket Resolution Summary Owner Reporter
#76 fixed spec: Pull sources directly from SVN/GIT dmik

Currently, for many packages the logic of obtaining the sources to build the package is like this:

  1. Take the original vendor source archive.
  2. Generate an OS/2 diff from SVN/GIT between the corresponding vendor branch and the corresponding revision of the trunk.
  3. Apply the diff to the source tree from 1.
  4. Pack the archive from 1. and the diff from 2. in the source RPM.

This approach has several problems:

  1. You need to find and download the right source archive and generate the right diff each time you want to make a new RPM package. This is kind of double work since both the source and the diff are already in the repo, matched and merged.
  2. The information about the exact SVN/GIT commit the sources are taken from is lost. This makes it hard to tell which state of the source tree the given RPM release represents. It's therefore easy to mess things up when there are too many packages to maintain.

I have a better solution which I already tested on a small which package. In short, the logic looks like this:

  1. Add two variables to .spec: svn_url and svn_rev which point to the correct SVN branch and revision of the source tree to build (including all necessary OS/2 patches etc).
  2. In the %prep section, check for the presence of the ZIP with the given revision in SRCS and if not there, check it out right from SVN, then pack and put to SRCS.
  3. Proceed further as usual.

For GIT, use a similar logic but with the appropriate variables git_url and git_commit and respective commands.

This way, no duplication takes place, no manual work is needed and it's always clear which revision the given RPM represents. This simplifies package managing a lot.

The .spec code for this is very simple, these are the corresponding parts from which may be used as a template:

%define svn_url
%define svn_rev     733

Source: %{name}-%{version}-r%{svn_rev}.zip
%if %(sh -c 'if test -f "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip" ; then echo 1 ; else echo 0 ; fi')
%setup -q
%setup -n "%{name}-%{version}" -Tc
svn export -r %{svn_rev} %{svn_url} . --force
rm -f "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip"
(cd .. && zip -SrX9 "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip" "%{name}-%{version}")

I suggest to use this approach for all programs for which we maintain a SVN or a GIT repo (i.e. everything from, for instance).

#77 fixed 'No module named urlgrabber' after 'yum update python' Silvan Scherrer Andib

After I did a 'yum update python' I always get -

{1}[m:\] yum update
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named urlgrabber

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.6 (default, Apr  7 2014, 18:19:49)
[GCC 4.7.3]

If you cannot solve this problem yourself, please go to
the yum faq at:

Other packages are also updated but don't know which. Is there a log somewhere?

#80 fixed The Perl RPM package doesn't actually contain any Perl dbanet

[C:\]yum install perl netlabs-rel 100% |=========================| 1.3 kB 00:00 Setting up Install Process Package perl-5.10.0-3.oc00.i386 already installed and latest version Nothing to do

[C:\]perl SYS1041: The name perl is not recognized as an internal or external command, operable program or batch file.

Note: See TracQuery for help on using queries.