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

Bug#683030: unblock: vlc/2.0.3-1



clone 683030 -1
retitle -1 unblock libav
block 683030 by -1
tag -1 moreinfo
stop

On Sat, Jul 28, 2012 at 5:47 PM, Adam D. Barratt
<adam@adam-barratt.org.uk> wrote:
> On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote:
>>     Depends: vlc libav (not considered)
>>
>> The new libav does not have an unblock request ttbomk and from a quick
>> look at the diff I'm not prepared to unblock it without at least some
>> discussion (there are changes which don't appear to be mentioned in the
>> changelog and some of the changes listed in the changelog don't actually
>> appear tohave been made).

Yeah, sorry for the confusion. I indeed intend to request the release
team to unblock the libav package, but didn't manage to get the
package in shape for that so far. I had a hell of a week with day-work
and returned from my one-week vacation only today. So your review is
more than appreciated, I will see to address your comments ideally
this week in a new package upload.

> Looking again and reading through the associated bug reports, it looks a
> bit better than I thought; I really shouldn't have to read through
> longish bug report logs to find out why a change has been made to the
> packaging, however.
>
> libav maintainers (Cced):
>
> - the changelog for -5 mentions making transitional packages arch:all,
> but not a number of removals of "Multi-Arch: foreign" that seem to have
> been applied to some packages.

Oh, I will make the changelog more explicit, then.

AFAIUI the multi-arch spec, arch:all packages are not allowed to
specify "Multi-Arch: foreign", so I had the impression that this part
was rather obvious to multi-arch experts. Which I am clearly not, so
being more explicit in the changelog is very much warrented.

> - the changelog also doesn't mention the dropping of the ffmpeg
> Provides.

I'll amend the changelog. The provides is potentially harmful as it
prevents package to declare a versioned dependency on the 'ffmpeg'
package. In any case, as long as we still provide an empty,
transitional package 'ffmpeg', the provides seem pretty pointless to
me.

> - this change looks slightly odd:
>
>   * Do not run doxygen if it is not installed.
>
> doxygen is in B-D-Indep and only appears to be used when building the
> arch:all -doc package.  On that basis, why would it not always be
> installed when required?

Your analysis in
1343596589.18013.133.camel@jacala.jungle.funky-badger.org">http://lists.debian.org/1343596589.18013.133.camel@jacala.jungle.funky-badger.org
seems right to me. The point of this commit seems to me (Fabian,
please clarify if I'm wrong) to allow the package to be built also in
with earlier version of dpkg, such as found in earlier releases of
Debian and derivatives.

I intend to work on a new upload that incorporates your suggestions
for clarifying the debian/changelog file this week. If you don't mind,
I'd leave the doxygen and the "Provides: ffmpeg" changes as-is.
Additionally, I intend to change ffmpeg-dbg from Arch: any to arch:
all for consistency with libav-extra-dbg (both are empty, transitional
 packages).

I believe that such an -6 upload qualifies the RT criteria for
unblocks at this point. However, I'd appreciate feedback on the points
that you disagree so that I can address them in time to avoid a
further, unnecessary -7 upload.

Thank you for your time reviewing the libav package!

-- 
regards,
    Reinhard


Reply to: