Control: tags -1 pending
The above looks like success - thanks.
Someone please upload beignet (as currently in Alioth); I'll file an
unblock request.
-1,3 +1,10 @@
+beignet (1.3.0-3) unstable; urgency=medium
+
+ * Fix "Exec...-5" error on older hardware. (Closes: #860805)
+ * Use LLVM 3.8 on x32 to fix FTBFS.
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Tue, 02 May 2017
23:23:11 +0100
+
beignet (1.3.0-2) unstable; urgency=me
On 02/05/17 07:57, Andreas Tille wrote:
I can confirm that beignet-dev_1.3.0-2 produces a lot of errors which
vanished when using said status from Git.
Good so far.
- the clFFT test from https://bugs.freedesktop.org/show_bug.cgi?id=100639
This needs a small change to work in sid (its
The upstream report of "this isn't a complete fix" turned out to be
mistaken: the user had both versions and had accidentally used the
unfixed one. https://bugs.freedesktop.org/show_bug.cgi?id=100639#c19
This bug also affects jessie-backports beignet when used with
jessie-backports Linux
+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 <rebecca_pal...@zoho.com> Thu, 25 May 2017 19:50:07
+0100
+
beignet (1
Has anyone tried the clFFT test I requested above?
Nothing further from upstream.
I intend to file this upstream after investigating further (with a patch
if I can); the main purpose of this Debian bug is to explain why I can't
fully test the theano package I recently pushed.
This is actually at least three problems:
- (arm*, mips*el) datetime issues, at least mostly inconsistency in
whether casting NaN to datetime gives NaT.
- (armel, armhf) SystemError in JSON processing. Known upstream as
https://github.com/pandas-dev/pandas/issues/14852 , but they don't have
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.
Control: severity -1 minor
Control: affects -1 src:theano
Control: retitle -1 libjs-d3: SyntaxError - non-ASCII variable names
This actually does have practical consequences: because d3's source
contains Greek-alphabet variable names (e.g. in
Package: libclblas2
Version: 2.12-1
Control: tags -1 upstream
Control: affects -1 beignet-opencl-icd
Some clblas operations use '0.0' (a double-precision literal) not '0.0f'
(a single-precision literal) even when processing single-precision arrays.
This causes it to crash on GPUs that don't
Package: clang-4.0
Version: 1:4.0.1-5
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
Control: affects -1 beignet-opencl-icd liboclgrind-16.10
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Generating a .pch precompiled header with
They have now said libgpuarray 0.6 for Theano 0.9 (i.e. what we
currently have is fine) and libgpuarray 0.7 for Theano 0.10.
https://github.com/Theano/Theano/issues/6454
(#877316 is a separate problem.)
On 01/10/17 08:38, Ghislain Vaillant wrote:
I thought Theano v0.9.x would require libgpuarray 0.7.x? Or is that for
the future (and probably last) 1.0 version?
The documentation for theano stable (0.9.0, this package) says 0.6.2:
Possible workarounds for beignet:
- Remove the .pch files entirely. This slows down compiling (which is a
run-time operation in OpenCL): 263sec instead of 90sec for the
540-kernel test suite = ~0.3sec extra per kernel compile. At a guess,
that's unlikely but not impossible to matter in
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.
- build path captured in ORIGINAL_PCH_DIR. _Might_ be fixable in
beignet by using clang (...) > /path/to/beignet.pch
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
reproducible
Author: Rebecca N. Palmer <rebecca_pal...@zoho.com>
Bug-Debian: https://bugs.debian.org/877359
Forwarded: no
--- llvm-toolchain-5.0-5.0.orig/clang/lib/Serialization/ASTWriter.cpp
+++ llvm-toolchain-5.0-5.0/clang/lib/Serialization/ASTWriter.cpp
@@ -4153,9 +4153,13 @@ void AST
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-
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
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
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
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?
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
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 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
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
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: 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
+++
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 fixed-upstream pending
Ready for upload (the GPU tests again haven't been run, but this
shouldn't touch those parts).
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
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
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.
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
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
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"?
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:
-
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
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
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: 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
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 ->
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
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
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: 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: 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
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 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
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:
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
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
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
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.)
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
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
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 ).
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
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.)
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
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
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
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 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
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
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
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
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
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
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: 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: 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
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
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: 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
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 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: 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
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
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
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
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
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
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
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
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
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
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?
301 - 400 of 916 matches
Mail list logo
