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
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
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
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
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:
Thanks. Are you also applying my corrected CVE-2012-2091 patch to simgear?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-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
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
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-rc-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.
Libav 9.10 is now in unstable; you might want to retry with that.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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
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: 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
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
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
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: 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,
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
The current version builds fine with Ruby 1.9, but later upstream
versions successfully produce near-empty packages. See #738635 for
the fix.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian doesn't have a /usr/share/OpenCV/java/libopencv_java248.so, but
it does have a /usr/lib/libopencv_java248.so in libopencv2.4-jni; does
build-depending on that help?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
libopencv-dev doesn't pull in the Java libraries; I don't know if the
appropriate fix is that it should, or that the cmake script shouldn't be
looking for them when building C(++).
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
I've successfully built openscenegraph in sid with the patches for
#739460 and #687332, and tested it with flightgear, confirming that they
fix those bugs (for #739460, fixed meaning builds with libav 10, and
still has an osgdb_ffmpeg.so; I don't know if we have any packages that
actually use
Control: retitle -1 jitsi: documentation not built
Control: tags -1 jessie sid
Control: severity -1 normal
jitsi has always had these error: unmappable character for encoding
error: unmappable character for encoding ASCII messages (due to
non-ASCII characters in comments), but though they
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]
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-rc-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
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
There's also some work on ossim 1.8.16 here
http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-January/017876.html
, but it seems to have been abandoned.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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: flightgear-data-base
Version: 3.0.0-1
Severity: grave
Justification: renders package unusable
Control: tags -1 patch
A fresh install (no .fgfs) of amd64 flightgear in current jessie or
current sid fails to start:
Program received signal SIGABRT, Aborted.
0x71d6f077 in
Control: reassign -1 src:simgear
Control: found -1 3.0.0-5
Control: merge -1 765932
These are both the same kfreebsd FTBFS; this (#765818) patch looks
better, but I haven't tried either.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
@@ -1,3 +1,10 @@
+flightgear-data (3.0.0-2) UNRELEASED; urgency=medium
+
+ * Fix type mismatch crash. Closes: #766251.
+ * Downgrade -ai, -aircrafts to Recommends.
+
+ -- Rebecca N. Palmer rebecca_pal...@zoho.com Wed, 22 Oct 2014 18:27:01
+0100
+
flightgear-data (3.0.0-1) unstable; urgency=low
dpkg-source --commit produced a patch with all Unix line endings, which
failed; running that through unix2dos gave a patch with all DOS line
endings, which also failed, with
(Stripping trailing CRs from patch; use --binary to disable.)
patching file Effects/model-combined-transparent.eff
Hunk
/patches/versioned-llvm-tools 2014-10-28
12:17:01.0 +
@@ -1,9 +1,20 @@
Description: Use versioned LLVM tools
-Author: Simon Richter s...@debian.org
-Last-Update: 2014-04-19
+Description: short summary of the patch
+Author: Simon Richter s...@debian.org, Rebecca N. Palmer
rebecca_pal
Source: libjogl2-java
Version: 2.2.4-1
Severity: serious
Justification: Policy 2.1
Control: found -1 2.1.5-2
src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/shader/landscape.fp
has a NonCommercial license, which is not allowed in Debian (even if the
file isn't actually used:
Package: beignet
Version: 0.8-1.1
Severity: serious
Justification: Policy 2.1
Control: tags -1 patch upstream
X-Debbugs-CC: pkg-opencl-de...@lists.alioth.debian.org
The beignet test suite contains three images derived from Lenna (
kernels/lenna128x128.bmp kernels/compiler_box_blur_float_ref.bmp
I'm just wondering where
the build failure in late August with exactly those dependencies came
from and why the change fixed them?
during compilation clang
was called but could not be found:
[...]
Only the clang metapackage but not the clang-some.version package
provides /usr/bin/clang.
Control: forwarded -1
http://lists.freedesktop.org/archives/beignet/2014-October/004343.html
I have reported this upstream; they have agreed it's a problem and are
in the process of removing the first group and investigating the second.
To deal with this problem in the meantime, we will need
*mandelbrot* were included in this report by mistake, and are actually
OK to keep.
Now it FTBFS (it was working before the dfsg changes), tail of buildlog:
I get the same error with git-buildpackage, but success with
dpkg-buildpackage (as root in cowbuilder --login chroot; not cowbuilder
You have my blessing to change the maintainer field if you like, as I
won't be able to do as much as is needed in the next days.
It would probably make sense for the pkg-opencl-devel list to own this
package; I'm willing to be named as uploader, but will need a sponsor to
actually upload
versioned-llvm-tools.patch.
+(Closes: #764930)
+ * State in the description what hardware this supports.
+
+ -- Rebecca N. Palmer rebecca_pal...@zoho.com Sat, 01 Nov 2014
14:01:26 +
+
beignet (0.8-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru beignet-0.8/debian
, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
beignet (0.9.3~dfsg-2) UNRELEASED; urgency=medium
.
* Fix tgamma,pow,pown,erf,erfc
* Enable debug output in tests
Author: Rebecca N. Palmer rnpalmer@rnpalmer-laptop
---
The information above should follow the Patch
Fix committed to Alioth.
This fix has been accepted upstream; they found that it exposed another
bug that compare and type-convert don't properly handle constants
(http://lists.freedesktop.org/archives/beignet/2014-November/004387.html),
so I included the fix for that as well.
My own
I think the trigger is nvidia-opencl-icd adding a new dependency on
libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to
be capable of doing dlopen(libcuda.so) or dlopen(libcuda.so.1).),
which pulls in the rest of nvidia-* as libcuda1 Recommends:
nvidia-kernel-dkms which
Rebecca Palmerr wrote:
The only other [than pyopencl]
Depends or Recommends on opencl-icd in the current archive is bfgminer.
Sorry...only ones found by path:debian/control opencl-icd in
sources.debian.net search (apt-cache rdepends doesn't work on virtual
packages), which evidently doesn't
a better fix might be for whatever sets nvidia
as default graphics provider to only do so if the hardware is present,
but I don't know whether that's practical.
The package already has a check in
http://sources.debian.net/src/nvidia-graphics-drivers/340.46-5/debian/libgl1-nvidia-glx.preinst.in
(Should we merge these bugs? Also, #767803 looks like another instance
of this, though it doesn't have the apt log to confirm it yet)
* nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver.
...or drop this
* nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver.
#768185
suggests that nvidia-opencl-icd works without the graphics side (can
someone check that?), making this the more correct place to cut the chain.
what would happen to
an Nvidia-hardware-only system with nvidia kernel module (which
blacklists the nouveau kernel module) + nouveau graphics userspace,
which under [nvidia-kernel-dkms Recommends: nvidia-driver | libcuda1]
would be the result of trying to install OpenCL on
a previously
nouveau is not blacklisted ... the kernel module would probably get loaded by a
cuda application
#580894 (the original reason for the blacklist) has conflicting reports
of what would happen next: some report nvidia.ko gets control (=blank
screen if the graphics side isn't installed), some that
This is an intentionally abandoned transition: a serious bug delayed the
(upstream) release of 3.2 past (Ubuntu and Debian) freezes, and 3.4 is
due before the next Ubuntu freeze (LP#1414379).
If you urgently want 3.2, dropping the 3.2 flightgear-data upstream into
the 3.0.0-1 (not -2)
I installed
openjdk-7-jre:i386 on an amd64 system and for some reason
openjdk-7-jre:amd64 has been pulled as well.
That's probably because of this dependency cycle: multiarch treats
arch:all packages as the native architecture
now every kernel invocation, regardless of arguments
counts and array sizes, fails
i.e. including ones that worked in 1.0.2-1? Do they use the 'local'
memory space (which triggers a third known bug on Haswell)?
drm_intel_gem_bo_context_exec() failed: Invalid argument
That's the error check
Control: retitle -1 beignet: silently does nothing on large arrays
(previous discussion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875 )
This isn't a Haswell-specific problem (and might not be ICD-specific
either: did you test that at these sizes, or only with the testsuite?),
Control: forwarded -1
http://lists.freedesktop.org/archives/beignet/2015-April/date.html
The ICD interface works for me (i5-3230M), which makes this bug _both_
hardware- and interface-dependent, which is weird.
Since version 1.0.1 beignet has been able to recognitze the hardware on
my
On 05/04/15 00:08, David Couturier wrote:
This looks like the problem I experienced on my i7-4770. I fixed the issue by
applying this patch to the kernel:
https://01.org/zh/beignet/downloads/linux-kernel-patch-hsw-support
That's the long-standing no shared local memory on Haswell problem,
Control: tags -1 patch
Since libfltk1.3-dev 1.3.3-1 switched to using upstream's cmake files
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792386#10), using it
from cmake now appears to require libcairo2-dev and fluid, which are not
hard Depends of the package (presumably because they
It's lmms that isn't finding fluid (because it doesn't build-depend on
it), fgrun is only missing libcairo2-dev.
However, fgrun already bypasses cmake-data with
find_package(FLTK REQUIRED NO_MODULE)
as recommended in
https://sources.debian.net/src/fltk1.3/1.3.3-2/README.CMake.txt/#L233
Control: retitle -1 fgrun: missing build-dependency on libcairo2-dev
Control: severity -1 important
(should no longer be an FTBFS, though I haven't tested it)
I've worked around both of these problems on my side for now for the
sake of the GCC 5 transition, but may want to revisit them once
Control: reopen -1
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 790756
Control: reassign -1 release.debian.org
Control: forwarded -1
https://release.debian.org/transitions/html/auto-llvm-toolchain-3.5.html
Control: retitle -1 llvm-toolchain-3.5: library
=medium
+
+ * Rename for gcc5 transition.
+
+ -- Rebecca N. Palmer <rnpalmer@rnpalmer-laptop> Sat, 05 Sep 2015 14:08:42 +0100
+
simgear (3.4.0-2) unstable; urgency=medium
* Really drop the conflicts against simgear0 (in control.in).
diff --git a/debian/control b/debian/control
index d
Package: src:pocl
Version: 0.10-10
Severity: serious
Control: found -1 0.10-12
Control: block 794935 with -1
The binNMU of pocl for the llvm-toolchain-3.5 transition
(https://buildd.debian.org/status/fetch.php?pkg=pocl=amd64=0.10-10%2Bb1=1442439767)
failed with symbols mismatches, at least
Reassigning back so the maintainers see this.
It appears to be random (race condition in the BTS??) whether the old or
new package's maintainer gets the main text of a reassign message (this
one went to the old one, but #793517 went to the new one). Is that a bug?
(Both maintainers get the
Package: oclgrind
Version: 15.5-2
Severity: serious
oclgrind FTBFS on big-endian systems (mips,powerpc,s390x) with several
test failures:
https://buildd.debian.org/status/fetch.php?pkg=oclgrind=mips=15.5-2=1449588354
Given that this is its first upload with tests enabled, it is fairly
likely
[ 31%] Building C object src/CMakeFiles/cl.dir/cl_khr_icd.c.o
cd
/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/obj-x86_64-linux-gnu/src
&& /usr/bin/cc -DGEN7_SAMPLER_CLAMP_BORDER_WORKAROUND -DLLVM_36 -Dcl_EXPORTS
There is several libraries missing in dependencies. While libalut0 is
just missing, the needed library libopenscenegraph65 is not in debian
anymore. And without that library, flightgear will not even start.
There might be others like libopenthreads13 (which is also missing in
debian).
Only the
Control: forcemerge 826896 826997
I've also seen this, and confirm that a no-change rebuild of the sid
(2.9.0.11-1) source in jessie fixes the problem. (Hence the "resolved"
status, as this is defined to mean "fixed in sid". Such updates have
previously been allowed in stable: see #744730.)
Control: reassign -1 src:khronos-opencl-headers
On 05/01/16 18:09, J Price wrote:
On 5 January 2016 at 09:42, Brice Videau <brice.vid...@imag.fr> wrote:
On 05-Jan-16 00:02, Rebecca N. Palmer wrote:
This is probably due to ocl-icd 2.2.8 adding CL/cl_egl.h to the headers
#included by ocl
Are you able to reproduce this (under an up to date Jessie + backports
system).
No - the build (of master, i.e. 2.1.2+20160525-1) fails with
/tmp/pocldFu22d/program.cl:3273:32: error: call to '_cl_ldexp' is ambiguous
sum[pat][state] += ldexp(frexp(dRootPartials[u + delta *
r], ),
Is this going to get a stable update (as previously suggested)?
On 11/06/16 08:04, Rebecca N. Palmer wrote:
a no-change rebuild of the sid
(2.9.0.11-1) source in jessie fixes the problem.[...]Such updates have
previously been allowed in stable: see #744730.)
Control: forwarded -1 https://github.com/Theano/Theano/issues/5498
Control: tags -1 patch
I don't think this is a regression - it's Python 3 specific
(numpy.array(list of longs, which this test uses on Python 2)=int64
array, but numpy(list of Python 3 ints)=int_nativesize array; see above
Control: tags -1 patch
Three patches because this is logically three bugs, though it's filed as
two upstream:
https://github.com/Theano/Theano/issues/5494
https://github.com/Theano/Theano/issues/5396
First patch taken from upstream
On 22/01/17 21:07, Sylvestre Ledru wrote:
> , you haven't pass the arg to LDFLAGS to make sure that libclang or
> liblldb get it,
> is that on purpose?
My original intent was to avoid passing it to those parts of LLVM that
already use a "version" (actually which-symbols-are-public) script, as
I
(1.5.3+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't fail tests on a harmless wand warning. Closes: #848478
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Sun, 22 Jan 2017 22:13:59
+
+
blockdiag (1.5.3+dfsg-1) unstable; urgency=medium
* New up
Found the problem: the affected functions (
https://sources.debian.net/src/theano/0.8.2-4/theano/sparse/opt.py/#L862
,
https://sources.debian.net/src/theano/0.8.2-4/theano/sparse/opt.py/#L1902
) cast a pointer-to-intptr_t (64 bit) to a pointer-to-int (32-bit).
Which isn't just broken on
and negative stride handling
Cast values, not pointers, from int64 to int32.
Remember that first-in-index order (numpy) and
first-in-memory-order (BLAS) are not always the same thing.
Bump c_code_cache_version to make sure existing installs use the fixes.
Author: Rebecca N. Palmer <rebecca_
1 - 100 of 376 matches
Mail list logo
