Bug#843379: blender: FTBFS (internal compiler error)
Package: src:blender
Version: 2.77.a+dfsg0-9
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
dh build-indep --buildsystem=cmake --parallel --with python3
dh_testdir -i -O--buildsystem=cmake -O--parallel
dh_update_autotools_config -i -O--buildsystem=cmake -O--parallel
debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/blender-2.77.a+dfsg0'
dh_auto_configure -- \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_SKIP_RPATH=ON \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DFREETYPE_INCLUDE_DIRS="/usr/include/freetype2" \
-DPYTHON_VERSION=3.5 \
-DWITH_CODEC_FFMPEG=ON \
[... snipped ...]
((
# 110
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h"
output_luma ==
# 110
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h"
3 4
__null) ? static_cast (0) : __assert_fail (
# 110
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h"
"output_luma == __null"
# 110
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h"
3 4
,
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h",
110, __PRETTY_FUNCTION__))
# 110
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_cpu_impl.h"
;
kernel_bake_evaluate(kg,
input,
output,
(ShaderEvalType)type,
filter,
i,
offset,
sample);
}
else {
kernel_shader_evaluate(kg,
input,
output,
output_luma,
(ShaderEvalType)type,
i,
sample);
}
}
}
# 37
"/<>/blender-2.77.a+dfsg0/intern/cycles/kernel/kernels/cpu/kernel_avx2.cpp"
2
=== END GCC DUMP ===
intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/build.make:185: recipe for
target
'intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_avx2.cpp.o'
failed
make[3]: ***
[intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_avx2.cpp.o]
Error 1
make[3]: Leaving directory
'/<>/blender-2.77.a+dfsg0/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:1315: recipe for target
'intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/all' failed
make[2]: *** [intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/all] Error 2
make[2]: Leaving directory
'/<>/blender-2.77.a+dfsg0/obj-x86_64-linux-gnu'
Makefile:163: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory
'/<>/blender-2.77.a+dfsg0/obj-x86_64-linux-gnu'
dh_auto_build: make -j1 returned exit code 2
debian/rules:72: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
This may be reproduced easily. There are full logs available here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/blender.html
If you reassign to gcc-6, please use "affects" as well so that we can still see
this
bug in the web page for blender.
Thanks.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#837273:
affects 837273 src:csoundqt thanks The affects keyword helps to avoid duplicate bugs in the affected packages (in fact, this bug was first reported against csoundqt and then reassigned, and I was close to report it again). Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#820416: kodi: FTBFS in testing (Segmentation fault)
On Wed, Aug 24, 2016 at 11:43:54PM +0200, Bálint Réczey wrote: > I don't like having this bug, but if a program fails to build 50% of > the time but runs fine it can be released IMO since users are not > affected. You seem to imply that our "output" as package distributors is just the set of binary packages. That's not the case. We provide source packages and binary packages. If a user can't build a source package that we provide then he/she is affected as well, because taking the source package and building it (possibly with modifications) is also a way of "using" it. In either case, it is not the severity definitions what we have to consider here, but release policy. Release policy says "packages must autobuild". If policy said "packages must autobuild most of the time", then yes, we could maybe have packages which only build ok most of the time. But that's not what release policy says, and that's why FTBFS bugs are usually reported as serious regardless of the "frequency" of the failure. In practice this is not as difficult to achieve as one might think, because it often happens that it's the tests who made the build to fail. If a test fails very often but does not mean that the package is "bad", the logical thing to do until somebody has the time to investigate it is to just disable it (as you have just done with kodi, thanks a lot). Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#820416: kodi: FTBFS in testing (Segmentation fault)
Hi. Any progress on this? This is still reproducible. I'm attaching a build log for the version which has just entered testing. On Sun, 17 Apr 2016, Balint Reczey wrote: > It suggests there is something wrong with the mutex handling and TSAN seems > to confirm that: > [...] > I need to test if the problem still exists in upstream master and verify if > it is not a false positive TSAN warning and the root cause is indeed here. Could you translate that into a language that a non-programmer could understand? > I'm setting the bug's severity to normal because while it is reproducible > the FTBFS does not happen on Debian's buildds [...] Hmm. I'm not going to enter into a severity war, but you should be aware that the theory that a FTBFS is not RC because "it does not happen" in Debian's buildds has many flaws. For example, for a package which FTBFS randomly, it is completely useless, as a successful build just means that we were lucky that time. We should better not care too much about what happened in the autobuilders the last time it was tried, we should care more about what could happen the next time. I'm using sbuild and the autobuilders are using sbuild as well (or a variant of it). If you think this may not happen in official autobuilders, could you please explain why? (Because my machine does not have enough memory? How would I know that in advance when we don't have a Build-Memory control field?) > thus does not prevent rebuilding the package when needed. It does prevent me from rebuilding the package, which makes the software non-free for me and apparently anybody who does not have a machine with 32 GB of RAM (which is still a lot of people). I would say that would deserve important severity at least. (I said 32 GB just as an example, but if that's a more or less accurate summary of this bug, I'd like to know the exact figure). Thanks. kodi_16.1+dfsg1-2_amd64-20160824T064358Z.gz Description: application/gzip ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#811844: fixed in composite 0.006.2+dfsg0-5
found -1 0.006.2+dfsg0-5 thanks Still FTBFS: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/composite_0.006.2+dfsg0-5.rbuild.log Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#819842: pyliblo: Build not reliable
retitle 819842 pyliblo: Build not reliable severity 819842 normal user sanv...@debian.org usertags 819842 - binary-indep thanks I have both successful and unsuccessful build logs for this package. All of them for version 0.10.0-1. Status: successful pyliblo_0.10.0-1_amd64-20160225-2103 Status: successful pyliblo_0.10.0-1_amd64-20160227-1325 Status: successful pyliblo_0.10.0-1_amd64-20160313-1519 Status: attempted pyliblo_0.10.0-1_amd64-20160402-0031 Status: attempted pyliblo_0.10.0-1_amd64-20160402-1951 Status: attempted pyliblo_0.10.0-1_amd64-20160402-2012 Status: attempted pyliblo_0.10.0-1_amd64-20160402-2024 Status: attempted pyliblo_0.10.0-1_amd64-20160521-1427 Status: successful pyliblo_0.10.0-1_amd64-20160621-2143 This bug needs to be investigated, but it does not seem to be the typical binary-indep bug so I'm removing it from my list of binary-indep bugs for now. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#806046: horgand: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
Greetings. I have the ok from the Release Managers to consider this issue as RC for stretch. I'm going to wait at least one week before raising this to "serious". There is a patch available for this bug. If you need someone to make an upload, please ask for a sponsor in debian-mentors. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#827630: soundscaperenderer: FTBFS in testing (Class scrartcl Error: undefined old font command `bf'.)
Package: src:soundscaperenderer
Version: 0.4.2~dfsg-5
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
LaTeX Warning: Reference `sec:asdf' on page 4 undefined on input line 88.
! Class scrartcl Error: undefined old font command `\bf'.
See the scrartcl class documentation for explanation.
Type H for immediate help.
...
l.111 ...linewidth]{images/coordinate_system.eps}}
\hfill
?
! Emergency stop.
...
l.111 ...linewidth]{images/coordinate_system.eps}}
\hfill
Output written on SoundScapeRenderer.dvi (3 pages, 10364 bytes).
Transcript written on SoundScapeRenderer.log.
Latexmk: List of undefined refs and citations:
Citation `Geier08:AES' on page 3 undefined on input line 21
Citation `geier2012ssr' on page 3 undefined on input line 21
Reference `sec:asdf' on page 4 undefined on input line 88
Reference `sec:renderers' on page 3 undefined on input line 14
Reference `sec:running_ssr' on page 4 undefined on input line 64
Reference `sec:running_ssr' on page 4 undefined on input line 81
Latexmk: Summary of warnings:
Latex failed to resolve 4 reference(s)
Latex failed to resolve 2 citation(s)
Collected error summary (may duplicate other messages):
latex: Command for 'latex' gave return code 256
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs of latex/pdflatex.
Latexmk: Errors, so I did not complete making targets
debian/rules:53: recipe for target 'build/soundscaperenderer-common' failed
Because packages in stretch must be buildable in stretch, this is RC for
stretch.
You can find a full build log here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/soundscaperenderer.html
Thanks.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#823589: mplayer: Please create dummy package for upgrades from jessie
Package: mplayer Version: 2:1.2.1-1+b1 Dear maintainer: It is customary that packages changing names should provide a dummy package with the old name so that an upgrade makes the new package to be installed smoothly and automatically. Smooth upgrades have always been one of Debian's goals. I know that this case is not exactly a "package rename" in strict sense but a different codebase / different fork, but for most purposes we can assume that whoever had mplayer2 installed in jessie will want to have mplayer installed in stretch. Ok, there may be little differences (I don't know the details), and it is possible that mplayer is not a 100% drop-in replacement of mplayer2, but that's what the Release Notes (for stretch) are for. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#806046: horgand: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
tags 806046 + patch thanks >debian/rules override_dh_install > make[1]: Entering directory '/<>' > dh_install > cp debian/horgand.wrapper /<>/debian/horgand/usr/bin/horgand > cp: cannot create regular file > '/<>/debian/horgand/usr/bin/horgand': No such file or directory > debian/rules:10: recipe for target 'override_dh_install' failed Explanation: We are creating arch-independent packages only, so debian/horgand/[...] does not exist because "horgand" is arch-dependent. The trivial fix is to override dh_install only when creating arch-dependent packages. Patch attached. Thanks.--- a/debian/rules +++ b/debian/rules @@ -6,7 +6,7 @@ override_dh_auto_configure: dh_auto_configure -- --bindir=/usr/lib/horgand -override_dh_install: +override_dh_install-arch: dh_install cp debian/horgand.wrapper $(CURDIR)/debian/horgand/usr/bin/horgand chmod 755 $(CURDIR)/debian/horgand/usr/bin/horgand ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#820416: kodi: FTBFS in testing (Segmentation fault)
I've put the program kodi-test here: https://people.debian.org/~sanvila/bug-820416/kodi-test.gz It was built on a stretch chroot today (for amd64). To reproduce the segfault, just install the build-dependencies for kodi, i.e. on a stretch chroot, please do: apt-get build-dep kodi then try to execute kodi-test: ./kodi-test This is all you need to reproduce the problem. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#820416: kodi: FTBFS in testing (Segmentation fault)
tags 820416 - unreproducible found 820416 16.1~rc2+dfsg1-1 thanks I can reproduce it *every* time on several machines, so the problem is indeed real and not imagined. The program that segfaults is "kodi-test". Here is a backtrace: #0 __gnu_cxx::__normal_iterator > >::__normal_iterator (__i=@0x201: , this=) at /usr/include/c++/5/bits/stl_iterator.h:741 #1 std::vector >::begin (this=0x201) at /usr/include/c++/5/bits/stl_vector.h:548 #2 CEvent::Set (this=this@entry=0x7ffdea4caca0) at Event.cpp:78 #3 0x014b2d09 in CThread::staticThread (data=0x7ffdea4cabd0) at Thread.cpp:137 #4 0x7f871f914454 in start_thread (arg=0x7f86f65b1700) at pthread_create.c:334 #5 0x7f8716dddecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 If you still believe there is not a problem anywhere, I can give you access to a virtual machine where the problem may be reproduced easily (please contact me privately for this). I'm testing on a machine having 4GB of RAM and 4GB of swap. According to my tests, kodi needs an average of 300 MB and a maximum of 1200 MB to build. If the tests suddenly need more than 8 GB of virtual memory (version 16.0+dfsg1-1 worked ok), I would say this is disproportionate and a big step backwards. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#820416: kodi: FTBFS in testing (Segmentation fault)
Package: src:kodi Version: 16.1~rc2+dfsg1-1 Severity: serious Dear maintainer: This package fails to build from source in stretch. The error happens while doing the tests: [--] 1 test from TestAsyncFileCopy [ RUN ] TestAsyncFileCopy.General /bin/bash: line 1: 21695 Segmentation fault /<>/kodi-16.1~rc2+dfsg1/$check_program Makefile:608: recipe for target 'check' failed make[1]: *** [check] Error 139 make[1]: Leaving directory '/<>/kodi-16.1~rc2+dfsg1' dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2 debian/rules:81: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 The full build log is attached. Thanks. kodi_16.1~rc2+dfsg1-1_amd64-20160407-2325.gz Description: application/gzip ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#819842: pyliblo: FTBFS when built with dpkg-buildpackage -A (test suite fails)
Package: src:pyliblo
Version: 0.10.0-1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important
Dear maintainer:
I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:
[...]
debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
dh_testdir -i -O--buildsystem=pybuild
dh_update_autotools_config -i -O--buildsystem=pybuild
dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config
running config
I: pybuild base:184: python3.5 setup.py config
running config
dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build
running build
[... snipped ...]
testRandomPort (test.test_liblo.ServerCreationTestCase) ... ok
testSendReceive (test.test_liblo.ServerTCPTestCase) ... ERROR
testBundleCallbacksFire (test.test_liblo.ServerTestCase) ... ok
testMethodAfterFree (test.test_liblo.ServerTestCase) ... ok
testPort (test.test_liblo.ServerTestCase) ... ok
testRecvImmediate (test.test_liblo.ServerTestCase) ... ok
testRecvTimeout (test.test_liblo.ServerTestCase) ... ok
testSendBlob (test.test_liblo.ServerTestCase) ... ok
testSendBundle (test.test_liblo.ServerTestCase) ... ok
testSendInt (test.test_liblo.ServerTestCase) ... ok
testSendInvalid (test.test_liblo.ServerTestCase) ... ok
testSendLong (test.test_liblo.ServerTestCase) ... ok
testSendMessage (test.test_liblo.ServerTestCase) ... ok
testSendOthers (test.test_liblo.ServerTestCase) ... ok
testSendTimestamped (test.test_liblo.ServerTestCase) ... ok
testSendVarious (test.test_liblo.ServerTestCase) ... ok
testSendingLongAsIntOverflows (test.test_liblo.ServerTestCase) ... ok
testURL (test.test_liblo.ServerTestCase) ... ok
testSendAndReceive (test.test_liblo.ServerThreadTestCase) ... ok
==
ERROR: testSendReceive (test.test_liblo.ServerTCPTestCase)
--
Traceback (most recent call last):
File "/<>/test/test_liblo.py", line 225, in testSendReceive
liblo.send(self.server.url, '/foo', 123)
File "src/liblo.pyx", line 186, in liblo.send (src/liblo.c:3321)
_send(target, None, args)
File "src/liblo.pyx", line 160, in liblo._send (src/liblo.c:3180)
raise IOError("sending failed: %s" %
IOError: sending failed: Connection timed out
--
Ran 27 tests in 256.358s
FAILED (errors=1)
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=1:
python2.7 setup.py test
dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit
code 13
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:
* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.
* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").
Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.
Thanks.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#816996: gmerlin: FTBFS in stretch with new perl: Unescaped left brace in regex is deprecated
Package: src:gmerlin Version: 1.2.0~dfsg+1-4 Severity: serious Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed. But the failure is related to the new perl, so I infer that this would FTBFS in the general case too, hence the serious severity. [...] Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: sbuild-build-depends-core-dummy 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/770 B of archives. After this operation, 0 B of additional disk space will be used. Get:1 file:/<>/resolver-FlAtzo/apt_archive ./ sbuild-build-depends-core-dummy 0.invalid.0 [770 B] debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package sbuild-build-depends-core-dummy. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 14543 files and directories currently installed.) Preparing to unpack .../sbuild-build-depends-core-dummy.deb ... Unpacking sbuild-build-depends-core-dummy (0.invalid.0) ... Setting up sbuild-build-depends-core-dummy (0.invalid.0) ... W: No sandbox user '_apt' on the system, can not drop privileges Merged Build-Depends: cdbs, autotools-dev, gnulib, debhelper (>= 9~), dh-buildinfo, libtool, automake1.11, autoconf, devscripts, doxygen, fontconfig, libasound2-dev, libcddb2-dev, libcdio-paranoia-dev, libesd0-dev, libexif-dev, libfreetype6-dev, libgavl-dev (>= 1.4.0), libglu1-mesa-dev, libgtk2.0-dev, libjack-dev, libjpeg-dev, libpulse-dev, libquicktime-dev, libtiff-dev, libv4l-dev, libvisual-0.4-dev, libxml2-dev, libxv-dev, texinfo Filtered Build-Depends: cdbs, autotools-dev, gnulib, debhelper (>= 9~), dh-buildinfo, libtool, automake1.11, autoconf, devscripts, doxygen, fontconfig, libasound2-dev, libcddb2-dev, libcdio-paranoia-dev, libesd0-dev, libexif-dev, libfreetype6-dev, libgavl-dev (>= 1.4.0), libglu1-mesa-dev, libgtk2.0-dev, libjack-dev, libjpeg-dev, libpulse-dev, libquicktime-dev, libtiff-dev, libv4l-dev, libvisual-0.4-dev, libxml2-dev, libxv-dev, texinfo dpkg-deb: building package 'sbuild-build-depends-gmerlin-dummy' in '/<>/resolver-wUAk5p/apt_archive/sbuild-build-depends-gmerlin-dummy.deb'. OK Get:1 file:/<>/resolver-wUAk5p/apt_archive ./ InRelease Ign:1 file:/<>/resolver-wUAk5p/apt_archive ./ InRelease Get:2 file:/<>/resolver-wUAk5p/apt_archive ./ Release [2119 B] Get:2 file:/<>/resolver-wUAk5p/apt_archive ./ Release [2119 B] Get:3 file:/<>/resolver-wUAk5p/apt_archive ./ Release.gpg [299 B] Get:3 file:/<>/resolver-wUAk5p/apt_archive ./ Release.gpg [299 B] Get:4 file:/<>/resolver-wUAk5p/apt_archive ./ Sources [402 B] Get:5 file:/<>/resolver-wUAk5p/apt_archive ./ Packages [707 B] Reading package lists... W: No sandbox user '_apt' on the system, can not drop privileges Reading package lists... +--+ | Install gmerlin build dependencies (apt-based resolver) | +--+ Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: autoconf automake automake1.11 autopoint bison cdbs devscripts dh-buildinfo dh-python doxygen esound-common fontconfig fontconfig-config fonts-dejavu-core gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-gtk-2.0 gir1.2-pango-1.0 gnulib gperf icu-devtools libasound2 libasound2-data libasound2-dev libasyncns0 libatk1.0-0 libatk1.0-data libatk1.0-dev libaudiofile-dev libaudiofile1 libavahi-client3 libavahi-common-data libavahi-common3 libavcodec-ffmpeg56 libavutil-ffmpeg54 libbison-dev libbsd0 libcairo-gobject2 libcairo-script-interpreter2 libcairo2 libcairo2-dev libcddb2 libcddb2-dev libcdio-cdda-dev libcdio-cdda1 libcdio-dev libcdio-paranoia-dev libcdio-paranoia1 libcdio13 libclang1-3.6 libcrystalhd3 libcups2 libdatrie1 libdbus-1-3 libdrm-amdgpu1 libdrm-dev libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libdv4 libedit2 libelf1 libesd0 libesd0-dev libexif-dev libexif12 libexpat1 libexpat1-dev libfaad2 libflac8 libfontconfig1 libfontconfig1-dev libfreetype6 libfreetype6-dev libgavl-de
Bug#806877: x265: FTBFS when built with dpkg-buildpackage -A (ld: cannot find -lx265_main10)
On Wed, Dec 02, 2015 at 01:18:42PM +0100, Sebastian Ramacher wrote: > On 2015-12-02 12:09:03, Santiago Vila wrote: > > I tried to build this package with "dpkg-buildpackage -A" > > (i.e. only architecture-independent packages), and it failed: > > Do you have a full build log? The interesting stuff is in the snipped part. Yes. I attach two different logs. Note 1: The build was done on stretch/amd64. Note 2: The fact that the failing libraries are x265_main10 and x265_main12 suggests that maybe this has something to do with Bug #804376 or the fix that was applied for that bug. Thanks. x265_1.8-4_amd64-20151114-0944.gz Description: Binary data x265_1.8-4_amd64-20151202-0021.gz Description: Binary data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#806877: x265: FTBFS when built with dpkg-buildpackage -A (ld: cannot find -lx265_main10)
Package: src:x265 Version: 1.8-4 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] debian/rules build-indep dh build-indep --parallel --buildsystem=cmake \ --sourcedirectory=source \ --builddirectory=x265-8bit dh_testdir -i -O--parallel -O--buildsystem=cmake -O--sourcedirectory=source -O--builddirectory=x265-8bit debian/rules override_dh_auto_configure make[1]: Entering directory '/<>' dh_auto_configure --builddirectory=x265-10bit -- \ -DENABLE_PIC=ON \ -DENABLE_CLI=OFF \ -DENABLE_SHARED=OFF \ -DEXPORT_C_API=OFF \ [... snipped ...] cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/slice.cpp.o -c /<>/source/common/slice.cpp [ 77%] Building CXX object common/CMakeFiles/common.dir/lowres.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/lowres.cpp.o -c /<>/source/common/lowres.cpp [ 78%] Building CXX object common/CMakeFiles/common.dir/piclist.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/piclist.cpp.o -c /<>/source/common/piclist.cpp [ 80%] Building CXX object common/CMakeFiles/common.dir/predict.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/predict.cpp.o -c /<>/source/common/predict.cpp [ 81%] Building CXX object common/CMakeFiles/common.dir/scalinglist.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/scalinglist.cpp.o -c /<>/source/common/scalinglist.cpp [ 82%] Building CXX object common/CMakeFiles/common.dir/quant.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/quant.cpp.o -c /<>/source/common/quant.cpp [ 83%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.o cd /<>/x265-8bit/common && /usr/bin/c++ -DEXPORT_C_API=1 -DHAVE_INT_TYPES_H=1 -DHAVE_LIBNUMA -DHIGH_BIT_DEPTH=0 -DX265_ARCH_X86=1 -DX265_DEPTH=8 -DX265_NS=x265 -DX86_64=1 -D__STDC_LIMIT_MACROS=1 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -I/<>/source/. -I/<>/source/common -I/<>/source/encoder -I/<>/x265-8bit-Wall -Wextra -Wshadow -fPIC -Wno-array-bounds -ffast-math -mstackrealign -fno-exceptions -o CMakeFiles/common.dir/deblock.cpp.o -c /<>/source/common/deblock.cpp make[3]: Leaving directory '/<>/x265-8b
Bug#806046: horgand: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
Package: src:horgand Version: 1.14-5 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] fakeroot debian/rules binary-indep dh binary-indep --with autoreconf dh_testroot -i dh_prep -i dh_installdirs -i dh_auto_install -i make -j1 install DESTDIR=/<>/debian/tmp AM_UPDATE_INFO_DIR=no make[1]: Entering directory '/<>' Making install in src make[2]: Entering directory '/<>/src' make[3]: Entering directory '/<>/src' /bin/mkdir -p '/<>/debian/tmp/usr/lib/horgand' /usr/bin/install -c horgand '/<>/debian/tmp/usr/lib/horgand' make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/<>/src' make[2]: Leaving directory '/<>/src' Making install in data make[2]: Entering directory '/<>/data' make[3]: Entering directory '/<>/data' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/<>/debian/tmp/usr/share/horgand' /usr/bin/install -c -m 644 Default.horeb Rhythm_List.txt 130_Houseloop_2.wav AcousticBass.wav crackle_loop01.wav egg_loop01.wav FenderBass.wav FretlessBass.wav frog_loop01.wav funkyfeet1.wav '/<>/debian/tmp/usr/share/horgand' make[3]: Leaving directory '/<>/data' make[2]: Leaving directory '/<>/data' Making install in man make[2]: Entering directory '/<>/man' make[3]: Entering directory '/<>/man' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/<>/debian/tmp/usr/share/man/man1' /usr/bin/install -c -m 644 horgand.1 '/<>/debian/tmp/usr/share/man/man1' make[3]: Leaving directory '/<>/man' make[2]: Leaving directory '/<>/man' make[2]: Entering directory '/<>' make[3]: Entering directory '/<>' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/<>' make[2]: Leaving directory '/<>' make[1]: Leaving directory '/<>' debian/rules override_dh_install make[1]: Entering directory '/<>' dh_install cp debian/horgand.wrapper /<>/debian/horgand/usr/bin/horgand cp: cannot create regular file '/<>/debian/horgand/usr/bin/horgand': No such file or directory debian/rules:10: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 1 make[1]: Leaving directory '/<>' debian/rules:4: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 Sorry not to have a fix, as I am reporting many bugs similar to this one, but I can give some general hints: * If all the arch-independent packages are dummy transitional packages released with jessie, the easy fix is to drop them now. * If not, debian/rules should be modified so that the binary-indep target works in all cases, even when binary-arch is not used (this is what the "Architecture: all" autobuilder does). For that: * If you are using debhelper, you might want to use options -a and -i for dh_* commands so that they do not act on packages they do not have to act. * Also, if you are using dh, the (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo") may be useful to write a debian/rules which behaves exactly as desired. After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, this package will be suitable to be uploaded in source-only form if you wish (you might want to try it). Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
