[Reproducible-builds] Bug#817116: civicrm: FTBFS: dh_linktree: link destination debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib/classes is a directory

[Chris Lamb]

Source: civicrm
Version: 4.7.2+dfsg-2
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

civicrm fails to build from source in unstable/amd64:

  [..]

  mkdir: created directory 
'debian/civicrm-common/usr/share/civicrm/packages/tcpdf'
  pre-linktree: /usr/share/php/dompdf --> 
debian/civicrm-common/usr/share/civicrm/vendor/dompdf/dompdf
  pre-linktree: /usr/share/php/php-font-lib --> 
debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib
  pre-linktree: /usr/share/php/Psr/Log --> 
debian/civicrm-common/usr/share/civicrm/vendor/psr/log/Psr/Log
  ## we need to call dh_linktree before dh_link, not after like it
  ## happens by default in "--with linktree" mode.
  dh_linktree
  dh_linktree: link destination 
debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib/classes is a 
directory
  debian/rules:54: recipe for target 'override_dh_link' failed
  make[1]: *** [override_dh_link] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160308073122.zwCgusrmHz/civicrm-4.7.2+dfsg'
  debian/rules:7: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


civicrm.4.7.2+dfsg-2.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#815844: marked as done (diffoscope won't build without python-magic from PyPi)

[Debian Bug Tracking System]

Your message dated Mon, 7 Mar 2016 19:42:21 -0500
with message-id <20160308004221.GA27498@jasmine>
and subject line Re: [Reproducible-builds] Bug#815844: diffoscope won't build 
without python-magic from PyPi
has caused the Debian Bug report #815844,
regarding diffoscope won't build without python-magic from PyPi
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
815844: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815844
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: diffoscope

Dear Maintainer,

I am maintaining the diffoscope package in GNU Guix [0].

I recently updated from version 34 to 49, and found that I could not
build diffoscope from source without the python-magic package from PyPi
[1].

However, diffoscope's README [2] says that:

``Magic-file-extension`` can be used instead of
``python-magic``. It is built from `file
`_.
Available on Debian and Fedora as ``python3-magic``.

I removed the requirement of python-magic from setup.py and built
against the Python bindings distributed with `file`, as packaged in Guix
[3]. Diffoscope seems to work just fine this way.

I even confirmed, with strace, that diffoscope was using libmagic from
`file`.

Will you consider making python-magic an optional dependency of
diffoscope, so that downstream packagers don't have to package
python-magic from PyPi or work around this issue by patching setup.py?

[0]
https://www.gnu.org/software/guix/package-list.html#diffoscope

[1]
https://pypi.python.org/pypi/python-magic/

[2]
https://anonscm.debian.org/cgit/reproducible/diffoscope.git/tree/README.rst#n58

[3]
https://www.gnu.org/software/guix/package-list.html#python-file
--- End Message ---
--- Begin Message ---
On Thu, Feb 25, 2016 at 01:49:24PM +0100, Jérémy Bobbio wrote:
> Leo Famulari:
> > However, diffoscope's README [2] says that:
> > 
> > ``Magic-file-extension`` can be used instead of
> > ``python-magic``. It is built from `file
> > `_.
> > Available on Debian and Fedora as ``python3-magic``.
> > 
> > I removed the requirement of python-magic from setup.py and built
> > against the Python bindings distributed with `file`, as packaged in Guix
> > [3]. Diffoscope seems to work just fine this way.
> 
> Indeed. That's how it works in Debian.
> 
> > Will you consider making python-magic an optional dependency of
> > diffoscope, so that downstream packagers don't have to package
> > python-magic from PyPi or work around this issue by patching setup.py?
> 
> I have no idea how you can specify alternate dependencies in setup.py or
> if that's possible. If you find a solution I guess someone could apply a
> patch.

I spent some time researching this and didn't find a satisfactory
solution.

> 
> If that's not possible, I believe that carrying a one-liner in Guix is
> not unreasonable.

Yes, it seems to be working fine for us.

It would be helpful to add a comment explaining that python-magic is
actually not required if you have built the Python bindings of file.--- End Message ---
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

[Lennart Sorensen]

On Sun, Mar 06, 2016 at 08:34:23AM -0800, Vagrant Cascadian wrote:
> I got the impression it was another broadcom chip, maybe with a
> cortex-a53? Gotta love ARM's confusing namespace.

Yes another broadcom videocore chip with the quad A7 upgraded to quad
A53.  Nothing to do with Allwinner (who really like to confuse things
by using A## codes for their chips that have nothing to do with the A##
arm cores they are based on).

> I've definitely been thinking about some of these new arm64 capable
> boards. The Odroid-C2, Pine64 and LeMaker HiKey have 2GB RAM options, at
> least. I do worry a bit about sufficient mainline support, as a few of
> the boards I've tried (odroid-c1+, cubieboard4) didnt really work out
> with vendor kernels and the mainline support wasn't close enough to be
> useable.
> 
> That said, I'm not sure how much CPU/board diversity has really resulted
> in reproducibility issues at this point, so getting a less diverse
> network set up might be fine.
> 
> Also of note, the arm64 boards *could* be used to test arm64, armhf or
> armel. So they're certainly more flexible. I've considered getting a
> small number of the arm64 capable boards and plugging them into the
> armhf network with the idea that they could be switched over to arm64 in
> the future.

Actually armv8 deprecated quite a bit of stuff, so armel code might not run
on it, and some armhf code might not either, although certainly most will.

-- 
Len Sorensen

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] openSUSE Conference

[Holger Levsen]

Hi Christian,

On Freitag, 26. Februar 2016, Christian Boltz wrote:
> (I'm not subscribed here - please CC me in your replies.)

done :)
 
> Is someone interested to give a talk about Reproducible Builds at the
> openSUSE Conference (June 22-26 in Nürnberg, Germany)?
> 
> We had some interest in this topic on the opensuse-packaging mailinglist
> recently [1], so having a talk about Reproducible Builds would hopefully
> help to get openSUSE towards being reproducible.
> 
> If you want to give this (or another) talk or workshop at the openSUSE
> conference, please submit it at https://events.opensuse.org/

sadly it seems noone is interested in giving this talk? Maybe this mail 
reminds someone that my impression is wrong? :)


cheers,
Holger, busy with other events at the time :/


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Number of CPUs for armhf builds

[Holger Levsen]

Hi,

On Montag, 7. März 2016, Vagrant Cascadian wrote:
> Sure, but I suspect there are *some* builds that will never succeed in
> under 12 hours with a single CPU core (on the current armhf build
> hardware, anyways).

I doubt there are many of those, who will manage with dual-cores in 12h, 
especially if there are other builds going on at the same time.

> Overall I like the proposal to stop varying number of CPUs for armhf.
> There's some variation with number of cores simply due to having
> dual-core, quad-core and (recently) octa-core systems.  That also means
> we have no builds running with only CPUs=1, which I think is a good
> thing overall.

I've implemented and documented this in the variation table now.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Number of CPUs for armhf builds

[Vagrant Cascadian]

On 2016-03-07, Holger Levsen wrote:
> On Sonntag, 6. März 2016, Vagrant Cascadian wrote:
>> > I'm also pondering to change it to use CPUs+1 for the first builds and
>> > CPUs for the 2nd ones.
>> That would be interesting, although I was thinking we might want to do a
>> fewer number of CPUs on the first build, to make it more likely the
>> second build doesn't timeout.
>
> I don't think we should make any build slower by design.

Understandable...


>> e.g. If your first build is with 4 CPUs (from one of the quad-cores),
>> and your second builds with 1 CPU (a dual-core), you're more likely to
>> reach the timeout limit on the second build...
>
> you cannot assume such things. Builds are scheduled on arbitrary hosts.

