Hi,
Any ideas or thoughts on how to get rid of these new daily warning mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount of work and not going to happen any time soon unless someone kindly volunteers to work on it.)
Is there a white list or something this can be added to?
Thanks, Jens
On Wed, 2008-09-17 at 20:25 -0400, Jens Petersen wrote:
Any ideas or thoughts on how to get rid of these new daily warning mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount of work and not going to happen any time soon unless someone kindly volunteers to work on it.)
Is there a white list or something this can be added to?
ifarch the things that depend on it.
Any ideas or thoughts on how to get rid of these new daily warning mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount
of
work and not going to happen any time soon unless someone kindly volunteers to work on it.)
Is there a white list or something this can be added to?
ifarch the things that depend on it.
How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 trees?
Jens
On Thu, 2008-09-18 at 00:49 -0400, Jens Petersen wrote:
How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 trees?
ExcludeArch
Jesse Keating wrote:
On Thu, 2008-09-18 at 00:49 -0400, Jens Petersen wrote:
How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 trees?
ExcludeArch
ExcludeArch is odd, and is distinctly tied to the build. Note that only srpms get the ExcludeArch/BuildArchs/ExclusiveArch data in their headers; the built rpms do not have this data.
While certain tools might theoretically be able to look up the matching srpm, check this data, and enforce it in some way for the built rpms, I don't believe there is any way to signal such restrictions only for a sub-package. In any case, such use seems a little fragile and sketchy to me.
I'm not that familiar with Pungi's capabilities. Can it be told to special-case situations like this with a config?
If Pungi is performing the roundabout ExcludeArch lookup I described above, then you might need to split the arch-limited subpackage into its own srpm in order to take advantage of that. I'm not sure if that is any better for you than moving the package away from noarch.
On Mon, 2008-09-22 at 17:06 -0400, Mike McLean wrote:
While certain tools might theoretically be able to look up the matching srpm, check this data, and enforce it in some way for the built rpms, I don't believe there is any way to signal such restrictions only for a sub-package. In any case, such use seems a little fragile and sketchy to me.
I'm not that familiar with Pungi's capabilities. Can it be told to special-case situations like this with a config?
Hrm, I need to look up what mash does again, as mash does notice and not put ExcludeArch packages (even noarch ones) where they don't belong. But you're right, it may be on an srpm level not a subpackage level.
buildsys@lists.fedoraproject.org