Daily recipe: failure because of Permission denied accessing build/patch directories

Bug #760735 reported by Curtis Hovey
74
This bug affects 15 people
Affects Status Importance Assigned to Milestone
launchpad-buildd
Triaged
Critical
Unassigned

Bug Description

This is a summary of the current state of the issue.

The first patch fails to apply because of permission denied on the ubiquity directory and the three files it contains. This implies a umask issue in the chroot. This is not an issue when building locally

I wonder if a work around for this would be to add a hook in rules for "debian/stamp-autotools-files" that makes the directory or forces the umask.

From the log:
----------------------------------------------
dh_clean
rm -f debian/stamp-autotools-files
test -d . && cd . && \
   rm -f intltool-extract intltool-merge intltool-update po/.intltool-merge-cache; \
   if test -d doc; then find doc -name '*.omf.out' -exec rm -f \{\} \; ; fi; \
   if test -d help; then find help -name '*.omf.out' -exec rm -f \{\} \; ; fi
 dpkg-source -i -I -b recipe-3.1.0~5184+14
dpkg-source: info: using source format `3.0 (native)'
dpkg-source: info: building gnome-orca in gnome-orca_3.1.0~5184+14~natty1.tar.gz
tar: recipe-3.1.0~5184+14/.pc/01_add_ubiquity-script.patch/src/orca/scripts/apps/ubiquity/Makefile.am: Cannot open: Permission denied
tar: recipe-3.1.0~5184+14/.pc/01_add_ubiquity-script.patch/src/orca/scripts/apps/ubiquity/script.py: Cannot open: Permission denied
tar: recipe-3.1.0~5184+14/.pc/01_add_ubiquity-script.patch/src/orca/scripts/apps/ubiquity/__init__.py: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors

Revision history for this message
Curtis Hovey (sinzui) wrote :

This may relate to the broken sudo in builds, but since this issue affects natty, maverick, and lucid, another underlying bug may be the cause.

Changed in launchpad:
status: New → Triaged
importance: Undecided → Critical
tags: added: recipe soyuz-build
Revision history for this message
Boris Dušek (dusek) wrote :

Thanks for reporting the bug, would you like me to try your suggestion with the stamp-autotools-files? If yes, I will try to get to it ASAP (probably this evening).

Revision history for this message
Curtis Hovey (sinzui) wrote :

From the question adding tar-ignore = .pc allows natty and maverick to build, but lucid does not support that.

Revision history for this message
Don Marang (speedychair) wrote :

This bug effects the Vinux distribution because we need to test against daily builds of critical accessibility packages, such as orca, at-spi2, and so on in order to provide a more stable, responsive, full featured experience for our long term support of Vinux 3.0.1, based upon Ubuntu Lucid.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

This should be fixed with the newer version of bzr-builder, which no longer tries to apply patches at build time.

Changed in launchpad:
status: Triaged → In Progress
assignee: nobody → Jelmer Vernooij (jelmer)
Revision history for this message
Jelmer Vernooij (jelmer) wrote :

The simplest work around for this is to upload native packages only - bzr-builder will convert non-native packages to native packages anyway.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

This should now be fixed - please reopen if it is not.

Changed in launchpad:
status: In Progress → Fix Released
Revision history for this message
Deryck Hodge (deryck) wrote :

Re-opening since this appears to not be fixed. Please see the recently duped bug.

Changed in launchpad:
status: Fix Released → Triaged
Jelmer Vernooij (jelmer)
affects: launchpad → launchpad-buildd
Changed in launchpad-buildd:
assignee: Jelmer Vernooij (jelmer) → nobody
Revision history for this message
John Leach (johnleach) wrote :

Definitely still broken for me:

https://code.launchpad.net/~brightbox/+archive/ruby-ng-experimental/+recipebuild/173708

the --tar-ignore workaround work for maverick and up, but not on Lucid.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

A way to work around this is to change your package to a native source format (e.g. "3.0 (native)") and apply all of the patches to the source tree.

This has the same result as leaving it as "3.0 (quilt)", as it will be converted to "3.0 (native)" by bzr-builder anyway.

Revision history for this message
i30817 (i30817) wrote :

When this happened to me i suspect it was because diff was creating a new file that didn't exist yet on the source. "I suspect" because when i tried to create the file on the merged repo i got a bzr merge conflict. Now i tried the tar ignore .pc option in debian/options and will know if that works tomorrow

Revision history for this message
i30817 (i30817) wrote :

tar-ignore = .pc in debian/source/options that is

Revision history for this message
i30817 (i30817) wrote :

It worked

Revision history for this message
Johannes Dewender (jonnyjd) wrote :

That bug is still a problem, see https://launchpadlibrarian.net/153854887/buildlog.txt.gz

Same reason. There are several patches, but the one creating new files (and a new folder) leads to the problem:

tar: recipe-{debversion}/.pc/manpage.patch/doc/isrcsubmit.1.rst: Cannot open: Permission denied
tar: recipe-{debversion}/.pc/manpage.patch/doc/conf.py: Cannot open: Permission denied

This is the patch (applying fine):
http://bazaar.launchpad.net/~jonnyjd/isrcsubmit/packaging/view/170/debian/patches/manpage.patch

Adding "tar-ignore = .pc" to "debian/source/options" works.
In that case it means a package from debian wouldn't work unchanged on launchpad.

Revision history for this message
Johannes Dewender (jonnyjd) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.