Sure, but I suspect there are *some* builds that will never succeed in
under 12 hours with a single CPU core (on the current armhf build
hardware, anyways).


>> So combining the two ideas, I guess I would propose CPUs for first
>> build, and CPUs+1 for the second build?
>
> I'm not sure, this is what I have been meaning to do, but then I fear that 
> CPUs+1 might _slow down_ things if the machine is overloaded already… So I'm 
> now pondering to just use the number of cores always, and
>
> - on amd64+i386: make sure by node "hw" design, that every build has a 
> different number of cores (either 16 or 17)
> - on armhf: stop systematically varying numbers of CPUs, often they will vary 
> anyway (by scheduling choices) and then… there's not much unreproducibility 
> due to this issue anyway, and we will still notice if there is, on x86 and 
> sometimes here too. (And flipping status is actually even more noticable.)
>
> What do you think? Or should I go with CPUs+1 on armhf?

Overall I like the proposal to stop varying number of CPUs for armhf.
There's some variation with number of cores simply due to having
dual-core, quad-core and (recently) octa-core systems.  That also means
we have no builds running with only CPUs=1, which I think is a good
thing overall.


live well,
  vagrant


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Heads-up! (was: [dpkg] 07/07: Document 1.18.5.0~reproducible1)

[Holger Levsen]

Hi Lunar,

thanks for rebasing our changes on the latest master branch!

On Freitag, 4. März 2016, Jérémy Bobbio wrote:
> This versions implement changes discussed in #138409. One is that we are
> now capturing some environment variables in .buildinfo files. In the
> case of tests.reproducible-builds.org and the prebuilder script that means
> that, as it is, every package would fail to be reproducible with the
> current comparison.

which environment variables are put into the .buildinfo files so that the 
comparison will fail?

or maybe rather: why cant we make the .changes file include reproducible 
.buildinfo files?

> So I refrained from uploading binaries yet.
> 
> Couple of ways out I can think of:
> 
>  1. Easy quick fix: use sed to remove .buildinfo from both .changes
> file, then give .changes file to diffoscope.
>  2. Slightly more complicated: change diffoscope to ignore most
> fields in .buildinfo files.
>  3. More involved: finally add “ignore modules” to diffoscope and
> write a module to ignore most fields in .buildinfo files. I
> would enable such a module by default.

4. teach diffoscope to ignore .buildinfo files when processing .changes files?

> (I won't have time to work on any of this before probably 8-10 days.)
> 
> Just for the record, Guillem said on IRC that he was waiting for us to
> test the treewalk code before uploading dpkg/1.18.5 which ought to fix
> file ordering issues.

/me nods.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

[Holger Levsen]

Hi Axel,

On Sonntag, 6. März 2016, Axel Beckert wrote:
> > I think we'd need 10-12 of such boards for a start, not sure if we still
> > have Debian funds to buy those (but I almost think so… Vagrant?) -
> > providing we would find someone interested+able to host these. Would you
> > (Axel) be able too?
> I probably can host some, too, given that them only being reachable
> via IPv6 suffices. (I currently only have a SixXS IPv6 tunnel at home,
> but I'm thinking about switching my ISP at home to one with fiber and
> native IPv6.)

I guess that would be fine in principle, except that jenkins.d.n has no ipv6, 
and adding that would involve tunneling.

Would you be willing to forward ports from an ipv4 address of yours to the ssh 
ports of these nodes, so that we can use ipv4 like in the setup with Vagrant?


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

[Holger Levsen]

Hi,

as a general comment to the Debian ARM people: thanks a lot for your 
insightful comments, even though they smashed the idea of cheap arm64 Debian 
builders for now! Much appreciated feedback!

On Sonntag, 6. März 2016, Vagrant Cascadian wrote:
> That said, I'm not sure how much CPU/board diversity has really resulted
> in reproducibility issues at this point, so getting a less diverse
> network set up might be fine.

I think it has found a fair number of bugs.

> > I think we'd need 10-12 of such boards for a start, not sure if we still
> > have Debian funds to buy those (but I almost think so… Vagrant?) -
> I need to do a final tally yet, but it's nearly done. There might be
> some funding left for a few boards, but probably not 10 boards once you
> factor in the costs of SSDs, power supplies, and other necessary
> adapters.

It would be good to know the exact number left…
 
> We've certainly met the target of tripling the build network speed, at
> least!
> 
>   https://tests.reproducible-builds.org/stats_builds_per_day_armhf.png

:-))) and \o/


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Number of CPUs for armhf builds

