[Pkg-pascal-devel] FPC 2.6.4 is released.

[Paul Gevers]

On 29-03-14 18:51, Abou Al Montacir wrote:
>> No, if you remove the Makefiles in your clean target, then dpkg-source
>> will not abort (it will give you the warning you mention below, but that
>> is harmless and correct).
> Anyway, it seems that those make files and .o files that are removed
> during the clean target are the real cause of "git buildpackage" to
> fail!
> 
> I have re-packaged again removing .o files and it worked perfectly. I've
> pushed this for record, but of course it does not mean I'm pushing to
> enforce my point of view. It is only to record something as working.

Could it be that all you/we need to do is tell git to ignore the *.o
files? E.g. by creating a .gitignore file (also available in the
upstream branch) and committing once (well, actually you already did)
the removal of these files? .... Although, now I think of it, that
probably will not do the trick. But git-import-orig also has the
--filter option that apparently is meant for this purpose. I think the
trick is to create an appropriate gbp.conf file.

>>> Do you see?
>>> dpkg-source: warning: ignoring deletion of file fpcsrc/rtl/palmos/m68k/libcrt.a
>>> dpkg-source: warning: ignoring deletion of file fpcsrc/rtl/palmos/m68k/crt0.o
>>> ...
>>> We got the same think for make files.
>>
>> But this is perfectly acceptable. That is what happens if you remove a
>> file in clean that is in the tar ball. No problem at all.
> I also think this is acceptable. But as you can see above, this is
> preventing "git buildpackage" to work. As this is the way I want to
> enforce as standard flow for this group. I'm a bit confused how to
> proceed. For me "git buildpackage" is the easiest and the standard way
> to go. But we are dealing about a 'dirty' upstream package. And
> repackaging is the only way I see to workaround this.

Well, it may be the only way you see, but I disagree it is the only way.
We just have to look harder, and I think configuring git-buildpackage is
just the way it can be done.

> I've also Tried push on upstream side to not package the make files, but
> they argued that for newbees, this could be a real problem.

I follow that stand. And it is argued in the link I send you earlier as
well. So let's not make fuss about in anymore.

> Of course, as upstream developer, I can add a debian centric tar.gz.
> This is already done for dos, win with .zip sources ... But this is kind
> of repackaging and is not contributing to transparence we want for our
> packaging.

Nah, don't do that. It is not needed.

> For me, just adding a few lines in README.debian explaining
> that we removed make files and that user can generate them simply by
> executing "find * -name Makefile.fpc -exec ${FPCMAKE} -Tall -q '{}' ';'"
> is enough.

Hmm, that reminds me that this line would make a nice debian/rules
target. Oh, you already did that. So the line in README.Debian would
actually be "debian/rules make-files". (Off topic, but now I look at it,
you clean the make-files twice in the clean target, once by dependence
and once explicitly with the line you mention above.)

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140330/6e868971/attachment.sig>