On Mon, Aug 13, 2012 at 10:23:39AM -0600, Eric Blake wrote:
On 08/13/2012 07:56 AM, Cole Robinson wrote:
> I tried to reproduce on master, but it has its own set of issues:
>
> IOError: [Errno 13] Permission denied:
'../../src/hyperv/hyperv_wmi.generated.h'
> types_typedef = open_and_print(os.path.join(output_dirname,
> "esx_vi_types.generated.typedef"))
> File "../../src/esx/esx_vi_generator.py", line 1492, in open_and_print
> return open(filename, "wb")
> IOError: [Errno 13] Permission denied:
Sounds like we have a case of a file that gets included in the tarballs,
but where the makefile rules think it is out of date and tries to
regenerate it. Either it should always be generated (and not part of
the tarball), or we need to audit the dependencies to make sure that it
does not need rebuilding when used from a pristine tarball. I'll try to
take a look into this one later this week (my past experience with dist
bugs like this is that they take a good chunk of dedicated time on my
part to get to a real root cause).
>
> $ git revert 1bfb47dfe61c3cf9a716db072cbe22f26e980081
> [master f5a9a90] Revert "Make ESX & Hyper-V code generator safe with
parallel
> builds"
So that means that our conversion to using a stamp file is the real
culprit. It may be as simple as just making sure the stamp file is also
part of the tarball.
Ahh, right. So the ESX generator explicitly sets the files readonly when
it creates them. So when they are in the dist, and the stmp file is not,
you hit the EPERM issue.
I copied the make rules from the python generator, which also does not
include the stamp file in dist. The difference is though that the python
generator doesn't make its files readonly
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|