Bug#669024: Patches for CVE-2012-2090 / CVE-2012-2091
Sorry, my patch for simgear CVE-2012-2091 had an off-by-one error. Corrected version here: https://bugs.launchpad.net/ubuntu/+source/simgear/+bug/1077624/+attachment/3808144/+files/simgear_CVE2012_2091.patch flightgear still needs the two 2.6.0-1.1 patches applying to 2.10, and also has a third similar vulnerability (upstream issue 1117: http://code.google.com/p/flightgear-bugs/issues/detail?id=1117q=2090colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone ), which should be fixed by this patch: https://bugs.launchpad.net/ubuntu/+source/simgear/+bug/1077624/+attachment/3806304/+files/flightgear_bug1117.patch (Related Ubuntu discussion: last few comments on https://bugs.launchpad.net/ubuntu/+source/simgear/+bug/1077624 ) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
Alioth currently appears to be down, but if I remember correctly, that is actually Alberto's patch (as noted above, we both came up with essentially the same fix independently), and other patches in VCS bump the upstream version to 3.2.1rc (avoiding the need for a second round of binNMUs when 3.2.1 comes out: 3.2.0rc is libopenscenegraph99, 3.2.0/3.2.1rc/3.2.1 are libopenscenegraph100, #722674) and fix #724753. I hence suggest uploading the current VCS head (with its version number corrected: having not been intended to be released, it currently has the invalid 3.2.1-rc1-1 instead of 3.2.1~rc1-1) rather than just this patch. Upstream 3.2.1 was originally meant to be out in mid-October, but has evidently been delayed; I can't find a reason or new estimate, but can't look in the obvious place (osg-news) as its archive is private. Reverse dependencies status as far as I can find in the BTS (I have _not_ yet tested any myself; maintainers, if you have a real tracker, please point us to it): Probably just need a binNMU: choreonoid, ossim, simgear*, flightgear* Need source upload, patch exists: libcitygml (#719396), osgearth (#725383), fgrun* (#719402) Broken (but won't be any more broken with this than it already is in 3.2.0rc): openwalnut (#718381 / #719388, latest upstream reported to build but not work properly: http://www.openwalnut.org/issues/298) *I wouldn't bother NMUing simgear/flightgear/fgrun, as these are currently waiting on this bug to upload a new version. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
Apologies for the confusing wording of my previous message: my reverse dependencies status did indeed refer to the already-started libopenscenegraph80-99 transition, not the proposed 99-100. The request for an official transition tracker is now #729289. One more fix that is needed before uploading 3.2.1rc (and may or may not already be there, since I can't check until Alioth comes back up): libopenscenegraph99 and libopenscenegraph100 have file conflicts, so should declare this (see #722674). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
Sorry for not notifying you earlier; given the names on the git commits, I thought Alberto was effectively the maintainer and you his sponsor. Would you like to set up a maintainer-team mailing list to avoid such problems in future? Are you still looking for help (#392266), and if so with what? - fgrun is a bit neglected in Debian, [...] it's already been removed from testing for 2 years The simgear/flightgear/fgrun set was lacking maintenance for some time, but is now in the process of returning with a new maintainer; the problems that got it removed from testing have been fixed, but it can't be rebuilt yet because this bug makes libopenscenegraph-dev uninstallable. I now see that these [reverse dependencies] packages are 'sid only', They're sid-only because this transition stalled for long enough for its FTBFS bugs to trigger the autoremover. Is that an autoremover bug or a feature? Since the transition requested already mentions libopenscenegraph100, but 3.2.1 is not released, I think that it's actually more risky (or prone to more delays) if to tie the current transition to these future ones of OSG. The 99-100 soname bump is 3.2.0rc-3.2.0 not 3.2.0-3.2.1 and appears to be a standard OSG release procedure (possibly intended as a don't use pre-releases in production marker) rather than a real change (https://github.com/openscenegraph/osg/commits/OpenSceneGraph-3.2?page=2, scroll down to Jul 23), so I wouldn't _expect_ further breakage, but I agree it's always possible. (E.g. building with --as-needed, which you do (as recommended), is currently unreliable on ia64: #718047) Furthermore, Alioth is now expected to be down for days (http://lists.debian.org/debian-infrastructure-announce/2013/11/msg1.html), so just getting access to the 3.2.1 package might take some time. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
That's why I'm not so keen on uploading a RC again, given the grief that caused the last one. Maybe we can just patch 3.2.0 and then wait for the 3.2.1, If you mean real 3.2.0 as opposed to the current 3.2.0rc, that could be a good compromise: it has soname 100 (so no need for binNMUs when 3.2.1 comes out) and avoids the need to patch libcitygml (as the bug in that is that it doesn't understand ~rc version numbers). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728521: ogre-1.9 / gcc-4.8
Control: severity 728521 normal Control: merge 725143 728521 It's now official that gcc 4.8 will be required in jessie [1], so this is now not an RC (and could even be closed altogether, though that isn't my decision to make; the current non-working attempts to select gcc-4.8 are ugly, but harmless wherever 4.8+ is the default). s390x are currently switching to 4.8 [2], so another try once they have should fix the out of date on s390x testing blocker. [1] http://lists.debian.org/debian-devel-announce/2013/11/msg7.html [2] http://lists.debian.org/debian-devel/2013/11/msg00449.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728150: (but ia64 isn't keeping up, so nevermind)
Just for the heads up, this bug is currently the only reason why lesstif2 can't be removed from Debian. Thus, I would appreciate an upload (I can sponsor if needed). Given that britney now ignores ia64, a faster way to finish the motif transition would be to just downgrade this bug to important. (I agree that if fixes for this and #672719 exist then they should be applied some time, but suggest letting the above go through first.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729495: possible #729495 patch (untested)
an executable Python file that has #!/usr/bin/env python as first line Code Search finds this in the 4 scripts in src/plugins/grass/scripts, where it is also present in 2.0.1, but I haven't actually tested whether changing this fixes the problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph uninstallable
On 12/11/13 20:59, Manuel A. Fernandez Montecelo wrote: We will discuss it and come up with a plan. Did you decide anything? As the libav transition has now been completed, this bug makes openscenegraph uninstallable. If the problem is that you are busy elsewhere, would you be happy with someone else NMUing the minimal patch (already in Ubuntu, https://launchpad.net/ubuntu/+source/openscenegraph/3.2.0~rc1-1ubuntu1 ; their armhf FTBFS is a long-standing GL-vs-GLES issue that doesn't affect Debian) to get things working again? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph uninstallable
We decided that we would wait a bit to see if the last -rc became final, to avoid unneeded breakages/binNMUs, etc. in the case that they changed the ABI or even API again. This was also partially motivated because of the breakage in alioth which happened around that time. I don't know if Alberto knows the plans of upstream (maybe a Christmas present? :-) ), but I think that the last -rc was almost 2 months ago, 3.2.1~rc1 released 3 Oct, at which point they said 3.2.1 was planned for mid-October and would not break ABI (from 3.2.0, there was a break from 3.2.0~rc1 to 3.2.0): http://www.openscenegraph.org/index.php/download-section/stable-releases Since then, there have been several commits to the 3.2 branch (https://github.com/openscenegraph/osg/commits/OpenSceneGraph-3.2), but no new ~rc or revised estimate. It would be a good idea to ask them before waiting any longer. the more that it goes on the most likely that they disrupt something. I agree that the delay may mean they've found a major bug, and that we hence probably shouldn't upload 3.2.1~rc1, but we don't need that to fix this bug: we can use either 3.2.0 + all patches (http://anonscm.debian.org/gitweb/?p=pkg-osg/pkg-osg.git;a=commit;h=22a14b36635a2736b6e6d22a3003eace10f68071) for soname 100 (i.e. only one round of binNMUs) or 3.2.0~rc1 + just this patch for soname 99 (i.e. avoid new-queue for now). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph uninstallable
Upstream have now said they are waiting for more reports of whether 3.2.1 works before releasing it (their original request for such got only one response), and that a release can happen quickly if they get them: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2013-December/065705.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669024: Patches for CVE-2012-2090 / CVE-2012-2091
Thanks. Are you also applying my corrected CVE-2012-2091 patch to simgear? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: 720816 patch
The url_* functions were removed in libav 9 (having been deprecated in
0.8
http://libav.org/doxygen/release/0.8/avio_8h.html#af4bc39f7600ed162ad8f35e5e15bcd9d
), hence this bug. The attached should fix it, but has not been tested.
Is there a reason we're still using a pre-release when upstream 3.2 has
been released? (That wouldn't fix this particular bug, but might fix
others)
diff -up FFmpegDecoder.cpp FFmpegDecoder_fixed.cpp
--- FFmpegDecoder.cpp 2013-09-08 15:05:37.160056831 +0100
+++ FFmpegDecoder_fixed.cpp 2013-09-08 15:09:20.724050225 +0100
@@ -279,7 +279,7 @@ bool FFmpegDecoder::readNextPacketNormal
int error = av_read_frame(m_format_context.get(), packet);
if (error 0)
{
-if (error == AVERROR_EOF || url_feof(m_format_context.get()-pb))
+if (error == AVERROR_EOF || (m_format_context.get()-pb-eof_reached))
end_of_stream = true;
else {
OSG_FATAL av_read_frame() returned AvStrError(error) std::endl;
Bug#690005: close bug 690005 ??
Why does this show as affecting 2.10.0-x? The build logs appear to show all architectures now compiling (several then fail the test suite, but that's bug 722115). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722115: 722115 patches
The test_cppbind issue appears to be caused by using a plain char
(unsigned on affected platforms) to hold -1: it can be triggered on
amd64 by the -funsigned-char compiler flag, and is there fixed by the
attached patch.
I can't reproduce the binobj bug, but enabling -fno-strict-aliasing may
fix it, as it uses a lot of casts that are undefined without it (mostly
for endianness reversal, which fits with the error only appearing on
big-endian machines).
diff -up flightgear_source/simgear-2.10.0/simgear/nasal/data.h_orig flightgear_source/simgear-2.10.0/simgear/nasal/data.h
--- flightgear_source/simgear-2.10.0/simgear/nasal/data.h_orig 2013-09-09 22:40:33.107742921 +0100
+++ flightgear_source/simgear-2.10.0/simgear/nasal/data.h 2013-09-09 22:06:43.595678127 +0100
@@ -96,7 +96,7 @@ struct naObj {
#define MAX_STR_EMBLEN 15
struct naStr {
GC_HEADER;
-char emblen; /* [0-15], or -1 to indicate not embedded */
+signed char emblen; /* [0-15], or -1 to indicate not embedded */
unsigned int hashcode;
union {
unsigned char buf[16];
diff -up debian/rules_orig debian/rules
--- debian/rules_orig 2013-09-12 23:01:10.938897982 +0100
+++ debian/rules 2013-09-12 23:00:56.358898413 +0100
@@ -6,8 +6,8 @@
#http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
-CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS)
-CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
+CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) -fno-strict-aliasing
+CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) -fno-strict-aliasing
LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
CMAKE_FLAGS = \
Bug#723129: should not be Architecture: any
Package: emscripten Severity: serious Tags: patch Emscripten is marked Architecture: any, but indirectly (via nodejs) depends on libv8-3.14.5 which is not, and is hence rejected from testing for unsatisfiable dependencies. The standard fix for that (http://www.debian.org/doc/manuals/developers-reference/pkgs.html#packages-arch-specific) would be to change the Architecture line of debian/control to Architecture: i386 kfreebsd-i386 amd64 kfreebsd-amd64 armel armhf mipsel and request removal of the existing broken binaries. Is there a reason nobody has done this, or has it just not been noticed? (If the build process actually does as little as suggested by the buildd logs, Architecture: all might work and would then be a better option, but I haven't investigated that in detail.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722115: 722115 patches
Following private discussion, this version of the patch enables -fno-strict-aliasing selectively by architecture, to avoid possibly slowing down those that don't need it. (I included sparc, which currently works, because the big-endian code is undefined as opposed to guaranteed wrong, and hence might break later from an apparently unrelated change.) If this is what the problem is, it is still present in 2.12rc, and the same fix should work there. diff -up debian/rules_orig debian/rules --- debian/rules_orig 2013-09-12 23:01:10.938897982 +0100 +++ debian/rules 2013-09-16 23:55:27.712339252 +0100 @@ -6,8 +6,14 @@ #http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) +ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 i386 mipsel ia64 armel armhf arm64)) CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) +else +#required on big-endian architectures, see bug 722115 +CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) -fno-strict-aliasing +CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) -fno-strict-aliasing +endif LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) CMAKE_FLAGS = \
Bug#723803: fix for arm/powerpc/s390 test failures
src/simulator/wireframe-simulator/core/vpLex.c assumes that the plain chars CURC and NEXTC can hold -1 (EOF) or -2 (EOB), and hence fails if char is unsigned. This is the default on arm*/powerpc/s390, hence this bug, and can be tested elsewhere using -funsigned-char. The attached fixes this by explicitly casting them to signed char. I don't know what's wrong on ia64; given that the last successful build on it was before the test suite was added (and hence may well be just as broken), and that this package is a transition blocker for coin3/opencv2.4/libav9, would it make sense to remove it on that architecture? diff -up /home/palmer/flightgear_source/ViSP-2.8.0/src/simulator/wireframe-simulator/core/vpLex.c_orig /home/palmer/flightgear_source/ViSP-2.8.0/src/simulator/wireframe-simulator/core/vpLex.c --- /home/palmer/flightgear_source/ViSP-2.8.0/src/simulator/wireframe-simulator/core/vpLex.c_orig 2013-09-22 11:58:14.822567806 +0100 +++ /home/palmer/flightgear_source/ViSP-2.8.0/src/simulator/wireframe-simulator/core/vpLex.c 2013-09-22 12:57:05.754575672 +0100 @@ -239,9 +239,9 @@ void close_lex (void) #define ECHO printf (%c, *(mysptr)) -#define CURC (*mysptr) /* caractere courant */ -#define NEXTC (*(mysptr+1)) /* caractere suivant */ -#define PREVC (*(mysptr-1)) /* caractere precedent */ +#define CURC (*((signed char *)mysptr)) /* caractere courant */ +#define NEXTC (*((signed char *)mysptr+1)) /* caractere suivant */ +#define PREVC (*((signed char *)mysptr-1)) /* caractere precedent */ /*
Bug#723129: (no subject)
That fixes the source package, but you also need to have the existing broken binaries removed: https://wiki.debian.org/ftpmaster_Removals -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719402: fgrun rebuild
Control: tags -1 patch The above occurs because fgrun uses an old version of simgear which doesn't support openscenegraph 3.2; recompiling against simgear 2.10+ (which requires the attached patch because the library names changed) should fix it. Tell fgrun that simgear's library names have changed. $ diff -up fgrun-1.6.0/src/Makefile.am_orig fgrun-1.6.0/src/Makefile.am --- fgrun-1.6.0/src/Makefile.am_orig 2011-09-11 16:55:39.0 +0100 +++ fgrun-1.6.0/src/Makefile.am 2013-10-02 22:22:59.902444571 +0100 @@ -33,7 +33,7 @@ fgrun_SOURCES = \ util.cxx util.h \ $(platform_srcs) -simgear_libs = -lsgmodel -lsgscreen -lsgprops -lsgxml -lsgdebug -lsgbvh -lsgmaterial -lsgmodel -lsgutil -lsgstructure -lsgprops -lsgtgdb -lsgmath -lsgmisc -lsgbvh -lsgio -lsgbucket -lsgmodel -lsgutil -lsgthreads +simgear_libs = -lSimGearScene -lSimGearCore fgrun_LDADD = $(simgear_libs) $ diff -up fgrun-1.6.0/src/Makefile.in_orig fgrun-1.6.0/src/Makefile.in --- fgrun-1.6.0/src/Makefile.in_orig 2011-09-11 16:55:41.0 +0100 +++ fgrun-1.6.0/src/Makefile.in 2013-10-02 22:22:58.670444608 +0100 @@ -247,7 +247,7 @@ fgrun_SOURCES = \ util.cxx util.h \ $(platform_srcs) -simgear_libs = -lsgmodel -lsgscreen -lsgprops -lsgxml -lsgdebug -lsgbvh -lsgmaterial -lsgmodel -lsgutil -lsgstructure -lsgprops -lsgtgdb -lsgmath -lsgmisc -lsgbvh -lsgio -lsgbucket -lsgmodel -lsgutil -lsgthreads +simgear_libs = -lSimGearScene -lSimGearCore fgrun_LDADD = $(simgear_libs) all: $(BUILT_SOURCES) config.h $(MAKE) $(AM_MAKEFLAGS) all-am $ diff -up fgrun-1.6.0/debian/control_orig fgrun-1.6.0/debian/control --- fgrun-1.6.0/debian/control_orig 2011-11-09 11:43:42.0 + +++ fgrun-1.6.0/debian/control 2013-10-02 22:41:06.662412461 +0100 @@ -3,7 +3,7 @@ Section: games Priority: optional Maintainer: Debian FlightGear Crew pkg-fgfs-c...@lists.alioth.debian.org Uploaders: Christopher Baines cbain...@gmail.com -Build-Depends: debhelper (= 8.9.9), autotools-dev, libfltk1.1-dev, simgear-dev (= 2.4.0), libboost-dev, zlib1g-dev (= 1:1.2.3.4.dfsg-3) +Build-Depends: debhelper (= 8.9.9), autotools-dev, libfltk1.1-dev, libsimgear-dev, libboost-dev, zlib1g-dev (= 1:1.2.3.4.dfsg-3) Standards-Version: 3.9.2 Homepage: http://fgrun.sourceforge.net/
Bug#724713: (no subject)
The Breaks: is correct; the problem is known upstream (http://bugs.jython.org/issue2087), but there is currently no fix. If you're trying to rebuild sikuli for the opencv2.4 transition, you might want to use testing-proposed-updates (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712615#45). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723129: emscripten: broken binaries need to be removed
Was this just overlooked, or are you planning a different fix? That fixes the source package, but you also need to have the existing broken binaries removed: https://wiki.debian.org/ftpmaster_Removals -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724186: frei0r: fix for new automake
Control: tags 724186 patch This appears to be caused by the default Automake being upgraded to 1.14, and should be fixed by the attached patch. Fix build with automake1.14 (#724186) $ diff -up debian/rules_orig debian/rules --- debian/rules_orig 2013-10-10 19:04:50.764234000 +0100 +++ debian/rules 2013-10-10 20:18:21.580104091 +0100 @@ -14,4 +14,4 @@ clean:: makebuilddir:: libtoolize -f - autoreconf -fs + autoreconf -ifs $ diff -up configure.ac_orig configure.ac --- configure.ac_orig 2010-01-15 14:59:03.0 + +++ configure.ac 2013-10-10 20:01:37.636133754 +0100 @@ -5,7 +5,7 @@ AC_PREREQ(2.59c) AC_INIT(frei0r-plugins, [1.1.22], [richard.spind...@gmail.com]) AC_CONFIG_MACRO_DIR([m4]) -AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION) +AM_INIT_AUTOMAKE([subdir-objects]) # Checks for programs. AC_PROG_CXX
Bug#724186: frei0r: fix for new automake
The only change _required_ now is adding -i to autoreconf (in debian/rules), but it seemed a good idea to also fix the deprecation warnings (copied below) before they become errors in a future version. configure.ac:8: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: configure.ac:8: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation configure.ac:12: installing './compile' src/Makefile.am:72: warning: source file 'filter/3dflippo/3dflippo.c' is in a subdirectory, src/Makefile.am:72: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722610: retry with new libav?
Libav 9.10 is now in unstable; you might want to retry with that. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726487: frei0r build can't find opencv
Source: frei0r Severity: serious Tags: patch frie0r's build process can't find opencv, probably because it depends on libcv-dev and the .pc files are now (since 2.3.1-9) in libopencv-dev. The build succeeds as using opencv is optional, but I don't know how much functionality this disables (feel free to adjust the severity as appropriate). It worked on my system because I do have libopencv-dev installed, which suggests that adding that as a build-dep would fix the problem, but I don't have time right now to test that properly. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726487: player build can't find opencv either
Control: clone 726487 -1 -2 Control: reassign -2 player player also has this bug; it appears that nothing else does. Both of them have had this bug in Ubuntu for about a year without anyone noticing (which suggests the functionality in question isn't widely used); I have reported it there as https://bugs.launchpad.net/ubuntu/+source/player/+bug/1240608 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723099: taoframework: fix for libav 9
Removal shouldn't be necessary: this bug should be fixable by simply
updating the libav* version numbers in
src/Tao.FFmpeg/Tao.FFmpeg.dll.config (patch attached, replaces all three
existing libav*update patches), though I haven't tested this.
Also, your libav{codec,format}-dev build-dependencies should be updated
to =6:9, as the same problem would occur if libav was older than this
file expects.
Update libav version numbers
$ diff -up Tao.FFmpeg.dll.config_orig Tao.FFmpeg.dll.config
--- Tao.FFmpeg.dll.config_orig 2013-10-17 19:12:08.372519000 +0100
+++ Tao.FFmpeg.dll.config 2013-10-17 19:13:44.032516362 +0100
@@ -1,15 +1,15 @@
configuration
dllmap dll=avcodec-51.dll os=windows target=avcodec-51.dll /
dllmap dll=avcodec-51.dll os=osx target=libavcodec.so.51 /
-dllmap dll=avcodec-51.dll os=!windows,osx target=libavcodec.so.51 /
+dllmap dll=avcodec-51.dll os=!windows,osx target=libavcodec.so.54 /
dllmap dll=avformat-52.dll os=windows target=avformat-52.dll /
dllmap dll=avformat-52.dll os=osx target=libavformat.so.52 /
-dllmap dll=avformat-52.dll os=!windows,osx target=libavformat.so.52 /
+dllmap dll=avformat-52.dll os=!windows,osx target=libavformat.so.54 /
dllmap dll=avutil-49.dll os=windows target=avutil-49.dll /
dllmap dll=avutil-49.dll os=osx target=libavutil.so.49 /
-dllmap dll=avutil-49.dll os=!windows,osx target=libavutil.so.49 /
+dllmap dll=avutil-49.dll os=!windows,osx target=libavutil.so.52 /
dllmap dll=swscale-0.dll os=windows target=swscale-0.dll /
dllmap dll=swscale-0.dll os=osx target=libswscale.so.0 /
Bug#726561: player build can't find opencv
Ubuntu tried the fix I suggested above, but the result was an FTBFS on amd64: https://bugs.launchpad.net/ubuntu/+source/player/+bug/1246306 https://launchpadlibrarian.net/155392274/buildlog_ubuntu-trusty-amd64.player_3.0.2%2Bdfsg-4.1ubuntu1_FAILEDTOBUILD.txt.gz It doesn't look like an opencv-related problem (so the current version may also be unbuildable in the new toolchain), but I haven't tested this yet. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735891: patch
Control: tags -1 patch
This bug also exists on amd64 in current sid, and the attached patch
appears to fix it (builds and has the same file list as the current
package, except for choreonoid-doc where doxygen has changed its naming
convention; I haven't tried running it).
commit a316937c9b2e26e45b2912c1d5070a09edf502b0
Author: Rebecca Palmer r.pal...@bham.ac.uk
Date: Tue Jan 21 22:44:41 2014 +
Install also when CMAKE_BUILD_TYPE=None, as set by new dh. Closes: #735891.
diff --git a/debian/patches/0004-Install-choreonoid-program-always.patch b/debian/patches/0004-Install-choreonoid-program-always.patch
new file mode 100644
index 000..0521684
--- /dev/null
+++ b/debian/patches/0004-Install-choreonoid-program-always.patch
@@ -0,0 +1,22 @@
+Subject: Install choreonoid program in all build types
+
+Install choreonoid program in all build types,
+for compatibility with newer debhelper
+
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735891
+Forwarded: not-needed (this line is commented out completely in v1.4)
+Author: Thomas Moulard thomas.moul...@gmail.com, Rebecca Palmer
+---
+ src/Choreonoid/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Choreonoid/CMakeLists.txt b/src/Choreonoid/CMakeLists.txt
+index 80d3c4c..39715b5 100644
+--- a/src/Choreonoid/CMakeLists.txt
b/src/Choreonoid/CMakeLists.txt
+@@ -30,4 +30,4 @@ if(MSVC)
+ set_target_properties(${target} PROPERTIES DEBUG_POSTFIX -debug)
+ endif()
+
+-install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release Debug)
++install(TARGETS ${target} RUNTIME DESTINATION bin)
diff --git a/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch b/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
deleted file mode 100644
index 80e71d6..000
--- a/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-From: Thomas Moulard thomas.moul...@gmail.com
-Date: Thu, 9 May 2013 00:11:16 +0900
-Subject: Install choreonoid program when build type is RelWithDebInfo.
-
-Install choreonoid program when build type is RelWithDebInfo.
-
-Forwarded: yes
-Author: Thomas Moulard thomas.moul...@gmail.com
- src/Choreonoid/CMakeLists.txt | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/Choreonoid/CMakeLists.txt b/src/Choreonoid/CMakeLists.txt
-index 80d3c4c..39715b5 100644
a/src/Choreonoid/CMakeLists.txt
-+++ b/src/Choreonoid/CMakeLists.txt
-@@ -30,4 +30,4 @@ if(MSVC)
- set_target_properties(${target} PROPERTIES DEBUG_POSTFIX -debug)
- endif()
-
--install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release Debug)
-+install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release Debug RelWithDebInfo)
diff --git a/debian/patches/0009-Install-libraries-always.patch b/debian/patches/0009-Install-libraries-always.patch
new file mode 100644
index 000..8d0a727
--- /dev/null
+++ b/debian/patches/0009-Install-libraries-always.patch
@@ -0,0 +1,58 @@
+Description: Install libraries in all build types
+
+Install libraries in all build types,
+for compatibility with newer debhelper
+
+Author: Rebecca Palmer
+Bug-Debian: http://bugs.debian.org/735891
+Forwarded: no
+--- choreonoid-1.1.0+dfsg.orig/CMakeLists.txt
choreonoid-1.1.0+dfsg/CMakeLists.txt
+@@ -331,20 +331,18 @@ function(apply_common_setting_for_librar
+
+ if(INSTALL_SDK)
+ install(TARGETS ${target}
+- RUNTIME DESTINATION bin CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
++ RUNTIME DESTINATION bin
+ LIBRARY DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE}
+- CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
+- ARCHIVE DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE}
+- CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel)
++ ARCHIVE DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE})
+ if(headers)
+ get_filename_component(subdir ${CMAKE_CURRENT_SOURCE_DIR} NAME_WE)
+ install(FILES ${headers} DESTINATION ${CNOID_HEADER_SUBDIR}/cnoid/src/${subdir})
+ endif()
+ else()
+ install(TARGETS ${target}
+- RUNTIME DESTINATION bin CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
++ RUNTIME DESTINATION bin
+ LIBRARY DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE}
+- CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel)
++ )
+ endif()
+
+ endfunction()
+@@ -356,17 +354,17 @@ function(apply_common_setting_for_plugin
+
+ if(INSTALL_SDK)
+ install(TARGETS ${target}
+- RUNTIME DESTINATION ${CNOID_PLUGIN_SUBDIR} CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
+- LIBRARY DESTINATION ${CNOID_PLUGIN_SUBDIR} CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
+- ARCHIVE DESTINATION ${CNOID_PLUGIN_SUBDIR} CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel)
++ RUNTIME DESTINATION ${CNOID_PLUGIN_SUBDIR}
++ LIBRARY DESTINATION
Bug#735891: please upload
I haven't tried running it I have now: I couldn't find how to get the Scene window to actually show anything (this isn't a package I normally use) and trying to open a file of the wrong type could crash it, but those are also the case in the existing version. This bug is blocking two transitions (icu and openscenegraph), so an early upload would be appreciated. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735891: intent to NMU #735891 FTBFS: dh_install: choreonoid missing files (usr/bin/*), aborting
Attached is a proposed NMU that fixes this bug (identical to the above
patch other than adding the changelog entry). Please let us know if you
do not want this; if you remain silent, it is likely to be uploaded
without further warning.
diff -Nru choreonoid-1.1.0+dfsg/debian/changelog
choreonoid-1.1.0+dfsg/debian/changelog
--- choreonoid-1.1.0+dfsg/debian/changelog 2013-09-26 06:25:11.0
+0100
+++ choreonoid-1.1.0+dfsg/debian/changelog 2014-02-02 22:30:58.0
+
@@ -1,3 +1,11 @@
+choreonoid (1.1.0+dfsg-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Install binary and libraries also when CMAKE_BUILD_TYPE=None,
+as used by new dh. Closes: #735891.
+
+ -- Rebecca Palmer r.pal...@bham.ac.uk Sun, 02 Feb 2014 22:23:06 +
+
choreonoid (1.1.0+dfsg-6) unstable; urgency=low
* Remove debian/libcnoid1.symbols (Closes: #708991, #713355)
diff -Nru
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-always.patch
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-always.patch
---
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-always.patch
1970-01-01 01:00:00.0 +0100
+++
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-always.patch
2014-01-21 21:35:52.0 +
@@ -0,0 +1,22 @@
+Subject: Install choreonoid program in all build types
+
+Install choreonoid program in all build types,
+for compatibility with newer debhelper
+
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735891
+Forwarded: not-needed (this line is commented out completely in v1.4)
+Author: Thomas Moulard thomas.moul...@gmail.com, Rebecca Palmer
+---
+ src/Choreonoid/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Choreonoid/CMakeLists.txt b/src/Choreonoid/CMakeLists.txt
+index 80d3c4c..39715b5 100644
+--- a/src/Choreonoid/CMakeLists.txt
b/src/Choreonoid/CMakeLists.txt
+@@ -30,4 +30,4 @@ if(MSVC)
+ set_target_properties(${target} PROPERTIES DEBUG_POSTFIX -debug)
+ endif()
+
+-install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release
Debug)
++install(TARGETS ${target} RUNTIME DESTINATION bin)
diff -Nru
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
---
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
2013-09-26 00:34:56.0 +0100
+++
choreonoid-1.1.0+dfsg/debian/patches/0004-Install-choreonoid-program-when-build-type-is-RelWit.patch
1970-01-01 01:00:00.0 +0100
@@ -1,22 +0,0 @@
-From: Thomas Moulard thomas.moul...@gmail.com
-Date: Thu, 9 May 2013 00:11:16 +0900
-Subject: Install choreonoid program when build type is RelWithDebInfo.
-
-Install choreonoid program when build type is RelWithDebInfo.
-
-Forwarded: yes
-Author: Thomas Moulard thomas.moul...@gmail.com
- src/Choreonoid/CMakeLists.txt | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/Choreonoid/CMakeLists.txt b/src/Choreonoid/CMakeLists.txt
-index 80d3c4c..39715b5 100644
a/src/Choreonoid/CMakeLists.txt
-+++ b/src/Choreonoid/CMakeLists.txt
-@@ -30,4 +30,4 @@ if(MSVC)
- set_target_properties(${target} PROPERTIES DEBUG_POSTFIX -debug)
- endif()
-
--install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release
Debug)
-+install(TARGETS ${target} RUNTIME DESTINATION bin CONFIGURATIONS Release
Debug RelWithDebInfo)
diff -Nru
choreonoid-1.1.0+dfsg/debian/patches/0009-Install-libraries-always.patch
choreonoid-1.1.0+dfsg/debian/patches/0009-Install-libraries-always.patch
--- choreonoid-1.1.0+dfsg/debian/patches/0009-Install-libraries-always.patch
1970-01-01 01:00:00.0 +0100
+++ choreonoid-1.1.0+dfsg/debian/patches/0009-Install-libraries-always.patch
2014-01-21 22:40:45.0 +
@@ -0,0 +1,58 @@
+Description: Install libraries in all build types
+
+Install libraries in all build types,
+for compatibility with newer debhelper
+
+Author: Rebecca Palmer
+Bug-Debian: http://bugs.debian.org/735891
+Forwarded: no
+--- choreonoid-1.1.0+dfsg.orig/CMakeLists.txt
choreonoid-1.1.0+dfsg/CMakeLists.txt
+@@ -331,20 +331,18 @@ function(apply_common_setting_for_librar
+
+ if(INSTALL_SDK)
+ install(TARGETS ${target}
+- RUNTIME DESTINATION bin CONFIGURATIONS Release Debug RelWithDebInfo
MinSizeRel
++ RUNTIME DESTINATION bin
+ LIBRARY DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE}
+- CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel
+- ARCHIVE DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE}
+- CONFIGURATIONS Release Debug RelWithDebInfo MinSizeRel)
++ ARCHIVE DESTINATION lib/${CMAKE_LIBRARY_ARCHITECTURE})
+ if(headers)
+ get_filename_component(subdir ${CMAKE_CURRENT_SOURCE_DIR} NAME_WE)
+ install(FILES ${headers}
Bug#737733: [Flightgear-devel] simgear: license issue
Fortunately, this problem has been solved elsewhere in Debian before - here's a legal replacement: http://sources.debian.net/src/dpkg/1.17.6/lib/compat (They no longer use it as MD5 is now too easy to break, but it still works if you're only checking for accidental corruption.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737733: fixed (but will soon be fixed more neatly)
Control: severity -1 normal Today's upload no longer builds the BSD-with-advertising-clause simgear/package/md5.* (and hence avoids triggering its GPL incompatibility); upstream plan to remove it completely by 3.0 final. It also updates debian/copyright as requested. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738436: flightgear/simgear version mismatch
Control: retitle -1 flightgear/simgear version mismatch Control: tags -1 patch This error occurs because flightgear needs the matching version of simgear, so should go away when we upload flightgear 3.0.0~ (currently in Alioth). (Given that this happens every release, this dependency should probably be stated at the debian/control level.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735653: don't just drop the 1.8
The current version builds fine with Ruby 1.9, but later upstream versions successfully produce near-empty packages. See #738635 for the fix. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737153: OpenCVModules.cmake not installed, causing visp FTBFS
Debian doesn't have a /usr/share/OpenCV/java/libopencv_java248.so, but it does have a /usr/lib/libopencv_java248.so in libopencv2.4-jni; does build-depending on that help? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737153: OpenCVModules.cmake not installed, causing visp FTBFS
libopencv-dev doesn't pull in the Java libraries; I don't know if the appropriate fix is that it should, or that the cmake script shouldn't be looking for them when building C(++). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739460: osg: patches test results
I've successfully built openscenegraph in sid with the patches for #739460 and #687332, and tested it with flightgear, confirming that they fix those bugs (for #739460, fixed meaning builds with libav 10, and still has an osgdb_ffmpeg.so; I don't know if we have any packages that actually use that plugin). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748503: jitsi: this isn't the FTBFS, #747789 is
Control: retitle -1 jitsi: documentation not built Control: tags -1 jessie sid Control: severity -1 normal jitsi has always had these error: unmappable character for encoding error: unmappable character for encoding ASCII messages (due to non-ASCII characters in comments), but though they contain error, they only fail javadoc, which does not stop the build; what does is the failure to find json-simple (#747789). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph uninstallable
Control: block 724686 by -1 Control: block 719402 by -1 Upstream may be releasing 3.2.1 soon, but there is still no definite date (http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2013-December/065775.html). As far as I can tell, the only packaging change needed (beyond what has already been done in Alioth) is to declare the conflicts with 3.2.0rc (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722674#10). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732405: upstream's #732405+#650575(?) fixes
The upstream source (http://cpansearch.perl.org/src/KARASIK/Prima-1.37/img/codec_tiff.c) gained a new #ifndef at lines 175-177 that would appear to be the fix, but I haven't tested this. There's also something similar at http://cpansearch.perl.org/src/KARASIK/Prima-1.37/img/codec_png.c lines 281-285 that looks like a fix for #650575. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732405: upstream's #732405+#650575 fixes
Control: tags 732405 patch
Control: tags 650575 patch
Confirmed that 1.28 with these fixes builds in sid and in experimental +
alioth's libpng1.6.7, though I haven't tried to use either result.
An essentially identical libtiff fix (but not the libpng fix) is already
in Ubuntu: https://launchpad.net/ubuntu/+source/prima/+changelog
Note that dropping the whole of upstream 1.37 into the existing
packaging fails at debian/rules line 32, as img/codecs.c no longer exists.
diff -u prima-1.28/debian/changelog prima-1.28/debian/changelog
--- prima-1.28/debian/changelog
+++ prima-1.28/debian/changelog
@@ -1,3 +1,10 @@
+prima (1.28-2) UNRELEASED; urgency=low
+
+ * Cherry-pick from upstream: allow compilation with newer versions of
+libtiff and libpng. Closes: #732405, #650575.
+
+ -- Rebecca Palmer palmer@lap14 Thu, 09 Jan 2014 09:43:46 +
+
prima (1.28-1.1) unstable; urgency=medium
* Non-maintainer upload.
only in patch2:
unchanged:
--- prima-1.28.orig/img/codec_png.c
+++ prima-1.28/img/codec_png.c
@@ -279,7 +279,11 @@
{
char * buf = ( char *) png_get_error_ptr( png_ptr);
if ( buf) strncpy( buf, msg, 256);
+#if PNG_LIBPNG_VER_MAJOR == 1 PNG_LIBPNG_VER_MINOR 5
longjmp( png_ptr- jmpbuf, 1);
+#else
+ png_longjmp( png_ptr, 1);
+#endif
}
static void
only in patch2:
unchanged:
--- prima-1.28.orig/img/codec_tiff.c
+++ prima-1.28/img/codec_tiff.c
@@ -161,6 +161,10 @@
{ COMPRESSION_SGILOG24, SGILOG24},
};
+#ifndef TIFF_VERSION
+#define TIFF_VERSION TIFF_VERSION_CLASSIC
+#endif
+
static ImgCodecInfo codec_info = {
TIFF Bitmap,
www.libtiff.org,
Bug#704713: (no subject)
Control: merge -1 732848 This package is now uninstallable, as its binNMU for libglew1.7-1.10 failed with this bug. Making it build again now also requires another fix for automake1.11, which is also already in Ubuntu: https://launchpad.net/ubuntu/+source/gimp-plugin-registry/5.20120621ubuntu3 I have checked that this builds in sid (amd64 pbuilder) without further changes, but have not tried to actually use it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719396: no longer blocked by #720816
Control: merge -1 718385 openscenegraph is now installable again, still with an ~rc version. Note that this assumes that release candidates are sufficiently compatible with the corresponding final versions. They have different sonames (libopenscenegraph99/100 in the present case), but this *appears* to be a standard this is not the final release notice rather than a real API break. Note however that the libopenscenegraph-dev package no longer contains static libraries at all since 3.2.0~rc1-1, so if that's what -static in the package name means, that part will have to go altogether. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735891: FTBFS: dh_install: choreonoid missing files (usr/bin/*), aborting
Package: choreonoid Version: 1.1.0+dfsg-6 Severity: serious choreonoid FTBFS on mips* and armel. Failed builds have [...compiles successfully...] /usr/bin/cmake -P cmake_install.cmake -- Install configuration: None [...installs only some files, and in particular not /usr/bin/choreonoid] dh_install -a -O--parallel dh_install: choreonoid missing files (usr/bin/*), aborting (Full log: https://buildd.debian.org/status/fetch.php?pkg=choreonoidarch=mipselver=1.1.0%2Bdfsg-6stamp=1390018740 ) Successful builds have [...compiles successfully...] /usr/bin/cmake -P cmake_install.cmake -- Install configuration: RelWithDebInfo [...installs everything...] dh_install -a -O--parallel [succeeds] (Full log: https://buildd.debian.org/status/fetch.php?pkg=choreonoidarch=i386ver=1.1.0%2Bdfsg-6stamp=1380253859 ) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735891: FTBFS: dh_install: choreonoid missing files (usr/bin/*), aborting
armhf has now also failed, as have all the recent builds (the successes were several months ago, before #720816 made this package temporarily BD-Uninstallable). I suspect the cause is this change in debhelper's defaults: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701233#27 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735814: ossim: FTBFS: multiarch related?
This looks like a lack of multiarch support: this package adopted libtiff5 before that had pkg-config or multiarch, and expects to find it in the old directories (./configure lines ~7650). Given that 1.8 has a new build system that does know how to find multiarch tiff5, and has successfully done so in the UbuntuGIS PPA (https://launchpadlibrarian.net/145422701/buildlog_ubuntu-quantal-amd64.ossim_1.8.16~1ubuntu4_UPLOADING.txt.gz), it might be best to switch to that, though I have not tried to build it in Debian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735828: spatialite: why not transition?
Now that openscenegraph is fixed (and assuming the new qgis builds), what is now blocking the spatialite transition (which would fix this and #688328)? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719396: no longer blocked by #720816
Control: unmerge -1 (I wanted them merged the other way round, ie this one becoming the listed bug, but that evidently isn't possible) so if that's what -static in the package name means, that part will have to go altogether. It evidently doesn't: the patch above is sufficient to build the package in current sid (amd64). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739743: FTBFS: circular dependency
Package: libfontconfig1 Severity: serious fontconfig recently added a build-dependency on docbook-utils, and hence an indirect build-dependency on itself. As the arch:any libfontconfig1 has an exact version dependency on the arch:all fontconfig-config, this causes the build to fail on all architectures other than the first: https://buildd.debian.org/status/package.php?p=fontconfig -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735814: ossim: FTBFS: configure: error: libtiff support required!
There's also some work on ossim 1.8.16 here http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-January/017876.html , but it seems to have been abandoned. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739743: FTBFS: circular dependency
If only the documentation requires this dependency, a better solution would be to put it in an arch:all package (fontconfig-config or a new (beware queue delay) fontconfig-doc) and use build-depends-indep (https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps). However, if you can't do that quickly, I'd go with the previous solution as a temporary measure, as this bug makes ~all GUI packages BD-Uninstallable on non-amd64. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766251: flightgear fails to start with *** stack smashing detected ***
Package: flightgear-data-base
Version: 3.0.0-1
Severity: grave
Justification: renders package unusable
Control: tags -1 patch
A fresh install (no .fgfs) of amd64 flightgear in current jessie or
current sid fails to start:
Program received signal SIGABRT, Aborted.
0x71d6f077 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0 0x71d6f077 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 25441
selftid = 25441
#1 0x71d70458 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x3020702d77722030,
sa_sigaction = 0x3020702d77722030}, sa_mask = {__val =
{2319406791620833328, 2319389199435444272, 2314885530818453536,
2314885530818453536, 2314885530818453536, 6731583338252032800,
7378697629483820554, 3472328296331896422, 7378697629483806000,
3472609797883717222, 2337500343188860976, 3472328296227680304,
3467824696768081952, 2314885530818453536, 2314885530818453536,
140737488344416}}, sa_flags = 60, sa_restorer = 0x7fffd660}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x71dacfb4 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x71e9d60b *** %s ***: %s terminated\n) at
../sysdeps/posix/libc_fatal.c:175
ap = {{gp_offset = 32, fp_offset = 32767, overflow_arg_area =
0x7fffd670, reg_save_area = 0x7fffd600}}
fd = 18
on_2 = optimized out
list = optimized out
nlist = optimized out
cp = optimized out
written = optimized out
#3 0x71e300a7 in __GI___fortify_fail
(msg=msg@entry=0x71e9d5f3 stack smashing detected) at
fortify_fail.c:31
No locals.
#4 0x71e30070 in __stack_chk_fail () at stack_chk_fail.c:28
No locals.
#5 0x76c99569 in simgear::PredicateExpressionint,
std::equal_to::eval (this=0xb6d9e70, value=optimized out,
b=optimized out) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:1184
No locals.
#6 0x770b1e72 in getValue (binding=0x7fffd730,
this=optimized out) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:126
value = true
#7 simgear::AndExpression::eval (this=0xb6da340, value=@0x7fffd750:
true, b=0x7fffd730) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:1266
i = 0
#8 0x770afd03 in getValue (binding=0x7fffd730,
this=optimized out) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:126
value = true
#9 simgear::Technique::validateInContext (this=0xb6d9bc0, gc=optimized
out) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/scene/material/Technique.cxx:122
oldVal = simgear::Technique::QUERY_IN_PROGRESS
binding = {simgear::expression::Binding = {_vptr.Binding =
0x7742e670 vtable for
simgear::expression::FixedLengthBinding1+16}, _bindings = {{typeTag =
simgear::expression::INT, val = {boolVal = false, intVal = 0, floatVal =
0, doubleVal = 0
contextId = 0
newVal = simgear::Technique::INVALID
#10 0x751ef556 in osg::GraphicsContext::runOperations() () from
/usr/lib/x86_64-linux-gnu/libosg.so.100
No symbol table info available.
#11 0x758a2d08 in osgViewer::ViewerBase::renderingTraversals()
() from /usr/lib/x86_64-linux-gnu/libosgViewer.so.100
No symbol table info available.
#12 0x00b989ea in fgOSMainLoop() ()
No symbol table info available.
#13 0x005f94ee in fgMainInit(int, char**) ()
No symbol table info available.
#14 0x005a00ff in main ()
No symbol table info available.
It looks like the problem is casting simgear::ConvertExpressiondouble,
float* (derived from SGExpressiondouble*,
simgear/structure/SGExpression.hxx:11xx) to SGExpressionint*:
(gdb) frame 5
#5 0x76c99569 in simgear::PredicateExpressionint,
std::equal_to::eval (this=0xb6d9e70, value=optimized out,
b=optimized out) at
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:1184
1184
/build/simgear-mmipqT/simgear-3.0.0/simgear/structure/SGExpression.hxx:
No such file or directory.
(gdb) print *(simgear::PredicateExpressionint, std::equal_to *) 0xb6d9e70
$2 = {simgear::GeneralNaryExpressionbool, int =
{SGExpressionbool = {simgear::Expression = {SGReferenced =
{_refcount = {mValue = 1}}, _vptr.Expression = 0x76f26150 vtable
for simgear::EqualToExpressionint+16}, No data fields},
_expressions = std::vector of length 2, capacity 2 = {{_ptr =
0xb6d9de0}, {_ptr = 0xb6d9e10}}}, _pred = {std::binary_functionint,
int, bool = {No data fields}, No data fields}}
(gdb) print *(SGExpressionbool *) 0xb6d9de0
$22 = {simgear::Expression = {SGReferenced = {_refcount = {mValue =
1}}, _vptr.Expression = 0x76f25e50 vtable for
Bug#765818: simgear: FTBFS[kfreebsd]: wrong usage of GL/glxext.h
Control: reassign -1 src:simgear Control: found -1 3.0.0-5 Control: merge -1 765932 These are both the same kfreebsd FTBFS; this (#765818) patch looks better, but I haven't tried either. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766251: flightgear fails to start with *** stack smashing detected ***
The debian/patches/series mechanism won't patch DOS-line-ending files
such as Effects/model-combined-transparent.eff, so the attached manually
applies the patch in debian/rules instead.
It also downgrades -ai, -aircrafts to Recommends as suggested earlier; I
have quickly tested that FlightGear works without these, but nothing
beyond that. (This is independent of the bug fix, but if we're going to
do it, we should probably do it when we're uploading it anyway.)
diff --git a/debian/changelog b/debian/changelog
index fe90b25..b856dbc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+flightgear-data (3.0.0-2) UNRELEASED; urgency=medium
+
+ * Fix type mismatch crash. Closes: #766251.
+ * Downgrade -ai, -aircrafts to Recommends.
+
+ -- Rebecca N. Palmer rebecca_pal...@zoho.com Wed, 22 Oct 2014 18:27:01
+0100
+
flightgear-data (3.0.0-1) unstable; urgency=low
[ Markus Wanner ]
diff --git a/debian/control b/debian/control
index 817ed1d..23e0e00 100644
--- a/debian/control
+++ b/debian/control
@@ -64,10 +64,10 @@ Package: flightgear-data-all
Architecture: all
Depends:
flightgear-data-base (= 3.0.0~),
- flightgear-data-ai (= 3.0.0~),
- flightgear-data-aircrafts (= 3.0.0~),
flightgear-data-models (= 3.0.0~),
${misc:Depends}
+Recommends: flightgear-data-ai (= 3.0.0~),
+ flightgear-data-aircrafts (= 3.0.0~)
Description: FlightGear Flight Simulator - virtual package
FlightGear is a free and highly sophisticated flight simulator.
.
diff --git a/debian/patches/766251.patch b/debian/patches/766251.patch
new file mode 100644
index 000..da2d905
--- /dev/null
+++ b/debian/patches/766251.patch
@@ -0,0 +1,19 @@
+Description: Fix type mismatch crash in SGExpression
+
+(This patch is applied in debian/rules rather than debian/patches/series,
+as the latter can't patch a DOS-line-ending file)
+
+Author: Rebecca N. Palmer rebecca_pal...@zoho.com
+Forwarded: not-needed
+Bug-Debian: https://bugs.debian.org/766251
+--- flightgear-data-3.0.0.orig/Effects/model-combined-transparent.eff
flightgear-data-3.0.0/Effects/model-combined-transparent.eff
+@@ -12,7 +12,7 @@ and fallback to plain transparency when
+ and
+ equal
+
float-property/sim/rendering/shaders/model/float-property
+- value type=int0/value
++ value type=float0/value
+ /equal
+ or
+ less-equal
diff --git a/debian/rules b/debian/rules
index 0be03d6..f7f272f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,8 @@ override_dh_auto_install:
dh_installdirs -pflightgear-data-aiusr/share/games/flightgear
dh_installdirs -pflightgear-data-aircrafts usr/share/games/flightgear
dh_installdirs -pflightgear-data-modelsusr/share/games/flightgear
+#apply patch (can't use debian/patches/series as it can't patch a
DOS-line-ending file)
+ patch -p1 --binary debian/patches/766251.patch
# Contents of flightgear-data-base
cp -av \
@@ -96,6 +98,8 @@ override_dh_auto_install:
$(CURDIR)/debian/flightgear-data-ai/usr/share/games/flightgear/AI/Aircraft/A330-MRTT/COPYING
\
$(CURDIR)/debian/flightgear-data-base/usr/share/games/flightgear/ATC/Chatter/BR/LICENCE.txt
\
$(CURDIR)/debian/flightgear-data-base/usr/share/games/flightgear/Aircraft/Generic/Engines/LICENSE
+#clean up
+ patch -p1 -R --binary debian/patches/766251.patch
Bug#766251: patch line endings
dpkg-source --commit produced a patch with all Unix line endings, which failed; running that through unix2dos gave a patch with all DOS line endings, which also failed, with (Stripping trailing CRs from patch; use --binary to disable.) patching file Effects/model-combined-transparent.eff Hunk #1 FAILED at 12 (different line endings). 1 out of 1 hunk FAILED dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch '766251.patch' is correctly applied by quilt, use 'quilt refresh' to update it Evidently what is required is Unix in the headers and DOS in the actual patch lines. I consider it a bug that dpkg-source --commit doesn't produce that, but haven't yet reported it. Since this is an arch:all package, it only needs to build on your system. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764930: beignet: FTBFS - uses versioned llvm commands, but unversioned build dependency
Control: tags -1 patch
This occurs because beignet currently expects llvm 3.4 but Depends: on
the default, which recently changed to 3.5 (#760050); the attached fixes
it by explicitly using 3.4 everywhere.
(Testing note: Due to linux bug #767148, neither the existing beignet
nor this version work in current sid without
$ sudo sh -c echo -n 0 /sys/module/i915/parameters/enable_cmd_parser
_Warning_: I do not know whether this workaround is a security risk.)
I tried actually switching to 3.5, but this didn't build, and README.md
says it would only work if LLVM was compiled with --enable-cxx11, which
Debian's isn't; I hence suggest staying with 3.4 for Jessie.
diff -Nru beignet-0.8/debian/control beignet-0.8/debian/control
--- beignet-0.8/debian/control 2014-09-11 16:43:33.0 +0100
+++ beignet-0.8/debian/control 2014-10-28 11:56:51.0 +
@@ -4,9 +4,9 @@
Build-Depends: debhelper (= 9), cmake, pkg-config, python-minimal,
ocl-icd-dev, ocl-icd-opencl-dev,
libdrm-dev, libxfixes-dev, libxext-dev,
- llvm-dev (= 1:3.4),
- clang (= 1:3.4),
- libclang-dev (= 1:3.4),
+ llvm-3.4-dev,
+ clang-3.4,
+ libclang-3.4-dev,
libgl1-mesa-dev (= 9) [!kfreebsd-any],
libegl1-mesa-dev (= 9) [!kfreebsd-any],
libgbm-dev (= 9) [!kfreebsd-any],
diff -Nru beignet-0.8/debian/patches/versioned-llvm-tools
beignet-0.8/debian/patches/versioned-llvm-tools
--- beignet-0.8/debian/patches/versioned-llvm-tools 2014-04-19
18:54:55.0 +0100
+++ beignet-0.8/debian/patches/versioned-llvm-tools 2014-10-28
12:17:01.0 +
@@ -1,9 +1,20 @@
Description: Use versioned LLVM tools
-Author: Simon Richter s...@debian.org
-Last-Update: 2014-04-19
+Description: short summary of the patch
+Author: Simon Richter s...@debian.org, Rebecca N. Palmer
rebecca_pal...@zoho.com
+Bug-Debian: https://bugs.debian.org/759933,https://bugs.debian.org/764930
--- beignet-0.8.orig/backend/src/CMakeLists.txt
+++ beignet-0.8/backend/src/CMakeLists.txt
+@@ -58,8 +58,8 @@ set (clang_cmd ${clang_cmd} -fno-builtin
+ add_custom_command(
+ OUTPUT ${pch_object}
+ COMMAND rm -f ${pch_object}
+- COMMAND clang ${clang_cmd} --relocatable-pch -emit-pch -isysroot
${CMAKE_CURRENT_BINARY_DIR} ${ocl_blob_file} -o ${pch_object}
+- COMMAND clang ${clang_cmd} -emit-pch ${ocl_blob_file} -o
${local_pch_object}
++ COMMAND clang-3.4 ${clang_cmd} --relocatable-pch -emit-pch -isysroot
${CMAKE_CURRENT_BINARY_DIR} ${ocl_blob_file} -o ${pch_object}
++ COMMAND clang-3.4 ${clang_cmd} -emit-pch ${ocl_blob_file} -o
${local_pch_object}
+ DEPENDS ${ocl_blob_file}
+ )
+
@@ -71,14 +71,14 @@ macro(ll_add_library ll_lib ll_sources)
add_custom_command(
OUTPUT ${ll}.bc
Bug#767384: libjogl2-java: non-DFSG file in test suite
Source: libjogl2-java Version: 2.2.4-1 Severity: serious Justification: Policy 2.1 Control: found -1 2.1.5-2 src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/shader/landscape.fp has a NonCommercial license, which is not allowed in Debian (even if the file isn't actually used: https://release.debian.org/jessie/rc_policy.txt ). (Given https://lists.debian.org/debian-release/2014/10/msg00590.html , you may want to ask the release team _before_ uploading a fix.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767387: beignet: Non-free files in test suite
Package: beignet Version: 0.8-1.1 Severity: serious Justification: Policy 2.1 Control: tags -1 patch upstream X-Debbugs-CC: pkg-opencl-de...@lists.alioth.debian.org The beignet test suite contains three images derived from Lenna ( kernels/lenna128x128.bmp kernels/compiler_box_blur_float_ref.bmp kernels/compiler_box_blur_ref.bmp ), which is non-distributable ( https://bugs.debian.org/758442 ). It also contains a number of OpenCL kernels and expected outputs stated in utests/compiler_shader_toy.cpp to be derived from shaders on Shadertoy ( kernels/compiler_chocolux.cl kernels/compiler_chocolux_ref.bmp kernels/compiler_clod.cl kernels/compiler_clod_function_call.cl kernels/compiler_clod_ref.bmp kernels/compiler_julia.cl kernels/compiler_julia_function_call.cl kernels/compiler_julia_no_break.cl kernels/compiler_julia_no_break_ref.bmp kernels/compiler_julia_ref.bmp kernels/compiler_mandelbrot.cl kernels/compiler_mandelbrot_alternate.cl kernels/compiler_mandelbrot_alternate_ref.bmp kernels/compiler_mandelbrot_ref.bmp kernels/compiler_menger_sponge.cl kernels/compiler_menger_sponge_no_shadow.cl kernels/compiler_menger_sponge_no_shadow_ref.bmp kernels/compiler_menger_sponge_ref.bmp kernels/compiler_nautilus.cl kernels/compiler_nautilus_ref.bmp kernels/compiler_ribbon.cl kernels/compiler_ribbon_ref.bmp ), with no explicitly stated license. These particular shaders are no longer on Shadertoy, but its default license and that author's usual one ( https://www.shadertoy.com/user/iq/sort=name ) is CC-BY-NC-SA, which is not DFSG-free. Since we don't run the test suite in the build anyway (servers typically don't have the required GPU hardware) deleting all of these should be harmless; if the second group do turn out to have permission, they can be added back later. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764930: [Pkg-opencl-devel] Bug#764930: beignet: FTBFS - uses versioned llvm commands, but unversioned build dependency
I'm just wondering where the build failure in late August with exactly those dependencies came from and why the change fixed them? during compilation clang was called but could not be found: [...] Only the clang metapackage but not the clang-some.version package provides /usr/bin/clang. Agreed; my patch instead fixes that by extending versioned-llvm-tools.patch to add -3.4 to that call as well. If you're offering to NMU this, it would be a good idea to put back the patch description header I accidentally deleted, and to do #767387 at the same time. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767387: beignet: Non-free files in test suite
Control: forwarded -1 http://lists.freedesktop.org/archives/beignet/2014-October/004343.html I have reported this upstream; they have agreed it's a problem and are in the process of removing the first group and investigating the second. To deal with this problem in the meantime, we will need to repack the orig tarball (which the version just added to Alioth does _not_ do); the new version would then conventionally be called 0.8+dfsg1-0.1 or 0.9.3+dfsg1-0.1. Also note that as the first group is undistributable (not just non-DFSG), creating an Alioth repository that includes the previous versions may not be a good idea. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767387: [Pkg-opencl-devel] Bug#767387: beignet: Non-free files in test suite
*mandelbrot* were included in this report by mistake, and are actually OK to keep. Now it FTBFS (it was working before the dfsg changes), tail of buildlog: I get the same error with git-buildpackage, but success with dpkg-buildpackage (as root in cowbuilder --login chroot; not cowbuilder --build because I wanted the test suite)...not sure what to make of that (are the quotes around OCL_PCM_PATH relevant? I don't have them:) [ 8%] Generating ../../src/kernels/cl_internal_built_in_kernel_str.c cd /home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/src rm -rf /home/rnpalmer/Debian/builds/stackbuild/beignet/src/kernels//cl_internal_built_in_kernel_str.c cd /home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/src OCL_PCM_PATH=/home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/backend/src/beignet.bc:/usr/lib/beignet//beignet.bc OCL_PCH_PATH=/home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/backend/src/usr/lib/beignet/ocl_stdlib.h.local.pch:/usr/lib/beignet//ocl_stdlib.h.pch LD_LIBRARY_PATH=/home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/backend/src /home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/backend/src/gbe_bin_generater -s /home/rnpalmer/Debian/builds/stackbuild/beignet/src/kernels//cl_internal_built_in_kernel.cl -o/home/rnpalmer/Debian/builds/stackbuild/beignet/src/kernels//cl_internal_built_in_kernel_str.c /usr/bin/cmake -E cmake_progress_report /home/rnpalmer/Debian/builds/stackbuild/beignet/obj-x86_64-linux-gnu/CMakeFiles 2 The attached patch disables the removed tests, but that's only required if you actually want to run the others, which our normal build doesn't. debian/source/include-binaries probably shouldn't be there, but removing it doesn't help. Description: Skip deleted tests Parts of the test suite are omitted from this package because they are not DFSG-free. Skip those parts to allow running the rest. Author: Rebecca Palmer rebecca_pal...@zoho.com Bug-Debian: https://bugs.debian.org/767387 diff --git a/utests/CMakeLists.txt b/utests/CMakeLists.txt index 9c531de..43965ac 100644 --- a/utests/CMakeLists.txt +++ b/utests/CMakeLists.txt @@ -22,12 +22,8 @@ set (utests_sources utest_error.c compiler_basic_arithmetic.cpp compiler_displacement_map_element.cpp - compiler_shader_toy.cpp compiler_mandelbrot.cpp compiler_mandelbrot_alternate.cpp - compiler_box_blur_float.cpp - compiler_box_blur_image.cpp - compiler_box_blur.cpp compiler_insert_to_constant.cpp compiler_argument_structure.cpp compiler_arith_shift_right.cpp
Bug#764930: [Pkg-opencl-devel] Bug#764930: beignet: FTBFS - uses versioned llvm commands, but unversioned build dependency
You have my blessing to change the maintainer field if you like, as I won't be able to do as much as is needed in the next days. It would probably make sense for the pkg-opencl-devel list to own this package; I'm willing to be named as uploader, but will need a sponsor to actually upload anything. There is a regression in the last NMU: Ubuntu LLVM has a different epoch, Not any more: https://launchpadlibrarian.net/188131885/buildlog_ubuntu-vivid-amd64.beignet_0.8-1.1_FAILEDTOBUILD.txt.gz (FTBFS with this bug, not BD-Uninstallable) There's two Ubuntu bugs that are fixed in 0.9.3: LP#1372889 and LP#1350773. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767387: beignet 0.8+dfsg-1
This is my proposed freeze-policy-compliant 0.8+dfsg-1 for jessie (0.9.3
would go to jessie-backports). Please do not upload right now as it
hasn't been tested yet.
It may still happen that we decide to drop beignet from jessie and just
have 0.9.3 in -backports, but I'd rather not be rushed into choosing.
Non-DFSG files deleted:
kernels/lenna128x128.bmp kernels/compiler_box_blur_float_ref.bmp
kernels/compiler_box_blur_ref.bmp kernels/compiler_chocolux.cl
kernels/compiler_chocolux_ref.bmp kernels/compiler_clod.cl
kernels/compiler_clod_function_call.cl kernels/compiler_clod_ref.bmp
kernels/compiler_julia.cl kernels/compiler_julia_function_call.cl
kernels/compiler_julia_no_break.cl
kernels/compiler_julia_no_break_ref.bmp kernels/compiler_julia_ref.bmp
kernels/compiler_menger_sponge.cl
kernels/compiler_menger_sponge_no_shadow.cl
kernels/compiler_menger_sponge_no_shadow_ref.bmp
kernels/compiler_menger_sponge_ref.bmp kernels/compiler_nautilus.cl
kernels/compiler_nautilus_ref.bmp kernels/compiler_ribbon.cl
kernels/compiler_ribbon_ref.bmp
Debian directory diff:
diff -Nru beignet-0.8/debian/changelog beignet-0.8+dfsg/debian/changelog
--- beignet-0.8/debian/changelog2014-09-12 17:11:43.0 +0100
+++ beignet-0.8+dfsg/debian/changelog 2014-11-01 14:08:08.0 +
@@ -1,3 +1,13 @@
+beignet (0.8+dfsg-1) unstable; urgency=medium
+
+ * Change of maintainer.
+ * Remove non-DFSG tests. (Closes: #767387)
+ * Revert to LLVM/Clang 3.4, update versioned-llvm-tools.patch.
+(Closes: #764930)
+ * State in the description what hardware this supports.
+
+ -- Rebecca N. Palmer rebecca_pal...@zoho.com Sat, 01 Nov 2014
14:01:26 +
+
beignet (0.8-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru beignet-0.8/debian/control beignet-0.8+dfsg/debian/control
--- beignet-0.8/debian/control 2014-09-11 16:43:33.0 +0100
+++ beignet-0.8+dfsg/debian/control 2014-11-01 14:01:06.0 +
@@ -1,12 +1,16 @@
Source: beignet
Priority: extra
-Maintainer: Simon Richter s...@debian.org
+Maintainer: Debian OpenCL Maintainers
pkg-opencl-de...@lists.alioth.debian.org
+Uploaders:
+ Simon Richter s...@debian.org,
+ Rebecca N. Palmer rebecca_pal...@zoho.com,
+ Andreas Beckmann a...@debian.org,
Build-Depends: debhelper (= 9), cmake, pkg-config, python-minimal,
ocl-icd-dev, ocl-icd-opencl-dev,
libdrm-dev, libxfixes-dev, libxext-dev,
- llvm-dev (= 1:3.4),
- clang (= 1:3.4),
- libclang-dev (= 1:3.4),
+ llvm-3.4-dev,
+ clang-3.4,
+ libclang-3.4-dev,
libgl1-mesa-dev (= 9) [!kfreebsd-any],
libegl1-mesa-dev (= 9) [!kfreebsd-any],
libgbm-dev (= 9) [!kfreebsd-any],
@@ -34,9 +38,13 @@
Conflicts: beignet0.0.1
Replaces: beignet0.0.1
Provides: opencl-icd
-Description: Intel OpenCL library
+Description: OpenCL library for Intel Ivy Bridge GPUs
OpenCL (Open Computing Language) is a multivendor open standard for
general-purpose parallel programming of heterogeneous systems that
include
CPUs, GPUs and other processors.
.
This package contains the shared library for the Intel implementation.
+ .
+ This version of the package supports only Ivy Bridge GPUs
+ (HD Graphics 2500/4000, Core ix-3xxx); versions supporting new hardware
+ will be made available in -backports.
diff -Nru beignet-0.8/debian/patches/versioned-llvm-tools
beignet-0.8+dfsg/debian/patches/versioned-llvm-tools
--- beignet-0.8/debian/patches/versioned-llvm-tools 2014-04-19
18:54:55.0 +0100
+++ beignet-0.8+dfsg/debian/patches/versioned-llvm-tools 2014-11-01
13:28:17.0 +
@@ -1,9 +1,20 @@
Description: Use versioned LLVM tools
-Author: Simon Richter s...@debian.org
-Last-Update: 2014-04-19
+Author: Simon Richter s...@debian.org, Rebecca N. Palmer
rebecca_pal...@zoho.com
+Bug-Debian: https://bugs.debian.org/759933,https://bugs.debian.org/764930
--- beignet-0.8.orig/backend/src/CMakeLists.txt
+++ beignet-0.8/backend/src/CMakeLists.txt
+@@ -58,8 +58,8 @@ set (clang_cmd ${clang_cmd} -fno-builtin
+ add_custom_command(
+ OUTPUT ${pch_object}
+ COMMAND rm -f ${pch_object}
+- COMMAND clang ${clang_cmd} --relocatable-pch -emit-pch -isysroot
${CMAKE_CURRENT_BINARY_DIR} ${ocl_blob_file} -o ${pch_object}
+- COMMAND clang ${clang_cmd} -emit-pch ${ocl_blob_file} -o
${local_pch_object}
++ COMMAND clang-3.4 ${clang_cmd} --relocatable-pch -emit-pch
-isysroot ${CMAKE_CURRENT_BINARY_DIR} ${ocl_blob_file} -o ${pch_object}
++ COMMAND clang-3.4 ${clang_cmd} -emit-pch ${ocl_blob_file} -o
${local_pch_object}
+ DEPENDS ${ocl_blob_file}
+ )
+
@@ -71,14 +71,14 @@ macro(ll_add_library ll_lib ll_sources)
add_custom_command(
OUTPUT ${ll}.bc
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768090: beignet: pow(n), erf(c), tgamma give wrong results
Package: beignet
Version: 0.9.3~dfsg-1
Severity: serious
Justification: a math library should NOT silently give wrong answers
Control: found -1 0.8-1.1
Control: tags -1 upstream patch
In current beignet (0.8, 0.9.3 and upstream-HEAD):
-pow/pown ignore the sign of their first argument (e.g. pow(-2,3) gives
8 instead of -8)
-erf/erfc diverge (instead of converging to 1 or 0) for arguments above
about 2
-tgamma is actually lgamma, a related but very different function (and
the test suite doesn't notice because it checks against glibc's gammaf,
which is also lgamma, instead of tgammaf)
#!/usr/bin/env python3
#Depends: python3-pyopencl python3-scipy
import pyopencl
import pyopencl.array
import numpy as np
import scipy.special as spfn
import time
ctx=pyopencl.create_some_context()
cq=pyopencl.CommandQueue(ctx)
a1=np.array(-0.95*np.random.rand(1e6)-0.01,dtype=np.float32)
a2=-1000*a1
a3=20*(a1+0.5)
ai=np.array(a3,dtype=np.int32)
aCL1=pyopencl.array.to_device(cq,a1)
aCL2=pyopencl.array.to_device(cq,a2)
aCL3=pyopencl.array.to_device(cq,a3)
aCLi=pyopencl.array.to_device(cq,ai)
bCL=aCL1+1
c=np.array(range(20),dtype=np.float32)/3-2
ci=np.array(c,dtype=np.int32)
cCL=pyopencl.array.to_device(cq,c)
cCLi=pyopencl.array.to_device(cq,ci)
dCL=cCL+1
def approx_erfc(x):
p = 0.3275911
a1 = 0.254829592
a2 = -0.284496736
a3 = 1.421413741
a4 = -1.453152027
a5 = 1.061405429
d = np.exp(-x*x)
t = 1/(1+p*np.abs(x))
r = (a1*t+a2*t*t+a3*t*t*t+a4*t*t*t*t+a5*t*t*t*t*t)*d
return r*np.sign(x)+1-np.sign(x)
erfc_err=np.abs(spfn.erfc(a3)-approx_erfc(a3))
print(x:,c,\n,ci)
print(erfc:,np.max(erfc_err),np.mean(erfc_err))
f_to_test=[(cos,np.cos),(sin,np.sin),(tan,np.tan),(cosh,np.cosh),(cospi,lambda x:np.cos(np.pi*x)),(tanh,np.tanh),(exp,np.exp),(log,np.log),(sqrt,np.sqrt),(acos,np.arccos),(acosh,np.arccosh),(pow(a[i],c[i]),lambda x,y:x**y),(pown(a[i],d[i]),lambda x,y:x**y),(tgamma,spfn.gamma),(erf,spfn.erf),(erfc,spfn.erfc)]
for f in f_to_test:
for aCL in aCL1,aCL2,aCL3:
fCL=pyopencl.elementwise.ElementwiseKernel(ctx,float *a,float *b,float *c,int *d,b[i]=+f[0]+( if f[0] in (pow(a[i],c[i]),pown(a[i],d[i]),powr(a[i],c[i])) else (a[i])))
t0=time.time()
fCL(aCL,bCL,aCL3,aCLi).wait()
t=time.time()-t0
b=bCL.get()
if f[0] in (pow(a[i],c[i]),powr(a[i],c[i])):
b0=f[1](aCL.get(),a3)
elif f[0] in (pown(a[i],d[i]),):
b0=f[1](aCL.get(),ai)
else:
b0=f[1](aCL.get())
abserr=np.abs(b-b0)
relerr=np.abs(b/b0-1)
print(f[0],abs avg err:,np.nanmean(abserr), max err:,np.max(abserr),rel avg err:,np.nanmean(relerr), max err:,np.max(relerr), time:,t)
if f[0] in (erf,erfc,tgamma,pown(a[i],d[i]),pow(a[i],c[i])):
fCL(cCL,dCL,cCL,cCLi).wait()
if f[0] in (pow(a[i],c[i]),powr(a[i],c[i])):
d0=f[1](c,c)
elif f[0] in (pown(a[i],d[i]),):
d0=f[1](c,ci)
else:
d0=f[1](c)
print(dCL.get(),\n,d0)
Description: short summary of the patch
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
beignet (0.9.3~dfsg-2) UNRELEASED; urgency=medium
.
* Fix tgamma,pow,pown,erf,erfc
* Enable debug output in tests
Author: Rebecca N. Palmer rnpalmer@rnpalmer-laptop
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: https://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- beignet-0.9.3~dfsg.orig/utests/builtin_acos_asin.cpp
+++ beignet-0.9.3~dfsg/utests/builtin_acos_asin.cpp
@@ -2,12 +2,13 @@
#include cmath
#include algorithm
-#define udebug 0
+#define udebug 1
#define printf_c(...) \
{\
printf(\033[1m\033[40;31m);\
printf( __VA_ARGS__ );\
printf(\033[0m);\
+ status = 1;\
}
const float input_data[] = {-30, -1, -0.92, -0.5, -0.09, 0, 0.09, 0.5, 0.92, 1, 30};
@@ -29,6 +30,7 @@ static void builtin_acos_asin(void)
{
// Setup kernel and buffers
int k, i, index_cur;
+ int status = 0;
float gpu_data[max_function * count_input] = {0}, cpu_data[max_function * count_input] = {0};
OCL_CREATE_KERNEL(builtin_acos_asin);
@@ -82,6 +84,7 @@ static void builtin_acos_asin(void)
#endif
}
}
+ OCL_ASSERT(status == 0);
}
MAKE_UTEST_FROM_FUNCTION(builtin_acos_asin)
--- beignet-0.9.3~dfsg.orig/utests/builtin_pow.cpp
+++ beignet
Bug#768090: beignet: pow/erf/tgamma, GBE_DEBUG, constants bug
Fix committed to Alioth. This fix has been accepted upstream; they found that it exposed another bug that compare and type-convert don't properly handle constants (http://lists.freedesktop.org/archives/beignet/2014-November/004387.html), so I included the fix for that as well. My own testing had missed this because GBE_DEBUG was off in our build, probably by accident (debhelper's default build type fairly recently changed from RelWithDebInfo to None, see #701233) and the test data used in compiler_constant_expr are all positive; I've turned it on again as I'd rather have an obvious error than silently broken code. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: #769072,#769191: nvidia-opencl-icd breaking non-nvidia systems
I think the trigger is nvidia-opencl-icd adding a new dependency on libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to be capable of doing dlopen(libcuda.so) or dlopen(libcuda.so.1).), which pulls in the rest of nvidia-* as libcuda1 Recommends: nvidia-kernel-dkms which Recommends: nvidia-driver. Next question, why did you have nvidia-opencl-icd in the first place? I suspect the answer is probably https://bugs.debian.org/739176 which has already been fixed. It can't be pyopencl if it's still installed (that now Depends: libopencl-1.2-1 and both providers of that Conflict: libopencl1 as provided by nvidia-libopencl1), but it could have been if it were then removed (perhaps after noticing that it didn't work). The only other Depends or Recommends on opencl-icd in the current archive is bfgminer. (If you actually want to use OpenCL on Intel hardware, you need beignet from experimental (the version in unstable/testing is too old to support Haswell) and ocl-icd-libopencl1, but the absence of those shouldn't break graphics.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: Bug#769072: #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
Rebecca Palmerr wrote: The only other [than pyopencl] Depends or Recommends on opencl-icd in the current archive is bfgminer. Sorry...only ones found by path:debian/control opencl-icd in sources.debian.net search (apt-cache rdepends doesn't work on virtual packages), which evidently doesn't search non-free as it missed that nvidia-libopencl1 Recommends: nvidia-opencl-icd. Nathaniel Smith wrote: Looking through my apt history, it looks like the critical operation that gave me nvidia stuff was the installation of libboost[-all-dev] (!?): libboost-all-dev Depends: libboost-mpi-dev Depends: libboost-mpi1.55-dev Depends: libboost-mpi1.55.0 Depends: libhwloc5 Recommends: libhwloc-plugins, which at the time had Depends: libopencl-1.1-1, a virtual package provided by (among other things) nvidia-libopencl1, which Recommends: nvidia-opencl-icd. This has already been reported (#739409) and fixed: libhwloc-plugins now Depends: ocl-icd-libopencl1 | libopencl-1.1-1. However, cutting the chain there doesn't remove nvidia-opencl-icd if already installed, hence this bug. On 23/11/14 02:09, Andreas Beckmann wrote: I don't know how seriously the missing libcuda1 breaks nvidia-opencl-icd. I can see that this is being dlopen()ed, but at least clinfo still reports something about the GPU. I don't have a better testcase right now, suggestions welcome. If you want a quick does OpenCL work test, try python3 accuracy_speed_test.py (from https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=accuracy_speed_test.py;att=1;bug=768090 , Depends: python3-pyopencl, python3-scipy ). (Note that some of those tests are expected to give high/NaN errors because not all the inputs used are valid for all the functions: for the present purpose we're mainly looking for crashes/exceptions.) Given that we also don't want to break systems that are intentionally using nvidia-opencl-icd, a better fix might be for whatever sets nvidia as default graphics provider to only do so if the hardware is present, but I don't know whether that's practical. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: Bug#769072: #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
a better fix might be for whatever sets nvidia as default graphics provider to only do so if the hardware is present, but I don't know whether that's practical. The package already has a check in http://sources.debian.net/src/nvidia-graphics-drivers/340.46-5/debian/libgl1-nvidia-glx.preinst.in that offers to abort an install/upgrade on hardware that is too old for the new driver version, but it doesn't warn for hardware that isn't Nvidia at all (deliberately, according to the changelog; the warning currently suggests using nvidia-legacy-304xx-driver instead, which is the right solution for old Nvidia hardware but probably as bad as plain nvidia-driver on non-Nvidia hardware). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: Bug#769072, #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
(Should we merge these bugs? Also, #767803 looks like another instance of this, though it doesn't have the apt log to confirm it yet) * nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1 to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver. ...or drop this Recommends: entirely (IIRC circular Depends/Recommends are discouraged because they confuse apt's autoremover, though I can't find where I saw that). Cutting the chain here (tested with apt-get install nvidia-libopencl1 nvidia-driver-, the - after a package means remove/don't install) does still allow much of nvidia-* (including nvidia-kernel-dkms and glx-alternative-nvidia) to be installed, but that appears to be harmless without libgl1-nvidia-glx (at least on my Intel IvyBridge M GT2, both graphics and OpenCL continue to work after rebooting). Given that the error on loading nvidia-opencl-icd in a non-Nvidia system is modprobe: ERROR: could not insert 'nvidia_current': No such device it is plausible that nvidia-opencl-icd uses the nvidia kernel module (i.e. nvidia-kernel-dkms | nvidia-kernel-version) and as such _should_ pull it in (whether or not it also needs libcuda1), while #768185 suggests that nvidia-opencl-icd works without the graphics side (can someone check that?), making this the more correct place to cut the chain. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: Bug#769072, #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
* nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1 to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver. #768185 suggests that nvidia-opencl-icd works without the graphics side (can someone check that?), making this the more correct place to cut the chain. Sorry, that may not be such a good idea. #768185 says Nvidia OpenCL + Intel graphics can coexist; it says nothing about what would happen to an Nvidia-hardware-only system with nvidia kernel module (which blacklists the nouveau kernel module) + nouveau graphics userspace, which under the above would be the result of trying to install OpenCL on a previously nouveau-using system. That leaves the options of cutting nvidia-opencl-icd - libcuda1 and accepting broken OpenCL as less bad than broken graphics, or making the libgl1-nvidia-glx.preinst.in do you really want to install this? warning trigger on non-Nvidia hardware. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767367: nvidia-opencl-icd dependencies
what would happen to an Nvidia-hardware-only system with nvidia kernel module (which blacklists the nouveau kernel module) + nouveau graphics userspace, which under [nvidia-kernel-dkms Recommends: nvidia-driver | libcuda1] would be the result of trying to install OpenCL on a previously nouveau-using system. Did you test this (i.e. apt-get install nvidia-opencl-icd libcuda1 with Nvidia hardware but no already-installed *nvidia* packages)? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751082#27 suggests the result is no graphics. (Having it be a Recommends: nvidia-driver rather than a hard Depends already allows the headless GPGPU case, and cutting nvidia-opencl-icd - libcuda1 is enough to fix the original accidental nvidia-opencl-icd on inappropriate hardware problem.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767367: [Pkg-opencl-devel] Bug#767367: nvidia-opencl-icd dependencies
nouveau is not blacklisted ... the kernel module would probably get loaded by a cuda application #580894 (the original reason for the blacklist) has conflicting reports of what would happen next: some report nvidia.ko gets control (=blank screen if the graphics side isn't installed), some that nouveau.ko does. It also may have changed since, and isn't testable in a chroot. It must be possible to have *all* installed at the same time and to switch between them without package removal (since only one can be active at a time). I agree that that's the ideal solution in the long term but too much of a change for jessie. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776913: flightgear-data-all: new upstream version needed by flightgear/experimental
This is an intentionally abandoned transition: a serious bug delayed the (upstream) release of 3.2 past (Ubuntu and Debian) freezes, and 3.4 is due before the next Ubuntu freeze (LP#1414379). If you urgently want 3.2, dropping the 3.2 flightgear-data upstream into the 3.0.0-1 (not -2) packaging will probably work, but this has not been tested. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774873: Circular dependency in java-headless packages
I installed openjdk-7-jre:i386 on an amd64 system and for some reason openjdk-7-jre:amd64 has been pulled as well. That's probably because of this dependency cycle: multiarch treats arch:all packages as the native architecture (https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages), i.e. openjdk-7-jre:i386 - ca-certificates-java:all - openjdk-7-jre:amd64 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: beignet: [regression] broken on Haswell
now every kernel invocation, regardless of arguments counts and array sizes, fails i.e. including ones that worked in 1.0.2-1? Do they use the 'local' memory space (which triggers a third known bug on Haswell)? drm_intel_gem_bo_context_exec() failed: Invalid argument That's the error check added by this patch, but not the same error code as I get for a too-large array on Ivy Bridge (that's drm_intel_gem_bo_context_exec() failed: No space left on device), so may be it catching a different bug. I will report this upstream. sudo cat /sys/module/i915/parameters/enable_cmd_parser returns 1 That means you don't have the #767148 workaround enabled. Does it ( sudo echo 0 /sys/module/i915/parameters/enable_cmd_parser ) help? What are your other i915 parameters ( sudo head /sys/module/i915/parameters/* )? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: silently does nothing on large arrays (was ICD interface (only) broken on Haswell)
Control: retitle -1 beignet: silently does nothing on large arrays (previous discussion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875 ) This isn't a Haswell-specific problem (and might not be ICD-specific either: did you test that at these sizes, or only with the testsuite?), it's a large-array-specific problem: I simply hadn't tried arrays that big before. The array size required to trigger it decreases as the number of arrays (arguments to the kernel being run, not total existing) increases, suggesting a total-memory limit: on my system, approximately 2x240Mifloat, 3x160Mifloat, or 5x100Mifloat, but these vary ~10% from run to run. (Hence, re-adding the per-array size limit probably wouldn't completely avoid the problem, though I haven't actually tried that.) These sizes do _not_ appear to depend on free system memory, but due to their variability and the limited range I can test before running into running out of memory in beignet hangs the entire system (https://bugs.launchpad.net/ubuntu/+source/beignet/+bug/1354086 ), I cannot be completely sure of this. #!/usr/bin/env python3 #Depends: python3-pyopencl python3-numpy from __future__ import division,print_function import pyopencl import pyopencl.array import numpy as np import time import pyopencl.clmath ctx=pyopencl.create_some_context() cq=pyopencl.CommandQueue(ctx) asize=100*(2**20)#fails above approx. 235 for 2-array, 162 for 3-array, 100 for 5-array, but the exact number varies #Warning: very large sizes will hang your system, https://bugs.launchpad.net/ubuntu/+source/beignet/+bug/1354086 aCL=pyopencl.array.arange(cq,0,asize,1,dtype='float32') bCL=pyopencl.array.arange(cq,0,asize,1,dtype='float32') cCL=pyopencl.array.arange(cq,0,asize,1,dtype='float32') dCL=pyopencl.array.arange(cq,0,asize,1,dtype='float32') eCL=pyopencl.array.arange(cq,0,asize,1,dtype='float32') print(CL arrays created) ans=aCL[0:1000].get()*4 f2=pyopencl.elementwise.ElementwiseKernel(ctx,pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *a,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *c,c[i]=3*a[i]+c[i],twoarray) f3=pyopencl.elementwise.ElementwiseKernel(ctx,pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *a,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *b,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *c,c[i]=3*a[i]+b[i],threearray) f5=pyopencl.elementwise.ElementwiseKernel(ctx,pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *a,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *b,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *c,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *d,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *e,c[i]=a[i]+b[i]+d[i]+e[i],fivearray) f5b=pyopencl.elementwise.ElementwiseKernel(ctx,pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *a,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *b,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *c,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *d,+pyopencl.tools.dtype_to_ctype(aCL.dtype)+ *e,c[i]=4*e[i],fivearray_usetwo) f2(aCL,cCL).wait() #f3(aCL,bCL,cCL).wait() f5(aCL,bCL,cCL,dCL,eCL).wait() #f5b(aCL,bCL,cCL,dCL,eCL).wait() print(size,len(aCL), error ,np.max(np.nan_to_num(np.abs(cCL[0:1000].get()-ans))),first 10 ,ans[0:10],cCL[0:10].get())
Bug#781875: [Pkg-opencl-devel] Bug#781875: beignet: kernels don't seem to run
Control: forwarded -1 http://lists.freedesktop.org/archives/beignet/2015-April/date.html The ICD interface works for me (i5-3230M), which makes this bug _both_ hardware- and interface-dependent, which is weird. Since version 1.0.1 beignet has been able to recognitze the hardware on my machine[...]However, kernels don't seem to run at all[...] * has been introduced _probably_ somewhere between 1.0.0 and 1.0.1. Are you saying 1.0.0 didn't work for you at all, or are you saying 1.0.0 worked properly and this is a regression? If it is a regression, the obvious next step is to find the commit that introduced it, by a git bisect (git help bisect for instructions) from Release_v1.0.0 to Release_v1.0.1 of the upstream repository (git://anongit.freedesktop.org/beignet, build instructions: http://www.freedesktop.org/wiki/Software/Beignet/). Uninstall all other ICDs (including Debian beignet) before doing this; to speed up the process, you may also want to install ccache and set PATH=/usr/lib/ccache:$PATH. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781875: ICD interface (only) broken on Haswell
On 05/04/15 00:08, David Couturier wrote: This looks like the problem I experienced on my i7-4770. I fixed the issue by applying this patch to the kernel: https://01.org/zh/beignet/downloads/linux-kernel-patch-hsw-support That's the long-standing no shared local memory on Haswell problem, which supposedly _does_ show up in the test suite. Are you also seeing the bug reported here, i.e. a totally broken ICD interface but working direct linking? Even if that patch does fix the problem, disable a security feature in the kernel is not the kind of fix that's likely to be accepted in Debian. Does using a newer kernel (e.g. 3.19.3 from Debian experimental) help? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793517: fltk1.3-dev cmake interface now requires libcairo2-dev and fluid?
Control: tags -1 patch Since libfltk1.3-dev 1.3.3-1 switched to using upstream's cmake files (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792386#10), using it from cmake now appears to require libcairo2-dev and fluid, which are not hard Depends of the package (presumably because they aren't required when using it from autotools/pkg-config). This causes fgrun (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793517) and lmms (https://reproducible.debian.net/rb-pkg/unstable/amd64/lmms.html) to FTBFS; it could also affect gmsh, zynaddsubfx and mathgl. (yoshimi already had these dependencies, and freecad appears to not actually use FLTK.) Adding libcairo2-dev (and fluid, where not already present) as build-dependencies should fix this (though I currently can't run a full test due to the gcc5 transition). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793517: [pkg-fgfs-crew] Bug#793517: fltk1.3-dev cmake interface now requires libcairo2-dev and fluid?
It's lmms that isn't finding fluid (because it doesn't build-depend on it), fgrun is only missing libcairo2-dev. However, fgrun already bypasses cmake-data with find_package(FLTK REQUIRED NO_MODULE) as recommended in https://sources.debian.net/src/fltk1.3/1.3.3-2/README.CMake.txt/#L233 and required to use FLTK as a shared library; packages that don't may well hit #793549 as well. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793517: [pkg-fgfs-crew] Bug#793517: Fwd: fltk1.3_1.3.3-3_amd64.changes ACCEPTED into unstable
Control: retitle -1 fgrun: missing build-dependency on libcairo2-dev Control: severity -1 important (should no longer be an FTBFS, though I haven't tested it) I've worked around both of these problems on my side for now for the sake of the GCC 5 transition, but may want to revisit them once that's settled down. Does that mean FLTK+cmake users should start build-depending on libcairo2-dev (at least fgrun is due a new upstream release soon), or that you're hoping to make the cmake file stop doing this? (Debian generally prefers linking to only direct dependencies, https://wiki.debian.org/ToolChain/DSOLinking, but I don't know how practical this is in this case.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794935: llvm-toolchain-3.5 - upload != transition done
Control: reopen -1 User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 790756 Control: reassign -1 release.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-llvm-toolchain-3.5.html Control: retitle -1 llvm-toolchain-3.5: library transition is needed when GCC 5 is the default (This was always 3.5's bug; 3.6 was #793899, which _is_ done) Is this blocked by something, or just needing binNMUs of pocl, beignet, gambas3? -The only open gcc5-related bug on these packages is https://bugs.debian.org/797917, which also affects the version already in testing -pocl and beignet contain C++ code, but their preferred interface (and their only one used by other packages in main) is C (*-opencl-icd), and neither is listed as needing its own transition -I haven't checked whether all their other C++ dependencies have been rebuilt yet
Bug#797944: simgear: library transition - now or later?
Control: user release.debian@packages.debian.org
Control: usertag -1 + transition
Control: block -1 by 790756
Control: reassign -1 release.debian.org
(I am not the maintainer of this, but am an upstream developer)
The attached does the rename; both reverse dependencies (flightgear and
fgrun) build and appear to work.
Do we need to wait for libglu (not yet rebuilt, but not listed as
needing a transition)?
diff --git a/debian/changelog b/debian/changelog
index 00b4e80..7b6816b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+simgear (3.4.0-3) UNRELEASED; urgency=medium
+
+ * Rename for gcc5 transition.
+
+ -- Rebecca N. Palmer <rnpalmer@rnpalmer-laptop> Sat, 05 Sep 2015 14:08:42 +0100
+
simgear (3.4.0-2) unstable; urgency=medium
* Really drop the conflicts against simgear0 (in control.in).
diff --git a/debian/control b/debian/control
index d490a6f..661f8c0 100644
--- a/debian/control
+++ b/debian/control
@@ -18,11 +18,13 @@ Homepage: http://www.simgear.org/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/simgear.git
Vcs-Git: git://anonscm.debian.org/collab-maint/simgear.git
-Package: libsimgearcore3.4.0
+Package: libsimgearcore3.4.0v5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsimgearcore3.4.0
+Replaces: libsimgearcore3.4.0
Description: Simulator Construction Gear -- core library
SimGear is a collection of libraries useful for constructing
simulation and visualization applications such as FlightGear
@@ -35,7 +37,7 @@ Architecture: any
Section: debug
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: libsimgearcore3.4.0 (= ${binary:Version}),
+Depends: libsimgearcore3.4.0v5 (= ${binary:Version}),
${misc:Depends}
Description: debugging symbols for libsimgearcore
SimGear is a collection of libraries useful for constructing
@@ -44,12 +46,14 @@ Description: debugging symbols for libsimgearcore
.
This package contains the debug symbols for the core library.
-Package: libsimgearscene3.4.0
+Package: libsimgearscene3.4.0v5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: libsimgearcore3.4.0 (= ${binary:Version}),
+Depends: libsimgearcore3.4.0v5 (= ${binary:Version}),
${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsimgearscene3.4.0
+Replaces: libsimgearscene3.4.0
Description: Simulator Construction Gear -- scene library
SimGear is a collection of libraries useful for constructing
simulation and visualization applications such as FlightGear
@@ -62,7 +66,7 @@ Architecture: any
Section: debug
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: libsimgearcore3.4.0 (= ${binary:Version}),
+Depends: libsimgearcore3.4.0v5 (= ${binary:Version}),
${misc:Depends}
Description: debugging symbols for libsimgearscene
SimGear is a collection of libraries useful for constructing
@@ -74,8 +78,8 @@ Description: debugging symbols for libsimgearscene
Package: libsimgear-dev
Architecture: any
Section: libdevel
-Depends: libsimgearcore3.4.0 (= ${binary:Version}),
- libsimgearscene3.4.0 (= ${binary:Version}),
+Depends: libsimgearcore3.4.0v5 (= ${binary:Version}),
+ libsimgearscene3.4.0v5 (= ${binary:Version}),
libopenscenegraph-dev, libc6-dev, ${misc:Depends}
Replaces: simgear-dev (<< 2.10.0~)
Breaks: simgear-dev (<< 2.10.0~)
diff --git a/debian/control.in b/debian/control.in
index 8a2bf9c..86f0382 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -18,11 +18,13 @@ Homepage: http://www.simgear.org/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/simgear.git
Vcs-Git: git://anonscm.debian.org/collab-maint/simgear.git
-Package: libsimgearcore##UVER
+Package: libsimgearcore##UVERv5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsimgearcore##UVER
+Replaces: libsimgearcore##UVER
Description: Simulator Construction Gear -- core library
SimGear is a collection of libraries useful for constructing
simulation and visualization applications such as FlightGear
@@ -35,7 +37,7 @@ Architecture: any
Section: debug
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: libsimgearcore##UVER (= ${binary:Version}),
+Depends: libsimgearcore##UVERv5 (= ${binary:Version}),
${misc:Depends}
Description: debugging symbols for libsimgearcore
SimGear is a collection of libraries useful for constructing
@@ -44,12 +46,14 @@ Description: debugging symbols for libsimgearcore
.
This package contains the debug symbols for the core library.
-Package: libsimgearscene##UVER
+Package: libsimgearscene##UVERv5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: libsimgearcore##UVER (= ${binary:Version}),
+Depends: libsimgearcore##UVERv5 (= ${binary:Version}),
${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsimgearscene##UVER
+Replaces: libsimgearscene##UVER
Desc
Bug#799322: pocl: FTBFS: (gcc5 related?) symbols mismatches + test failures
Package: src:pocl Version: 0.10-10 Severity: serious Control: found -1 0.10-12 Control: block 794935 with -1 The binNMU of pocl for the llvm-toolchain-3.5 transition (https://buildd.debian.org/status/fetch.php?pkg=pocl=amd64=0.10-10%2Bb1=1442439767) failed with symbols mismatches, at least some of which look gcc-5 related (though I haven't checked whether they all are, and pocl does have a history of symbols issues), e.g. - (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeESsEES1_RKT_RKT0_@Base 0.10 [...] +#MISSING: 0.10-10+b1# (optional=templinst)_ZN4llvm12hash_combineINS_9hash_codeENS_9StringRefEEES1_RKT_RKT0_@Base 0.10 + _ZN4llvm12hash_combineINS_9hash_codeENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcES1_RKT_RKT0_@Base 0.10-10+b1 Also, nearly all the tests failed: the build treats this as non-fatal, but it should probably be investigated. A local build of 0.10-12 from experimental had far fewer (but not no) test failures, but still FTBFS with the symbols issue.
Bug#797944: simgear: gcc5 transition - please upload libsimgear*3.4.0v5
Reassigning back so the maintainers see this. It appears to be random (race condition in the BTS??) whether the old or new package's maintainer gets the main text of a reassign message (this one went to the old one, but #793517 went to the new one). Is that a bug? (Both maintainers get the Processed: receipt.) There's no need to wait for libglu. This could be done at any time. Feel free to reassign to release.debian.org once this is uploaded. Patch is earlier in this bug. (Upstream still haven't released 3.6.)
Bug#807446: oclgrind: tests fail on big-endian systems
Package: oclgrind Version: 15.5-2 Severity: serious oclgrind FTBFS on big-endian systems (mips,powerpc,s390x) with several test failures: https://buildd.debian.org/status/fetch.php?pkg=oclgrind=mips=15.5-2=1449588354 Given that this is its first upload with tests enabled, it is fairly likely that it has never worked on such systems, and it may be appropriate to have it removed: see https://wiki.debian.org/ftpmaster_Removals for how to do this.
Bug#809263: beignet: FTBFS: /usr/include/CL/cl_egl.h:31:21: fatal error: EGL/egl.h: No such file or directory
[ 31%] Building C object src/CMakeFiles/cl.dir/cl_khr_icd.c.o cd /home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/obj-x86_64-linux-gnu/src && /usr/bin/cc -DGEN7_SAMPLER_CLAMP_BORDER_WORKAROUND -DLLVM_36 -Dcl_EXPORTS -I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/obj-x86_64-linux-gnu -I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1 -I/usr/include/libdrm -I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/src -I/usr/include/libdrm/.. -I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/src/../backend/src/backend -I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/src/../include -I/usr/lib/llvm-3.6/include -DHAS_SUBSLICE_TOTAL -DHAS_EU_TOTAL -DHAS_USERPTR -DHAS_OCLIcd -DHAS_X11 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DGBE_DEBUG=1 -funroll-loops -fstrict-aliasing -fPIC -Wall -Wcast-align -Wl,-E -fPIC -o CMakeFiles/cl.dir/cl_khr_icd.c.o -c /home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/src/cl_ k hr_icd.c In file included from /usr/include/ocl_icd.h:40:0, from /home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/src/cl_khr_icd.c:17: /usr/include/CL/cl_egl.h:31:21: fatal error: EGL/egl.h: No such file or directory This is probably due to ocl-icd 2.2.8 adding CL/cl_egl.h to the headers #included by ocl_icd.h (https://anonscm.debian.org/cgit/collab-maint/ocl-icd.git/commit/icd_generator.rb?id=9fdd8caf362d9b848f6a722e05e4f79768a82f72). The obvious (but untested) fix is to add a dependency on libegl1-mesa-dev, but does that belong in ocl-icd-dev or beignet? It is likely that pocl (the other user of ocl-icd-dev in main) is also affected, but I haven't tested this.
Bug#805722: [pkg-fgfs-crew] Bug#805722: That's not where your problem is
There is several libraries missing in dependencies. While libalut0 is just missing, the needed library libopenscenegraph65 is not in debian anymore. And without that library, flightgear will not even start. There might be others like libopenthreads13 (which is also missing in debian). Only the very outdated sparc64/sh4/m68k flightgear depends on those (and hence is uninstallable: it should probably be removed). amd64 flightgear depends on the current versions: Architecture: amd64 (x86_64) Foreign Architectures: i386 ii libopenal11:1.16.0-3 ii libopenscenegraph100v53.2.1-8 ii libopenthreads20 3.2.1-8 If your flightgear won't start, you have a different problem; please post the exact error message, and if possible, a debugger backtrace.
Bug#826896: xul-ext-noscript: incompatible with firefox-esr in jessie
Control: forcemerge 826896 826997 I've also seen this, and confirm that a no-change rebuild of the sid (2.9.0.11-1) source in jessie fixes the problem. (Hence the "resolved" status, as this is defined to mean "fixed in sid". Such updates have previously been allowed in stable: see #744730.) Note that while a "do you really want to remove NoScript?" dialog with a "Cancel" button may appear, clicking Cancel does *not* stop NoScript being disabled.
Bug#809263: [Pkg-opencl-devel] Bug#809263: beignet: FTBFS: /usr/include/CL/cl_egl.h:31:21: fatal error: EGL/egl.h: No such file or directory
Control: reassign -1 src:khronos-opencl-headers On 05/01/16 18:09, J Price wrote: On 5 January 2016 at 09:42, Brice Videau <brice.vid...@imag.fr> wrote: On 05-Jan-16 00:02, Rebecca N. Palmer wrote: This is probably due to ocl-icd 2.2.8 adding CL/cl_egl.h to the headers #included by ocl_icd.h (https://anonscm.debian.org/cgit/collab-maint/ocl-icd.git/commit/icd_generator.rb?id=9fdd8caf362d9b848f6a722e05e4f79768a82f72). I reported this problem to Khronos. The worst is that commenting the #include results in functional headers. This dependency is not needed... So I asked if they could remove the include like they did for OpenGL... So far no answer. Maybe we could distribute modified cl_egl.h without the problematic includes. I think this is the correct fix. I've raised this for discussion inside Khronos. It may take another week or so but as soon as I've got agreement I'll push the fix to the public Khronos GitHub repository. James ___ Pkg-opencl-devel mailing list pkg-opencl-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-opencl-devel What's the status of this? Nothing has happened in either the upstream or Debian repositories.
Bug#831235: Building libhmsbeagle in pbuilder mixes up desktop environment (Was: backport of libreoffice-calc (5.1.2-3~bpo8+1) mixes up desktop environment)
Are you able to reproduce this (under an up to date Jessie + backports system). No - the build (of master, i.e. 2.1.2+20160525-1) fails with /tmp/pocldFu22d/program.cl:3273:32: error: call to '_cl_ldexp' is ambiguous sum[pat][state] += ldexp(frexp(dRootPartials[u + delta * r], ), expTmp + (tmpFactor - maxScaleFactor)) * matrixProp[r]; ^ during the test suite, but it doesn't do anything to graphics. What else information might be possibly helpful? Have you done anything to your pbuilder setup (pbuilderrc, gbp.conf) to make it install/use beignet? A program in a chroot can only see the OpenCL ICDs installed inside the chroot, which with those build-dependencies defaults to pocl-opencl-icd. Does the problem go away if you uninstall beignet-opencl-icd and reboot? Do sid builds also trigger it?
Bug#826896: xul-ext-noscript: incompatible with firefox-esr in jessie
Is this going to get a stable update (as previously suggested)? On 11/06/16 08:04, Rebecca N. Palmer wrote: a no-change rebuild of the sid (2.9.0.11-1) source in jessie fixes the problem.[...]Such updates have previously been allowed in stable: see #744730.)
Bug#831540: (no subject)
Control: forwarded -1 https://github.com/Theano/Theano/issues/5498
Control: tags -1 patch
I don't think this is a regression - it's Python 3 specific
(numpy.array(list of longs, which this test uses on Python 2)=int64
array, but numpy(list of Python 3 ints)=int_nativesize array; see above
link for longer discussion) and 0.8.2-2 appears to be the first time the
tests were run with Python 3.
Fix (though I've only tried these particular tests, not a full build):
--- a/theano/tensor/tests/test_basic.py
+++ b/theano/tensor/tests/test_basic.py
@@ -6672,11 +6672,11 @@ class T_long_tensor(unittest.TestCase):
assert scalar_ct.value == val
vector_ct = constant([val, val])
-assert vector_ct.dtype == 'int64'
+assert vector_ct.dtype in ('int32','int64')
assert numpy.all(vector_ct.value == val)
matrix_ct = constant([[val, val]])
-assert matrix_ct.dtype == 'int64'
+assert matrix_ct.dtype in ('int32','int64')
assert numpy.all(matrix_ct.value == val)
def test_too_big(self):
Bug#848764: (no subject)
Control: tags -1 patch
Three patches because this is logically three bugs, though it's filed as
two upstream:
https://github.com/Theano/Theano/issues/5494
https://github.com/Theano/Theano/issues/5396
First patch taken from upstream
https://github.com/Theano/Theano/commit/e8e01f4e0da83d038b244cd5dcec4f0d3f6c0777
by chinnadhurai
(I've only tried these tests, not a full build; I can't reproduce the
other three failures reported in upstream 5396)
--- a/theano/sparse/tests/test_sp2.py
+++ b/theano/sparse/tests/test_sp2.py
@@ -61,7 +61,7 @@ class PoissonTester(utt.InferShapeTester):
class BinomialTester(utt.InferShapeTester):
-n = tensor.scalar()
+n = tensor.scalar(dtype='int64')
p = tensor.scalar()
shape = tensor.lvector()
_n = 5
--- a/theano/tensor/tests/test_elemwise.py
+++ b/theano/tensor/tests/test_elemwise.py
@@ -414,7 +414,11 @@ class test_CAReduce(unittest_tools.InferShapeTester):
zv = numpy.bitwise_or.reduce(zv, axis)
elif scalar_op == scalar.and_:
for axis in reversed(sorted(tosum)):
-zv = numpy.bitwise_and.reduce(zv, axis)
+if zv.shape[axis] == 0:
+# Theano and old numpy use +1 as 'AND of no elements',
new numpy uses -1
+zv = numpy.abs(numpy.bitwise_and.reduce(zv,
axis).astype('int8'))
+else:
+zv = numpy.bitwise_and.reduce(zv, axis)
elif scalar_op == scalar.xor:
# There is no identity value for the xor function
# So we can't support shape of dimensions 0.
--- a/theano/tensor/tests/test_extra_ops.py
+++ b/theano/tensor/tests/test_extra_ops.py
@@ -135,7 +135,7 @@ class TestBinCountOp(utt.InferShapeTester):
def test_bincountFn(self):
w = T.vector('w')
def ref(data, w=None, minlength=None):
-size = data.max() + 1
+size = int(data.max()) + 1
if minlength:
size = max(size, minlength)
if w is not None:
Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries
On 22/01/17 21:07, Sylvestre Ledru wrote: > , you haven't pass the arg to LDFLAGS to make sure that libclang or > liblldb get it, > is that on purpose? My original intent was to avoid passing it to those parts of LLVM that already use a "version" (actually which-symbols-are-public) script, as I suspect having two version scripts is an error; you're right that there might be other parts of LLVM that would benefit. >> - Are the symbols versioned? For this creating a temporary symbols files is >> enough. Ping me if you don't know how to do this. > Just libclang is (the C lib). > I haven't done it for the rest because it is C++ and not commitment > from upstream on API stability The lack of API stability is exactly why we need symbol versioning (otherwise we could just make everything use 3.9). We're not proposing to ship this .symbols file (which would be a compatibility statement), just use it to check whether symbol versioning was successfully enabled. >> - Install and test LLVM 3.9 with stuff built with previous versions, like >> for >> example kdevelop ;-) Everything should just work. kdevelop (#846410) has already been fixed by moving it to all-3.9; if you need a test case, I suggest the pocl-opencl-icd + blender one above.
Bug#848748: intent to NMU #848748: blockdiag FTBFS
Attached is a proposed NMU fixing this bug (identical to my original
patch other than adding the changelog entry; the olefile issue noted
above was a bug in pillow, which has now been fixed).
As the execnet issue (#840823) now also appears to have a fix,
this will allow blockdiag's ~30 rdeps to stay in stretch.
diff -Nru blockdiag-1.5.3+dfsg/debian/changelog
blockdiag-1.5.3+dfsg/debian/changelog
--- blockdiag-1.5.3+dfsg/debian/changelog 2016-10-11 02:21:04.0
+0100
+++ blockdiag-1.5.3+dfsg/debian/changelog 2017-01-22 22:14:34.0
+
@@ -1,3 +1,10 @@
+blockdiag (1.5.3+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't fail tests on a harmless wand warning. Closes: #848478
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Sun, 22 Jan 2017 22:13:59
+
+
blockdiag (1.5.3+dfsg-1) unstable; urgency=medium
* New upstream release. Closes: #801314
diff -Nru
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch
---
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch
1970-01-01 01:00:00.0 +0100
+++
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch
2017-01-09 22:32:13.0 +
@@ -0,0 +1,38 @@
+Description: Fix test failure with wand 0.4.1+
+
+wand 0.4.1 added an Image.destroy()
+(https://sources.debian.net/src/wand/0.4.4-1/wand/image.py/#L2760) that
+iterates over self.sequence (the frames of an animation) to free their
+memory; this throws an exception on single images (where
+self.sequence=None), but as this is called from __del__, this
+exception is warned about then ignored
+(https://docs.python.org/3/reference/datamodel.html#object.__del__),
+and hence is not an error in normal use.
+
+However, blockdiag tests that use capture_stderr fail on any output
+containing "Traceback", including this warning message.
+
+This patch ignores this message to allow blockdiag to build.
+
+Author: Rebecca Palmer <rebecca_pal...@zoho.com>
+Bug-Debian: https://bugs.debian.org/848748
+Forwarded: no
+
+--- blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/utils.py
blockdiag-1.5.3+dfsg/src/blockdiag/tests/utils.py
+@@ -64,7 +64,14 @@ def capture_stderr(func):
+
+ func(*args, **kwargs)
+
+-if re.search('(ERROR|Traceback)', sys.stderr.getvalue()):
++filtered_stderr=re.sub(r"""Exception ignored in: >
++Traceback \(most recent call last\):
++ File "/usr/lib/python3/dist-packages/wand/resource\.py", line [0-9]+, in
__del__
++self\.destroy\(\)
++ File "/usr/lib/python3/dist-packages/wand/image\.py", line [0-9]+, in
destroy
++for i in range\(0, len\(self\.sequence\)\):
++TypeError: object of type 'NoneType' has no
len\(\)""","",sys.stderr.getvalue())#this is the expected result of freeing a
single image (as opposed to an animation) in wand 0.4, not a blockdiag bug -
#848748
++if re.search('(ERROR|Traceback)', filtered_stderr):
+ raise AssertionError('Caught error')
+ finally:
+ if sys.stderr.getvalue():
diff -Nru blockdiag-1.5.3+dfsg/debian/patches/series
blockdiag-1.5.3+dfsg/debian/patches/series
--- blockdiag-1.5.3+dfsg/debian/patches/series 2016-10-11 01:32:49.0
+0100
+++ blockdiag-1.5.3+dfsg/debian/patches/series 2017-01-09 21:50:32.0
+
@@ -1 +1,2 @@
Fixed-remote-image-resouces.patch
+848748-exception-ignored-in-Image-del.patch
Bug#831541: theano: single GradientError and WrongValues in tests on s390x, ppc64 and sparc
Found the problem: the affected functions ( https://sources.debian.net/src/theano/0.8.2-4/theano/sparse/opt.py/#L862 , https://sources.debian.net/src/theano/0.8.2-4/theano/sparse/opt.py/#L1902 ) cast a pointer-to-intptr_t (64 bit) to a pointer-to-int (32-bit). Which isn't just broken on big-endian systems, it's a strict aliasing violation *everywhere* (i.e. technically undefined behaviour with optimization on, which it is by default, though it appears to work in practice). (I expect to post a patch tonight: the obvious has a potential overflow issue, and it also needs a c_code_cache_version change to make the fix be used in existing installs).
Bug#831541: (no subject)
Control: tags -1 patch
(Combined patch for both bugs as the changes are so close together, but
you *can* do the obvious split if you only want to fix one.)
This has been tested only by running sparse/test_basic.py and #855102's
example from the source tree, *not* a full build. This confirms that it
does fix #855102, but I can't test for #831541 (due to several qemu
bugs). The syntax for running a single test is nosetests3 -v
'/path/to/theano/theano/sparse/tests/test_basic.py':SamplingDotTester.test_op
I intend to send this upstream tomorrow.
Description: Fix invalid casts and negative stride handling
Cast values, not pointers, from int64 to int32.
Remember that first-in-index order (numpy) and
first-in-memory-order (BLAS) are not always the same thing.
Bump c_code_cache_version to make sure existing installs use the fixes.
Author: Rebecca N. Palmer <rebecca_pal...@zoho.com>
Bug-Debian: https://bugs.debian.org/855102 https://bugs.debian.org/831541
Forwarded: not yet
diff --git a/theano/sparse/opt.py b/theano/sparse/opt.py
index 6100405..d1c2b54 100644
--- a/theano/sparse/opt.py
+++ b/theano/sparse/opt.py
@@ -829,7 +829,11 @@ class UsmmCscDense(gof.Op):
npy_intp Sind = PyArray_STRIDES(%(x_ind)s)[0] / PyArray_DESCR(%(x_ind)s)->elsize;
npy_intp Sptr = PyArray_STRIDES(%(x_ptr)s)[0] / PyArray_DESCR(%(x_ptr)s)->elsize;
npy_intp Sy = PyArray_STRIDES(%(y)s)[1] / PyArray_DESCR(%(y)s)->elsize;
-
+
+// blas expects ints; convert here (rather than just making N etc ints) to avoid potential overflow in the negative-stride correction
+int N32 = N;
+int Sy32 = Sy;
+int Szn32 = Szn;
if (!(%(inplace)s))
{
@@ -859,7 +863,7 @@ class UsmmCscDense(gof.Op):
if (Szn < 0)
z_row += (N - 1) * Szn;
-%(axpy)s((int*), (%(conv_type)s*), (%(conv_type)s*)y_row, (int*), (%(conv_type)s*)z_row, (int*));
+%(axpy)s(, (%(conv_type)s*), (%(conv_type)s*)y_row, , (%(conv_type)s*)z_row, );
}
}
}
@@ -868,7 +872,7 @@ class UsmmCscDense(gof.Op):
return rval
def c_code_cache_version(self):
-return (1, blas.blas_header_version())
+return (1, blas.blas_header_version(), 0xdeb1a)
usmm_csc_dense = UsmmCscDense(inplace=False)
usmm_csc_dense_inplace = UsmmCscDense(inplace=True)
@@ -1748,7 +1752,7 @@ class SamplingDotCSR(gof.Op):
])
def c_code_cache_version(self):
-return (2, blas.blas_header_version())
+return (2, blas.blas_header_version(), 0xdeb1a)
def c_support_code(self):
return blas.blas_header_text()
@@ -1891,6 +1895,11 @@ PyErr_SetString(PyExc_NotImplementedError, "rank(y) != 2"); %(fail)s;}
memcpy(Dzi, Dpi, PyArray_DIMS(%(p_ind)s)[0]*sizeof(dtype_%(p_ind)s));
memcpy(Dzp, Dpp, PyArray_DIMS(%(p_ptr)s)[0]*sizeof(dtype_%(p_ptr)s));
+// blas expects ints; convert here (rather than just making K etc ints) to avoid potential overflow in the negative-stride correction
+int K32 = K;
+int Sdx32 = Sdx;
+int Sdy32 = Sdy;
+
for (npy_int32 m = 0; m < M; ++m) {
for (npy_int32 n_idx = Dpp[m * Sdpp]; n_idx < Dpp[(m+1)*Sdpp]; ++n_idx) {
const npy_int32 n = Dpi[n_idx * Sdpi]; // row index of non-null value for column K
@@ -1898,8 +1907,15 @@ PyErr_SetString(PyExc_NotImplementedError, "rank(y) != 2"); %(fail)s;}
const dtype_%(x)s* x_row = (dtype_%(x)s*)(PyArray_BYTES(%(x)s) + PyArray_STRIDES(%(x)s)[0] * m);
const dtype_%(y)s* y_col = (dtype_%(y)s*)(PyArray_BYTES(%(y)s) + PyArray_STRIDES(%(y)s)[0] * n);
+// dot expects pointer to the beginning of memory arrays,
+// so when the stride is negative, we need to get the
+// last element
+if (Sdx < 0)
+x_row += (K - 1) * Sdx;
+if (Sdy < 0)
+y_col += (K - 1) * Sdy;
-Dzd[n_idx * Sdzd] = Dpd[n_idx * Sdpd] * %(cdot)s((int*), (const %(conv_type)s*)x_row, (int*), (const %(conv_type)s*)y_col, (int*));
+Dzd[n_idx * Sdzd] = Dpd[n_idx * Sdpd] * %(cdot)s(, (const %(conv_type)s*)x_row, , (const %(conv_type)s*)y_col, );
}
}
}
diff --git a/theano/sparse/tests/test_basic.py b/theano/sparse/tests/test_basic.py
index 8c183b9..03d79f1 100644
--- a/theano/sparse/tests/test_basic.py
+++ b/theano/sparse/tests/test_basic.py
@@ -3085,6 +3085,20 @@ class SamplingDotTester(utt.InferShapeTester):
assert tested.format == 'csr'
assert tested.dtype == expected.dtype
+def test_negative_stride(self):
+f = theano.function(
+
