On Tue, 5 Jun 2012, Wang, Shane wrote:
>
> Khem Raj wrote on 2012-06-05:
>
> > On Mon, Jun 4, 2012 at 10:04 PM, Wang, Shane <shane.w...@intel.com>
> > wrote:
> >> Yeah, Robert,
> >>
> >> You found a bug in bitbake. In the fetch code, local directory
> >> /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is decoded as
> >> /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 by newuri = uri_replace(origud,
> >> find, replace, ld), which is line 480 in lib/bb/fetch2/__init__.py. And
> >> later on it is checked whether or not existed by if not
> >> os.path.exists(newpath) and path.find("*") == -1:, which is line 61 in
> >> lib/bb/fetch2/local.py.
> >>
> >> Actually the directory /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is there, but
> > /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 can't be found by bitbake code. That
> > is the problem. Therefore, Gtk+ shouldn't be decoded as gtk%2B.
> >>
> >> I am not familiar with the whole fetch code and hope someone else can
> > correct it, so can you please file a bug first?
> >
> > its probably due to use of urllib.unquote in decodeurl and not keeping
> > the unquoted name for subsequent use
> >>
> >> --
> >> Shane
>
> Correct.
at this point, has the problem been identified? or does this still
require a bugzilla submission? it would appear that the issue
involves any package with a "+" in the package name which, for now,
appears to be just that gtk+ package. would any other special
characters trigger this? that's the only package i've tripped over
that caused this behaviour.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
