Openmoko Bug #2199: bitbake wpa-supplicant-0.6.3 fails (OSError)

Openmoko Public Trac bugs at docs.openmoko.org
Tue Jan 6 06:56:44 CET 2009


#2199: bitbake wpa-supplicant-0.6.3 fails (OSError)
---------------------------------------+------------------------------------
    Reporter:  cfriedt                 |        Owner:  openmoko-kernel
        Type:  defect                  |       Status:  reopened       
    Priority:  normal                  |    Milestone:                 
   Component:  System Software         |      Version:                 
    Severity:  normal                  |   Resolution:                 
    Keywords:  wpa-supplicant OSError  |     Haspatch:  0              
   Blockedby:                          |    Estimated:                 
 Patchreview:                          |     Blocking:                 
Reproducible:                          |  
---------------------------------------+------------------------------------

Comment(by cfriedt):

 Well, I've identified the culprit in my issue. It seems that while
 examining bitbake encounters an Error 13 (EPERM) causing the build to
 fail.

 Checking out packages/wpa-supplicant/wpa-suplicant-0.6.inc, at around line
 65, I noticed that there are two symbolic links created in the image dir.


 do_install () {
 ...
         ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network
 /if-pre-up.d/wpasupplicant
         ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network
 /if-post-down.d/wpasupplicant
 ...
 }

 On my machine, /etc/wpa_supplicant is owned by root:root and has mode 750.
 Hence the EPERM.

 Now - rule #1 - there should be no access to files on the build system by
 bitbake during the install stage at all. By (obvious?) inspection, there
 really is none! The install process is instructed to create a symbolic
 link called 'etc/network/if-pre-up.d/wpasupplicant' to point to a location
 (/etc/wpa_supplicant/ifupdown.sh). The location that any symbolic link
 points to should be (to some extent) irrelevent.

 So I looked into openembedded/classes/package.bbclass, where the exception
 was coming from, around line 450, stat() is called on the file in the
 image directory ($D). When stat() is called on the symbolic link, it
 actually follows the symbolic link, causing the EPERM.

 A slight modification of package.bbclass is necessary in my opinion, so
 that inappropriate stat() calls are not made to symbolic links.

 Does anyone know how? I'm still a bit of a n00b when it comes to python.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2199#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list