Package: clblas
Version: 2.12-1
Control: tags -1 patch
(Split from #881054: cloning a merged bug is not allowed, and both
original reports better match the other part.)
After a compile failure (e.g. due to #881054), clblas crashes trying to
dereference a NULL pointer.
Fix:
diff --git
On i386 with the above patches (plus the gcc8 build fix from the other
bug), all tests pass in the build but Test_gfor_cpu fails in the
autopkgtest; I don't yet know why.
Control: tags -1 fixed-upstream patch
These look like the upstream fixes, though I haven't actually tried them
yet.
for index:
https://github.com/arrayfire/arrayfire/commit/58ac59497b50257631713e689a6b0ddffb73361a
for assign:
Package: freefem3d
Severity: serious
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to have an opinion on this: I am opening
this bug as a "don't waste your time fixing it" notice.
If this
Package: clsparse
Severity: serious
X-Debbugs-Cc: debian-scie...@lists.debian.org, ghisv...@gmail.com
(plus an identical one for freefem3d)
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to
Control: tags -1 fixed-upstream patch
The test failure is that np.array @ pd.DataFrame (matrix product) tries
to keep both the DataFrame's indices, which fails because the new matrix
is a different shape.
This appears to be fixed in 0.24.1 from PyPI, but as previously noted,
this is a new
While this doesn't crash on amd64, valgrind does find a double free in
test_index - and a comment in the test says checking that there isn't a
double free is the whole point of that test:
https://sources.debian.org/src/arrayfire/3.3.2+dfsg1-4/test/index.cpp/#L1255
==4773== Invalid free() /
Package: libboost1.67-dev
Version: 1.67.0-12
Control: tags -1 fixed-upstream patch
Control: affects -1 src:arrayfire
In GCC 8, #including svm_ptr.hpp (including via other Boost.Compute
headers, and whether or not it is actually used) is an error, as GCC 8
rejects known non-instantiable
Control: tags -1 patch
Taking just this part of the upstream patch (the other parts are for
code our version doesn't have), together with the Boost fix (which I
will file a separate bug for), makes it build.
Description: Fix const-related FTBFS with GCC 8
Author: Pradeep "9prady9"
Origin:
template specialization
This is probably unused (the use in FatBoundary is commented out),
which would explain it only being an FTBFS in GCC 8 and not sooner:
https://gcc.gnu.org/gcc-8/porting_to.html#hypothetical-instantiation
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/897752
non-instantiable (and hence unusable) as char[4] to char& is an
invalid conversion.
Older GCC didn't check this until it was attempted, which it isn't
(instantiating a class template only instantiates those member
functions that are used), but in GCC 8 its existence is an error.
Author: Rebec
, but there are suspicious-looking instances in at least her(2)
and rot(m)g; see attached list.
Description: Don't use double precision in s(ingle)gemm
Allows it to work on single-precision-only hardware/ICDs e.g. beignet
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/877316
Forwarded: no
--- clblas
Package: libclblas2,libpocl2
Version: 2.12-1,1.2-3
(and also 1.2-2, but the below is from -3)
libgpuarray's test_ger (DEVICE=opencl0:0 POCL_KERNEL_CACHE=0 nosetests3
-v pygpu.tests.test_blas:test_ger, requires python3-pygpu, python3-nose,
python3-scipy, ocl-icd-opencl-dev, libclblas-dev)
Andreas Beckmann wrote:
I need more instructions to reproduce this ...
# apt-get install python3-pygpu python3-nose python3-scipy libclblas-dev
ocl-icd-opencl-dev pocl-opencl-icd
$ DEVICE=opencl0:0 python3 /usr/bin/nosetests3 -v pygpu.tests.test_blas
You may need to run the second one twice
Control: forcemerge -1 886327
Control: retitle -1 clblas: "unknown argument: -g" on beignet (Intel)
Control: reassign -1 clblas2,beignet-opencl-icd
Control: tags -1 patch
This is technically a bug in _beignet_, since -g is a required option
for OpenCL 2.0 (but not 1.x) ICDs, but applying the
Control: reassign -1 libpocl2
Control: affects -1 libclblas2
Control: found -1 1.2-2
sid (clblas 2.12-1+b1, pocl 1.2-2) amd64. Applying the fixes from
#881054 doesn't help.
Emptying the cache makes it repeatable which test fails, and disabling
the cache (POCL_KERNEL_CACHE=0) avoids the
Source: pocl,clblas
(Probably really only one of them, but I don't know which.)
When using pocl-opencl-icd, clblas sometimes exits with
module flag identifiers must be unique (or of 'require' type)
!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!
The test suites of both
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
I have just been given permission to take over libgpuarray.
I would like to update it from 0.6.9 to 0.7.6, which bumps SONAME from 2
to 3 and is described by upstream as including API
Control: tags -1 pending
Control: tags 918771 pending
I intend to upload theano (also containing other changes - see Salsa
repo) either tonight or tomorrow night.
...or by calling numpy 1.16 a transition, are you implying you want this
minimal fix and nothing else?
Source: theano
Severity: important
[Originally reported privately]
When using cython3 from experimental, the build fails at this point:
cd theano/scan_module && cython3 scan_perform.pyx && patch
--no-backup-if-mismatch scan_perform.c numpy_api_changes.diff && mv
scan_perform.c -t c_code
Package: node-browserify-lite
Version: 0.5.0-1
Control: tags -1 upstream patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
X-Debbugs-Cc: reproducible-bui...@alioth-lists.debian.net
browserify-lite produces its output in a (pseudo)random order: see e.g.
Control: tags -1 patch
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
-Test-Command: nodejs -e "require('"'"'browserify-lite'"'"');"
+Test-Command: nodejs -e "require('browserify-lite');"
Depends: @
Package: tracker.debian.org,debci
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
says autopkgtest failures trigger an automatic email.
When theano recently started failing [0] (#918090), no such email was
received, either to its maintainer list [1] or to me
Source: theano
Version: 1.0.2+dfsg-1
Severity: serious
Control: tags -1 patch
Many Theano operations include C code for speed; the compilation process
uses an undocumented Numpy function to check ABI compatibility.
In Numpy 1.16 (recently added to sid), this function is moved, causing
all
Source: llvm-toolchain-7
Version: 7.0.1-1
Control: tags -1 patch
(warning, untested)
The "failed to find link section" errors (#913946) are gone, but there
still aren't any -dbgsym packages.
I believe this is because clang does not include a Build ID by default
[0], and dh_strip only builds
On 14/12/2018 21:21, Sylvestre Ledru wrote:
Maybe it will be automatically fixed as doko told me that he backported
the fix in binutils.
The original form of this bug (i.e. "failed to find link section" when
using GNU strip) should be fixed in binutils 2.31.1-11.
To get back to that being
On 14/12/2018 20:26, Michael Biebl wrote:
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/
That's not the one that gets installed -
https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/debian/sddm.service/ is.
Control: reopen -1
Still no -dbgsym packages, and the build log contains
dh_strip -p libomp5-7 --dbgsym-migration='libomp5-7-dbg (<<
1:7~svn327768-1~)'
PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/:$PATH
LD_LIBRARY_PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/debian/tmp//usr/lib/llvm-7/lib/
dh_strip -a -v
Control: tags -1 patch
That works (starts successfully with the desktop on tty1) - due to the
intermittent nature of the bug I can't be sure it's gone, but if we're
right about the cause it should be.
Full sddm.service tested:
[Unit]
Description=Simple Desktop Display Manager
Package: sddm
Version: 0.14.0-4+deb9u1
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
With this /etc/sddm.conf:
[Autologin]
User=rnpalmer
Session=plasmawayland.desktop
autologin works only ~80% of the time; failures usually drop to a text
login prompt (which works but leads to a
Control: retitle -1 llvm*-dbgsym not built "failed to find link section"
(the llvm-strip fix attempt has been reverted)
The original errors with GNU strip appear to be this upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=23788
https://bugs.llvm.org/show_bug.cgi?id=39359
This
dh_strip uses objcopy as well as strip, so we might need to similarly force that to the LLVM version.
That won't work: LLVM objcopy doesn't accept --compress-debug-sections,
and accepts but ignores --only-keep-debug.
https://sources.debian.org/src/debhelper/11.5.3/dh_strip/#L308
Also, LLVM
Control: retitle -1 llvm*: not properly stripped, -dbgsym missing
Control: tags -1 - patch
dh_strip uses objcopy as well as strip, so we might need to similarly
force that to the LLVM version.
On 05/12/2018 22:50, Sven Joachim wrote:
the installed libraries are unstripped,
While this could
Control: reopen -1
Control: tags -1 patch
(though I haven't tried it)
This doesn't work on the buildds: still no -dbgsym packages, and the
errors now say
PATH=/<>/llvm-toolchain-7-7.0.1~+rc2/:$PATH
LD_LIBRARY_PATH=/<>/llvm-toolchain-7-7.0.1~+rc2/debian/tmp//usr/lib/llvm-7/lib/
dh_strip -p
Package: lintian
Version: 2.5.112
Patrice Duroux wrote:
I was surprise to discover such case of the following package:
https://tracker.debian.org/pkg/libnfs
for which the unstable and testing versions have the ~exp1 suffix and
the head of the corresponding changelog.Debian.gz is:
libnfs
This appears to be a crash in a loop unrolling optimization pass
(enabled only when -cl-fast-relaxed-math is set, hence only crashing then).
Disabling this pass unconditionally (see attached) avoids the crash, but
may reduce performance.
Description: Disable loop unrolling, as it may crash
Control: reassign -1 beignet-opencl-icd
A somewhat (but not very) cut-down version of the test case.
This produces a slightly different backtrace (the "No symbol table info
available" is LLVM bug #914021):
Thread 1 "bug913141" received signal SIGSEGV, Segmentation fault.
0x719f68c0
Package: libllvm6.0-dbgsym
Version: 1:6.0.1-9.2
Backtraces into libllvm6.0 (in either gdb or lldb-6.0) aren't any more
complete with the libllvm6.0-dbgsym package installed than without it:
they have function names but no local variables or source line numbers.
I don't know how long this
On 17/11/2018 12:43, Sylvestre Ledru wrote:
I guess this is caused by the move to a stage2 build. Maybe clang
generates .o files which make strip sad?!
That suggests trying llvm-strip instead (plain 'strip' is GNU binutils
strip). For initial testing you could just copy llvm-strip over
Source: llvm-toolchain-7
Version: 1:7.0.1~+rc2-3
LLVM 7 no longer builds any debug symbol packages, and at the point in
the build log where it attempts to do so, there are >1000 messages of
the form
strip --strip-debug --remove-section=.comment --remove-section=.note
Control: reopen -1
Control: reassign -1 libllvm6.0
Control: found -1 1:6.0.1-9.2
Control: affects -1 src:pocl mesa-opencl-icd
Control: retitle -1 crash if multiple ICDs dynamically linked to LLVM
X-Debbugs-CC: pkg-opencl-de...@alioth-lists.debian.net
This bug still exists in LLVM 6.0 (and given
On 10/11/2018 14:53, Rebecca N. Palmer wrote:
I had been mostly ignoring those because there was no point fixing them
if this bug was to be left open, but can try to deal with them today.
salsa beignet now has a fix for the INPUT_FILES_BLOCK issue (and uses
LLVM 7), so applying this patch
I am able to reproduce this by just compiling (and not running) that on
its own (as below, with the affected source in bug913141kernel.cl).
Hence, no further action is needed from you.
Switching to LLVM 7 (after fixing the other issue you noted) didn't
change anything. Removing
Do you know how to test that ? besides building beignet?
No, sorry - oclgrind is the other package to ship what appear to be
clang .pch files, but I haven't specifically checked whether it's affected.
beignet currently isn't the easiest test case, as (as noted above) it
has other
Control: reopen -1
Control: reassign -1 clang-7
Control: found -1 1:7.0.1~+rc2-2
OPENCL_EXTENSION_TYPES is still nondeterministic in 7. (I haven't
checked whether the above patch still makes sense.)
That's a crash while trying to compile something.
Is this bug present in LLVM 7? LLVM 3.9 has just been removed, so isn't
an option.
Do any of the tests (/usr/lib/x86_64-linux-gnu/beignet/utest_run from
the beignet-dev package) also crash?
Please install libllvm6.0-dbgsym and
On 23/09/2018 19:51, Paul Gevers wrote:
Hi,
On 23-09-18 19:29, Rebecca N. Palmer wrote:
What kind of logic do you have in mind?
If any binary of the package under test is being installed and isn't the
same version as the source, abort the run as a tmpfail. (At least in a
standard debci run
On 23/09/2018 18:04, Paul Gevers wrote:
I didn't came across it yet.
Probably because it's so rare, and easy not to notice if the status
didn't change.
What kind of logic do you have in mind?
If any binary of the package under test is being installed and isn't the
same version as the
Package: autopkgtest
Version: 5.5
When a new version of the package under test enters the archive during a
test run, the tests towards the end of the run may use the binaries of
the new version, but debci lists it as a test of the old version.
If these tests fail because the new version
This also happens on amd64 (backtrace follows), where it only affects
python3.7-dbg (not python3-dbg (3.6) or python3.7). It happens on
interpreter exit, not on import.
I suspect this is _not_ the new cffi version as such, because:
- It does not affect pyzmq or pillow (which also use cffi
Package: apparmor-profiles
Version: 2.13-8
Control: tags -1 patch
Control: affects -1 src:firefox src:firefox-esr
Firefox now uses /dev/shm in its multiprocess sandboxing. If AppArmor
blocks this (I was using a custom profile, but the packaged profile
appears to have the same problem), the
On 15/08/18 18:45, Simon McVittie wrote:
On Mon, 30 Jul 2018 at 07:57:35 +0100, Rebecca N. Palmer wrote:
#equivalent to Restrictions: trivial
Restrictions: skippable
Test-Command: do_the_test && exit 77
and later
-else:
+elif 'trivial' not in t.rest
On 01/08/18 02:58, Antonio Terceiro wrote:
FWIW, most of the supported package types do already set allow-stderr.
From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append
`2>/dev/null` to the Test-Command.
Those being dkms, go, octave, r (allow-stderr) and ruby (2>&1). I don't
Package: autodep8
Severity: wishlist
(Moving to a new bug: note that I have not decided whether I agree with
this proposal.)
On 31/07/18 14:59, Paul Gevers wrote:
Hi Rebecca,
On 30-07-18 08:57, Rebecca N. Palmer wrote:
On 29/07/18 14:58, Paul Gevers wrote:
[...]
A similar idea has come
On 31/07/18 14:59, Paul Gevers wrote:
Not sure if that would be the same value of trivial.
I agree that "should trivial be a defined Restriction" and "should
autodep8 and similar checks that we can import/link to/etc this (i.e.
checking its top-level module for syntax errors/missing
Control: tags -1 patch
(in https://salsa.debian.org/ci-team/autopkgtest/merge_requests/24)
On 29/07/18 14:58, Paul Gevers wrote:
I think we should keep
neutral-to-fail a regression.
I agree that neutral (tests all ignored) -> fail should be a regression.
I was referring to the no tests ->
Package: autopkgtest
Severity: wishlist
Control: block -1 by 901804
(From #901804 discussion, moving to a new bug as requested.)
On 29/07/18 14:58, Paul Gevers wrote:
[...]> On 27-07-18 22:49, Rebecca N. Palmer wrote:
[...]
Simon McVittie wrote:
At some point I might add a way to mark s
Package: tracker.debian.org
Severity: minor
Control: tags -1 patch
The 'all' bugs count double-counts 'patch' bugs (but not 'help' or
'newcomer' bugs, which also appear both there and in a severity
category), e.g. https://tracker.debian.org/pkg/debhelper
Can probably be fixed (though I
I take this discussion to mean the existence of autopkgtests is
considered a good thing even when they can't be run on ci.debian.net
(should we explicitly say that somewhere?). I hence added some to
beignet (an OpenCL driver, so hardware specific).
Simon McVittie wrote:
At some point I
Package: lintian
Version: 2.5.94
Severity: minor
Control: tags -1 patch
autopkgtest recently (5.4) added two new Restrictions, flaky and
skippable. Lintian does not know about these and hence reports
unknown-runtime-tests-restriction.
This can probably be fixed by adding them to the list at
Control: unblock -1 by 873408
Control: block 893401 by 873408
(julia has now moved to LLVM 4.0)
beignet, and presumably mesa, use LLVM 3.8 on kfreebsd-* because there
isn't anything newer available there.
LLVM 3.9 to 6.0~svn315736 were attempted and FTBFS on kfreebsd-*; these
bugs do not
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
(or should this be 'nmu'?)
The Clang resource directory (clang --print-resource-dir) changes every
upstream *bugfix* release (e.g. /usr/lib/llvm-6.0/lib/clang/6.0.1/ ),
but clang's
Control: tags -1 patch
The only required packaging change to build the new version is to update
the soname (see below). I only tested the Python 3 version on pocl,
which passes (i.e. #870128 is gone as expected).
Other things you might want to look at while you're making an upload:
-
Control: tags -1 fixed-upstream
Upstream have a different patch for skipping CUDA-only tests on OpenCL
(which I haven't tried myself):
https://github.com/Theano/libgpuarray/commit/f036aef3a425560161de362f390d238f4e7c1721
There are also two real issues in this set of test failures/errors:
-
Control: tags -1 patch
It's failing because the documentation build (arch:all) expects the main
build (arch:any) to have been done first. Fix:
diff -Nru libgpuarray-0.6.9/debian/rules libgpuarray-0.6.9/debian/rules
--- libgpuarray-0.6.9/debian/rules 2017-07-26 21:25:20.0 +0100
+++
Source: sphinx
Version: 1.7.5-1
Severity: serious
Control: tags -1 patch
Control: affects -1 src:theano src:python-jira
(These are the ones I've actually checked; I suspect most/all of the
~100 packages that build-depend on *-sphinx-rtd-theme are affected.)
sphinx's included themes have
Package: python3-pygpu,python3-theano
theano.gpuarray does not work because the currently packaged version of
pygpu is too old for it.
Is there a reason for not packaging 0.7.x or have you just not got
around to it? According to codesearch, theano is the only package using
pygpu, so
Control: severity -1 normal
This is not a new problem (I'm not sure if it's got worse per test, or
just got noticed because the test suite got longer), so removing the
migration block.
The largest (but not only) leaks are
test_pickle_big_fusion (theano.tensor.tests.test_opt.test_fusion)
Package: python-theano
Version: 1.0.1+dfsg-2
Severity: serious
(Filing this as RC to give myself time to investigate: I may downgrade
it later.)
Memory usage increases over theano's tests, to ~6GB by the end of the
python2 set (6981 tests) in Debian sid amd64, and enough to fail the
Ubuntu
This is known upstream:
https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/96b69154-ebd9-166f-9be5-d4971ee4ab05%40numericable.com/#msg36224500
Upstream keep a dependency list in
https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh
(lines ~330), but
This looks like a GL vs GLES incompatibility: libqt5opengl uses OpenGL
ES on armel+armhf, simgear/flightgear use full OpenGL on all
architectures, and the two can't be mixed.
simgear+flightgear probably can't switch to OpenGL ES because they use
legacy OpenGL functions that aren't in ES.
This has previously come up in another large game [0], and it was there
noted that while Debian Policy discourages absolute links within a
top-level directory [1], it does not forbid them.
That discussion led to the -X option of dh_link, but note that this only
disables relative/absolute
It's trying to create a cache directory. You can tell it to do this
somewhere else with the THEANO_FLAGS variable (as we do for the test
suite -
https://sources.debian.org/src/theano/0.9.0+dfsg-2/debian/rules/#L34 ).
Control: tags -1 patch
The failing tests also happen with the current version installed, so are
probably nothing to do with this fix.
9 tests fail or crash for me, of which 5 are things my hardware isn't
expected to be able to do:
test_coarse_grain_svm - needs OpenCL 2.0
test_scan
lasagne - 3 test failures; fixed upstream by
https://github.com/Lasagne/Lasagne/pull/836
Latest upstream (37ca134; only packaging change was to drop
remove-deprecated.patch) doesn't have these failures. There is a
warning that cuda_convnet is no longer available with Theano 1.0, but
that has
Control: tags -1 patch
Looks like the problem is the "-i pythonX.Y" at
https://sources.debian.org/src/pyopencl/2018.1.1-1/debian/rules/#L38 :
that's not valid input to pybuild, and (probably since pybuild commit
setuptools instead
of distutils as recommended by the PyPA?
Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer <rebecca_pal...@zoho.com> a
écrit :
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org
python3-distutils has been moved out of pyt
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org
python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so if you need it, please build-depend on it. (Or python3-setuptools,
given that this looks like it might prefer that.)
Source: theano
Severity: wishlist
(Posting here rather than on debian-release as the formal transition
process is rarely used, and its tools mostly useless, for non-compiled
cases.)
Theano 1.0 (currently in Salsa) contains some API-breaking changes:
This is because tornado 5.0 deliberately removed
ioloop.IOLoop.initialized() because "It is no longer possible to provide
this method with reasonable semantics":
https://github.com/tornadoweb/tornado/commit/426b3812b9dd21ae0bac19d4146c6952816c7bfe#diff-1d4144f0ef561b7c18c7fe438816e1f5
This
On 11/03/18 16:06, Mattia Rizzolo wrote:
the DMUP is one policy (you have read it, right??)
It's one document, but its title uses the word 'Policies'.
'Policy..it' would also be grammatically correct.
Package: nm.debian.org
Severity: minor
- The documentation on the wiki (
https://wiki.debian.org/DebianMaintainer#step_1_:_Identification ) says
1 (but that more is recommended).
- The form for registering oneself in the NM database says 2 are needed
(but doesn't enforce this, presumably
Package: nm.debian.org
Severity: minor
The page requesting one's signed agreement to the SC/DFSG/DMUP contained
the text below when I used it: 'convenince' is mis-spelled, and
'Policy...them' is grammatically incorrect (it should probably be
'Policies').
The latter would presumably need to
Control: tags -1 fixed-upstream patch
Upstream agree that this is expected under Wayland. The warning can be
disabled with
https://cgit.freedesktop.org/beignet/commit/?id=d1b99a1da56757971753288986419f1b8b9d55f4
Control: tags -1 patch
Description: Fix self-test fail in Darktable
Reverts upstream 81755054c4c19d821e58456a1a7d601806e60e92
Author: Rebecca N. Palmer <rebecca_pal...@zoho.com>
Bug-Debian: https://bugs.debian.org/885423
Forwarded: todo
diff --git b/backend/src/b
I have now reproduced this bug, but have not yet had time to investigate
further.
On 02/01/18 23:16, Achim Schaefer wrote:
now boinc does not find the GPU anymore.
This was after a restart, I don't know when I started boinc the last time.
This might be the same bug, but I don't know if/where
On 01/01/18 22:38, Achim Schaefer wrote:
Here I see something different:
displacement_map_element() [SUCCESS]
compiler_mandelbrot()utest_run:
/build/beignet-ydQSQk/beignet-1.3.2/utests/utest_helper.cpp:713: void
cl_write_bmp(const int*, int, int, const char*): Assertion `fp' failed.
The lack of failures is strange - does the original bug still exist?
(beignet hasn't changed, but it might be elsewhere.) Does
/usr/lib/x86_64-linux-gnu/beignet/utest_run without OCL_IGNORE_SELF_TEST
also report "self-test failed"?
To identify more precisely what isn't working, please install the
beignet-dev package and run
OCL_IGNORE_SELF_TEST=1 /usr/lib/x86_64-linux-gnu/beignet/utest_run
Is this a new problem (i.e. have you used it without this error before),
and if so, when did it start?
darktable doesn't actually
Package: libqt5wayland5,plasma-workspace-wayland
Version: 5.7.1~20161021-2,4:5.8.6-2.1
Severity: minor
To reproduce (>50% but not 100% reproducible):
- right-click on two areas, opening both their right-click menus (the
example below was two application launchers, but the desktop then an
empty
Control: retitle -1 unnecessarily scary warning under Wayland
I also see this warning, but beignet still works after it.
Is this also the case for you (to check, run
/usr/lib/x86_64-linux-gnu/beignet/utest_run from the beignet-dev
package) or is your beignet actually broken?
Laura Arjona Reina wrote:
I didn't add exact rules to match
www.debian.org/doc/debian-policy/footnotes.html#f1 to
www.debian.org/doc/debian-policy/#id1 etc because I'm not sure all the
"old" footnotes and the "new" footnotes match in content
They don't - they're not even unique in the one-page
Should this also make explicit which Debian suites have this restriction?
I thought this rule also applied to backports having found [0] in a list
archive search, and hence have been explicitly changing dependencies for
backports [1] instead of using alternatives.
However after finding this
This breaks the (6 according to codesearch [0]) links from Developers'
Reference to specific Policy sections.
[0]
https://codesearch.debian.net/search?q=package%3Adevelopers-reference+url-debian-policy%3Bch-
Package: python3-xarray
Version: 0.9.2-1
Severity: serious
Control: tags -1 upstream
Two netcdf tests fail in current sid (see log below).
This is known upstream as https://github.com/pydata/xarray/issues/1721 ,
according to which the actual problem is that scipy has been writing
netcdf files
Control: tags -1 upstream fixed-upstream
This appears to be 2 separate bugs, both triggered by using pandas 0.20
and fixed upstream.
groupby_bins:
https://github.com/pydata/xarray/issues/1386
https://github.com/pydata/xarray/pull/1390
test_sel: this is really a pandas bug (fixed in 0.21, but
/dar_par.dcf): No such file or directory
Author: Rebecca N. Palmer <rebecca_pal...@zoho.com>
Bug-Debian: https://bugs.debian.org/
Forwarded: not-needed
--- a/doc/samples/Makefile.in
+++ b/doc/samples/Makefile.in
@@ -465,7 +465,7 @@ install-data-hook:
$(INSTALL) -m 0644 $(NO_EXE_SAMPLES) $(D
Control: tags -1 patch fixed-upstream pending
Ready for upload (the GPU tests again haven't been run, but this
shouldn't touch those parts).
Package: python-theano
Version: 0.9.0+dfsg-1
Severity: serious
Suspect the problem is theano/theano/tensor/signal/pool.py:650, which
effectively does int32 = *(int64 *)(pointer_to_some_int_type) - if
some_int_type is int32, that works on little-endian but not big-endian.
On 07/10/17 14:09, Rebecca N. Palmer wrote:
The problems with current beignet look to be:
- file timestamps in INPUT_FILES_BLOCK (some of beignet's .h files are
script-generated). This part can be fixed in beignet.
That works (COMMAND touch -d '@$ENV{SOURCE_DATE_EPOCH}'
${OCL_OBJECT_DIR
501 - 600 of 916 matches
Mail list logo
