[Ltib] Re: Found issue relating to xorg-x11-proto-devel.spec and xextproto-7.0.2.tar.bz2

[Stuart Hughes]

Hi Rodney,

Thanks for the patch.  Ironically there used to be something very
similar (in spirit) to this in the early days.

The problem with this approach (and I think why I removed it in the
first place) is that in the loop, the proxy mode is not related to the
GPP or PPP.  So really you should do the direct attempt after all the
GPP/PPP stuff has been tried and exhausted.  Then the question is
whether the pull from the URL should be with/without proxies turned on/off.

I guess the "correct" thing would be to have a url_proxy entry in the
.ltibrc file and used that.  The issue with this is that it starts to
get a bit contrived/complicated for people to figure out.  The
alternative may be to say that the GPP proxy setting is likely to be the
same as that for the direct URL access and so to just use that.

I'll think about this for a bit, but in the mean time I'd be happy to
take opinions about what is the right balance between correctness versus
complexity.

Regards, Stuart


Rodney Lott wrote:
> Thanks, Stuart.
> 
> That sounds good.  I have reverted the spec file to the checked-in version. 
> 
> I added the following logic that would as a last ditch effort try to
> download the package using the original URL:
> 
> Index: bin/Ltibutils.pm
> ===================================================================
> RCS file: /sources/ltib/ltib/bin/Ltibutils.pm,v
> retrieving revision 1.36
> diff -a -u -r1.36 Ltibutils.pm
> --- bin/Ltibutils.pm    30 Mar 2010 08:33:05 -0000  1.36
> +++ bin/Ltibutils.pm    15 Nov 2010 15:28:43 -0000
> @@ -441,8 +441,15 @@
>          my $pxmode = $cf->{$pp . '_proxy'} ? 'on' : 'off';
>          my $rpath  = $cf->{$pp . '_url'} . "/$file";
>          get_remote($dest, $pxys, $cf->{wget_opts}, $pxmode, $rpath);
> +       # Package not found the GPP or PPP: Use the URL that was supplied
> +       unless( -f $path ) {
> +           print "Try $url directly\n" unless $cf->{quiet};
> +           get_remote($dest, $pxys, $cf->{wget_opts}, $pxmode, $url);
> +       }
>          return $path if -f $path;
>      }
> +
> +
>      return;
>  }
> 
> I don't know if this is at all useful to you or even desirable, but if
> you want to use it, go right ahead.
> 
> 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: Stuart Hughes [mailto:address@hidden
> Sent: Sat 11/13/2010 1:54 PM
> To: Rodney Lott
> Cc: address@hidden
> Subject: Re: Found issue relating to xorg-x11-proto-devel.spec and
> xextproto-7.0.2.tar.bz2
> 
> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>