[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: asterisk t-p-u upload

Ron wrote:
> Hi,
> I'm happy to consider this grounds for requesting a freeze exception
> for vpb-driver, the changes since 4.2.36 that affect Debian users are
> all in the 'too minor to request one otherwise' category, so I hadn't
> done so previously.  This code has been in freeze upstream for quite
> some months, so the changes are all deliberately minimal and suitable
> for propagation to production users.
> I definitely should relax the -V with the next upload, this is an
> oversight/bug on my part.  The strict versioning was appropriate when
> the packages were first created, but that hasn't been true since the
> first upload to the distro, it's just gone unnoticed until now.  I'll
> hold off on an upload to do that until I hear how you'd like to deal
> with this for Lenny.  vpb-driver already has enough time in unstable
> and is eligible to migrate immediately if you choose to go that way.
> Cheers,
> Ron
> On Fri, Dec 26, 2008 at 02:08:59AM +0200, Faidon Liambotis wrote:
>> Hi,
>> I've prepared a fix for #507883, an RC bug for asterisk.
>> Unfortunately, one of its dependencies, libvpb0, had a new upload in
>> unstable (v4.2.38-1 vs. v4.2.36-1 in lenny) and uses  "dh_makeshlibs -V"
>> with no symbol files, which resulted in new shlibs for asterisk.
>> Those libvpb0 changes are minor -mostly fixing GCC 4.4 FTBFS due to
>> missing headers- and do not change the ABI at all (verified both by
>> looking at the source and by comparing the exported symbols).
>> So, I can see four solutions:
>>   a) The obvious: upload asterisk to t-p-u.
>>   b) Fix libvpb0's shlibs to state the reality (">= 4.2.36"), upload,
>>      wait for it to build on all architectures and then upload asterisk.
>>      Versioned build-dep is obviously not an option here.
>>   c) Push vpb-driver 4.2.38-1 to lenny.
>>      asterisk is the only rev-dep in Debian, Ron is also upstream.
>>      But I can see how this can be a problem during our hard freeze :)
>>   d) Override the shlibs with debian/shlibs.local.
>> If there's no real rush and Ron agrees, I'd say that (c) is the best
>> solution. I have no real problem with (d) either, despite its uglyness.
>> What's the preferred way in your opinion?

c) is the preferred way, I unblocked vpb-driver.



Reply to: