Bug 328811

Summary: kiwi: doesn't find a pattern when ftp source is used
Product: [openSUSE] openSUSE 10.3 Reporter: Jiří Suchomel <jsuchome>
Component: OtherAssignee: Marcus Schaefer <ms>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: francis
Version: Beta 2   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Jiří Suchomel 2007-09-27 07:13:47 UTC 
This has been originally solving in bug 328003, however it is still not working.

My kiwi changelog says:

* Wed Sep 26 2007 ms@suse.de
- fixed stick creation for compressed images. Too many spare
  space was added to the read-only image part. This was a waste
  of space

* Wed Sep 26 2007 ms@suse.de
- added harddisk boot for isoboot (#328509)
- load BusLogic module for vmxboot/oemboot systems (#327358)
- fixed pattern download by using the content file. On local
  repo check by glob search if no content file exists (#328003)


Yes, in bug 328003, I meantioned DESCRDIR as the correct directory where patterns are saved, but the real problem was that even when kiwi knows the correct path, it is not able to read the pattern list. See comments 25 and 26 of bug 328003 - the directory actually was correct.

Now with new kiwi, I get 

Pattern match or DESCRDIR search failed: default   failed

error. If I add some debugging into KIWIPattern.pm, I can see that the $content variable was empty before calling checkContentData function. The response of http request from line 273 is:
$VAR1 = bless( {
                 '_content' => '',
                 '_rc' => 400,
                 '_headers' => bless( {
                                        'client-date' => 'Thu, 27 Sep 2007 07:06:37 GMT',
                                        'content-type' => 'text/plain'
                                      }, 'HTTP::Headers' ),
                 '_msg' => 'FTP return code 000',
                 '_request' => bless( {
                                        '_content' => '',
                                        '_uri' => bless( do{\(my $o = 'ftp://cml.suse.cz/netboot/find/openSUSE-10.3-RC1-DVD-i386-DVD1/content')}, 'URI::ftp' ),
                                        '_headers' => bless( {
                                                               'user-agent' => 'libwww-perl/5.806'
                                                             }, 'HTTP::Headers' ),
                                        '_method' => 'GET'
                                      }, 'HTTP::Request' )
               }, 'HTTP::Response' );
Comment 1 Marcus Schaefer 2007-09-27 08:22:15 UTC 
Now with new kiwi, I get 
Pattern match or DESCRDIR search failed: default   failed

==> but the pattern name is "default-10.3"

??
Comment 2 Jiří Suchomel 2007-09-27 08:32:00 UTC 
That's not the issue.
The error "Pattern match or DESCRDIR search failed" is printed after checkContentData function. But checkContentData already got the empty string as $content variable. So there was no name matching inside checkContentData.
Comment 3 Marcus Schaefer 2007-09-27 08:58:38 UTC 
that's true but I can't reproduce this here: I used the following
location: 

   ftp://10.20.3.1/netboot/find/openSUSE-10.3-RC1-DVD-i386-DVD1

will it work if you use this location ?
I mean the content is checked by:

        my $browser  = LWP::UserAgent->new;
        my $location = $publics_url."/content";
        my $request  = HTTP::Request->new (GET => $location);
        my $response = $browser  -> request ( $request );
        $content     = $response -> content ();
        if (! defined $content) {
            return (undef,"Failed to load content file: $location");
        }

but you got the error later, so the download works but the contents
of the download couldn't be evaluated. That's unclear to me ?
Comment 4 Jiří Suchomel 2007-09-27 09:09:48 UTC 
I think that $content is empty string (but defined) so it doesn't fail on "! defined" check.
See initial comment: '_content' => '' in the $response hash.

I'm confused that it works for you with the 10.20.3.1 location.
Comment 5 Marcus Schaefer 2007-09-27 09:24:47 UTC 
yes it does, this was the test I made before committing. Does it work for you or not with this location ?
Comment 11 Marcus Schaefer 2007-09-27 09:49:24 UTC 
I have tested the following code on your machine:

use strict;
use LWP;

my $publics_url="ftp://10.20.3.1/netboot/find/openSUSE-10.3-RC1-DVD-i386-DVD1";
#my $publics_url="http://cml.suse.cz/netboot/find/openSUSE-10.3-RC1-DVD-i386-DVD1";

print "start\n";
        my $browser  = LWP::UserAgent->new;
        my $location = $publics_url."/content";
        print "$location\n";
        my $request  = HTTP::Request->new (GET => $location);
        my $response = $browser  -> request ( $request );
        my $content     = $response -> content ();
print "stop\n";

print $content;

http works ftp doesn't. On my system here in Nuremberg both works.
Could you confirm ?

Thanks
Comment 12 Jiří Suchomel 2007-09-27 10:52:37 UTC 
Yes, http works ftp doesn't.
That ftp source is valid and YaST is able to install from it.
Comment 13 Marcus Schaefer 2007-09-27 11:01:47 UTC 
This is interesting maybe this is a perl LWP problem ? I have
10.2 perl-libwww-perl-5.805-32 you have 10.3 perl-libwww-perl-5.806-11

I don't think it's a kiwi problem


Anna, could you check this. See my sample application in comment #11

Thanks
Comment 14 Anna Maresova 2007-09-27 11:41:40 UTC 
The script works for me with ftp perfectly (current perl-libwww-perl on 10.3 machine). I am sorry.
Comment 15 Jiří Suchomel 2007-09-27 11:50:21 UTC 
Hm, it all looks like my configuration is somehow broken; I should reinstall to RC2. But the fact that yast is able to use the ftp source and perl script fails just confuses me.
Comment 16 Marcus Schaefer 2007-09-27 12:48:18 UTC 
maybe you should install RC3 :-)

let me know if this fixes your problem
Comment 17 Jiří Suchomel 2007-10-01 08:57:48 UTC 
Installed GM, ftp works. 
Something in my setup had to be wrong :-(