ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ltib] Re: Found issue relating to xorg-x11-proto-devel.spec and xextpro


From: Stuart Hughes
Subject: [Ltib] Re: Found issue relating to xorg-x11-proto-devel.spec and xextproto-7.0.2.tar.bz2
Date: Sat, 13 Nov 2010 18:54:09 +0000
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Rodney,

I have uploaded the missing file referenced by xorg-x11-proto-devel.spec
so your build should now work (at least for that package).

There are 2 ways that xextproto can be provided, either as an individual
package (when building Kdrive) or as part of a combo package provided by
xorg-x11-proto-devel.spec when building the full (and experimental) full
X server.

Because xorg-x11-proto-devel.spec is actually imported from
xorg-x11-proto-devel-7.3-12.fc9.src.rpm (Fedora 9), I'd like to leave
this .spec file as-is.  The other version came into existence when X was
 originally provided as split-out packages by ProFUSION.

Regards, Stuart


Rodney Lott wrote:
> Stuart:
> 
> I just ran into the xextproto issue again and I think I found what was
> causing it:
> 
> address@hidden:~/doodles/ltib-10-1-1a-sv$ find . | xargs grep xextproto
> ...
> ./dist/lfs-5.1/xorg-x11-proto-devel/xorg-x11-proto-devel.spec:Source19       
> : ftp://ftp.x.org/pub/individual/proto/xextproto-7.0.2.tar.bz2
> 
> It appears that the xorg-x11-proto-devel.spec file is referencing a
> xextproto-7.0.2.tar.bz2 file, which is why I am getting the error:
> 
> Processing: xorg-x11-proto-devel
> ==================================
> Build path taken because: no prebuilt rpm,
> Testing network connectivity for gpp
> OK GPP: is available
> Try xextproto-7.0.2.tar.bz2.md5 from the GPP
> Read error (Connection timed out) in headers.
> Try xextproto-7.0.2.tar.bz2 from the GPP
> http://bitshrine.org/gpp/xextproto-7.0.2.tar.bz2:
> 11:19:35 ERROR 404: Not Found.
> Can't get: xextproto-7.0.2.tar.bz2 at ./ltib line 802.
> 
> I think if you are wanting to lock things down at the X.Org 7.3 release,
> maybe the best solution would be to change all the URL's in the Source
> lines to use X11R7.3/src/ in place of individual.  In this way, you
> would not have to change the spec file that much and it would find the
> packages as expected.
> 
> I temporarily changed the xorg-x11-proto-devel.spec file and but I am
> still getting the same error.  I am not sure why it is trying to find
> the package in the GPP, when the Source line specifies a full URL. 
> 
> Rodney
> 
> -----Original Message-----
> From: Stuart Hughes [mailto:address@hidden
> Sent: Thu 11/11/2010 2:57 PM
> To: Rodney Lott
> Cc: address@hidden
> Subject: Re: [Ltib] Problems with libxslt
> 
> Hi Rodney,
> 
> The tarball is not the latest, however it's upgradable, if you do this:
> 
> cd ltib-10-1-1a-sv
> cvs up -dP
> 
> However I digress as the reference you have is incorrect, are you using
> what you downloaded? did you modify it?
> 
> Check the following: dist/lfs-5.1/xextproto/xextproto.spec
> 
> Even the older ltib-10-1-1a-sv for me shows:
> 
> Summary         : Xext proto
> Name            : xextproto
> Version         : 7.0.3
> ...
> Source          : %{name}-%{version}.tar.bz2
> 
> So I would not expect it to try to fetch xextproto-7.0.2.tar.bz2
> 
> Please investigate and let me know what you find.
> 
> Regards, Stuart
> 
> 
> Rodney Lott wrote:
>> Hi, Stuart.
>>
>> The latest and greatest tarball is working just as well if not better
>> than the Freescale LTIB.  Thanks for the help.  I had to make sure to
>> install the following Debian packages:
>>
>> libwww-perl (needed in general)
>> xlstproc (needed to build libxslt)
>>
>> I was about to built the xorg-x11-proto-devel package and it reports
>> that the package is not found in the GPP:
>>
>> Try xextproto-7.0.2.tar.bz2 from the GPP
>> http://bitshrine.org/gpp/xextproto-7.0.2.tar.bz2:
>> 09:54:56 ERROR 404: Not Found.
>> Can't get: xextproto-7.0.2.tar.bz2 at ./ltib line 794.
>>
>> Is the xextproto-7.0.2.tar.bz2 still available?  Please advise.
>>
>> Rodney Lott
>> R&D Design Engineer
>> Evertz Microsystems Ltd.
>> 5288 John Lucas Drive
>> Burlington, ON
>> L7L 5Z9
>> Phone: (905) 335-3700 x. 374
>> Toll Free: (877) 995-3700
>> Fax: (905) 335-0909
>>
>>
>>
>> -----Original Message-----
>> From: address@hidden [mailto:address@hidden
>> Sent: Wed 11/10/2010 12:42 PM
>> To: Rodney Lott
>> Cc: address@hidden
>> Subject: Re: [Ltib] Problems with libxslt
>>
>> Hi Rodney,
>>
>> Unless you're actually getting support, it may be worth thinking about
>> updating to the public CVS stuff.  Essentially even if the BSP specific
>> parts have not been updated, you'd get all the tool and other userspace
>> updates, which would likely solve some issues.
>>
>> If you just want to try to fix what you have (and that maybe the best if
>> you just need to get something working), do:
>>
>> find rootfs -name \*.la
>>
>> If there are any .la files in the rootfs, they can screw up the cross
>> compile and cause host library leakage.
>>
>> If find them, delete them.  Note the name of them though as this will
>> indicate which package they came from (because a re-build of that package
>> will put them back).  You should then ideally update the package's .spec
>> files to remove them from the package (example in existing .spec files,
>> grep for .la)
>>
>> Regards, Stuart
>>
>>
>>> Hello, Stuart.
>>>
>>> I am trying to build the libxslt and various xorg related packages
> using a
>>> LTIB BSP from Freescale for the MPC-8641HPCN (i.e.
>>> MPC8641DHPCN_20080118_Minimal-ltib.iso).  I was experiencing the same
>>> symptoms that Rogério de Souza Moraes submitted in the mailing list post
>>> on Aug 25, 2009.  I added the changes that are reflected in the patch to
>>> my own BSP and built it, but I am getting linking problems he was
> getting:
>>>
>>> /usr/lib/libxml2.so: could not read symbols: File in wrong format
>>>
>>> I am building using a Debian Etch VM and I have attached the full error
>>> output.  It appears that even though sys_lib_search_path_spec doesn't
> have
>>> /usr/lib in the search path, that it is still setting /usr/lib using its
>>> rpath flag.  I am going to try to figure out a way to fix this, and I
> will
>>> send you a patch of what I did.  If you happen to know of anything that
>>> could help me out, I would appreciate it.  I know I am using an old
>>> version of LTIB (since that is the one that Freescale supports :-<).
>>>
>>> Thanks in advance.
>>>
>>> Rodney Lott
>>> R&D Design Engineer
>>> Evertz Microsystems Ltd.
>>> 5288 John Lucas Drive
>>> Burlington, ON
>>> L7L 5Z9
>>> Phone: (905) 335-3700 x. 374
>>> Toll Free: (877) 995-3700
>>> Fax: (905) 335-0909
>>>
>>>
>>>
>>
>>
>>
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]