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
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
- - 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
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
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
=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
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/
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
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: 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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Agre
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
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
*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
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
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
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
.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
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 __GI_rai
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
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
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: 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
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
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
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
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
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: 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
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
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 #
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
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
Package: systemd
Version: 215-5+b1
Severity: normal
Dear Maintainer,
I have LUKS encrypted /, /home and swap; before attempting to hibernate,
the initramfs could successfully mount swap, but I normally skipped this
and let systemd mount it, as systemd's swap setup would report failure
if the
Package: upstart
Version: 1.11-4
Severity: important
I have LUKS encrypted /, swap and /home; / and swap are successfully
mounted in the initramfs, but /home is mounted by init. sysvinit and
systemd can both do this, but when Upstart tries to do so, it displays
"Unlocking disk ", waits for th
Control: tags -1 patch
Looks like the "swap=plain" assumption is at
src/cryptsetup/cryptsetup.c:162; here's a patch (untested as yet, will
try it in the morning if I don't hear anything).
--- cryptsetup.c2014-10-16 22:10:00.369584521 +0100
+++ cryptsetup2.c 2014-10-16 22:13:32.7
The patch (applied to Alioth git head) fixed this bug, but the system
hung on the first shutdown after install (but not subsequent ones).
/var/syslog extract:
Oct 17 13:58:10 rnpalmer-laptop NetworkManager[680]: (wlan0):
supplicant interface state: disconnected -> inactive
Oct 17 14:17:02 rnp
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
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
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:~$
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
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: 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
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
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: reassign -1 src:simgear
Control: tags -1 fixed-upstream patch
The function it complains about is indeed broken, but is currently
unused, so shouldn't be causing any problems other than this FTBFS.
Fixed by
http://sourceforge.net/p/flightgear/simgear/ci/a6290e367a461b9b083fd2331ccf8f9
[ 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
The user then compiled with Clang and caught a link error.
clang can't handle abi tags (i.e. can't link to new-ABI code even if you
aren't trying to mix it with old-ABI code):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917
https://llvm.org/bugs/show_bug.cgi?id=23529
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
.0 +0100
+++ beignet-1.3.0/debian/changelog 2017-05-25 19:51:36.0 +0100
@@ -1,3 +1,9 @@
+beignet (1.3.0-4) unstable; urgency=medium
+
+ * Install OpenCL 2.0 libraries. (Closes: #863300)
+
+ -- Rebecca N. Palmer Thu, 25 May 2017 19:50:07
+0100
+
beignet (1.3.0-3) unstabl
I haven't actually got around to doing anything with it, so go ahead.
Control: tags -1 pending
Fixed in Alioth, ready for upload.
On 07/08/17 16:47, Lucas Nussbaum wrote:
Source: beignet
Version: 1.3.0-4
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170807 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of
Since having both fonts-liberation and fonts-liberation2 on
the system may lead to undesired results
What undesired results? There's no such bug against the font packages,
and fonts-liberation2's README.Debian explicitly says installing both is
supposed to be OK.
flightgear uses these fonts v
What hardware (lspci -nn | grep -e "\[03..\]:"), and is this an
up-to-date (1.3.0-2) beignet? What versions (dpkg -l [package]) of
libdrm-intel1, and if installed, xserver-xorg-core and libgl1-mesa-dri?
Try removing xserver-xorg-video-intel: it isn't needed on anything
recent enough to use be
Control: severity -1 serious
I have been working on this upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=100639
It appears to totally break beignet on Ivybridge/Haswell on recent
(including sid/stretch) Linux. (I didn't notice it before because I
test in a chroot, i.e. with jessie's to
Control: tags -1 patch
One way to reproduce this bug:
# apt-get install pocl-opencl-icd blender
$ gdb blender
open User Preferences -> System
This promptly crashes; beignet-opencl-icd 1.2.1-1 (LLVM 3.8, like pocl)
also triggers it, but beignet-opencl-icd 1.2.1-2 and mesa-opencl-icd
(LLVM 3.9, l
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 su
kdiag (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 Sun, 22 Jan 2017 22:13:59
+
+
blockdiag (1.5.3+dfsg-1) unstable; urgency=medium
* New upstream release. Close
Control: retitle -1 beignet+mesa-opencl-icd crash if installed together
The lack of hardware isn't the trigger - having beignet-opencl-icd and
mesa-opencl-icd installed at the same time is. (beignet+pocl or
mesa+pocl is OK.)
Looks like some kind of "seeing the other ICD's copy of libllvm ins
Control: severity -1 normal
Looks like this isn't just warnings - it also prevents breakpoints
working in the affected files.
(Found while investigating #852746 - these are the only two places in
LLVM with that error message,
http://sources.debian.net/src/llvm-toolchain-3.9/1:3.9.1-3/lib/Sup
Control: severity -1 minor
(Found while investigating #852746 - these are the only two places in LLVM with
that error message,
Oops - there are actually three and #852746 is the other one. Sorry for noise.
This bug goes away on rebuilding beignet with LLVM 3.8 (but that isn't a
good solution as it can trigger #848368, and also disables some of
beignet's functionality).
Debug backtraces show mesa-opencl-icd being loaded first, and the crash
happening when beignet-opencl-icd is loaded, suggesting
(I had never heard of this package before your d-d post: I'm looking at
it because of the number of to-be-autoremoved reverse dependencies)
I can't reproduce any of these test failures: dpkg-buildpackage -us -uc
-A in a sid/amd64 cowbuilder --login chroot (build-deps + ccache
eatmydata lintian
Control: tags -1 patch
The failing tests are:
==
FAIL: blockdiag.tests.test_generate_diagram.test_generate(at 0x7f79a5528f28>, 'svg',
'/tmp/buildd/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_3.5/build/src/blockdiag/tests/diagrams/m
This involves a lot more than just sympy: the (build-)dependency chain is
execnet - sometimes FTBFS (3-4x unreproducible test failures, no known
fix; disabling/ignoring the tests in question would probably make it
build, but obviously isn't a real fix)
^
|
pytest-xdist
^
|(apparently only for
missing python{,3}-olefile in Build-Depends.
There is no such package in unstable - was this a typo?
(For me the only failed tests were the two in the bug, and just the
patch was enough to fix that.)
olefile (0.43-1) unstable; urgency=medium
* Initial release (closes: #850404).
-- Matthias Klose Fri, 06 Jan 2017 07:36:25 +0100
Which makes it too new to get into stretch, so we're not allowed to
build-depend on it if we want to stay there.
(https://release.debian.org/stretch/rc_policy
I now also see the no-olefile errors in sid:
(This was with a locally built wand - the in-archive one is currently
uninstallable due to #850815 - and is one of many with similar messages.)
I haven't checked whether it works in stretch (which has an older
version of pillow, with an embedded co
Package: libllvm3.9-dbg
Version: 1:3.9.1-2
Severity: minor
This -dbg package produces enough warnings that backtraces become
difficult to read:
$ sudo apt-get install beignet-opencl-icd beignet-dev libllvm3.9-dbg
$ OCL_STRICT_CONFORMANCE=0 gdb --args /usr/lib/x*/beignet/utest_run -c
vload_tes
It happens every time I run something that uses it in gdb, including
LLVM's own executables; do you mean it doesn't for you?
$ sudo apt-get install gdb libllvm3.9-dbg llvm-3.9
$ gdb llvm-link-3.9
[...]
(gdb) run
Starting program: /usr/bin/llvm-link-3.9
warning: Could not find DWO CU
CMakeFiles/
Control: severity -1 grave
Control: tags -1 fixed-upstream patch
The upstream flightgear-data 2016.4.1, 2, 3 and 4 are completely
identical except the version number - only flightgear and simgear were
actually being changed, but this check required all of them to be
re-released.
Upstream hav
Control: tags -1 patch pending
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/commit/?id=41b69622e19ce7f101ca8486601f7f77d58deea5
(Are you expecting to upload llvm 3.9 (with the fix for
"python-lldb-3.9/arm64 unsatisfiable Depends: liblldb-3.9-dev") soon?
One of the other changes I had
Source: beignet
Severity: serious
Control: tags -1 upstream patch
beignet started using drm_intel_get_pooled_eu and
drm_intel_get_min_eu_in_pool if available early in their development,
before their interface was finalized, and hence does not build with the
released version (libdrm-intel 2.4.7
The tests in question are checking that numexpr and numpy give the same
answers (by default, pandas uses numexpr if available for large arrays
but numpy for small ones), and require integers to match exactly. The
failing values are all 15**15, which is 437893890380859375 in exact
arithmetic bu
Package: libcmrt-dev
Version: 1.0.6+dfsg1-1
libcmrt-dev does an "#include "
(
http://sources.debian.net/src/libcmrt/1.0.6%2Bdfsg1-1/src/cm_rt_linux.h/?hl=35#L35
),
which is in libva-dev, but doesn't depend on it.
Control: tags -1 patch
It's the documentation timestamp added by ikiwiki: while this is
the file timestamp not the build time, some of these files are
modified by debian/patches.
This should fix it, but has not yet been tested:
--- a/debian/rules
+++ b/debian/rules
@@ -27,7 +27,7 @@ override_dh_
You shouldn't need libpoclu-dev to build OpenCL-using code, only
ocl-icd-opencl-dev (which is available on all architectures).
What does require an ICD is _running_ OpenCL code, including in the test
suite (if any); as buildds are unlikely to have a GPU, build-time
OpenCL-using tests can only be r
Package: qa.debian.org
Severity: minor
User: qa.debian@packages.debian.org
Usertags: udd
When a package has recently migrated, one may receive an autoremoval
warning that lists the new version of the package, but a problem only
the old version had.
Example (1.1.2-4 had the problem, 1.1.2-
As you can see in the headers of the mail, the autoremoval warnings
are sent by the release team not the QA infrastructure.
That script looks like it gets version and bug information in one fetch
from UDD
(https://anonscm.debian.org/git/mirror/release-tools.git/tree/mailer/mail_autoremovals.pl
[beignet] 1.1.2-4 had the problem, 1.1.2-5 doesn't, and is no longer listed for
autoremoval):
beignet now *is* listed for autoremoval, for (a different) LLVM 3.7 bug,
though I haven't had another warning email (yet).
1.1.2-5 dropped the LLVM 3.7 dependency on release architectures, but
kept
Control: severity -1 minor
This package depends on llvm-toolchain-3.7.
Only on kfreebsd-* (which aren't release architectures, and can't build
anything more recent).
(If you used a checking tool, see #836342.)
Control: retitle -1 UDD/testing_autoremovals_gatherer.pl: includes
non-release-architecture Build-Depends
The autoremoval listing went away when beignet 1.2.0 (which no longer
depends on LLVM 3.7 on any architecture) reached testing, and inspection
of the tool's source
(https://anonscm.debian.org
Source: llvm-toolchain-3.9
Version: 1:3.9-1
Severity: minor
Control: tags -1 patch
The Vcs-* links in debian/control both point to
pkg-llvm/llvm-toolchain/branches/3.8/ , not 3.9.
201 - 300 of 1024 matches
Mail list logo
