Comment # 2 on bug 1126887 from Jean Delvare

The problem is that your tarball does not only contain a patches/ directory, it
also contains a .pc/ directory. This directory recorded a "quilt state" at the
moment the tarball was generated, which includes one patch (tunctl-setgroup)
being applied.

In this specific case, "quilt setup" should not use alternative names
(quilt_patches and quilt_series). Instead, it should apply the SUSE-specific
patches *on top* of the already existing patch stack. It is the first time I
see this situation, usually upstream cleans up any quilt-specific state before
packaging.

To make things worse, the patch from upstream (tunctl-setgroup) does not even
un-apply cleanly. So the effective code changes are different from what is
stored in file patches/tunctl-setgroup.

I can't immediately think of a way to handle this situation cleanly. The
problem is that the patches provided in the tarball live in a patches/
directory inside the working directory, while the ones provided by us live in
the parent directory (outside of the working directory). "patches/" can't be
both a real directory and a ".." symbolic link at the same time.

My recommendation would be to modify the spec file of this package to ignore
the quilt state provided by upstream:

--- uml-utilities.spec  (revision 2462eb3a5caaaa44a30c0c23fdb18b30)
+++ uml-utilities.spec  (working copy)
@@ -44,6 +44,7 @@

 %prep
 %setup -q -n tools-%{version}
+rm -rf .pc patches
 %patch1 -p1 -b ia64
 %patch2
 %patch3

And then use the "--fast" option of "quilt setup" (which is not only faster,
but also handles many more corner cases in spec files, such as the one
suggested above, and for this reason is going to become the default in a near
future.)