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
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
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
+++
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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 ~
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
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
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
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
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
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
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:
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
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
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++
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
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
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
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
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
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
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
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
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
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?
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
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
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),
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
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,
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
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
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
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
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
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
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
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
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
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,
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).
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.
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
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
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
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:
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:
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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 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
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?
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
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.
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
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
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
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).
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
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
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
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
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
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
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:
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
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
1 - 100 of 915 matches
Mail list logo
