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 wrote:
On 05-Jan-16 00:02, Rebecca N. Palmer wrote:
This is probably due to ocl-icd 2.2.8 adding CL/cl_egl.h to the headers
#included by ocl_icd.h
(https
[ 31%] Building C object src/CMakeFiles/cl.dir/cl_khr_icd.c.o
cd
/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1.1/obj-x86_64-linux-gnu/src
&& /usr/bin/cc -DGEN7_SAMPLER_CLAMP_BORDER_WORKAROUND -DLLVM_36 -Dcl_EXPORTS
-I/home/lamby/temp/cdt.20151228220726.tJcO28ENAf/beignet-1.1
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&arch=mips&ver=15.5-2&stamp=1449588354
Given that this is its first upload with tests enabled, it is
You're right. Upstream needs the local copy since many systems don't
have recent enough OpenCL headers, but for Debian I could add a patch
to remove the local copy and have a build-dependency on opencl-headers
instead.
opencl-headers already has the __vector fix, but as already noted, the
bool
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
- - beignet builds fine with llvm-3.6, but needs a sourceful upload
because of hardcoded dependencies on control file
That's there because, while it builds and mostly works with 3.6, this at
least used to sometimes hit a bug:
http://www.freedesktop.org/wiki/Software/Beignet/
As I do not have c
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 Pr
Control: reopen -1
Control: tags -1 patch
Actually, I can't find cl2.hpp in the listing of the package [1].
[1] https://packages.debian.org/sid/all/opencl-headers/filelist
It's in the source package, but not the binary, because the line that
would install it is commented out:
https://anons
Forwarded Message
Subject: Re: Bug#799322: pocl: FTBFS: (gcc5 related?) symbols mismatches
+ test failures
Date: Thu, 17 Sep 2015 23:23:44 +0200
From: Vincent Danjean
To: Rebecca N. Palmer , 799...@bugs.debian.org
Le 17/09/2015 22:45, Rebecca N. Palmer a écrit :
Package
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&arch=amd64&ver=0.10-10%2Bb1&stamp=1442439767)
failed with symbols mismatches
If you're running pure stretch (not a stretch+sid mix), that probably
*isn't* this bug, as stretch only has the non-v5 version of
libllvm3.5/libclang1-3.5, and packages using the v5 version (e.g. new
versions of mesa) are hence not allowed to enter stretch.
#797917 occurs on using clang to com
21:27:13 +0000
From: Debian Bug Tracking System
To: Rebecca N. Palmer
CC: pkg-llvm-t...@lists.alioth.debian.org,
debian-bugs-forwar...@lists.debian.org, debian-rele...@lists.debian.org
Processing control commands:
reopen -1
Bug #794935 {Done: Sylvestre Ledru }
[src:llvm-toolchain-3.5] l
Control: retitle -1 beignet is not installable with libllvm3.5v5
beignet was built against llvm3.5 and (the version currently in sid)
does not support anything newer. The upcoming upload of 1.1.0 should
support llvm3.6. But Rebecca might correct me on this :-)
LLVM 3.5 is still the upstream de
This is probably the bug fixed upstream (from 3.5) by
http://sourceforge.net/p/flightgear/flightgear/ci/033957003f4be52ea554a4260b70f1f97440dca0/
, which occurs after settings are saved and is hence a harmless annoyance.
(Note that 3.5+ also enable the launcher by default, which causes a
diffe
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 t
Package: bugs.debian.org
I attempted to set a gcc5 transition usertag with Control:
pseudo-headers to nnn@b.d.o
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797944#10), but it
was rejected with "Unknown command or malformed arguments to command"
(https://lists.debian.org/debian-release/
=medium
+
+ * Rename for gcc5 transition.
+
+ -- Rebecca N. Palmer Sat, 05 Sep 2015 14:08:42 +0100
+
simgear (3.4.0-2) unstable; urgency=medium
* Really drop the conflicts against simgear0 (in control.in).
diff --git a/debian/control b/debian/control
index d490a6f..661f8c0 100644
--- a
Control: severity -1 grave
Control: reassign -1 libsimgearscene3.4.0
Confirmed in pure sid (original reporter was using a sid+stretch mix),
makes flightgear totally nonfunctional.
It looks vaguely like a gcc5 transition issue (the symbol in question
involves std::string,
http://sources.debia
New gcc5 transition notices are still being sent out with the "Such a
change can be avoided, if you have a soversion bump and you upload this
version instead of the renamed package" wording (e.g. simgear
https://bugs.debian.org/797944 ); is this a mistake, or is hdf5 special
because it has both
FindFLTK.cmake appears to be intended for fltk1.1, as upstream fltk1.3
recommend not using it at all (for either shared or static linking):
https://sources.debian.net/src/fltk1.3/1.3.3-2/README.CMake.txt/#L233
For an example of such shared FLTK linking, see
http://sources.debian.net/src/fgrun/3
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 tha
It's lmms that isn't finding fluid (because it doesn't build-depend on
it), fgrun is only missing libcairo2-dev.
However, fgrun already bypasses cmake-data with
find_package(FLTK REQUIRED NO_MODULE)
as recommended in
https://sources.debian.net/src/fltk1.3/1.3.3-2/README.CMake.txt/#L233
and
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 are
That probably
means changing the libgdal binary package name
to e.g. libgdal1a; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712688#10 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731261#30 for previous
examples.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.
In order to solve this problem, you could:[...]
2 add the source files to "debian/missing-sources" directory
Which we already have:
https://sources.debian.net/src/flightgear-data/3.4.0%2Bdfsg-1/debian/missing-sources/sprintf.js-1.0.2/src/sprintf.js/
Should this bug be closed?
--
To UNSUBSC
Control: tags -1 wontfix
Most of gpuocelot is not BSD but "BSD plus you must obey US export
restrictions (even if you are not in the US)" [0]. This is both
non-DFSG-free [1] and impractical for Debian to enforce, and is hence
not permitted even in non-free [2].
gpuocelot's authors have been
Package: src:linux
Version: 3.16.7-ckt9-2
Severity: normal
Dear Maintainer,
My USB mouse intermittently stops working (pointer not responding to it,
but responding normally to the internal trackpad); this has been
happening for at least 1-2 months (possibly since install), but has been
unusua
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 ad
Control: retitle -1 beignet: silently does nothing on large arrays
(previous discussion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875 )
This isn't a Haswell-specific problem (and might not be ICD-specific
either: did you test that at these sizes, or only with the testsuite?),
it's
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: forwarded -1
http://lists.freedesktop.org/archives/beignet/2015-April/date.html
The ICD interface works for me (i5-3230M), which makes this bug _both_
hardware- and interface-dependent, which is weird.
Since version 1.0.1 beignet has been able to recognitze the hardware on
my machine[
* write access to /tmp/*.xml is likely unneeded,
Fixed upstream: 51bfdc21e0b4528797697d32664eacb15d297449.
* symlinks are followed
As the remaining write-allowed directories are all under ~/.fgfs, not a
bug provided Nasal can't create symlinks (which I think it can't).
--
To UNSUBSCRIBE,
Symlinks are followed, but I don't think Nasal can create symlinks (and
if it could, I agree we'd have a bigger problem).
I'm assuming that there's no good reason for anyone ever to be running
flightgear in a privileged context
Agreed: that's one reason I have a 'create an unprivileged user' h
I'm not aware of any that do, but haven't specifically looked.
I now have: as far as I can tell, no Nasal scripts are currently writing
to /tmp, and given that upstream also support Windows, they would
probably consider doing so to be a bug. I'll suggest removing this
upstream, but currently d
On 18/03/15 21:32, Markus Wanner wrote:
On 03/18/2015 09:09 PM, Adam D. Barratt wrote:
++write_allowed_paths.push_back("/tmp/*.xml");
Is that really intended? (Both the hardcoding of /tmp/ rather than using
something respecting TMPDIR and being allowed to write any ".xml"
there.)
It certa
I installed
openjdk-7-jre:i386 on an amd64 system and for some reason
openjdk-7-jre:amd64 has been pulled as well.
That's probably because of this dependency cycle: multiarch treats
arch:all packages as the native architecture
(https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Arch
Control: forwarded -1
http://lists.freedesktop.org/archives/beignet/2015-February/005182.html
Control: tags -1 pending
Looks like you have a permanently-disabled Intel GPU, so beignet is
never going to work on that system, and the patch did stop it crashing.
The -3 I just pushed to Alioth is in
Control: tags -1 patch
sudo cat /sys/kernel/debug/vgaswitcheroo/switch
cat: /sys/kernel/debug/vgaswitcheroo/switch: No such file or directory
That suggests this system doesn't have a GPU switching mechanism, so may
have the Intel GPU permanently disabled (try xrandr --listproviders as a
furth
Not confident I have the hardware you asked to test on .
model name : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
Unfortunately you don't: what you've done is confirmed that this bug
("mesa breaks beignet") is fixed, what I wanted was a test for the
opposite problem ("does beignet break mesa?"
Package: www.debian.org
The file list links for packages in experimental, e.g.
https://packages.debian.org/experimental/all/libpocl1-common/filelist
https://packages.debian.org/experimental/amd64/beignet/filelist
do not work; they say
Error
No such package in this suite on this architecture.
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) packagin
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
If you don't want a (permanent) epoch, there's also the option of
calling it 3.4.13.really.3.4.11-1 or similar (see #767961).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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-usi
* 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.
Sorr
(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 Recom
This looks like #765726; there are some possible workarounds there.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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
Did the problem start when nvidia-libopencl1 and nvidia-opencl-icd were
upgraded (check /var/log/apt/history.log)? If so, this is probably the
same bug as #769191 (see there for discussion of possible fixes):
nvidia-opencl-icd just gained a dependency on libcuda1, which pulls in
several other
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 s
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 R
Package: opengl-4-html-doc
Version: 1.0~svn27841
This package's copyright file does not cover all the files in the
package (and also contains a syntax error: names on License: lines must
not contain spaces).
The attached copyright file fixes _most_ of this, but there are some
files with an a
Package: opengl-4-html-doc
Version: 1.0~svn27841
Control: tags -1 patch
This package fetches inline JavaScript from a remote server; this is
discouraged for privacy reasons (lintian error:
privacy-breach-may-use-debian-package), and also reduces functionality
when offline.
Fix:
diff -Nru kh
Package: opengl-4-html-doc
Version: 1.0~svn27841
Control: tags -1 patch
This package provides the index sidebar in .php format (index.php,
indexflat.php), presumably because upstream intended it to be installed
on a web server; this is problematic when using the package locally, as
iceweasel w
Control: fixed -1 beignet/0.9.3~really.0.8+dfsg-1
Control: found -1 beignet/1.0.0-1
Control: tags -1 patch
Adding RTLD_DEEPBIND in ocl-icd doesn't help, but building beignet with
-Bsymbolic (attached, replaces the existing patch with the same name)
does: beignet and pocl then continue to work w
bian/changelog 2014-11-19
18:56:35.0 +
@@ -1,3 +1,25 @@
+beignet (0.9.3~really.0.8+dfsg-1) unstable; urgency=medium
+
+ [ Andreas Beckmann ]
+ * Set Maintainer to "Debian OpenCL Maintainers" with Simon's permission.
+ * Add Simon Richter, Rebecca N. Palmer and m
I didn't look at the details of the patch for #768090, but the bug log
suggests that there are remaining failures. Is that still the case with this
patch?
Assuming you mean
The remaining test failures are:
-cospi/sinpi/tanpi, powr/pown/pow, tgamma are less accurate than the
OpenCL spec requires
Control: retitle -1 mesa-opencl-icd,beignet: installing together breaks all ICDs
Control: reassign -1 mesa-opencl-icd,beignet
Control: found -1 mesa/10.3.2-1
Control: found -1 beignet/0.9.3~dfsg-1
It appears I forgot to test mesa+pocl without beignet installed: pocl
then works, i.e. the problem o
Control: retitle -1 mesa-opencl-icd: installing this breaks other ICDs
Control: reassign -1 mesa-opencl-icd
Control: found -1 10.3.2-1
Those aren't normal "this is not valid OpenCL C" build errors (see
#769403 for those crashing beignet), they're compiler load errors,
matching
http://sources.d
Package: beignet
Version: 0.9.3~dfsg-2
(That version is only in Alioth as yet, but as I haven't touched
anything related to this, I suspect the problem is upstream)
If an OpenCL kernel attempts to call a non-existent function (e.g.
"b[i]=co(a[i])", as in the attached), pocl returns a helpf
Control: reassign -1 pyopencl,beignet
It is a kernel cache - in pyopencl (/tmp/pyopencl-compiler-cache-*), not
beignet itself, which is why you aren't seeing it when using beignet from C.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
Don't quite understand this issue. How do you set the OCL_STRICT_CONFORMANCE?
This is Debian's beignet 0.9.3~dfsg-1 (current unstable)
and accuracy_speed_test.py from
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;filename=accuracy_speed_test.py;att=4;bug=768090
rnpalmer@rnpalmer-laptop:~$
tests. (Closes: #767387)
+ * Revert to LLVM/Clang 3.4, update versioned-llvm-tools.patch.
+(Closes: #764930)
+ * Replace broken pow(n), rootn, erf(c), tgamma. (Closes: #768090)
+ * Document in the description what hardware this supports.
+
+ -- Rebecca N. Palmer Wed, 12 Nov 2014 12:34:41
Package: beignet
Version: 0.9.3~dfsg-1
When beignet is used as an ICD (which is the recommended way to use an
OpenCL library), only the first run after a reboot can change the
OCL_STRICT_CONFORMANCE (accuracy vs. speed) setting, or load a
newly-installed beignet version. Running ldconfig or u
However, I'm now tracking that [Alioth] git
repo (I was only pushing to my github.com repo for packaging chagnes)
but can't seem to push into it.
Have you registered your SSH key on Alioth? If so,
git push
ssh://mcpierce-gu...@anonscm.debian.org/git/pkg-middleware/qpid-proton.git
--
To UNS
Please unblock package beignet
That's already been requested and declined in #767961: we are already
too late for 0.9.3 in jessie, we need to decide whether 0.8 in jessie +
1.0 (expected soon) in jessie-backports is better or worse than just 1.0
in jessie-backports.
Backporting the relevant
Fix committed to Alioth.
This fix has been accepted upstream; they found that it exposed another
bug that compare and type-convert don't properly handle constants
(http://lists.freedesktop.org/archives/beignet/2014-November/004387.html),
so I included the fix for that as well.
My own testing
Warning on the kernel upgrade: it froze my system, see #768483.
Ah, that's tricky, at the packaging level. What I think is:
* all GPU-related ICDs should be installed, whenever the corresponding
video driver is;
* at least one CPU-capable ICD should also be installed;
Linking it to the video dr
It's a Dell XPS 15 from two months ago. [...]
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen
Core Processor Integrated Graphics Controller [8086:0416] (rev 06)
(prog-if 00 [VGA controller]) [...]
model name : Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz
That should work after upg
simgear has now been recompiled against a fixed openscenegraph, so
installing libsimgearscene3.0.0 3.0.0-6+b1 should fix this problem.
(This version may not have reached all mirrors yet. It does not appear
to be necessary to also recompile flightgear, or to actually install the
fixed libopensc
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
X-Debbugs-CC: pkg-fgfs-c...@lists.alioth.debian.org
openscenegraph 3.2.1-5 fixed crash bug #765855, but as the fix is in an
inline method, a rebuild of simgear is needed to pick it up.
nm
Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
beignet doesn't work on that version of Linux (#767148); a fixed version
was uploaded yesterday. Does upgrading to that help?
What hardware are you using?
Does the error occur on any attempt to use OpenCL, or only with this
program? (If you don
if f[0] in ("pow(a[i],c[i])","powr(a[i],c[i])"):
d0=f[1](c,c)
elif f[0] in ("pown(a[i],d[i])",):
d0=f[1](c,ci)
else:
d0=f[1](c)
print(dCL.get(),"\n",d0)
Description:
TODO: Put a short sum
.4, update versioned-llvm-tools.patch.
+(Closes: #764930)
+ * State in the description what hardware this supports.
+
+ -- Rebecca N. Palmer Sat, 01 Nov 2014
14:01:26 +
+
beignet (0.8-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru beignet-0.8/debian/control beigne
Do you see anything that should hold me back from uploading it?
Builds and works fine here.
Repacked packages usually use +dfsg, not ~dfsg, but the technical reason
for that (sorting after the corresponding non-dfsg version) only applies
if such a version existed, which it doesn't here.
Give
0.9.3 usually passes all its tests with 2 warnings:
double_precision_check()
- WARN: GPU doesn't have correct double precision. Got 9.995699E-05,
expected 0.000101
[SUCCESS]
test_printf()Warning: Have a int parameter for %f like specifier, take
care of it
it once failed one test (not
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 anyth
*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
--bu
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/tree/debian/changelog
beignet (0.9.3-0.1) UNRELEASED; urgency=medium
While I agree that this should have been done months ago, it can't be
done now without release team permission: the freeze is based on what is
in testing (_not_ unstable
Control: forwarded -1
http://lists.freedesktop.org/archives/beignet/2014-October/004343.html
I have reported this upstream; they have agreed it's a problem and are
in the process of removing the first group and investigating the second.
To deal with this problem in the meantime, we will need to
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.
Agre
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
Source: libjogl2-java
Version: 2.2.4-1
Severity: serious
Justification: Policy 2.1
Control: found -1 2.1.5-2
src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/shader/landscape.fp
has a NonCommercial license, which is not allowed in Debian (even if the
file isn't actually used: https://releas
4-04-19
18:54:55.0 +0100
+++ beignet-0.8/debian/patches/versioned-llvm-tools 2014-10-28
12:17:01.0 +
@@ -1,9 +1,20 @@
Description: Use versioned LLVM tools
-Author: Simon Richter
-Last-Update: 2014-04-19
+Description:
+Author: Simon Richter , Rebecca N. Palmer
Package: src:linux
Version: 3.16.5-1
Severity: important
Control: affects -1 beignet
Control: tags -1 fixed-upstream
X-Debbugs-CC: s...@debian.org,pkg-opencl-de...@lists.alioth.debian.org
In current jessie, beignet (OpenCL for Intel GPUs, 0.8-1.1) is
non-functional:
$ sudo apt-get install beign
Maybe not...after today's run, hibernation failed. Might it be relevant
that unattended-upgrades itself was upgraded in that run?
2014-10-27 08:55:27,163 INFO Initial blacklisted packages:
2014-10-27 08:55:27,163 INFO Starting unattended upgrades script
2014-10-27 08:55:27,163 INFO Allowed orig
Hmm, perhaps I misinterpret [1], but it says "on the 5th of November
2014, and we will run one automated migration at that time".
...under the existing automated migration rules, including the 10-day
rule (so anything uploaded now won't qualify). "Unlike the Wheezy
freeze, we are not planning t
Rebecca, do you think there is a way to trigger this bug with certainty?
Even if that means modifying the sources to create an artificial trigger
for the bug?
It happens when naGC_swapfree finds that the Nasal dead list is full, so
we can make it more likely by reducing that limit:
Descriptio
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 #
lling openscenegraph's removeUpdateCallback(nc) when there are no other
references to nc creates a use-after-free condition, and hence a crash.
Avoid this by creating another reference before calling it.
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/765855
--- simgear-3.0.0.or
Control: tags -1 upstream patch
I have now tried this patch, and while I can't tell if it fixes the
problem (as I never had it), it at least doesn't appear to break
anything else.
No comment from upstream on this particular patch, only a general
concern that other multithreading bugs might e
I think I know what's wrong here: it's not two actual threads waiting
for each other, it's the inner and outer Nasal levels of thread 1, that
think they're separate threads when they're not.
If it is that, the attached should fix it, but since I've never had this
problem myself I can't test it
Control: reassign -1 libopenscenegraph100
Control: retitle -1 libopenscenegraph100: use-after-free crash in
Node::remove*Callback
Control: tags -1 patch fixed-upstream
This crash is a use-after-free in openscenegraph Node::remove*Callback:
if the node holds the only reference to the callback (nc
Looks like the immediate cause is trying to run an _updateCallback with
a garbage address, but I don't yet know how that got there. I'm going
to try valgrind, but that may take some time.
Program received signal SIGSEGV, Segmentation fault.
0x00bab994 in osgUtil::UpdateVisitor::apply(o
ebian/changelog
@@ -1,3 +1,10 @@
+flightgear-data (3.0.0-2) UNRELEASED; urgency=medium
+
+ * Fix type mismatch crash. Closes: #766251.
+ * Downgrade -ai, -aircrafts to Recommends.
+
+ -- Rebecca N. Palmer Wed, 22 Oct 2014 18:27:01
+0100
+
flightgear-data (3.0.0-1) unstable; urgency=low
Control: tags -1 upstream
Confirmed; I also get it at KSFO (but only with Terrasync enabled), but
not everywhere.
Upstream bug
https://code.google.com/p/flightgear-bugs/issues/detail?id=1556 appears
to be the same issue, but they don't have a fix either.
--
To UNSUBSCRIBE, email to debian
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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
I have now tried the above patch: it fixes the problem on at least i386.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Control: severity -1 important
Control: tags -1 patch
This bug affects i386, kfreebsd-i386, mips, powerpc and sparc (as
determined by the attached script).
Replacing the existing
debian/patches/bug763818_fix_preprocessor_double_substitution with the
attached should fix it, but I haven't test
Control: reassign -1 libopenscenegraph100
Control: retitle -1 libopenscenegraph100: can't load plugins on i386
Confirmed; now only affects i386, not amd64.
strace contains
access("/usr/lib/1-linux-gnu/osgPlugins-3.2.1/osgdb_png.so", F_OK) = -1
ENOENT (No such file or directory)
(note 1 inste
701 - 800 of 922 matches
Mail list logo
