while that worked flawlessly, there might be problems on a subsequent build
in the same tree, if you were renaming directories.
To fix that, I added (to the aforementioned) an override_dh_autoreconf
sequence:
post_patch:
[ -d src/new-dir ] || mv src/orig-dir src/new-dir
override_dh_autorecon
Hi,
Has this been reported as a bug yet?
The only thing I found to work is:
pre_unpatch:
[ -f orig.c ] || mv new.c orig.c
...
override_dh_clean: pre_unpatch
dh_clean
# This forces the rename right before dpkg-source --after-build
override_dh_builddeb: pre_unpatch
Thibaut Paumard writes:
> Have you tried debuild -tc? It ought to call debian/rules clean before
> unapplying the patches. IMHO, it should be the default.
I agree. Since
debuild
[...]
debuild clean
is recommended in the docs [1], I would think it is a bug.
Cheers
Ole
[1] http://www.debian.o
Le 10/05/12 15:18, Olе Streicher a écrit :
> Thibaut Paumard writes:
>> Can you not override clean to be a no-op or at least not trigger
>> autoreconf if the patches have not been applied?
>
> Overriding with no-op doesn't help since then my directory is still
> cluttered with all the trash from
Thibaut Paumard writes:
> Can you not override clean to be a no-op or at least not trigger
> autoreconf if the patches have not been applied?
Overriding with no-op doesn't help since then my directory is still
cluttered with all the trash from the build.
To me, this problem sounds like a bug in
Le 10/05/12 14:47, Olе Streicher a écrit :
> Hi Thibaut,
>
> Thibaut Paumard writes:
>> If you use a patch system, you should use it to do the patching
>
> OK, so I created a small shell script what creates/updates a file
> in debian/patches.
>
> However, now I have another problem: when I run
Hi Thibaut,
Thibaut Paumard writes:
> If you use a patch system, you should use it to do the patching
OK, so I created a small shell script what creates/updates a file
in debian/patches.
However, now I have another problem: when I run
debuild
debuild clean
I get an error since "debuild clean
On Thu, 10 May 2012 13:18:42 +0200, Olе Streicher wrote:
> I have the same problem in another package: here, an executable is going
> to be renamed, and therefore also the manpage. Additionally, the manpage
> needs a patch. Since the manpage is renamed, unpatching it after build
> fails.
Not sur
Le 10/05/12 13:41, Thibaut Paumard a écrit :
> That said, I really don't get why dpkg--after-build does not call
> debian/rules clean. It also causes breakages to my packages. I'll
> investigate that someday.
Hi, self and Ole,
Have you seen the -tc option of dpkg-buildpackage?
Regards, Thibaut.
Hi Ole,
Le 10/05/12 13:18, Olе Streicher a écrit :
> Gergely Nagy writes:
>> The patch in debian/patches will be large, possibly complicated and
>> whatnot, but you can explain how it is created in debian/README.source,
>> and live happily ever after.
>>
>> There are cases where a bit of ugliness
Gergely Nagy writes:
> The patch in debian/patches will be large, possibly complicated and
> whatnot, but you can explain how it is created in debian/README.source,
> and live happily ever after.
>
> There are cases where a bit of ugliness is acceptable. This is one such
> case.
I still do not se
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Dear Mentors,
>
> For a package [1], I have to patch one file (Makefile.am) twice: once
> from debian/patches, and the other times from debian/rules. The patch in
> debian/patches is needed to bring allow the use of a standard automake
> (upstrea
gregor herrmann writes:
> Maybe try to move the second sed call from _clean to _autoreconf
> directly after the dh_autoreconf invocation?
I've tried this -- this triggers a re-creation of Makefile.in with the
original names, which are then errornously used to build the package.
Cheers
Ole
--
On Thu, 10 May 2012 11:22:46 +0200, Olе Streicher wrote:
> 8<-
> override_dh_autoreconf:
> sed s/libast/libstarlink_ast/g -i Makefile.am
> AUTOMAKE="automake --foreign" dh_autoreconf
>
> override_dh_clean:
> sed s/libst
Dear Mentors,
For a package [1], I have to patch one file (Makefile.am) twice: once
from debian/patches, and the other times from debian/rules. The patch in
debian/patches is needed to bring allow the use of a standard automake
(upstream uses a patched version), while the patch done from
debian/ru
15 matches
Mail list logo
