Re: using a macro in ExclusiveArch
On 2012-01-05, Björn Persson bj...@xn--rombobjrn-67a.se wrote: The simplest solution seems to be to let SIG members co-maintain redhat-rpm-config. Did you have some more elaborate solution in mind? My idea is to let SIGs to maintain their specific standalone packages injecting files into /etc/rpm and to ask redhat-rpm-config owner to require the SIG-maintaned packages. This would allow SIGs to tune build-root macros without disturbing redhat-rpm-config. On the other hand it would weaken surveillance over the changes. There is also processing advantage---each SIG has different policy who is core SIG developer (usually co-maintainers of the main intrepreter/compiler). My solution does not hassle redhat-rpm-config with these problems. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
On Thu, 5 Jan 2012 13:08:21 +0100, BP (Björn) wrote:
I need some advice on how to fix this build failure. The GtkAda package
builds
fine in Mock, but fails in Koji with the error No matching arches were
found:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3621310
Several Ada packages need an ExclusiveArch directive to prevent attempts to
build them on secondary architectures where GNAT isn't available. I thought
it
would be a good idea to keep the list of architectures in a macro to get
closer to a single point of truth. I defined the macro in
/etc/rpm/macros.gnat
in the package fedora-gnat-project-common:
%GNAT_arches %{ix86} x86_64 ia64 ppc ppc64 alpha
GtkAda uses the macro like this:
BuildRequires: fedora-gnat-project-common = 3.3
ExclusiveArch: %{GNAT_arches}
I *think* the reason why the build fails in Koji might be that Koji reads the
ExclusiveArch directive to figure out which build server should handle the
build, and it doesn't pull in buildrequired packages before doing that, so
GNAT_arches is undefined. Does this analysis seem correct?
Yes.
$ rpm -qp GtkAda-2.18.0-2.fc17.src.rpm --qf %{exclusivearch}\n
%{GNAT_arches}
If so, what should I do about it? Should macros simply not be used in the
ExclusiveArch directive? I see ghc_arches, mono_arches and ocaml_arches in
other files in /etc/rpm. Those files all belong to redhat-rpm-config. Would
this
work if GNAT_arches were defined in redhat-rpm-config instead of fedora-gnat-
project-common?
Sounds plausible, because with redhat-rpm-config in the buildroot, the
src.rpm would be fine with a defined macro.
Is it significant that all three filenames end in -srpm? Or
should this be considered a bug in Koji?
I think the -srpm in there is not important.
$ ls /etc/rpm
macros.color macros.fjava macros.mono-srpm macros.systemd
macros.distmacros.gconf2macros.ocaml-srpm macros.texlive
macros.emacs macros.ghc-srpm macros.perl
macros.faldor macros.jpackage macros.prelink
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
I've already written suggestion to redhat-rpm-config owner to plug dependencies maintained by particular SIGs (like perl or ada) to get them controll over macros in minimal build root. However he has never replied. I think this is inevitabla to allow smooth upgrades and boot-strapping of big package ecosystems (like perl or ada). If you are interrested in this area, I can resend the (quite long) mail to fedora-devel, where we can discuss more and get some resolution. E.g. a ticket to FPC/FESCo to allow/force this solution. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
El Thu, 5 Jan 2012 13:22:34 +0100
Michael Schwendt mschwe...@gmail.com escribió:
On Thu, 5 Jan 2012 13:08:21 +0100, BP (Björn) wrote:
I need some advice on how to fix this build failure. The GtkAda
package builds fine in Mock, but fails in Koji with the error No
matching arches were found:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3621310
Several Ada packages need an ExclusiveArch directive to prevent
attempts to build them on secondary architectures where GNAT isn't
available. I thought it would be a good idea to keep the list of
architectures in a macro to get closer to a single point of truth.
I defined the macro in /etc/rpm/macros.gnat in the package
fedora-gnat-project-common:
%GNAT_arches %{ix86} x86_64 ia64 ppc ppc64 alpha
GtkAda uses the macro like this:
BuildRequires: fedora-gnat-project-common = 3.3
ExclusiveArch: %{GNAT_arches}
I *think* the reason why the build fails in Koji might be that Koji
reads the ExclusiveArch directive to figure out which build server
should handle the build, and it doesn't pull in buildrequired
packages before doing that, so GNAT_arches is undefined. Does this
analysis seem correct?
Yes.
$ rpm -qp GtkAda-2.18.0-2.fc17.src.rpm --qf %{exclusivearch}\n
%{GNAT_arches}
If so, what should I do about it? Should macros simply not be used
in the ExclusiveArch directive? I see ghc_arches, mono_arches and
ocaml_arches in other files in /etc/rpm. Those files all belong to
redhat-rpm-config. Would this work if GNAT_arches were defined in
redhat-rpm-config instead of fedora-gnat- project-common?
Sounds plausible, because with redhat-rpm-config in the buildroot, the
src.rpm would be fine with a defined macro.
Is it significant that all three filenames end in -srpm? Or
should this be considered a bug in Koji?
I think the -srpm in there is not important.
$ ls /etc/rpm
macros.color macros.fjava macros.mono-srpm macros.systemd
macros.distmacros.gconf2macros.ocaml-srpm macros.texlive
macros.emacs macros.ghc-srpm macros.perl
macros.faldor macros.jpackage macros.prelink
the -srpm is there because the langugaes can provide other language
specific macros in a file without -srpm the -srpm is to define that
the macros are needed at srpm creation time and are slightly special
because of it. the idea of them is to make it pretty easy to add a arch
to a language by modifying one place rather than hundreds.
by having the macros.ghc-srpm a ghc-common or ghc-filesystem or some
such package can provide macros.ghc which has macros for rpm createion
and not for srpm creation
Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
On Thu, 5 Jan 2012 08:11:07 -0600, DG (Dennis) wrote: Is it significant that all three filenames end in -srpm? Or should this be considered a bug in Koji? I think the -srpm in there is not important. $ ls /etc/rpm macros.color macros.fjava macros.mono-srpm macros.systemd macros.distmacros.gconf2macros.ocaml-srpm macros.texlive macros.emacs macros.ghc-srpm macros.perl macros.faldor macros.jpackage macros.prelink the -srpm is there because the langugaes can provide other language specific macros in a file without -srpm the -srpm is to define that the macros are needed at srpm creation time and are slightly special because of it. the idea of them is to make it pretty easy to add a arch to a language by modifying one place rather than hundreds. by having the macros.ghc-srpm a ghc-common or ghc-filesystem or some such package can provide macros.ghc which has macros for rpm createion and not for srpm creation So, it's just a namespace issue, a slightly more unique file name, isn't it? To avoid file conflicts. RPM loads all files named macros.* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
Thanks Michael and Dennis! I'll try to get a macros.gnat-srpm into redhat-rpm- config. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
Petr Pisar wrote: I've already written suggestion to redhat-rpm-config owner to plug dependencies maintained by particular SIGs (like perl or ada) to get them controll over macros in minimal build root. However he has never replied. I think this is inevitabla to allow smooth upgrades and boot-strapping of big package ecosystems (like perl or ada). If you are interrested in this area, I can resend the (quite long) mail to fedora-devel, where we can discuss more and get some resolution. E.g. a ticket to FPC/FESCo to allow/force this solution. In the Ada case it's really the GCC maintainers who decide what architectures to build GNAT on, but it would indeed be useful if we who work on Ada packages could adjust the list of architectures ourselves. The simplest solution seems to be to let SIG members co-maintain redhat-rpm-config. Did you have some more elaborate solution in mind? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
El Thu, 5 Jan 2012 15:20:09 +0100 Michael Schwendt mschwe...@gmail.com escribió: On Thu, 5 Jan 2012 08:11:07 -0600, DG (Dennis) wrote: Is it significant that all three filenames end in -srpm? Or should this be considered a bug in Koji? I think the -srpm in there is not important. $ ls /etc/rpm macros.color macros.fjava macros.mono-srpm macros.systemd macros.distmacros.gconf2macros.ocaml-srpm macros.texlive macros.emacs macros.ghc-srpm macros.perl macros.faldor macros.jpackage macros.prelink the -srpm is there because the langugaes can provide other language specific macros in a file without -srpm the -srpm is to define that the macros are needed at srpm creation time and are slightly special because of it. the idea of them is to make it pretty easy to add a arch to a language by modifying one place rather than hundreds. by having the macros.ghc-srpm a ghc-common or ghc-filesystem or some such package can provide macros.ghc which has macros for rpm createion and not for srpm creation So, it's just a namespace issue, a slightly more unique file name, isn't it? To avoid file conflicts. RPM loads all files named macros.* correct. just to avoid file namespace conflicts Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
