DongInn,
I've uploaded a test src.rpm, could you try to rebuild it on fc18 with --target
noarch but without --defile '%_libdir /usr/lib64'.
I haven't changed the version yet, I need to check 1st that it works.
Thanks a lot for your great help.
Regards,
Olivier.
PS: If it fails to build can you give me also the output of
rpmbuild --target noarch --eval '%_target_cpu'
----- Mail original -----
> De: "olivier lahaye1" <olivier.laha...@free.fr>
> À: oscar-devel@lists.sourceforge.net
> Envoyé: Vendredi 12 Avril 2013 11:04:29
> Objet: [Oscar-devel] Need info on fc-18-x86_64 WAS: Re: systemimager
> should build.
> DongInn,
> Can you give me the output of this command on fc-18-x86_64:
> rpmbuild --target noarch --eval '%(arch) %_build_arch %_libdir'
> I need that to adapt the spec file so it works everywhere.
> The last solution would be to put the correct Requires per distro,
> but it's bad as it's not easy to read:
> %if 0%{?el5}
> BuildRequires: glibc-devel
> %endif
> %if 0%{?el6}
> BuildRequires: glibc-devel glibc-static
> %endif
> %if 0%{?fedora} > 15
> BuildRequires: glibc-devel glibc-static
> %endif
> And so on for suse, mandriva....
> Regards,
> Olivier.
> ----- Mail original -----
> > De: "olivier lahaye1" <olivier.laha...@free.fr>
>
> > À: oscar-devel@lists.sourceforge.net
>
> > Envoyé: Vendredi 12 Avril 2013 10:10:43
>
> > Objet: Re: [Oscar-devel] RE : [PROVENANCE INTERNET] RE : RE : RE :
> > systemimager should build.
>
> > Hi DongInn,
>
> > Cool to see that you've found a workaround. In the long term, we
> > should not use this though, as it prevent a build for 32bits for
> > example.
>
> > Fedora sets this so if the noarch rpm is installed on a 32bits
> > machine, the %_libdir points to something that exists which is
> > logic
> > except that in the case of systemimager, it's only used for
> > building
> > something that is not implicitly intended to run on the arch it was
> > built on....
>
> > I'll look at the systemimager spec file and I'll try to fix things
> > there.
>
> > (I also have issues to generate 32bits boot and initrd noarch
> > packages. linux32 rpmbuild --target i386 does build x86_64 binaries
> > even-though it triggers 32bit deps install.....)
>
> > Regards,
>
> > Olivier.
>
> > PS: Did you test the new yume?
>
> > ----- Mail original -----
>
> > > De: "DongInn Kim" <di...@cs.indiana.edu>
> >
>
> > > À: oscar-devel@lists.sourceforge.net
> >
>
> > > Envoyé: Jeudi 11 Avril 2013 23:18:40
> >
>
> > > Objet: Re: [Oscar-devel] RE : [PROVENANCE INTERNET] RE : RE : RE
> > > :
> > > systemimager should build.
> >
>
> > > Hi Olivier,
> >
>
> > > I think I fixed the problem of getting wrong _libdir value by
> > > assigning the _libdir value in the systemimager.cfg file.
> >
>
> > > > [17:13] fedora: systemimager $ cat systemimager.cfg
> > >
> >
>
> > > > source = wget,
> > > > http://svn.oscar.openclustergroup.org/pkgs/downloads/systemimager-4.3.0-0.10.src.rpm
> > >
> >
>
> > > > config = --define '_libdir /usr/lib64'
> > >
> >
>
> > > This config value is used in Packager.pm to setup the
> > > "RPMBUILDOPTS"
> > > environment variable which actually generates the rpmbuild
> > > command
> > > line with the proper options in /usr/bin/build_rpms.
> >
>
> > > I checked in this fix in r9868.
> >
>
> > > Regards,
> >
>
> > > --
> >
>
> > > - DongInn
> >
>
> > > On Apr 11, 2013, at 12:13 PM, olivier.laha...@free.fr wrote:
> >
>
> > > > Were does it sets the _libdir to /usr/lib ? In the spec file
> > > > (%ifarch) or in rpmbuild?
> > >
> >
>
> > > > if it's in rpmbuild, this is a behaviour change between fc17
> > > > and
> > > > fc18.....
> > >
> >
>
> > > > I'll need to change the package then....It may be a problem in
> > > > some
> > > > package in the future.
> > >
> >
>
> > > > If it's in the spec file, it should be easy to fix. forcing the
> > > > variable using --define '%_libdir %{_prefix}/lib64' is IMHO
> > > > unsure
> > > > as some system variables are overridden.
> > >
> >
>
> > > > The problem is that in the past, rpmbuild was basic and was
> > > > unable
> > > > to
> > > > build a multiarch rpm. If the main package was a arch package,
> > > > then
> > > > a subpackage (even if BuildArch:noarch was specified) was build
> > > > as
> > > > a
> > > > %arch.rpm.
> > >
> >
>
> > > > Thus, the trick was to protect subpackage with %ifarch noarch
> > > > and
> > > > build using rpmbuild --target x86_64,noarch xxx.spec for
> > > > example.(2
> > > > build triggered).
> > >
> >
>
> > > > torque (if I'm correct) is such a package for example. If you
> > > > build
> > > > it using rpmbuild -bb torque.rpm, 2 noarch packages are not
> > > > build
> > > > (doc, ...).
> > >
> >
>
> > > > Now, if a rpm wants sub packages of different types it's
> > > > possible.
> > > > just add the correct BuildArch: tag in the sub package and if
> > > > it's
> > > > a
> > > > noarch it'll wuild as such.
> > >
> >
>
> > > > The problem of this change of behaviour may have been
> > > > introduced
> > > > to
> > > > resolve the BuildArch: ix86 where the %_libdir must be
> > > > correctly
> > > > set. It also assumes that noarch libdir is in /usr/lib which is
> > > > somehow correct.
> > >
> >
>
> > > > unfortunately, in some situation (mainly old packages), this
> > > > produces
> > > > inconcistency betwen arch and noarch subpackages. and we've
> > > > just
> > > > hit
> > > > one of them.
> > >
> >
>
> > > > I'll search for a clean solution tomorrow.
> > >
> >
>
> > > > Regards,
> > >
> >
>
> > > > Olivier.
> > >
> >
>
> > > ------------------------------------------------------------------------------
> >
>
> > > Precog is a next-generation analytics platform capable of
> > > advanced
> >
>
> > > analytics on semi-structured data. The platform includes APIs for
> > > building
> >
>
> > > apps and a phenomenal toolset for data science. Developers can
> > > use
> >
>
> > > our toolset for easy data analysis & visualization. Get a free
> > > account!
> >
>
> > > http://www2.precog.com/precogplatform/slashdotnewsletter
> >
>
> > > _______________________________________________
> >
>
> > > Oscar-devel mailing list
> >
>
> > > Oscar-devel@lists.sourceforge.net
> >
>
> > > https://lists.sourceforge.net/lists/listinfo/oscar-devel
> >
>
> > ------------------------------------------------------------------------------
>
> > Precog is a next-generation analytics platform capable of advanced
>
> > analytics on semi-structured data. The platform includes APIs for
> > building
>
> > apps and a phenomenal toolset for data science. Developers can use
>
> > our toolset for easy data analysis & visualization. Get a free
> > account!
>
> > http://www2.precog.com/precogplatform/slashdotnewsletter
>
> > _______________________________________________
>
> > Oscar-devel mailing list
>
> > Oscar-devel@lists.sourceforge.net
>
> > https://lists.sourceforge.net/lists/listinfo/oscar-devel
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for
> building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free
> account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Oscar-devel mailing list
> Oscar-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
