[Debian-med-packaging] libzerg_1.0.7-3_amd64.changes is NEW

[Laszlo Kajan]

Hello Andreas!

Ok, thank you.

My only issue is that it does not build for me with svn-buildpackage on unstable. It does with dpkg-buildpackage on unstable or stable, it does
with svn-buildpackage on stable.

The difference seems to be that on unstable I get:

 dpkg-source: info: unapplying save_makefile.patch

and this fails with:

 The next patch, when reversed, would create the file Makefile, which already exists!  Skipping patch.

I am not too worried, indeed. I am going to commit changes that get it to build with svn-buildpackage on stable and unstable, but we can upload
it when there is some other change more important than that.

Best regards,

Laszlo

On 20/01/12 11:53, Andreas Tille wrote:
> Hi Laszlo,
> 
> (dragging discussion back to list to make sure there is some public record).
> 
> 
> On Thu, Jan 19, 2012 at 05:03:12PM +0100, Laszlo Kajan wrote:
>> Hello Andreas!
>>
>> I actually had problems building your version on a Debian-unstable machine (I had no problems whey I tried it on a Debian-stable one). The
>> problem was that your patch deleted the original Makefile.
> 
> Yes, this actually was the trick to "hide" the totally unneeded Makefile
> inside patch area because the clean target auf automake stuff (which you
> added in your patch) will remove it anyway.  After unpatching the
> original Makefile can be restored without any problem (at least this was
> my consideration and it worked for me under testing).
> 
>> At the end of the build (with svn-buildpackage), the bui.d process wanted to revert
>> your patch (recreating the Makefile) but it could not because a Makefile of the build itself was in place.
> 
> Hmmm, seems `make -f debian/rules clean` was not executed properly???
> 
>> I changed your patch to 'save' the
>> original Makefile as Makefile.libzerg-orig (and leave Makefile alone) and this builds for me.
> 
> I tried this approach (which is used by autotools-dev as well) but had
> some trouble with it (do not exactly remember what this was, but just
> did not worked as expected).
> 
>> Do you see this on a Debian-unstable build?
> 
> I would need to test this but currently do not have time for this.
>  
>> Anyway I see you've uploaded your version... so I guess I will just wait and see if it is accepted.
> 
> I do not see any blocking reason for acceptance.  It was just a package
> rename which does not require a rebuild (and specifically not twice in a
> row).  So I guess the package will be accepted.  If there is any problem
> remaining we should fix this in another Debian version - perhaps we
> should wait for other reasons for an upload as well rather than changing
> only this.  In any case: If you think you found a better solution than
> mine feel free to apply this and go on with the upload if you have time.
>  
> Kind regards
> 
>       Andreas.
>  
>> On 19/01/12 12:04, Andreas Tille wrote:
>>> On Wed, Jan 18, 2012 at 07:54:53PM +0100, Laszlo Kajan wrote:
>>>> Thank you Andreas! I see it did not build twice in a row... I will check this in the future.
>>>
>>> Sometimes this is complicated and needs some experience.  When I looked
>>> at libzerg at first moment I also had no clue.  However, this "builds
>>> twice in a row" is a feature which at some point in time will be really
>>> requested (people are considering filing bug reports about this).  So it
>>> is a good idea to fix it as soon as we can spend a reasonable effort
>>> into this issue even if the resulting binary has no difference for the
>>> end user it would fire back at some point in time.
>>>
>>> Kind regards
>>>
>>>       Andreas.
>>>
>>
>