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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706798: retry spek and yorick-av with libav 9.10?
The spek test crash (#725385, s390x) happens inside libav, and the yorick-av test crash (#722610, armhf) occurs on dereferencing a pointer that should come from libav; it is hence possible that these are fixed by the new (9.10) libav. Can someone try that? -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725143: unbuildable on some archs
Control: reopen -1
Looks like upstream forgot that OGRE_GCC_VERSION (the CMake variable) is
just the version, not multiplied by 100 like OGRE_COMP_VER (the C
macro), so libatomic never gets enabled. Fix attached.
Fix version check for enabling libatomic: OGRE_COMP_VER (C macro) is multiplied by 100, OGRE_GCC_VERSION (CMake variable) isn't.
$ diff -up OgreMain/CMakeLists.txt_orig OgreMain/CMakeLists.txt
--- OgreMain/CMakeLists.txt_orig 2013-10-16 15:32:31.0 +0100
+++ OgreMain/CMakeLists.txt 2013-10-17 08:05:37.285790478 +0100
@@ -289,7 +289,7 @@ else()
set_target_properties(OgreMain PROPERTIES VERSION ${OGRE_SOVERSION} SOVERSION ${OGRE_SOVERSION})
endif()
-if(OGRE_GCC_VERSION GREATER 470)
+if(OGRE_GCC_VERSION VERSION_GREATER 4.7)#-dumpversion doesn't include the patch level, so this requires = 4.8
list(APPEND LIBRARIES -latomic)
endif()
Bug#725143: unbuildable on some archs
Also, your (debian/rules) gcc version check is the wrong way round, and the buildds always use the first alternative build-dep (failing if it doesn't exist) unless you use an explicit architecture tag (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614807); fix attached. Buildds always take the first dependency that isn't _explicitly_ marked as not for their architecture: the build will fail if the first alternative doesn't exist, even if one of the others does. (Example: https://buildd.debian.org/status/fetch.php?pkg=visparch=powerpcver=2.8.0-3stamp=1380322503) $ diff -up debian/control_orig debian/control --- debian/control_orig 2013-10-17 17:37:14.876687413 +0100 +++ debian/control 2013-10-17 17:37:03.016687763 +0100 @@ -10,7 +10,7 @@ Vcs-Git: git://anonscm.debian.org/pkg-ga Build-Depends: debhelper (= 9~), dpkg-dev (= 1.16.1~), cmake (= 2.8.0), - g++ (= 4:4.8.0) | g++-4.8, + g++-4.8 [powerpc sparc] | g++ (= 4:4.8.0) [mips mipsel powerpc sparc], pkg-config, libboost1.54-dev, libboost-atomic1.54-dev, Make the gcc version check the right way round (ifneq (,$(findstring means if nonempty, i.e. if the string _is_ found), accept future versions, and only do it on architectures that require it. $ diff -up debian/rules_orig debian/rules --- debian/rules_orig 2013-10-17 17:38:26.724685290 +0100 +++ debian/rules 2013-10-17 18:15:26.360619707 +0100 @@ -22,12 +22,13 @@ endif # see #725143, some architectures fail to build because they lack # __sync_fetch_and_add_8, need to link with libatomic (since ~rc2 done -# upstrema) and depend on the version provided by GCC = 4.8 -ifneq (,$(findstring $(shell g++ --version),4.8)) +# upstream) and depend on the version provided by GCC = 4.8 +ifneq (,$(findstring $(DEB_HOST_ARCH) , mips mipsel powerpc sparc )) +ifneq (,$(findstring $(shell dpkg --compare-versions `g++ -dumpversion` ge 4.8 || echo old),old)) export CXX := g++-4.8 export CC := gcc-4.8 endif - +endif DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
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#725143: unbuildable on some archs
I don't have any of the affected architectures (hence why it took so many attempts to get right); my concern has always been only that the strict partial-removal policy (cf. #723770, #724678) would make it hard for your reverse dependencies to switch from an any-arch 1.8 to a non-any-arch 1.9, and it hence isn't an urgent problem if you don't want to transition yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: 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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: 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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722014: Illegal example
Package: python-pyopencl-doc Version: 2013.1-1 (and also 2012.1-1) The example file /usr/share/doc/python-pyopencl-doc/examples/matrix-multiply.py is listed as Copyright 1993-2009 NVIDIA Corporation. All rights reserved, i.e. shouldn't be here. As the rest of the documentation does not appear to refer to (any of) these examples, this can be fixed by simply deleting it. (There's a free equivalent in https://pypi.python.org/pypi/reikna , but this is not a proposal to add that package.) -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
As several packages have already been built against libopenscenegraph99, and at least ossim depends only on the libopenthreads(13|14|15) part of openscenegraph, those also need to be included: title = openscenegraph; is_affected = .build-depends ~ /libopenscenegraph-dev/; is_bad = .depends ~ /libopenscenegraph(80|99)/ | .depends ~ /libopenthreads(13|14)/; is_good = .depends ~ libopenscenegraph100 | .depends ~ libopenthreads15; -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724584: (no subject)
I have this broken link (in a fresh install of Ubuntu's flightgear, i.e. simgear 2.10.0-5, flightgear 2.10.0-2, flightgear-data 2.10.0-2), but flightgear still works for me, and nobody has reported this bug in Ubuntu. Is this a Debian-only bug, or is there something else different about your system that makes this a total failure to start for you? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706798: libav 9 porting guide
Is there a libav 9 porting guide available somewhere? The 0.8 deprecated (= 9 removed) list (http://libav.org/doxygen/release/0.8/deprecated.html) has suggested replacements for most of them. PixelFormat is now AVPixelFormat, and its entries are similarly renamed: http://libav.org/doxygen/release/9/pixfmt_8h.html#a9a8e335cf3be472042bc9f0cf80cd4c5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#252899: Making Terrasync just work
I'd consider the real issue here turning on TerraSync by just ticking
the box should work. It currently doesn't, for several reasons:
1) The TerraSync dialog box (Environment Scenery Download) only allows
selecting directories that are in FG_SCENERY (so the new scenery will be
read) but not FG_ROOT/Scenery (as noted above, TerraSync isn't meant to
be run there). By default, FG_SCENERY = FG_ROOT/Scenery, so there are
no directories available for selection and TerraSync hence can't be
turned on. (The dialog script then tries, and fails, to display an
error message stating this: fixed by terrasync_error_display.patch)
I suggest including the TerraSync directory in the default scenery
directories even if TerraSync is currently off, both to allow it to be
turned on from this dialog box, and to keep displaying existing
TerraSync scenery if the user later disables new downloads (e.g. because
they are running out of data allowance). This is done by
terrasync_directory.patch.
This patch does not change the default TerraSync directory (currently
$HOME/.fgfs/TerraSync, which will be created if necessary); this can
easily be changed in flightgear/src/Main/options.cxx near line 2050, but
using a shared directory (such as /var/games/flightgear/TerraSync) would
require either making all the downloaded files world-writable (which
libsvn doesn't appear to provide a way to do) or making FlightGear
setgid (allowed by Policy 11.11, but would it be a good idea
security-wise?).
2) If one uses Select Airport to go to a less-negative lat/long (e.g.
KSFO to nearly anywhere else in the Americas) the tile one is now in is
not downloaded, as the tile selection process rounds the lat/long
towards 0 but the tile names are rounded down. Fixed by
terrasync_fix_rounding.patch.
3) Select Airport does not wait for the new scenery to become available,
so to see it one has to refresh scenery (to load it) then Select Airport
again (to get to the new ground level). I don't have an actual fix for
that yet, but terrasync_document_ground_refresh.patch adds a note
stating this workaround.
These patches were tested together (in upstream 2.12rc) but should all
be independent.
Set a default TerraSync directory, so the user can turn TerraSync on by simply ticking the box.
--- /home/palmer/flightgear_source/fg-flightgear/src/Main/options.cxx_orig 2013-09-23 19:02:44.193288081 +0100
+++ /home/palmer/flightgear_source/fg-flightgear/src/Main/options.cxx 2013-09-26 10:22:13.524362071 +0100
@@ -2040,8 +2040,10 @@ void Options::processOptions()
globals-append_fg_scenery(envp);
}
+ bool no_explicit_scenery_dir=globals-get_fg_scenery().empty(); //need to do terrasync dir before FG_ROOT so it takes priority
+
// terrasync directory fixup
- if (fgGetBool(/sim/terrasync/enabled)) {
+ if ( no_explicit_scenery_dir || fgGetBool(/sim/terrasync/enabled)) { //the no_explicit_scenery_dir case is because TerraSync can't be turned on from the dialog box if there is no non-fg-root directory in fg-scenery for it to be turned on in, and also because a user turning TerraSync off due to lack of bandwidth probably doesn't want their already-installed TerraSync scenery to disappear
string terrasyncDir = fgGetString(/sim/terrasync/scenery-dir);
if (terrasyncDir.empty()) {
SGPath p(globals-get_fg_home());
@@ -2052,11 +2054,11 @@ void Options::processOptions()
fgSetString(/sim/terrasync/scenery-dir, terrasyncDir);
}
- SGPath p(terrasyncDir);
- if (!p.exists()) {
+SGPath p(terrasyncDir);
+if (!p.exists()) {
simgear::Dir dd(p);
dd.create(0700);
- }
+}
const string_list scenery_paths(globals-get_fg_scenery());
if (std::find(scenery_paths.begin(), scenery_paths.end(), terrasyncDir) == scenery_paths.end()) {
@@ -2064,13 +2066,13 @@ void Options::processOptions()
globals-append_fg_scenery(terrasyncDir);
}
}
-
- if (globals-get_fg_scenery().empty()) {
-// no scenery paths set *at all*, use the data in FG_ROOT
+ if (no_explicit_scenery_dir) {
+// use the data in FG_ROOT
SGPath root(globals-get_fg_root());
root.append(Scenery);
globals-append_fg_scenery(root.str());
}
+
}
void Options::showUsage() const
Make the don't run terrasync in FG_ROOT/Scenery error message actually appear.
--- /home/palmer/flightgear_source/fgfsinstall2-12/lib/FlightGear/gui/dialogs/terrasync.xml_orig 2013-07-29 10:41:14.0 +0100
+++ /home/palmer/flightgear_source/fgfsinstall2-12/lib/FlightGear/gui/dialogs/terrasync.xml_fix1 2013-09-26 09:48:55.397460111 +0100
@@ -540,7 +540,7 @@
# Add error text if the user only has fg-data/Scenery available and disable controls.
if (!valid) {
-var warning = cmdarg().getChildren(group)[1].getChildren(text)[1];
+var warning = gui.findElementByName(cmdarg(),warning_text);
var txt = You must configure a separate
Bug#724678: RM: flightgear [kfreebsd-*] -- RoM; ANAIS due to missing systemd
I was unaware of the libusbhid-dev alternative at the time I suggested removal (everything else that depends on libudev is Linux-only: http://release.debian.org/transitions/html/libudev.html), and agree that it would now make more sense to try Pino's patch. Does the package also actually work on non-Linux ? What I'm concerned about is, that we are building software which isn't actually runnable. Upstream supports FreeBSD (http://www.flightgear.org/download/main-program/), but I don't know if that automatically translates to Debian-kFreeBSD. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725143: unbuildable on some archs
Source: ogre-1.9 Tags: patch Using __sync_fetch_and_add_8 on architectures without native support requires the libatomic library (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300), which is part of GCC 4.8+. The attached patch links against this library and forces compilation with gcc/g++ 4.8. It also disables --as-needed on ia64 to work around bug #718047. This should fix everything except armhf (crashing make, which is a bug there not here), but has not been tested. $ diff -up rules_orig rules --- rules_orig 2013-10-01 20:30:06.846713326 +0100 +++ rules 2013-10-01 20:52:56.234672865 +0100 @@ -15,8 +15,13 @@ export DEB_BUILD_MAINT_OPTIONS := hard dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS=$(DEB_BUILD_MAINT_OPTIONS) dpkg-buildflags export DEB_CFLAGS_MAINT_APPEND := -pipe -Wall $(shell $(dpkg_buildflags) --get CPPFLAGS) export DEB_CXXFLAGS_MAINT_APPEND := -pipe -Wall $(shell $(dpkg_buildflags) --get CPPFLAGS) -export DEB_LDFLAGS_MAINT_APPEND := -Wl,-z,defs -Wl,--as-needed - +# -latomic for __sync_fetch_and_add_8 +# disable -Wl,--as-needed on ia64 due to bug #718047 +ifeq($(DEB_HOST_ARCH),ia64) +export DEB_LDFLAGS_MAINT_APPEND := -Wl,-z,defs -latomic +else +export DEB_LDFLAGS_MAINT_APPEND := -Wl,-z,defs -Wl,--as-needed -latomic +endif DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) @@ -47,7 +52,8 @@ override_dh_auto_configure: -DOGRE_INSTALL_DOCS:BOOL=TRUE \ -DOGRE_BUILD_SAMPLES:BOOL=FALSE \ -DOGRE_INSTALL_SAMPLES:BOOL=FALSE \ - -DOGRE_INSTALL_SAMPLES_SOURCE:BOOL=FALSE + -DOGRE_INSTALL_SAMPLES_SOURCE:BOOL=FALSE \ + -DCMAKE_C_COMPILER=gcc-4.8 -DCMAKE_CXX_COMPILER=g++-4.8 override_dh_install: # Copy files from template for this particular version $ diff -up control_orig control --- control_orig 2013-10-01 21:00:50.306658858 +0100 +++ control 2013-10-01 21:02:02.410656727 +0100 @@ -28,7 +28,8 @@ Build-Depends: debhelper (= 9~), libxaw7-dev, libxt-dev, libois-dev [linux-any], - chrpath + chrpath, + g++-4.8 Package: libogre-1.9-dev Section: libdevel
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#706798: where is OpenSceneGraph 3.2 status?
Is there a tracker for the OpenSceneGraph 3.2 transition (tied to this one by #720816)? Status as far as I can find: libcitygml, choreonoid, ossim, simgear (sid only), flightgear (sid only) _probably_ just need a rebuild (the libcitygml and choreonoid build failures should go away when non-rc1 3.2 arrives, which is needed anyway for #720816) #719402 fgrun (sid only) has patch #719376 osgearth fixed in 2.4, but this is held in unstable because an unrelated upstream fix makes it non-kFreeBSD (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 ; SYS_gettid doesn't exist there) #718381 / #719388 openwalnut badly broken by 3.2, being worked on upstream (latest upstream reported to build but not work properly, http://www.openwalnut.org/issues/298) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706798: where is OpenSceneGraph 3.2 status?
It doesn't look to me that a transition was coordinated for openscenegraph? Exactly my point: it's a transition in the sense of API-breaking change, but not one with an official tracker. (possibly temporary) [openscenegraph] build issue on mips, That *is* #720816 (and hence should go away in 3.2.0): mips built libav9 before openscenegraph. dvswitch, Fix in delayed queue (#720783). vxl [on ia64]. Should be fixable by removing --as-needed, as suggested above. spek [on s390x], This build failure looks like a bash crash, not an error in spek itself. Try again?? opencv Fixed in 2.4, but that breaks frei0r and sikuli (http://release.debian.org/transitions/html/opencv2.4.html). frei0r (#724186) looks like a build script bug, sikuli probably just needs to be built somewhere with a working jython (which sid currently isn't due to another unofficial transition, #724713: try to fix that, or use testing-proposed-updates as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712615#45 ?). yorick-av, #722610. Sorry, no fix yet... * #719376 osgearth * #718381 / #719388 openwalnut -- To UNSUBSCRIBE, email to debian-bugs-dist-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
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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723132: Move OpenCL-using packages to main?
Package: python-pyopencl Severity: wishlist Given that we now have a DFSG-free opencl-icd (beignet), should its reverse dependencies (pyopencl and libviennacl) now move to main? -- To UNSUBSCRIBE, email to debian-bugs-dist-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#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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: whatever you want to call this: openscenegraph
Control: reopen -1 (This may or may not be called a transition, but certainly isn't fixed.) Current status (note that the tracker isn't currently being updated): osgearth: OK simgear/flightgear/fgrun: Fixed simgear uploaded (but is a new upstream version, so has to go through the NEW queue), flightgear/fgrun to follow soon libcitygml: NMU in DELAYED choreonoid #735891: patch exists, no maintainer response; NMU? openwalnut #718381: no fix yet (being worked on upstream) Not involved in 80-99, but will be in 99-100: ossim #735814 (openthreads only): fixed version in UbuntuGIS PPA, upload to Debian in preparation qgis (newly-added dependency in NEW queue): probably OK -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737153: OpenCVModules.cmake not installed, causing visp FTBFS
Package: libopencv-dev Version: 2.4.8+dfsg-1 Control: affects -1 visp openimageio sikuli sitplus digikam mrpt (= everything build-depending on libopencv-dev and cmake) The file OpenCVModules.cmake is created during the build process, but not put in any of the packages: dh_install -O--buildsystem=cmake --list-missing dh_install: usr/share/OpenCV/OpenCVModules-release.cmake exists in debian/tmp but is not installed to anywhere dh_install: usr/share/OpenCV/OpenCVModules.cmake exists in debian/tmp but is not installed to anywhere As this file is referenced from OpenCVConfig.cmake, attempting to use this library from CMake hence fails with (from https://buildd.debian.org/status/fetch.php?pkg=visparch=armelver=2.8.0-4stamp=1390889862) CMake Error at /usr/share/OpenCV/OpenCVConfig.cmake:45 (include): include could not find load file: /usr/share/OpenCV/OpenCVModules.cmake I expect that putting this file in libopencv-dev would fix the problem, but have not tested this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
Not being sure whether to go to 3.2.0rc, 3.2.0 final or wait for the (indefinitely delayed) 3.2.1 is what has already made this drag on for months. [3.2.1] should be binary compatible. (And their current 3.2 branch still has a SOVERSION of 100.) 3.2.1 bumps the OpenThreads soversion to 20, but this was done specifically to end the current split between Debian and upstream soversions (http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2014-January/065916.html ; our current 3.2.0rc libopenthreads14 is .so.12 upstream), so there is probably no real change. Updated status: osgearth, libcitygml, qgis: OK (qgis FTBFS on arm*, but that's non-RC as there's no old arm* version in sid) simgear: fixed in NEW queue flightgear, fgrun: fixed in Alioth, waiting for simgear to pass NEW choreonoid #735891: patch exists, no maintainer response; NMU? openwalnut #718381: no fix yet (being worked on upstream) ossim #735814: working version exists http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-January/date.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
The updated libcitygml package is not uploaded yet, It was NMUd about a week ago, fixing the FTBFS bug, but I don't know if all your planned changes were included. (By OK I meant OK for transition, ie built against latest openscenegraph and no RC bugs.) Making unrelated changes to OK-for-transition packages during a transition is normally discouraged due to the risk of accidentally breaking them, but I think that's only a problem if they are currently in testing, which these aren't; can anyone confirm? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
The state of openscenegraph itself isn't the problem here: what we're waiting for is for simgear to clear NEW and for Release Team to give official permission (britney hint??) to ignore openwalnut for now. There is the separate question of whether you want an ~rc in an Ubuntu LTS (14.04 freezes 20 Feb), but they finished their transition to 3.2.0rc months ago (by removing openwalnut) and will sync from experimental if you ask them to, so that isn't tied to what we do in Debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
The tracker is now working again. decrufting openscenegraph will have to wait until we have fixed all the packages that we can. That means choreonoid needs to be fixed; the patch is in #735891. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
Perhaps Alberto or Rebecca (who follow upstream mailing lists) have better guesses about the current state of mind of upstream. They recently released 3.2.1rc2, and said the release date of 3.2.1 final would depend on the test results from that; they did not give an estimate. Also, for the future, question to Niels: we know that multiple versions of the same library are discouraged, but maybe it would be useful in this case to accomodate to the pace of different rdeps? That wouldn't be as useful as it might look: openwalnut have long recommended using their own repository (in a VM if necessary) instead of their Debian-main packages (http://www.openwalnut.org/projects/openwalnut/wiki/Getting_OpenWalnut), and all the other problems that were actually due to openscenegraph changes (as opposed to other issues that would be RC bugs whether or not this transition existed) were fixed (at least upstream) months ago. -- To UNSUBSCRIBE, email to debian-bugs-dist-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#729289: transition: openscenegraph
The choreonoid maintainer has agreed to my fix. (This starts to be offtopic, so perhaps would be better to stop discussing it in the bug report). Where would you suggest: #718381 (the openwalnut breakage) or a new wishlist bug against openscenegraph? I don't understand why this would not be useful with my proposal. I didn't say it would be useless, just less useful than the high proportion of breakages here might suggest. , and stabilise that version in Debian before we ask rdeps to start to migrate, Use experimental for that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
choreonoid is now fixed (thanks to Andreas for sponsorship), which just leaves getting simgear through NEW and uploading flightgear/fgrun. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676504: pocl ITP, and opencl-icd selection
Control: retitle -1 ITP: pocl -- Portable OpenCL (For those reading in the bug, my previous message is http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140203/79.html ) (importing and testing the pre 0.9 releases, ...) I'll give that a try. Would it make sense for the pkg-opencl-devel list to own this package? -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
We have fixed versions of flightgear and fgrun, and I expect (but can't promise, I'm not the maintainer) that they will be uploaded soon. If you want to remove libopenscenegraph80 and end this now, go ahead, it's uninstallable anyway (but note that a previous request (#737676) was rejected). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733411: Recommend compiling in a clean chroot?
This problem would be noticed before upload if the maintainer used a clean chroot to (try to) build the package, and I get the impression that this is recommended, but the Developers' Reference and New Maintainers' Guide don't actually say so. (http://www.debian.org/doc/manuals/maint-guide/build.en.html#pbuilder is the closest they come.) Should they be changed as well? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#252899: Making Terrasync just work
Following feedback from upstream that the turning downloads off also
makes previously downloaded scenery disappear behaviour is intentional
(http://sourceforge.net/p/flightgear/mailman/message/31769643/), this is
a revised patch set that keeps that behaviour. (First two for
flightgear, last two for flightgear-data.)
Description: Always set Terrasync directory
Author: Rebecca Palmer
Bug-Debian: http://bugs.debian.org/252899
Forwarded: https://gitorious.org/fg/flightgear/merge_requests/52
This was previously done only if Terrasync was on, but this made it impossible
to use the GUI dialog to turn it on for the first time in a fresh install
--- flightgear-2.12.1.orig/src/Main/options.cxx
+++ flightgear-2.12.1/src/Main/options.cxx
@@ -2041,7 +2041,6 @@ void Options::processOptions()
}
// terrasync directory fixup
- if (fgGetBool(/sim/terrasync/enabled)) {
string terrasyncDir = fgGetString(/sim/terrasync/scenery-dir);
if (terrasyncDir.empty()) {
SGPath p(globals-get_fg_home());
@@ -2058,6 +2057,7 @@ void Options::processOptions()
dd.create(0700);
}
+ if (fgGetBool(/sim/terrasync/enabled)) {
const string_list scenery_paths(globals-get_fg_scenery());
if (std::find(scenery_paths.begin(), scenery_paths.end(), terrasyncDir) == scenery_paths.end()) {
// terrasync dir is not in the scenery paths, add it
Description: Fix Terrasync rounding error
Author: Rebecca Palmer
Bug-Debian: http://bugs.debian.org/252899
Forwarded: not-needed
Pass the lat/long rounded down (as used in tile names and expected by terrasync, e.g. 40.7,-90.4 - w091n40), instead of the default rounded-towards-0 (40.7,-90.4 - w090n40).
--- flightgear-2.12.1.orig/src/Scenery/tilemgr.cxx
+++ flightgear-2.12.1/src/Scenery/tilemgr.cxx
@@ -382,7 +382,7 @@ void FGTileMgr::schedule_tiles_at(const
scheduled_visibility = range_m;
schedule_needed(current_bucket, range_m);
if (_terra_sync)
-_terra_sync-schedulePosition(latitude,longitude);
+_terra_sync-schedulePosition(floor(latitude),floor(longitude));
}
// save bucket
previous_bucket = current_bucket;
Description: Allow enabling Terrasync while leaving the directory unchanged
Author: Rebecca Palmer
Bug-Debian: http://bugs.debian.org/252899
Forwarded: not-needed
Don't require the Terrasync directory to already be in fg-scenery before
allowing the user to turn on Terrasync from the GUI dialog.
This requires restarting the sim to automatically add the directory,
but avoids the need to use the command line.
--- flightgear-data-2.12.0.orig/gui/dialogs/terrasync.xml
+++ flightgear-data-2.12.0/gui/dialogs/terrasync.xml
@@ -53,7 +53,7 @@
halignleft/halign
row1/rowcol1/colcolspan3/colspan
property/sim/terrasync/enabled/property
- labelEnable automatic scenery download/update/label
+ labelEnable automatic scenery download/update (requires restart)/label
livetrue/live
binding
commanddialog-apply/command
@@ -529,18 +529,22 @@
var combo = gui.findElementByName(cmdarg(),scenery-dir);
var valid = 0;
- for (var i = 0; i size(fg_scenery); i = i + 1) {
-var s = fg_scenery[i].getValue();
-if ((s != fg_data ~ /Scenery) and (s != fg_data ~ \\Scenery)) {
+ for (var i = 0; i = size(fg_scenery); i = i + 1) {
+# Default to not changing the Terrasync directory
+var s = getprop(/sim/terrasync/scenery-dir);
+if (i 0) {
+ s = fg_scenery[i-1].getValue();
+}
+if ((s != fg_data ~ /Scenery) and (s != fg_data ~ \\Scenery) and (s != )) {
# Do not allow Terrasync to run in the default directory.
- combo.getNode(value[ ~ i ~ ], 1).setValue(fg_scenery[i].getValue());
+ combo.getNode(value[ ~ i ~ ], 1).setValue(s);
valid = 1;
}
}
# Add error text if the user only has fg-data/Scenery available and disable controls.
if (!valid) {
-var warning = cmdarg().getChildren(group)[1].getChildren(text)[1];
+var warning = gui.findElementByName(cmdarg(),warning_text);
var txt = You must configure a separate FG_SCENERY directory for automatic scenery download;
warning.getNode(label).setValue(txt);
}
Description: Document Terrasync + Select airport workaround
Author: Rebecca Palmer
Bug-Debian: http://bugs.debian.org/252899
Forwarded: not-needed
Select airport does not wait for scenery to be downloaded, and hence often
leaves one stuck underground. This tells the user how to get out of this.
(Upstream have really fixed this problem for 3.0, but the changes are
too large to sensibly backport.)
--- flightgear-data-2.12.0.orig/gui/dialogs/terrasync.xml
+++ flightgear-data-2.12.0/gui/dialogs/terrasync.xml
@@ -148,6 +148,21 @@
/binding
/button
+text
+ row7/row
+ col0/colcolspan4/colspan
+
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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735028: mumble and TS aren't compatible, but nor are TS2 and TS3
Control: retitle 735028 RM: teamspeak-server -- RoQA; orphaned, outdated (newer version undistributable) Control: retitle 735029 RM: teamspeak-client -- RoQA; orphaned, outdated (newer version undistributable) mumble/mumble-server aren't compatible with TeamSpeak (http://mumble.sourceforge.net/FAQ#Can_I_use_Mumble_to_connect_to_Ventrilo.2FTeamspeak.2FSkype.2F...), but TeamSpeak 2 and TeamSpeak 3 aren't compatible either (https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/56/12/is-teamspeak-2-compatible-with-teamspeak-3), and we only have permission to distribute TeamSpeak 2, not 3 (http://metadata.ftp-master.debian.org/changelogs//non-free/t/teamspeak-client/teamspeak-client_2.0.32-5_copyright). Hence, while mumble can't replace TeamSpeak if the other parties are unwilling to switch, the teamspeak-* packages can't replace TeamSpeak 3 either, and its falling popcon (http://qa.debian.org/popcon-graph.php?packages=teamspeak-client) suggests TeamSpeak 2 is now rarely used. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732389: fixed in git
Control: tags -1 patch Fixed in alioth git (http://anonscm.debian.org/gitweb/?p=pkg-grass/osmium.git;a=commitdiff;h=1a547fffc31cd036315fd7702f9adf5538ffca8c); since this is a build-time-only dependency, uploading the package just for this would only waste time. -- To UNSUBSCRIBE, email to debian-bugs-dist-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#729289: transition: openscenegraph
choreonoid and ossim turned out to also FTBFS (for non-openscenegraph-related reasons); I have posted a patch for choreonoid (#735891), and suggested that ossim (#735814) move to the already-fixed version in the UbuntuGIS PPA. this no longer blocks anything else or needs to be handled as a transition. britney still thinks it does: out of date on i386: libopenscenegraph80 (from 3.0.1-4.1). Given that libopenscenegraph80 is uninstallable (it depends on the no-longer-existing libavcodec53/libavformat53/libavutil51), keeping it around doesn't actually help its reverse dependencies; how should this be dealt with? (request its removal? request that openscenegraph be forced to testing anyway?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735333: RM: haskell-hledger-lib - mips or mipsel?
You asked for removal on mips, but gave a reason that currently only applies on mipsel (https://buildd.debian.org/status/package.php?p=haskell-regex-tdfa); which do you mean? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736350: libopenscenegraph99: openscengraph sid version causes texture corruption in flightgear
Control: tags -1 patch fixed-upstream
If somebody can test the current source code from Debian applying this
patch to confirm that it's working with the programs having problems,
it would be great.
It fixes it for me (tested in Trusty, Flightgear 2.12.1).
Description: Default to BIND_PER_VERTEX to fix texture corruption
Bug-Debian: http://bugs.debian.org/736350
Origin: upstream https://github.com/openscenegraph/osg/commit/b801ae9d499a78889a322b95fbdf9864828349bc
--- openscenegraph-3.2.0~rc1.orig/OpenSceneGraph/src/osg/Geometry.cpp
+++ openscenegraph-3.2.0~rc1/OpenSceneGraph/src/osg/Geometry.cpp
@@ -161,12 +161,14 @@ void Geometry::setTexCoordArray(unsigned
if (_texCoordList.size()=index)
_texCoordList.resize(index+1);
-if (array binding!=osg::Array::BIND_UNDEFINED) array-setBinding(binding);
+if (array)
+{
+if (binding!=osg::Array::BIND_UNDEFINED) array-setBinding(binding);
+else array-setBinding(osg::Array::BIND_PER_VERTEX);
+}
_texCoordList[index] = array;
-// do we set to array BIND_PER_VERTEX?
-
dirtyDisplayList();
if (_useVertexBufferObjects array)
Bug#736350: libopenscenegraph99: openscengraph sid version causes texture corruption in flightgear
This fix also works in sid with the build-depends changed to libxine2-dev (to fix #724753). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722674: latest upstream no longer conflicts
Control: tags -1 fixed-upstream Control: retitle -1 file conflict between 3.2.0rc and 3.2.0 Control: unblock 725383 by -1 (If you're looking for the transition tracker, see #729289.) As of upstream 3.2.1rc2, these files are all named *.so.3.2.1 (including the openthreads one missed in 3.2.1rc1), so this file conflict no longer exists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729289: 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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725143: Bug#728521: ogre-1.9 / gcc-4.8
My whole intent of posting my previous message was to agree that you had been right about 4.8 becoming required and that this was hence no longer our problem. I think that your attempt to merge the bugs failed. Yes, can't merge bugs when only one of them is forwarded, and since the forwarded part is the part that isn't in the other bug I decided not to try again (so if you want to close them, you need to close both). It's been built successfully in s390x and most other arches (at least the ones where it was present before with src:ogre-1.9) The only one we still need is armhf, where this has never been a problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687332: Not openscenegraph's, and probably fixed
Control: reassign -1 gnome-settings-daemon # found -1 3.6.4-0ubuntu8 # 13.04 raring # fixed -1 3.8.5-0ubuntu9 # 13.10 saucy (Those versions don't exist in Debian, so I won't try to run them through the control server.) This is fixed in Ubuntu 13.10, with no changes to openscenegraph other than a no-code-change libcoin60-80 transition and some very visible changes to the keyboard layout switcher, so I suspect the problem was actually there. I also suspect it is fixed in Debian as well, but don't have that here to test. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738635: opencl-1.2-html-doc/index.html is useless
Package: opencl-1.2-html-doc
Version: 1.0~svn22836-1
Tags: patch
Control: tags 735653 patch
The index.html from this package has 3 frames whose contents are all
missing because get-orig-source deletes them, and a favicon which is an
inline link to the Khronos website, which is now discouraged
(http://lintian.debian.org/tags/privacy-breach-logo.html).
The attached patch is the Debian directory only: as the fix is partly in
get-orig-source, rerunning this is required. It also includes a fix for
a broken build script in current upstream, and one to allow building
with Ruby 1.9+ (#735653).
diff -uprN /home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/changelog
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/changelog
--- /home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/changelog
2013-08-26 13:20:15.0 +0100
+++ /home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/changelog
2014-02-11 12:27:54.999709030 +
@@ -1,3 +1,13 @@
+khronos-opencl-man (1.0~svn25290-1) UNRELEASED; urgency=low
+
+ * Explicitly set text encoding to UTF-8 to allow building with newer
+Ruby versions. Closes: #735653.
+ * Do not delete Opencl_header.html, Opencl_tofc.html,
+oclRefPages-Title.html
+ * Remove runtime-fetched favicon. Closes: $this_bug
+
+ -- Rebecca Palmer r.pal...@bham.ac.uk Mon, 10 Feb 2014 22:32:21 +
+
khronos-opencl-man (1.0~svn22836-1) unstable; urgency=low
* Do not delete index.html, remove lintian error
diff -uprN /home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/control
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/control
--- /home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/control
2013-08-26 13:07:31.0 +0100
+++ /home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/control
2014-02-11 11:30:19.831799600 +
@@ -3,7 +3,7 @@ Section: doc
Priority: extra
Maintainer: Debian OpenCL Maintainers
pkg-opencl-de...@lists.alioth.debian.org
Uploaders: Mathieu Malaterre ma...@debian.org, Giuseppe Bilotta
giuseppe.bilo...@gmail.com
-Build-Depends: debhelper (= 9), docbook-mathml (= 1.1~), w3-dtd-mathml,
docbook-xsl, xsltproc, ruby1.8
+Build-Depends: debhelper (= 9), docbook-mathml (= 1.1~), w3-dtd-mathml,
docbook-xsl, xsltproc, ruby
Standards-Version: 3.9.4
Homepage: http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/
Vcs-Svn: svn://anonscm.debian.org/pkg-nvidia/packages/khronos-opencl-man/trunk
diff -uprN
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/get-orig-source
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/get-orig-source
--- /home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/get-orig-source
2013-05-30 14:00:51.0 +0100
+++ /home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/get-orig-source
2014-02-10 22:07:47.146486236 +
@@ -23,7 +23,7 @@ URL=https://cvs.khronos.org/svn/repos/re
svn export --quiet --revision ${REVISION} ${URL} ${FOLDER}
# we will re-generate them anyway:
-find ${FOLDER}/xhtml -name \*.html -not -name index.html -delete
+find ${FOLDER}/xhtml -name \*.html -not -name index.html -not -name
Opencl_header.html -not -name Opencl_tofc.html -not -name
oclRefPages-Title.html -delete
URL2=https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs/man4
cd ${FOLDER}
diff -uprN
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/patches/fix_dir_name.patch
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/patches/fix_dir_name.patch
---
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/patches/fix_dir_name.patch
1970-01-01 01:00:00.0 +0100
+++
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/patches/fix_dir_name.patch
2014-02-11 12:46:44.311679427 +
@@ -0,0 +1,17 @@
+Description: Fix directory name error
+Author: Rebecca Palmer
+Forwarded: no
+Last-Update: 2014-02-10
+
+--- khronos-opencl-man-1.0~svn21772.orig/Makefile
khronos-opencl-man-1.0~svn21772/Makefile
+@@ -36,7 +36,7 @@ COMMONPREF = standard
+ include $(ROOT)/usr/include/make/commondefs
+
+ SUBDIRS = \
+- html \
++ xhtml \
+ $(NULL)
+
+ default $(ALLTARGS): $(_FORCE)
+
diff -uprN
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/patches/privacy_remove_favicon.patch
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/patches/privacy_remove_favicon.patch
---
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn22836/debian/patches/privacy_remove_favicon.patch
1970-01-01 01:00:00.0 +0100
+++
/home/palmer/fs_dev/khronos-opencl-man-1.0~svn25290/debian/patches/privacy_remove_favicon.patch
2014-02-10 22:18:26.966467331 +
@@ -0,0 +1,22 @@
+Description: Remove favicon
+
+The favicon in index.html is fetched from upstream every time the
+document is opened, which is now discouraged in Debian for privacy
+reasons (http://lintian.debian.org/tags/privacy-breach-logo.html)
+
+The 'o' from KhronosLogo.jpg could be
Bug#729289: transition: openscenegraph
openscenegraph is now in testing, flightgear and fgrun successfully built everywhere; should this bug now be closed? Upstream talk of openscenegraph 3.2.1 has died down again, but uploading the fixed ossim would still be a good idea. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739759: lists.debian.org: Sort by date/age don't work
Package: lists.debian.org The list archive search page (https://lists.debian.org/search.html) shows options to sort by relevance, date or age, but ignores them and always sorts by relevance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739760: lists.debian.org: Docs reference non-existent option to search a particular list
Package: lists.debian.org The archive search instructions (https://wiki.debian.org/DebianMailingLists/SearchHowto) say one should be able to select a particular list to search, but there is no such option on the actual search page. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717500: libopencl1-mesa or mesa-opencl-icd?
If the new package is the ICD rather than the loader, why is it called libopencl1-mesa rather than mesa-opencl-icd? Consistency with the others would suggest the latter. Due to unsupported hardware, I can't tell you whether it actually works; you might want to join the current discussion at http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/ of how we should choose which ICD(s) to install/default to. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739851: lists.debian.org: Sorry is not an (un)subscription request
Package: lists.debian.org Twice, I've apologised on the BTS for my mistake in handling a bug (with no mention of any mailing lists), and got a don't send (un)subscription requests to the list autoresponse from debian-bugs-dist-request. The second case also had a Re: subject, which the notice itself says should avoid triggering it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650575#44 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739743#34 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739851: lists.debian.org: Sorry is not an (un)subscription request
If you want the full headers, see the BTS full text/mbox links. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650575#44 : Original Message Subject: sorry... Date: Sun, 19 Jan 2014 15:07:57 + From: Rebecca N. Palmer r.pal...@bham.ac.uk To: 650...@bugs.debian.org ...I forgot that libpng has versioned -dev packages, so what I thought was my test build against 1.6 was actually still 1.2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739743#34 : Original Message Subject: Re: Bug#739743: FTBFS: circular dependency Date: Sun, 23 Feb 2014 08:25:42 + From: Rebecca N. Palmer r.pal...@bham.ac.uk To: Keith Packard kei...@keithp.com, 739...@bugs.debian.org , as this bug makes ~all GUI packages BD-Uninstallable on non-amd64. Sorry...it looks like this is being fixed by forcing builds against 2.11.0-2 (https://buildd.debian.org/status/package.php?p=fontconfig), so fixing this bug is no longer so urgent. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739851: lists.debian.org: Sorry is not an (un)subscription request
Original Message Subject: Re: Bug#650575: sorry... Date: Sun, 19 Jan 2014 15:09:11 + From: debian-bugs-dist-requ...@lists.debian.org To: r.pal...@bham.ac.uk General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example thel...@lists.debian.org, then the -request address can be inferred from this to be: thelist-requ...@lists.debian.org. To subscribe to a mailing list, simply send a message with the word subscribe in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) unsubscribe in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be Re:, without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of every mail coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send mails to the -request address with the word archive as the first word of your Subject:. To get you started try sending a mail to the -request address with the following: Subject: archive help The listmaster -- To reach a human being answering your mail you may contact the address listmas...@lists.debian.org. We will process your request as soon as we can. Mail sent to this address is pre-parsed, a little mail robot will automatically answer all mails sent with the following Subject lines: help sends this help lists sends information on how to get a list of mailing lists Original Message Subject: Re: Bug#739743: FTBFS: circular dependency Date: Sun, 23 Feb 2014 08:27:18 + From: debian-bugs-rc-requ...@lists.debian.org To: r.pal...@bham.ac.uk General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example thel...@lists.debian.org, then the -request address can be inferred from this to be: thelist-requ...@lists.debian.org. To subscribe to a mailing list, simply send a message with the word subscribe in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) unsubscribe in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be Re:, without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of
Bug#739176: OpenCL implementation selection
For libopencl1-icd, I agree that defaulting to ocl-libopencl1-icd is a good idea: it works with this package, nvidia-lbopencl1 doesn't (due to only being v1.1: #682435). For opencl-icd there is currently no real solution; potential solutions are being discussed at http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745194: Undeclared dependency on python(3)-pkg-resources
Source: pyopencl Version: 2013.2-1 If python(3)-pkg-resources is not installed, pyopencl crashes on attempting to create a kernel (explicitly, or implicitly via pyopencl.array): bCL=aCL+1 Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/dist-packages/pyopencl/array.py, line 829, in __add__ self, common_dtype.type(other)) File /usr/lib/python2.7/dist-packages/pyopencl/array.py, line 172, in kernel_runner knl = kernel_getter(*args, **kwargs) File /usr/lib/python2.7/dist-packages/pyopencl/array.py, line 672, in _axpbz a.dtype, x.dtype, b.dtype, out.dtype) File string, line 2, in get_axpbz_kernel File /usr/lib/python2.7/dist-packages/pyopencl/tools.py, line 114, in first_arg_dependent_memoize result = func(cl_object, *args) File /usr/lib/python2.7/dist-packages/pyopencl/elementwise.py, line 600, in get_axpbz_kernel name=axpb) File /usr/lib/python2.7/dist-packages/pyopencl/elementwise.py, line 172, in get_elwise_kernel name=name, options=options, **kwargs) File /usr/lib/python2.7/dist-packages/pyopencl/elementwise.py, line 155, in get_elwise_kernel_and_types use_range=use_range, loop_prep=loop_prep, **kwargs) File /usr/lib/python2.7/dist-packages/pyopencl/elementwise.py, line 108, in get_elwise_program return Program(context, source).build(options) File /usr/lib/python2.7/dist-packages/pyopencl/__init__.py, line 141, in build options = options + [-I, _find_pyopencl_include_path()] File /usr/lib/python2.7/dist-packages/pyopencl/__init__.py, line 722, in _find_pyopencl_include_path from pkg_resources import Requirement, resource_filename ImportError: No module named pkg_resources -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676504: pocl package now builds
After importing version 0.9 and making the attached changes to /debian, pocl builds, and appears to be functional (tested with pyopencl). Remaining known issues: Out-of-date symbols files (how do you get the (c++) in there?) dpkg-shlibdeps warnings: dh_shlibdeps -a -- --warnings=7 dpkg-shlibdeps: warning: debian/libpocl1/usr/lib/x86_64-linux-gnu/pocl/llvmopencl.so.3.0.0 contains an unresolvable reference to symbol _ZNK4llvm15ScalarEvolution10isSCEVableEPNS_4TypeE: it's probably a plugin dpkg-shlibdeps: warning: 264 other similar warnings have been skipped (use -v to see them all) dpkg-shlibdeps: warning: debian/libpocl1/usr/lib/x86_64-linux-gnu/pocl/llvmopencl.so.3.0.0 should not be linked against libgcc_s.so.1 (it uses none of the library's symbols) dpkg-shlibdeps: warning: debian/libpocl1/usr/lib/x86_64-linux-gnu/libpocl.so.1.2.0 should not be linked against libffi.so.6 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libpocl1/usr/lib/x86_64-linux-gnu/pocl/llvmopencl.so.3.0.0 was not linked against libgcc_s.so.1 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libpocl1/usr/lib/x86_64-linux-gnu/libpocl.so.1.2.0 was not linked against libffi.so.6 (it uses none of the library's symbols) commit 993bed5ef33521ab7680bc110047b3d7c3888e4c Author: Rebecca Palmer r.pal...@bham.ac.uk Date: Sat Apr 19 16:23:33 2014 +0100 Link statically to llvm Upstream reports that not doing this can crash when used together with mesa llvmpipe, https://github.com/pocl/pocl/issues/46 diff --git a/debian/rules b/debian/rules index cc775c6..6ecb62e 100755 --- a/debian/rules +++ b/debian/rules @@ -32,6 +32,7 @@ export LLC_HOST_CPU=(unknown) override_dh_auto_configure: autoreconf -vif -Wall -Wno-obsolete dh_auto_configure -- --enable-icd --disable-static \ + --enable-static-llvm \ LLVM_CONFIG=/usr/lib/llvm-3.4/bin/llvm-config \ --host=`dpkg-architecture -qDEB_HOST_GNU_TYPE` \ --target=`dpkg-architecture -qDEB_HOST_GNU_TYPE` commit d5b54ec750a1be49f6065221038b5e031a00afaf Author: Rebecca Palmer r.pal...@bham.ac.uk Date: Sat Apr 19 15:36:03 2014 +0100 Rename libpoclu0-1 to match soname diff --git a/debian/control b/debian/control index 6b09772..7261e6a 100644 --- a/debian/control +++ b/debian/control @@ -44,7 +44,7 @@ Description: Portable OpenCL library . This package provides the core of POCL. -Package: libpoclu0 +Package: libpoclu1 Architecture: any Section: libs Multi-Arch: same @@ -89,4 +89,4 @@ Description: debugging symbols for POCL target-dependent manual optimizations. A native target is included, which allows running OpenCL kernels on the host (CPU). . - This package contains the debugging symbols for libpocl1 and libpoclu0. + This package contains the debugging symbols for libpocl1 and libpoclu1. diff --git a/debian/libpoclu0.install b/debian/libpoclu0.install deleted file mode 100644 index 0f2032a..000 --- a/debian/libpoclu0.install +++ /dev/null @@ -1 +0,0 @@ -usr/lib/*/libpoclu.*so.* diff --git a/debian/libpoclu0.symbols b/debian/libpoclu0.symbols deleted file mode 100644 index 23ed5c6..000 --- a/debian/libpoclu0.symbols +++ /dev/null @@ -1,6 +0,0 @@ -libpoclu.so.0 libpoclu0 #MINVER# - poclu_bswap_cl_float2_array@Base 0.7~rc2 - poclu_bswap_cl_float@Base 0.7~rc2 - poclu_bswap_cl_float_array@Base 0.7~rc2 - poclu_bswap_cl_int@Base 0.7~rc2 - poclu_bswap_cl_int_array@Base 0.7~rc2 diff --git a/debian/libpoclu1.install b/debian/libpoclu1.install new file mode 100644 index 000..0f2032a --- /dev/null +++ b/debian/libpoclu1.install @@ -0,0 +1 @@ +usr/lib/*/libpoclu.*so.* diff --git a/debian/libpoclu1.symbols b/debian/libpoclu1.symbols new file mode 100644 index 000..2fed492 --- /dev/null +++ b/debian/libpoclu1.symbols @@ -0,0 +1,6 @@ +libpoclu.so.1 libpoclu1 #MINVER# + poclu_bswap_cl_float2_array@Base 0.7~rc2 + poclu_bswap_cl_float@Base 0.7~rc2 + poclu_bswap_cl_float_array@Base 0.7~rc2 + poclu_bswap_cl_int@Base 0.7~rc2 + poclu_bswap_cl_int_array@Base 0.7~rc2 commit 940f4808e4ea874c61fc4f784cbafba4692d21d6 Author: Rebecca Palmer r.pal...@bham.ac.uk Date: Sat Apr 19 15:30:58 2014 +0100 Update fix_linkage.patch, add -Wl,--as-needed (Not yet enough to remove all the unnecessary linkage) diff --git a/debian/patches/fix_linkage.patch b/debian/patches/fix_linkage.patch index 51b9299..36c13cf 100644 --- a/debian/patches/fix_linkage.patch +++ b/debian/patches/fix_linkage.patch @@ -1,37 +1,28 @@ Description: remove most of superflous linkage Several binaries and libraries are linked with uneeded libraries. This patch remove most of them. -Author: Vincent Danjean vdanj...@debian.org +Author: Vincent Danjean vdanj...@debian.org, Rebecca Palmer --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ ---
Bug#743374: #743374: not a bug (libopencl1 isn't hardware specific)
nvidia-libopencl1 is OpenCL 1.1, not 1.2, and pyopencl hence doesn't work with it: https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1174205 You can still use pyopencl with Nvidia hardware, as the hardware-specific part is opencl-icd not libopencl1. The choices for this are: nvidia-opencl-icd (Nvidia GPUs) mesa-opencl-icd (Radeon GPUs; plans to support more in the future) amd-opencl-icd (Radeon GPUs, and CPUs) amd-opencl-icd-legacy (older Radeon GPUs) beignet (Intel GPUs) At present it is necessary to choose the correct opencl-icd manually, as the package management system doesn't know what GPU you have, and installing them all doesn't work as beignet crashes if its hardware is not present. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745363: No way to check whether the hardware is present
Package: beignet
Version: 0.8-1
Tags: patch
As discussed earlier [0-1], if no compatible hardware is present
clGetDeviceIDs should report this to the caller (allowing it to try
another ICD if more than one is installed, or to continue without using
OpenCL), but in beignet it instead calls exit(-1). This fixes this.
Warning: I don't have any Intel GPUs to test whether it still works when
the hardware is present.
[0]
http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140217/96.html
[1]
http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140217/000100.html
Description: If no device, return CL_DEVICE_NOT_FOUND instead of exiting
If no Intel GPU is present, beignet currently exits on
clGetDeviceIDs. This patch instead returns CL_DEVICE_NOT_FOUND,
allowing the calling application to decide what to do
(e.g. try a different platform).
Author: Rebecca Palmer
Forwarded: no
--- beignet-0.8.orig/src/cl_api.c
+++ beignet-0.8/src/cl_api.c
@@ -167,6 +167,7 @@ cl_check_device_type(cl_device_type devi
static cl_int
cl_device_id_is_ok(const cl_device_id device)
{
+ if(UNLIKELY(device == NULL)) return CL_FALSE;
return device != cl_get_gt_device() ? CL_FALSE : CL_TRUE;
}
--- beignet-0.8.orig/src/cl_device_id.c
+++ beignet-0.8/src/cl_device_id.c
@@ -184,7 +184,7 @@ ivb_gt2_break:
break;
default:
printf(cl_get_gt_device(): error, unknown device\n);
- exit(1);
+ ret = NULL;
}
return ret;
--- beignet-0.8.orig/src/cl_device_data.h
+++ beignet-0.8/src/cl_device_data.h
@@ -20,6 +20,8 @@
#ifndef __CL_DEVICE_DATA_H__
#define __CL_DEVICE_DATA_H__
+#define INVALID_CHIP_ID -1 //returned by intel_get_device_id if no device found
+
#define PCI_CHIP_GM45_GM0x2A42
#define PCI_CHIP_IGD_E_G0x2E02
#define PCI_CHIP_Q45_G 0x2E12
--- beignet-0.8.orig/src/intel/intel_driver.c
+++ beignet-0.8/src/intel/intel_driver.c
@@ -175,7 +175,7 @@ intel_driver_init(intel_driver_t *driver
#endif /* EMULATE_GEN */
}
-static void
+static cl_int
intel_driver_open(intel_driver_t *intel, cl_context_prop props)
{
int cardi;
@@ -185,7 +185,7 @@ intel_driver_open(intel_driver_t *intel,
props-gl_type != CL_GL_GLX_DISPLAY
props-gl_type != CL_GL_EGL_DISPLAY) {
printf(Unsupported gl share type %d.\n, props-gl_type);
-exit(-1);
+return CL_INVALID_OPERATION;
}
intel-x11_display = XOpenDisplay(NULL);
@@ -216,7 +216,7 @@ intel_driver_open(intel_driver_t *intel,
}
if(!intel_driver_is_active(intel)) {
printf(Device open failed\n);
-exit(-1);
+return CL_DEVICE_NOT_FOUND;
}
#ifdef HAS_EGL
@@ -224,6 +224,7 @@ intel_driver_open(intel_driver_t *intel,
assert(props-egl_display);
}
#endif
+ return CL_SUCCESS;
}
static void
@@ -361,7 +362,7 @@ intel_get_device_id(void)
driver = intel_driver_new();
assert(driver != NULL);
- intel_driver_open(driver, NULL);
+ if(UNLIKELY(intel_driver_open(driver, NULL) != CL_SUCCESS)) return INVALID_CHIP_ID;
intel_device_id = driver-device_id;
intel_driver_close(driver);
intel_driver_terminate(driver);
@@ -385,7 +386,7 @@ cl_intel_driver_new(cl_context_prop prop
{
intel_driver_t *driver = NULL;
TRY_ALLOC_NO_ERR (driver, intel_driver_new());
- intel_driver_open(driver, props);
+ if(UNLIKELY(intel_driver_open(driver, props) != CL_SUCCESS)) goto error;
/* We use the first 2 slots(0,1) for all the bufs.
* Notify the gbe this base index, thus gbe can avoid conflicts
* when it allocates slots for images*/
Bug#745456: create_some_context() can fail if multiple ICDs installed
Source: pyopencl Version: 2013.2-1 Tags: patch In non-interactive mode, create_some_context currently always chooses the first device of the first platform. This fails if this has no devices (eg. it is the wrong one for the available hardware), and will be slow if if is the CPU. This patch makes it search through the platforms for a device, preferring a GPU if available. As discussed earlier, this will allow making OpenCL just work (at least for hardware that has a free ICD) by defaulting to installing all ICDs. This requires the Make get_devices() return an empty list instead of erroring out fix you just sent upstream. Description: Don't fail if the first platform has no devices In non-interactive mode, create_some_context currently always chooses the first device of the first platform. This fails if this has no devices (eg. it is the wrong one for the available hardware), and will be slow if if is the CPU. This patch makes it search through the platforms for a device, preferring a GPU if available. Author: Rebecca Palmer Forwarded: no --- pyopencl-2013.2.orig/pyopencl/__init__.py +++ pyopencl-2013.2/pyopencl/__init__.py @@ -776,9 +776,22 @@ def create_some_context(interactive=True for i, pf in enumerate(platforms): cc_print([%d] %s % (i, pf)) -answer = get_input(Choice [0]:) +answer = get_input(Choice:) if not answer: -platform = platforms[0] +for pf in platforms: +devices = pf.get_devices(device_type=device_type.GPU) +if devices: +platform = pf +default_device = devices[0] +break +if not devices: # No GPUs found +for pf in platforms: +devices = pf.get_devices() +if devices: +platform = pf +default_device = devices[0] +break + else: platform = None try: @@ -828,9 +841,9 @@ def create_some_context(interactive=True for i, dev in enumerate(devices): cc_print([%d] %s % (i, dev)) -answer = get_input(Choice, comma-separated [0]:) +answer = get_input(Choice, comma-separated:) if not answer: -devices = [devices[0]] +devices = [default_device] else: devices = [parse_device(i) for i in answer.split(,)]
