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

[Abou Al Montacir]

On Sun, 2014-03-30 at 13:55 +0200, Paul Gevers wrote:
> 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.
It could be possible that it is as you said.

> >>> 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 agree

> > 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.
Please feel free to undo this (I'd like if you comment the lines in the
script rather than removing them).

> > 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.
I don't like this option myself!

> > 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.)
I've fixed that.

Paul, I've done all the job required to upload. I let you decide if you
want to upload or do some modifications related to importing sources
before. For me it is all the same. I consider my task here done and will
switch to Lazarus.

I hope you can upload soon.

Cheers,
Abou Al Montacir,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140401/99234892/attachment.sig>