osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: Re: unable to compile srpms - msg#00034

List: linux.redhat.rpm.atrpms.devel

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

On Wednesday 24 November 2004 22:35, Robert Hardy wrote:
> > Packaging the macros isn't also a problem, the missing parts really
> > is. As written above, you do have the macros already, and they are
> > part of this thread.
>
> Most users don't care about semantics. Many people are wasting time
> fighting with these unnecessary macros when all they want to do is rebuild
> simple packages. I can't see any valid reason to have a repository full of
> valuable packages that only a small handful of people can rebuild or fix.
> It defeats the whole point of packaged open source software.

To the best of my knowledge, all the macros have been posted on this list over
time. I've rebuilt probably half the ATrpms repo for RHEL3 and Tao Linux
without a problem using them (as well as a number of packages for YDL).

> I haven't used a packaged kernel for anything serious in 10 years. I use a
> stub to keep rpm happy and the rest I do manually. I totally agree that rpm
> based kernels are horrible and cause all sorts of problems, however this is
> completely tangential to the macros disclosure issue and to proper rpm
> building.

Completely tangential and, IMO, a bit off the deep end. I won't argue with you
beyond that, but there's no way in hell I'm putting anything BUT a common,
rpm-installed kernel on all my production machines at work...

> I've been subscribed to atrpms-devel for a good while now, I made notes of
> various peoples attempts to guess what macros atrpms uses, I have partial
> disclosures from atrpms developers and I've reverse engineered many macros.
> Unfortunately, I still don't have enough macros to build many of
> non-kernel packages which should easily compile.

It seems you've missed a number, everything I've got has been on the list. So
I'll just repost them all.

> The major problem people have with atrpms's build setup/repository is that
> it contains large numbers of SRPMS which fail to build due to missing
> custom macros which are completely unnecessary.

The large majority of the SRPMS rebuild just fine if you have the %atrelease
macro alone...

> I can't see how it would hurt to disclose a complete set of macros required
> to use to build non kernel rpms.

Please see the end of this message. I have yet to find a SRPM that didn't
build with the macro set I have.

> Ideally all atrpms packages should either rebuild with stock packages
> installed or explicitedly list their out of distribution dependencies.  As
> it is now many atrpms SRPMS have unspecified build dependancies on
> unreleased data.

The build dependencies are all in the spec files, once you have enough macros,
you're fine.

> A short term simple solution would be a line at the top of each spec
> non-kernel spec file that points to a set of defines a user can include to
> build the SRPMS: ex. http://atrpms.net/rpmmacros

I think that is a fine idea. I think it would help to reduce noise on the
list, and bring up the signal level a bit, as folks that haven't been able to
find all the macros wouldn't have any excuse to not be able to
rebuild/fix/upgrade ATrpms packages. Axel?

> If this really isn't possible how are atrpms developers building those
> packages?

More or less like this:

# rpm -ivh package.src.rpm
# vi /usr/src/redhat/SPECS/package.spec
# rpmbuild -bb /usr/src/redhat/SPECS/package.spec

Seriously, just a few tweaks to spec files, and the vast majority of packages
rebuild on systems without any of the custom macros.

> Please realize that many Linux users do have brains and need to be able
> recompile, upgrade and fix your rpms.

True. And ATrpms would indeed like more people to help out. I'd like to do
more myself. I'll agree that many of the macros are a bit of a nuisance (esp.
when you don't have them), but many are also very necessary to make managing
such a large repository that spans so many distributions doable.


Full-blown macro set:

