Workaround of some buildroot failure and ffmpeg

[Ben Rosser]

On Wed, Jul 6, 2016 at 11:52 PM, Ben Rosser <rosser.bjr at gmail.com> wrote:

> On Wed, Jul 6, 2016 at 5:44 PM, Nicolas Chauvet <kwizart at gmail.com> wrote:
>
>> - rfpkg needs to be removed from the default buildroot and use
>> rfpkg-minimal instead.
>> This is a simple task that anyone can take. (convert and create
>> rfpkg-minimal rpm package based on fedpkg-minimal)
>>
>
> I just took a look at this, since it sounded like something I might be
> able to do. fedpkg-minimal is pretty straightforward:
> https://git.fedorahosted.org/cgit/fedpkg-minimal.git/tree/bin/fedpkg
>
> Unfortunately, an RPM Fusion equivalent will need to know whether or not
> the package in question is in free/ or in nonfree/, because of the dist-git
> namespacing. e.g. the curl line should become
> "$baseurl/free/$pkgname/$tarball/$md5sum/$tarball" or
> "$baseurl/nonfree/$pkgname/$tarball/$md5sum/$tarball". Assuming I'm not
> missing something obvious, I can think of three ways to deal with this:
>
> a. Provide rfpkg-free and rfpkg-nonfree scripts, one for each namespace.
>
> b. Attempt to download both and ignore failures (curl ... || true?), then
> check to see if the file exists before proceeding.
>
> c. Somehow determine whether a package is in free/ or nonfree/ at runtime.
> This would be the optimal solution but I'm not sure if there's a good way
> to do it. Perhaps checking .git/config for a configured remote with URL
> containing "free" or "nonfree"?
>
> Thoughts?
>
> Ben Rosser
>


I ended up implementing (c) *and* (b); rfpkg-minimal attempts to read
.git/config and then just tries to download from both if it is not there. I
forked the fedpkg-minimal git repo and pushed to github here:
https://github.com/TC01/rfpkg-minimal

If this looks good, I'm happy to throw together a spec and submit a package
for review.

Ben Rosser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.rpmfusion.org/pipermail/rpmfusion-developers/attachments/20160707/56f23558/attachment.html>