[Holger Levsen]

Hi,

On Sonntag, 6. März 2016, Vagrant Cascadian wrote:
> > I'm also pondering to change it to use CPUs+1 for the first builds and
> > CPUs for the 2nd ones.
> That would be interesting, although I was thinking we might want to do a
> fewer number of CPUs on the first build, to make it more likely the
> second build doesn't timeout.

I don't think we should make any build slower by design.
 
> e.g. If your first build is with 4 CPUs (from one of the quad-cores),
> and your second builds with 1 CPU (a dual-core), you're more likely to
> reach the timeout limit on the second build...

you cannot assume such things. Builds are scheduled on arbitrary hosts.

> So combining the two ideas, I guess I would propose CPUs for first
> build, and CPUs+1 for the second build?

I'm not sure, this is what I have been meaning to do, but then I fear that 
CPUs+1 might _slow down_ things if the machine is overloaded already… So I'm 
now pondering to just use the number of cores always, and

- on amd64+i386: make sure by node "hw" design, that every build has a 
different number of cores (either 16 or 17)
- on armhf: stop systematically varying numbers of CPUs, often they will vary 
anyway (by scheduling choices) and then… there's not much unreproducibility 
due to this issue anyway, and we will still notice if there is, on x86 and 
sometimes here too. (And flipping status is actually even more noticable.)

What do you think? Or should I go with CPUs+1 on armhf?


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#817027: gstreamer1.0: FTBFS: LaTeX Error: File `ulem.sty' not found.

[Chris Lamb]

Source: gstreamer1.0
Version: 1.6.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