#---------------------------------------------------------------------
%distversion %(rpm -qf --qf='%{VERSION}' /etc/redhat-release)
%distinitials rh%(grep -i fedora /etc/redhat-release >/dev/null && echo "fc")
%distname %(grep -i fedora /etc/redhat-release >/dev/null && echo "Fedora
Core" || echo "Red Hat Linux")
%disttag %{distinitials}%{distversion}
%disttag2 %(echo %disttag | sed -e's,\\.,_,g')
%atrelease() %1.%{disttag}.jw

%eversion %{?epoch:%{epoch}:}%{version}
%evr %{?epoch:%{epoch}:}%{version}-%{release}

################################################################
%_initdir %{_sysconfdir}/rc.d/init.d
%_varlibdir %{_localstatedir}/lib
%_varcachedir %{_localstatedir}/cache
%_logdir %{_localstatedir}/log
%_rundir %{_localstatedir}/run
%_subsysdir %{_localstatedir}/lock/subsys
%_sysconfigdir %{_sysconfdir}/sysconfig
%_logrotatedir %{_sysconfdir}/logrotate.d

###
################################################################ kernel
# Use in specfiles:
# %kernelmodule foo
# %kerneldesc
# %{_kernel} in depmod, %kaddcustomkernel
# %kmdl_name
# %if %{kmain}
# %kernelconfig, %kreqprov
# %kmdlinstall
# %kernelname

# kflavour access only in lirc, deprecated

%_kernel %(uname -r)
%kmdl_kernelsrcdir /lib/modules/%{_kernel}/build
%kmdl_userland %(test "%{_kernel}" = none && echo 1 || echo 0)
%_kflavour %(echo %{_kernel} | grep -E '(smp|enterprise|bigmem)' | sed
-e's/^.*\\(smp\\|enterprise\\|bigmem\\).*$/\\1/')
%_kversion %(echo %{_kernel} | sed -e's/^\\(.*\\)\\(smp\\|enterprise\\|
bigmem\\).*$/\\1/')
%_krelver %(echo %{_kversion} | sed -e's/-/_/')
%_kname %(echo kernel-%{_kflavour} | sed -e's/-$//')
%_kname2 %(echo kmodule-%{_kflavour} | sed -e's/-$//')
%_kname3 %(echo kmdl-%{_kflavour} | sed -e's/-$//')
%_modflags -include /tmp/atrpms-mykernel-%{_kernel}-%{_target_cpu}.h
-DMODULE -DMODVERSIONS -include %{_kernelsrcdir}/include/linux/modversions.h

# "kernel": the output of "uname -r" of the kernel to build for
# (default: the running one)
# "_kernelsrcdir": The directory of the sources used to build "kernel"
# (default: /lib/modules/%{_kernel}/build)

%kmdl_name kernel-module-%{_kpkgname}-%{_kernel}
%kmdl_nameof() kernel-module-%1-%{_kernel}
%kmdl_namepure kernel-module-%{_kpkgname}
%kmdl_namepureof() kernel-module-%1
#_kmdl_name_old %{_kpkgname}-kmdl-%{_kernel}
#_kmdl_nameof_old() %1-kmdl-%{_kernel}
#_kmdl_name_old %{_kpkgname}-%{_kname3}-%{_kversion}
#_kmdl_nameof_old() %1-%{_kname3}-%{_kversion}
#_kmdl_namepure_old %{_kpkgname}-kmdl
#_kmdl_namepureof_old() %1-kmdl

%_kernelbuildreq %{nil}

%kmdl() \
%{expand:%%global _kpkgname %1} \
%_kernelbuildreq \
%{nil}

%kmdl_parentdependencies\
Requires: %{kmdl_namepure}-%{evr}

%kmdl_dependencies\
Requires: atrpms-kmdl-helper \
#Requires: strictdep-%{_kname}-%{_target_cpu} = %{_kversion}\
Requires: /boot/vmlinuz-%{_kernel}\
Requires: %{_kname} = %{_kversion}, /sbin/depmod, modutils >= 2.4.14\
BuildRequires: %_kernelcompiler\
Provides: %kmdl_namepure-%{evr}\
Provides: %kmdl_namepure-%_kernel = %{evr}\
#\
# backward compatibility foo-kmdl\
Provides: Provides: %{_kpkgname}-%{_kname3}-%{_kversion} = %{evr}
Provides: %{_kpkgname}-kmdl
# backward compatibility with foo-kernel-...\
Provides: %{_kpkgname}-kernel\
%{?_kflavour:Provides: %{_kpkgname}-%{_kname}}\
Provides: %{_kpkgname}-%{_kname}-%{_kversion} = %{evr}\
Provides: %{_kpkgname}-%{_kname}-%{_kversion}-%{_target_cpu} = %{evr}\
# backward compatibility with unversioned kernel-module-foo\
Provides: kernel-module-%{_kpkgname}\
%{?_kflavour:Provides: %{_kname}-module-%{_kpkgname}}\

%_kernelcompiler_rhfc2 /usr/bin/gcc
%_kernelcompiler_rhfc1 /usr/bin/gcc32
%_kernelcompiler_rh9 /usr/bin/gcc
%_kernelcompiler_rh8_0 /usr/bin/gcc
%_kernelcompiler_rh7_3 /usr/bin/gcc

%_kernelcompiler %{expand:%%_kernelcompiler_%{disttag2}}

%kmdl_moduledir /lib/modules/%{_kernel}/updates

%kmdl_config\
export CC=%_kernelcompiler\
#/sbin/mkkerneldoth.atrpms %{_kernel} %{_target_cpu}
> /tmp/atrpms-mykernel-%{_kernel}-%{_target_cpu}.h\
#mkdir -p %{buildroot}%{kmdl_moduledir}

%kmdl_desc\
This package contains the %kmdl_name kernel modules for the Linux kernel
package:\
%{_kname}-%{_kversion}.%{_target_cpu}.rpm.

%_kernelname %{_kname}-%{_kversion}.%{_target_cpu}.rpm

%kmdl_install\
%{_libdir}/atrpms/addcustomkmdl '/lib/modules/`uname -r`/updates'\
depmod -ae -F /boot/System.map-%{_kernel} %{_kernel}

%kmdl_remove\
depmod -ae -F /boot/System.map-%{_kernel} %{_kernel}

#---------------------------------------------------------------------

--
Jarod C. Wilson, RHCE
jcw@xxxxxxxxxxxx

Attachment: pgpQnD6nNln7t.pgp
Description: PGP signature



Thread at a glance:

Previous Message by Date:

Re: Re: unable to compile srpms

On Sun, 21 Nov 2004, Axel Thimm wrote: On Sat, Nov 20, 2004 at 08:08:24PM -0800, Fedor Pikus wrote: If I had the macros, that problem would be solved. I really don't see why you are so opposed to releasing them. But you already posted the macros yourself yesterday on the list (?)! These are the macros, there is nothing more to it. The rest is having the kernel source tree layed out, configured and prepared/deped in advance. This is where the real work is, and what is not covered by macros. Unfortunately that macro file is still incomplete. You keep saying that without the infrastructure they are not as useful as they could be, and lack of cooperation on the part of Fedora maintainers and others does not allow for a seamless solution. I agree that it would be nice, but for whatever reason it's not happening, and you alone cannot make it happen. Fine, you can't give me the solution you'd like, but you can make it a little easier for me to rebuild source RPMs on my own system, if you just posted the macros. What would be the problem with that? It takes probably 1 minute of your time (to post them in a flat file on WWW, not package them as you'd really like as a solution for Joe User), it makes life easier for users like me. Packaging the macros isn't also a problem, the missing parts really is. As written above, you do have the macros already, and they are part of this thread. Most users don't care about semantics. Many people are wasting time fighting with these unnecessary macros when all they want to do is rebuild simple packages. I can't see any valid reason to have a repository full of valuable packages that only a small handful of people can rebuild or fix. It defeats the whole point of packaged open source software. I haven't used a packaged kernel for anything serious in 10 years. I use a stub to keep rpm happy and the rest I do manually. I totally agree that rpm based kernels are horrible and cause all sorts of problems, however this is completely tangential to the macros disclosure issue and to proper rpm building. I've been subscribed to atrpms-devel for a good while now, I made notes of various peoples attempts to guess what macros atrpms uses, I have partial disclosures from atrpms developers and I've reverse engineered many macros. Unfortunately, I still don't have enough macros to build many of non-kernel packages which should easily compile. The major problem people have with atrpms's build setup/repository is that it contains large numbers of SRPMS which fail to build due to missing custom macros which are completely unnecessary. Case in point, I need a recompiled perl-Template-Toolkit for FC3. The build seems to fail due to a series of out of date perl-GD rpms. Due to the cooperation of the major repositories, the only repository with perl-GD packages was atrpms. Of course atrpms's perl-GD pacakages won't rebuild because they need a bunch of undefined macros: %perl_configure etc.. I was able to use cpanflute2 to recreate a buildable package, but that shouldn't have been necessary. I can't see how it would hurt to disclose a complete set of macros required to use to build non kernel rpms. Ideally all atrpms packages should either rebuild with stock packages installed or explicitedly list their out of distribution dependencies. As it is now many atrpms SRPMS have unspecified build dependancies on unreleased data. A short term simple solution would be a line at the top of each spec non-kernel spec file that points to a set of defines a user can include to build the SRPMS: ex. http://atrpms.net/rpmmacros If this really isn't possible how are atrpms developers building those packages? Please realize that many Linux users do have brains and need to be able recompile, upgrade and fix your rpms. Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy <at> webcon <dot> ca GPG Key available

Next Message by Date:

Updated Abstract and Visor Myth themes

Grab the srpms here: http://wilsonet.com/packages/srpms/mythtv-theme-abstract-0.20040910-2.rhfc2.jw.src.rpm http://wilsonet.com/packages/srpms/mythtv-theme-visor-0.16.2-5.rhfc2.jw.src.rpm -- Jarod C. Wilson, RHCE jcw@xxxxxxxxxxxx pgpxmhJUM9Ifv.pgp Description: PGP signature

Previous Message by Thread:

Re: Re: unable to compile srpms

On Sun, 21 Nov 2004, Axel Thimm wrote: On Sat, Nov 20, 2004 at 08:08:24PM -0800, Fedor Pikus wrote: If I had the macros, that problem would be solved. I really don't see why you are so opposed to releasing them. But you already posted the macros yourself yesterday on the list (?)! These are the macros, there is nothing more to it. The rest is having the kernel source tree layed out, configured and prepared/deped in advance. This is where the real work is, and what is not covered by macros. Unfortunately that macro file is still incomplete. You keep saying that without the infrastructure they are not as useful as they could be, and lack of cooperation on the part of Fedora maintainers and others does not allow for a seamless solution. I agree that it would be nice, but for whatever reason it's not happening, and you alone cannot make it happen. Fine, you can't give me the solution you'd like, but you can make it a little easier for me to rebuild source RPMs on my own system, if you just posted the macros. What would be the problem with that? It takes probably 1 minute of your time (to post them in a flat file on WWW, not package them as you'd really like as a solution for Joe User), it makes life easier for users like me. Packaging the macros isn't also a problem, the missing parts really is. As written above, you do have the macros already, and they are part of this thread. Most users don't care about semantics. Many people are wasting time fighting with these unnecessary macros when all they want to do is rebuild simple packages. I can't see any valid reason to have a repository full of valuable packages that only a small handful of people can rebuild or fix. It defeats the whole point of packaged open source software. I haven't used a packaged kernel for anything serious in 10 years. I use a stub to keep rpm happy and the rest I do manually. I totally agree that rpm based kernels are horrible and cause all sorts of problems, however this is completely tangential to the macros disclosure issue and to proper rpm building. I've been subscribed to atrpms-devel for a good while now, I made notes of various peoples attempts to guess what macros atrpms uses, I have partial disclosures from atrpms developers and I've reverse engineered many macros. Unfortunately, I still don't have enough macros to build many of non-kernel packages which should easily compile. The major problem people have with atrpms's build setup/repository is that it contains large numbers of SRPMS which fail to build due to missing custom macros which are completely unnecessary. Case in point, I need a recompiled perl-Template-Toolkit for FC3. The build seems to fail due to a series of out of date perl-GD rpms. Due to the cooperation of the major repositories, the only repository with perl-GD packages was atrpms. Of course atrpms's perl-GD pacakages won't rebuild because they need a bunch of undefined macros: %perl_configure etc.. I was able to use cpanflute2 to recreate a buildable package, but that shouldn't have been necessary. I can't see how it would hurt to disclose a complete set of macros required to use to build non kernel rpms. Ideally all atrpms packages should either rebuild with stock packages installed or explicitedly list their out of distribution dependencies. As it is now many atrpms SRPMS have unspecified build dependancies on unreleased data. A short term simple solution would be a line at the top of each spec non-kernel spec file that points to a set of defines a user can include to build the SRPMS: ex. http://atrpms.net/rpmmacros If this really isn't possible how are atrpms developers building those packages? Please realize that many Linux users do have brains and need to be able recompile, upgrade and fix your rpms. Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy <at> webcon <dot> ca GPG Key available

Next Message by Thread:

Restructuring kernel specfiles for allowing custom kernel rpms and end-user kmdl (re)packaging (was: unable to compile srpms)

On Thu, Nov 25, 2004 at 01:35:44AM -0500, Robert Hardy wrote: > > Packaging the macros isn't also a problem, the missing parts > > really is. As written above, you do have the macros already, and > > they are part of this thread. > > Most users don't care about semantics. Many people are wasting time fighting > with these unnecessary macros when all they want to do is rebuild simple > packages. But the macros are not even half your ticket. You got them, now you aremissing the whole infrastructure of kernel headers/sources preconfigured to do the right thing. See the other parts of the thread to see where the problems are, especially the part of having 1) methods of creating _packaged_ custom kernels with vendor analogon look (i.e. not simply "make rpm"), so they fit into the packging mechanism, and 2) packages providing the outlined kernel headers/sources to have kernel module packages depend upon. > I can't see any valid reason to have a repository full of valuable > packages that only a small handful of people can rebuild or fix. It > defeats the whole point of packaged open source software. I agree, and I'm always happy to see helping hands :) > I've been subscribed to atrpms-devel for a good while now, I made notes of > various peoples attempts to guess what macros atrpms uses, The policy behind not going public with the current set of macros, but sharing them in *-devel lists is that a) they are still in draft (although the interface has stabilized) b) they don't magically make package build, they require a whole infrastructure behind them, that you must provide separately. Most people asking for the macros have compiled a custom kernel, not even packaged (so the kmdl build system would generate kmdl rpms that cannot even satisfy the requirements ...), and think that getting the macros would allow an rpmbuild --rebuild. You need 1) and 2) before having an end-user friendly package rebuild method. Until then you have to do that with manual labour. For attacking both one need to pick a Red Hat kernel specfile and split it into two parts, one that is simply creating the kernel source tree, and another that is depending on this kernel source tree and a .config file to rebuild a flavour/arch of this kernel, along with creating a _separate_ kernel-devel package for this flavour/arch that can be used by kernel module builds. In principle it's not a too difficult task, but it's quite some work to do. -- Axel.Thimm at ATrpms.net pgpFuTv49bj6q.pgp Description: PGP signature
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!