gstreamer1.0 fails to build from source in unstable/amd64:

  [..]

  (/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
  (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/color.cfg)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/dvips.def)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/dvipsnam.def))
  (/usr/share/texlive/texmf-dist/tex/latex/colortbl/colortbl.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/marvosym/marvosym.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
  (/usr/share/texlive/texmf-dist/tex/latex/tools/multicol.sty)
  
  ! LaTeX Error: File `ulem.sty' not found.
  
  [..]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


gstreamer1.0.1.6.3-1.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#817026: gstreamer0.10: FTBFS: ! LaTeX Error: File `ulem.sty' not found.

[Chris Lamb]

Source: gstreamer0.10
Version: 0.10.36-1.5
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

gstreamer0.10 fails to build from source in unstable/amd64:

  [..]

DOC   Building XML
  ./gstreamer-decl.txt:7864: warning: GstTagList has multiple definitions.
  ../../gst/gstplugin.h:297: warning: GST_PLUGIN_DEFINE_STATIC is deprecated in 
the inline comments, but no deprecation guards were found around the 
declaration. (See the --deprecated-guards option for gtkdoc-scan.)
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::resync is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::lock 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::free 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::pushed is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::type 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::next 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::master_cookie is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::cookie is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::item 
is not used from source code comment block.
  ./gstreamer-unused.txt:1: warning: 5 unused declarations.They should be added 
to gstreamer-sections.txt in the appropriate place.
DOC   Building HTML
DOC   Fixing cross-references
  html/gstreamer-GstUriHandler.html:309: warning: no link for: 
'api-index-0.10.13' -> (0.10.13).
  html/gstreamer-GstUriHandler.html:372: warning: no link for: 
'api-index-0.10.4' -> (0.10.4).
  html/gstreamer-GstUriHandler.html:506: warning: no link for: 
'api-index-0.10.33' -> (0.10.33).
  html/GstRegistry.html:424: warning: no link for: 'api-index-0.10.26' -> 
(0.10.26).
  html/GstBus.html:599: warning: no link for: 'api-index-0.10.15' -> (0.10.15).
  html/GstBus.html:644: warning: no link for: 'api-index-0.10.12' -> (0.10.12).
  html/gstreamer-GstDateTime.html:230: warning: no link for: 
'api-index-0.10.31' -> (0.10.31).
  html/gstreamer-GstValue.html:1440: warning: no link for: 'api-index-0.10.32' 
-> (0.10.32).
  html/gstreamer-Gst.html:281: warning: no link for: 'gtk-init' -> (gtk_init()).
  html/gstreamer-Gst.html:470: warning: no link for: 'api-index-0.10.10' -> 
(0.10.10).
  html/gstreamer-GstBufferList.html:462: warning: no link for: 
'api-index-0.10.24' -> (0.10.24).
  html/GstTagSetter.html:253: warning: no link for: 'api-index-0.10.22' -> 
(0.10.22).
  html/gstreamer-GstPoll.html:292: warning: no link for: 'api-index-0.10.18' -> 
(0.10.18).
  html/gstreamer-GstPoll.html:667: warning: no link for: 'api-index-0.10.23' -> 
(0.10.23).
  html/gstreamer-GstIterator.html:530: warning: no link for: 
'api-index-0.10.25' -> (0.10.25).
  html/GstElementFactory.html:871: warning: no link for: 'api-index-0.10.14' -> 
(0.10.14).
  html/gstreamer-GstInfo.html:2018: warning: no link for: 'api-index-0.10.30' 
-> (0.10.30).
  html/GstClock.html:620: warning: no link for: 'api-index-0.10.16' -> 
(0.10.16).
  html/gstreamer-GstMessage.html:1617: warning: no link for: 
'api-index-0.10.11' -> (0.10.11).
  html/gstreamer-GstMessage.html:1700: warning: no link for: 
'api-index-0.10.20' -> (0.10.20).
  html/gstreamer-GstMessage.html:3012: warning: no link for: 
'api-index-0.10.29' -> (0.10.29).
  html/gstreamer-GstMessage.html:3338: warning: no link for: 
'api-index-0.10.22.' -> (0.10.22.).
  html/gstreamer-GstMessage.html:3500: warning: no link for: 
'api-index-0.10.24.' -> (0.10.24.).
  html/GstGhostPad.html:623: warning: no link for: 'api-index-0.10.36' -> 
(0.10.36).
  html/gstreamer-GstTagList.html:4167: warning: no link for: 'GstTagImageType' 
-> (GstTagImageType).
  html/gstreamer-GstTagList.html:4168: warning: no link for: 'api-index-0.10.6' 
-> (0.10.6).
  html/gstreamer-GstTagList.html:4177: warning: no link for: 'api-index-0.10.7' 
-> (0.10.7).
  html/gstreamer-GstTagList.html:4187: warning: no link for: 
'api-index-0.10.21' -> (0.10.21).
  html/gstreamer-GstEvent.html:845: warning: no link for: 'api-index-0.10.3' -> 
(0.10.3).
  html/gstreamer-GstMiniObject.html:339: warning: no link for: 
'api-index-0.10.35' -> (0.10.35).
  html/GstPipeline.html:640: warning: no link for: 'api-index-0.10.5' -> 
(0.10.5).
  html/gstreamer-GstBuffer.html:892: warning: no link for: 'api-index-0.10.9' 
-> (0.10.9).
  html/GstXML.html:202: warning: no link for: 'FILE:CAPS' -> (FILE).
  make[6]: