> Can you please try with the latest version of GHC available in unstable
> (9.4.7-1)?
I think the problem still exists:
$ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_9.4.7-1_armhf.deb
$ ar pf ghc_9.4.7-1_armhf.deb data.tar.xz | tar xJf -
$ file usr/lib/ghc/bin/ghc-9.4.7
usr/lib/ghc/bi
Package: apt-cacher-ng
Version: 3.7.4-1
Dear Maintainer,
With the above version of apt-cacher-ng we encounter a bug while installing
packages. (In our scenario the apt-cacher-ng itself runs in a Docker image
based on ubuntu:jammy-20230126 (22.04 LTS)).
The below error message happens for many pa
23:55, Steinar H. Gunderson wrote:
On Wed, Mar 09, 2022 at 04:03:01PM -0800, Edmund Biow wrote:
Thank you for the suggestion. I noticed that the output of updatedb
mentioned my server as cifs, which is how it is mounted, but also as "type
'autofs'", which I didn't have inst
Thank you for the suggestion. I noticed that the output of updatedb
mentioned my server as cifs, which is how it is mounted, but also as
"type 'autofs'", which I didn't have installed, so I didn't consider it.
I removed autofs from the PRUNEFS= line, ran updatedb again, and plocate
worked as ex
This bug is nine years old, but still valid in Debian Buster.
I meant bullseye at #10, never try to post a bug without coffee.
Anyway, the issue seems to have resolved itself on Debian testing for
me, this morning I was greeted by a request for an updated gmail
certificate (I have pidgin set to auto-start), and everything looks
ducky after several weeks.
New info, pidgin IS working on Debian stable. But I downloaded and set
up Empathy and it isn't working in Debian testing. This seems to be a
Buster issue, not specifically a pidgin problem.
Package: pulseaudio
Version: 12.2-4+deb10u1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the out
Sorry Maintainer (Eric?), PEBKAC, please delete this bug if possible.
The problem was messed up permissions, I'd had to move my approx cache
directory from my / root partition because it just keeps getting bigger
since it no longer seems to cull itself and approx-gc no longer works. It
is now clos
I am using Debian stable, buster, by the way.
So from what I understand by reading this bugreport is that there is a
workaround by removing the memory rule in
/etc/ImageMagick-6/policy.xml - but this file might be overwritten by
an security upgrade, right?
--
Edmund Christian Herenz (ESO Fellow) Office: M152
ESO Vitacura Email: eher...@eso.org
Alonso de Córdova 3107 Phone: +56 2 2463 3047 (Office)
Vitacura, Casilla 19001
.
--
Edmund Christian Herenz (ESO Fellow) Office: M152
ESO Vitacura Email: eher...@eso.org
Alonso de Córdova 3107 Phone: +56 2 2463 3047 (Office)
Vitacura, Casilla 19001 +56 9 4613 7517 (Mobile)
Santiago de Chile
On Sat, 6 May 2017 11:47:01 -0400 Eric Cooper wrote:
> On Sat, May 06, 2017 at 12:19:13PM +0200, Benedikt Trefzer wrote:
> > The manpage mentions approx-gc for removal of unneeded versions of
> > packages.
> > approx-gc was removed in version 5.7.1 of the debian package.
> > The manpage should th
I have observed a similar situation: my armel chroot seems to work all
right, but arch-test does not list "armel" as working. In my case,
SWPB is causing a SIGILL. It seems that a lot of armel binaries don't
use SWPB, but perhaps SWPB (and SWP) are still "officially" required
for armel? Who knows?
In 17.1-2 there's a simple omission in a script, which can be fixed with:
perl -i -pe 's!DIRNAME"!DIRNAME/mlucas-generic-c"!' scripts/mlucas.in
grep defraged_file_count `find * -type f`
reveals suspicious discrepency between declaration and format strings:
misc/e4defrag.c:static unsigned long longdefraged_file_count;
misc/e4defrag.c:" extents: %d -> %d\n", defraged_file_count,
misc/e4defrag.c:" exten
I'd guess this is a problem with the locale. In my case an unknown
locale adds 8, rather than 10, additional lines, but still:
$ LANG=C ./foo.pl
Global symbol "$foo" requires explicit package name at ./foo.pl line 3.
Execution of ./foo.pl aborted due to compilation errors.
$ LANG=sq ./foo.pl
perl:
This may be caused by a bug in "giza". Someone please tell the
giza developers.
The segfault happens when _giza_parse_string tries to return.
The return address on the stack was corrupted by this call to
cairo_get_current_point:
https://sources.debian.org/src/giza/1.0.0-1/src/lex.yy.c/#L2285
If
I just want to report that this bug still appears valid in 4.12.1 as
found in stretch.
My impression is that only shortcuts involving the key are affected.
In particular I have set Ctrl+Super+Up/Down/Left/Right as Shortcut for
Upper/Bottom/Left/Right Workspace .
I made the following observati
I upgraded my home server to current Debian stable stretch and it seems
to be working. I'm not completely convinced approx is always pulling
cached files from /var/cache/approx, but I have enabled logging and will
check the syslog if I see a suspicious situation and report back.
One observation I
Package: libgstreamer-plugins-bad1.0-0
Version: 1.14.0-1
Severity: important
Tags: upstream
Dear Maintainer,
After doing an apt-get update and apt-get upgrade on Debian Sid, the
libgstreamer-plugins-bad1.0-0 version was changed to 1.14.0-1. However, there
are dependencies on this package (inclu
swarmkit should build-dep on golang-github-docker-docker-dev (>=
1.13.1~), or something like that.
I was able to build swarmkit on arm64 after I manually installed a
newer golang-github-docker-docker-dev.
There's some kind of circular dependency between swarmkit and
docker.io. I think someone will have to break it with a binary upload.
(There was a binary upload on amd64, I notice.)
According
Control: retitle -1 uniq "loses" non-identical lines with some locales
I'm changing the title to refer to just "uniq" because it seems that
this behaviour of "sort -u" is specified; only "uniq" is behaving
incorrectly.
The upstream bug only talks about "sort -u" so should perhaps be
unlinked. Is
Control: retitle -1 sort -u and uniq "lose" non-identical lines with some
locales
I was hurt by this bug, too. I had a simple-minded script to check
files for dodgy characters before publishing them. How was I to know
that em-dash and en-dash would be considered identical in a standard
GB locale,
The build failure quoted above is not reproducible with the current
state of sid, I think. However, it is still not possible to build
swarmkit for a different reason: an indirect dependency on
golang-github-juju-ansiterm. See #886613 and the "Dependency
installability problem for swarmkit" on arm64
As described in https://github.com/torch/torch7/issues/1035, it seems
that LuaJIT provides only "a limited range of 47 bits for the legacy
lightuserdata data type". Therefore, lua-torch-torch7 can only be
built and run on systems that use virtual addresses with no more than
47 bits. Today many arm6
I was able to build rnahybrid 2.1.2-3 on armel in 104 minutes on some
more powerful hardware. I must definitely retract what I've said about
an "infinite loop".
Replacing loop nests with memset did not make a huge difference (I
gave up after 26 minutes).
Yes, it's not an infinite loop; it just takes an inordinate amount of time.
The code that triggers this seems to be a long sequence of assignments
initialising elements of a multi-dimensional array.
There are some big variations in the build times on some other
architectures, too. For example on
Those loop nests that set every element of a multi-dimensional array
to (floating-point) zero could perhaps be replaced with memset (not
officially portable) or memcpy (from a local variable of the same type
with an initialiser).
The problem still seems to occurs with:
- version 6.4.0-3cross1 of gcc-6-arm-linux-gnueabi (on amd64)
- version 7.2.0-7 of gcc-7 (on armel)
It's perhaps not really an infinite loop but just an unreasonably long time.
Perhaps someone should try running it over the weekend...
For what it's worth, rnahybrid seems to build on armel with this in
debian/rules:
export DEB_CFLAGS_MAINT_APPEND=-O0
Perhaps it would work with -O1 if I had more patience.
> The failure in build may in fact just be because the build machine is
> too slow.
It's a possibility to bear in mind, definitely, but the
perhaps-infinite loop can be observed with a cross-compiler:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825
(I will test with the compilers in uns
The infinite loop is still there with gcc-7. I've created bug #876825.
Before you exclude armel, you could perhaps try doing something about
this warning, which is given not just on armel and may or may not be
related to the compiler going into an infinite loop:
energy.c:539:104: warning: iterati
Package: gcc-6-arm-linux-gnueabi
Version: 6.3.0-18cross1
This is not specific to cross-compiling and not even to gcc-6.
We noticed the infinite loop when the buildd tries to build rnahybrid:
https://buildd.debian.org/status/logs.php?pkg=rnahybrid&arch=armel
It seems to be easy to reproduce with
I think this bug was fixed in 2.1.0~beta3. Can it be closed please?
Any objections?
# tail -n 1 /proc/self/maps
eb71-eb731000 rw-p 00:00 0 [stack]
# dpkg -i libluajit-5.1-2_2.1.0~beta2+dfsg-1_arm64.deb
libluajit-5.1-common_2.1.0~beta2+dfsg-1_arm64.deb
Source: jellyfish1
Version: 1.1.11-1
User: debian-...@lists.debian.org
Usertags: arm64
This package builds on arm64 if you change the type of dna_codes from
"char" to "signed char":
perl -i -pe 's/char/signed char/;' jellyfish/dna_codes.cc
jellyfish/dna_codes.hpp
It may build on other architectu
> Well, technically it might be correct, but I doubt that there is a
> working pipeline involving tophat, bowtie and friends on non-amd64
> architectures.
On the other hand, if you have a heterogeneous cluster then perhaps
you don't need or want all elements of the pipeline to run on the same
arch
> It might be that tophat builds on other architectures but it Depends
> bowtie2 | bowtie and these are only available on the explicitly
> specified architectures.
Bowtie2 is not yet available on arm64, but bowtie is, so a dependency
on "bowtie2 | bowtie" should not be an obstacle.
> unfortunately the bug does not seem to be sufficient. See
>
>
> https://buildd.debian.org/status/fetch.php?pkg=jellyfish&arch=arm64&ver=2.2.6-5&stamp=1504220784&raw=0
>
> Any further hints?
"portability.patch" is commented out in debian/patches/series and was
not applied?
Source: tophat
Version: 2.1.1+dfsg-3
User: debian-...@lists.debian.org
Usertags: arm64
It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?
Source: mrs
Version: 6.0.5+dfsg-2
User: debian-...@lists.debian.org
Usertags: arm64
It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?
Source: relion
Version: 1.4+dfsg-2
User: debian-...@lists.debian.org
Usertags: arm64
It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?
Source: gasic
Version: 0.0.r19-1
User: debian-...@lists.debian.org
Usertags: arm64
It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?
It might be possible to replace libnucleotidelikelihoodcore0's
"Architecture: amd64" with "Architecture: any". It seems to
build and install on arm64 at least. (I've not tried using it.)
Instead of: "pand " off
It should be: "pand " #off
(It may be necessary to disable "-Werror": an unrelated issue.)
Source: lua-torch-torch7
Version: 0~20170720-gaed3171-2
User: debian-...@lists.debian.org
Usertags: arm64
This package may work on arm64 now that luajit is available on that
architecture.
> Why I don't use "Architecture: any" in guymager is that its
> Build-Dependency libguytools2 is known to support only those
> architectures:
>
> Architecture: i386 amd64 powerpc armhf arm64
>
> If I'm using "Architecture: any" in guymager and it fails to build
> on those unsupported architecture
Source: jellyfish
Version: 2.2.6-1
User: debian-...@lists.debian.org
Usertags: arm64
Jellyfish seems to be easy to port. Just provide alternatives to the
inline assembler in rectangular_binary_matrix.hpp:
#ifdef __x86_64__
#define AND_XOR(off)\
It was very easy to "build" this package on arm64. All I did was:
* Modify each konfigure.perl to set $BITS = 64 instead of
die "unrecognized Architecture '$ARCH'".
* Provide ngs-sdk/ngs/unix/aarch64/atomic32.h containing stubs.
Now, if you wanted the package to actually work, you would presum
Source: ggcov
Version: 0.9-15
User: debian-...@lists.debian.org
Usertags: arm64
Would it be possible to add arm64?
With gcc-7 there's #853417, but with gcc-6 the only test failure on
arm64 is test033, where all the asserts are "PC" rather than "CO", and
the abort is "UN" rather than "SU". Does th
> As far as I can see all tests are disabled, failing tests means that
> the software has bugs, and I'm not sure whether we want to allow
> software with known bugs into the archives.
Yes, but if the bug is in the test then disabling the test is one way
of fixing the bug.
On the other hand, a tes
Source: mlucas
Version: 14.1-2
User: debian-...@lists.debian.org
Usertags: arm64
This package can easily be ported to arm64: in src/platform.h
recognise the architecture with defined(__aarch64__) and configure
it the same as amd64.
Also, the many mentions of "unknown" in platform.h suggest
that t
Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64
Please consider adding arm64.
Ubuntu built 4.9.0, 4.10.0 and 4.10.1 on arm64:
http://ports.ubuntu.com/ubuntu-ports/pool/universe/i/insighttoolkit4/
Though it looks like they may have ignored a few test failures to get there:
James:
> I think the runtime is working, but this is the testcase from the SIGBUS
> bug which you can use:
>
> ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi
> libx264rgb.avi -y -hide_banner -nostdin
> ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32
Source: picolisp
Version: 17.6-1
User: debian-...@lists.debian.org
Usertags: arm64
The arm64 version of PicoLisp was announced on 16 Nov 2015:
http://www.mail-archive.com/picolisp@software-lab.de/msg05727.html
And "arm64" is mentioned in INSTALL:
https://sources.debian.net/src/picolisp/17.6-1/I
On 5 August 2017 at 17:33, James Cowgill wrote:
> Hi,
>
> On 04/08/17 09:58, Jiong Wang wrote:
>> Change
>>
>> "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB"
>>
>> Into:
>>
>> .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon)
>> adreq lr, ff_h264_idct_add_neon_without_fu
As far as I know, the best way to implement run-time detection of
hardware capabilities is with getauxval(AT_HWCAP) and
getauxval(AT_HWCAP2).
There is some kind of NEON detection in ffmeg. See, for example:
https://sources.debian.net/src/ffmpeg/7:3.3.3-1/libavutil/arm/cpu.c/
That code appears to
Source: handbrake
Version: 1.0.7+ds1-2
User: debian-...@lists.debian.org
Usertag: arm64
Could this be "Architecture: any"? It seems to build on arm64.
This is being worked on upstream:
https://github.com/ldc-developers/ldc/issues/1931
https://github.com/ldc-developers/ldc/issues/2150
https://github.com/ldc-developers/ldc/issues/2153
The Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1656474
Memory corruption reported on mailing list:
http://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00827.html
It looks like Emacs Lisp may be involved. Does Emacs Lisp use tagged
pointers? Pointers have fairly recent
I think that test takes a long time because it is using long double,
which on arm64 has 128 bits and is implemented in software. Possible
things to do:
* Change the default type (however and wherever it is defined) from
"long double" to "double" on arm64, and perhaps other architectures.
* Get th
This robopatch seems to fix the problem on arm64 with 48-bit addresses:
perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ &&
!/gen\(longlong/;' src/*.cc
The idea is to change the type whenever there seems to be a cast
followed by a shift. The last condition is to avoid a couple of
h
So giac was supposed to be working now on arm64, but it failed on the buildd:
https://buildd.debian.org/status/package.php?p=giac&suite=sid
Having recently seen something similar I think I can guess what's happening.
User virtual addresses on Linux arm64 may have 39, 42 or 48 bits,
depending on
Source: ghc
Version: 8.0.1-17+b1
If I try to run "ghc" in one of my armhf chroots, it does not work very well:
$ ghc
Illegal instruction
The offending instruction is this one:
mcr 15, 0, r6, cr7, cr10, {5}
This is, I think, an ARMv6 memory barrier, and these instructions are,
if I recall c
Source: ghc
Version: 8.0.1-17+b1
If I try to run "ghc" in one of my armhf chroots, it does not work very well:
$ ghc
Segmentation fault
$ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_8.0.1-17+b1_armhf.deb
$ ar pf ghc_8.0.1-17+b1_armhf.deb data.tar.xz | tar xJf -
$ readelf -l usr/lib/ghc
Source: gocryptfs
Version: 1.2.1-1
Severity: serious
This arm64 build log shows the error:
https://buildd.debian.org/status/fetch.php?pkg=gocryptfs&arch=arm64&ver=1.2.1-1&stamp=1497480941&raw=0
The same error also happens on amd64 with the latest
golang-github-hanwen-go-fuse-dev from unstable,
0
Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64
It built on arm64 when I tried it. I didn't test it in any other way,
but perhaps you could add "arm64" to the Architecture line (replacing
the obsolete "arm").
Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64
No experimentation seems to be required. Ubuntu's
"xorp_1.8.6~wip.20160715-2ubuntu1" is identical to Debian's
"xorp_1.8.6~wip.20160715-2" apart from debian/changelog and
debian/control, where Ubuntu has "Architecture: any".
Whe
An update to this ancient bug:
Debian is still on version 4.2.8, released in 2008, and is including
this antique version with Stretch.
Upstream is now on 4.8.8, released in Feb 2017.
It looks as though Fedora has version 4.8.8, packaged under the name
"gambit-c", with "aarch64" (~ arm64) and "ar
Source: xine-plugin
Version: 1.0.2-4
User: debian-...@lists.debian.org
Usertags: arm64
On arm64 it failed to build like this (see
https://buildd.debian.org/status/package.php?p=xine-plugin&suite=sid):
In file included from ../include/prtypes.h:58:0,
from ../include/npapi.h:51,
The pattern of failures certainly looks like that of a program that
assumes char is signed... and, indeed, this seems to fix it:
- In io.web, change the return type of get() and peek() from char to int.
- In scan.web, change the type of prev_char, curr_char and next_char
from char to int.
I was able to build this package on arm64 after adding
"dh_autoreconf" just before the "./configure" line, and
"dh_autoreconf_clean" just before "dh_clean", in debian/rules.
One must presumably also add "dh-autoreconf" to the
Build-Depends.
Trying this same short program with version 20061220+dfsg3-4.3 of
cernlib in a Stretch chroot on amd64:
$ gfortran hbktst.f -o hbktst `cernlib packlib`
$ ./hbktst
RZMAKE. Unit 1003 Initializing with LREC= 1024, OPT= X?C
LOCB/LOCF: ad
This is easy to fix: in "Arch.hs" just use the smaller value of
maxBigIntWidth on any unrecognised architecture.
The fix is described here:
https://github.com/spacemonkeygo/spacelog/issues/6
Add golang-golang-x-sys-dev to the Build-Depends, and in capture_other.go
replace "syscall" with "golang.org/x/sys/unix",
and each "syscall." with "unix.".
The comparison makes no sense on any arch. Just replace "if (args !=
NULL)" with "if (1)".
It then builds on arm64.
I was able to build this package on arm64 by disabling the "JIT" as follows.
Please implement something similar in the next upload.
--- libretro-desmume-0.9.11+git20160819+dfsg1.orig/debian/rules
+++ libretro-desmume-0.9.11+git20160819+dfsg1/debian/rules
@@ -12,11 +12,15 @@
PLATFORM=platform=
Source: golang-defaults
Version: 2:1.7~5
User: debian-...@lists.debian.org
Usertags: arm64
This issue has been fixed upstream and in 1.8:
https://github.com/golang/go/issues/13191
If you follow the links from there you can read how this bug
apparently affects Kubernetes and how the fix has been
Source: golang-github-hanwen-go-fuse
Version: 0.0~git20161210.0.6c2b7d8-2
Control: affects -1 + gocryptfs
"const PAGESIZE = 4096":
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fuse.git/tree/fuse/types.go#n11
This is not portable. On arm64, the page size can be 4096, 16
The tests "tStatisticsUtilities" and "tLatticeStatistics" can be made
to pass on arm64 with these adjustments to the expected accuracy:
--- casacore-2.2.0.orig/lattices/LatticeMath/test/tLatticeStatistics.cc
+++ casacore-2.2.0/lattices/LatticeMath/test/tLatticeStatistics.cc
@@ -419 +419 @@
-
It seems to me likely that both #835108 and #853479 are caused by the
thing I mentioned at 2.1 in #863446: the program uses the "md5.h"
included in the package's source, but calls the system library
functions, which use a different MD5_CTX.
Source: lepton
Version: 1.2.1+20170405-1
I was able to build it on arm64 with just a few changes:
1. Change to "Architecture: any" in debian/control, obviously.
2. In debian/rules, use:
CPPFLAGS="-DUSE_SYSTEM_MD5_DEPENDENCY" dh_auto_configure --
--enable-system-dependencies --disable-vec
I've played a bit with trying to build this package on arm64:
sudo apt-get install ...
dpkg-source -x ldc*.dsc
cd ldc-1.1.1/
dpkg-buildpackage -b -d
The first five or so errors were compile-time "static assert" errors
in code that looks like floating-point library code. In each case I
could tempo
This has been fixed upstream. The fix is here:
https://github.com/numpy/numpy/pull/8713
https://github.com/numpy/numpy/commit/2fe5a4757e840362b7158e8548e26ffc9ef8b562
Only the one-line addition to loops.c.src is required; the rest is a test.
Could we have this fixed in Stretch?
Package: python-numpy
Version: 1:1.12.1-2
On amd64:
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> abs(numpy.nan)
nan
>>> numpy.abs(numpy.nan)
nan
>>>
On arm64:
$
On arm64 and at least one other architecture, the error says:
-3.2862601528904633e-16 != 0
It looks as though the test is computing (1.2 * 3.4 - 3.4 * 1.2).
Now, the log to base 2 of (1.2 * 3.4) divided by 3.286e-16 is about
53.5. There are 52 bits in the mantissa of a 64-bit float, or 53
includ
The package builds on arm64 if you comment out the "HAVE_SSE2" line in
configure.ac, so replacing the unconditional AC_DEFINE with an actual
test seems like a good first step.
I was able to build giac 1.2.3.25+dfsg1-3 on arm64 with this "patch":
perl -i -pe 's/^#ifdef __x86_64__$/#if 1/;' src/gen.h
perl -i -pe 's/^#ifndef __x86_64__$/#if 0/;' src/first.h
Obviously that change would break it on 32-bit architectures. A proper
fix might be to use something like ~(uintptr_
On arm64, if you run under GDB and look at the address that faulted it's
clear that the address has been truncated to 32 bits. And there's some
obvious code in src/gen.h that looks as if it's truncating addresses
to 32 bits on any architecture that isn't x86_64. However, I don't
think gen.h is the
You don't have this patch, I think:
https://reviews.llvm.org/D22095
> Unfortunately, this one line fix does not solve the problem of the LLVM
> build hanging during the sanitizer tests.
>
> Both issues appeared around the same time and seem to be linked to specific
> kernel versions.
Julia started failing when the kernel started using more bits in
virtual addresse
This problem is caused by:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862360
How I discovered this, would be a long story.
The effect of the LLVM bug is to OR the register field of a
"movz xD, #IMM, lsl #48" with bits 43-47 of an address. With some
kernels those bits are always zero, so n
Source: llvm-toolchain-3.8
Version: 1:3.8.1-23
Please apply this upstream bug fix to Debian's llvm-toolchain-3.8
before the release:
https://reviews.llvm.org/D27609?id=80860
See line 360 of RuntimeDyldELF.cpp.
The bug prevents julia from running on some arm64 systems and may
have other bad cons
It built on arm64 on the second attempt. So you can probably downgrade
this bug, or close it altogether if nobody can reproduce the build
failure.
It worked on arm64 on the third attempt. The second failure was
different from the first failure. So perhaps worth trying several
times on other architectures.
There may be no demand for this package (rnahybrid) on armel, but the
FTBFS might be caused by a bug in gcc-6, which would be worth
reporting if someone can confirm it.
) - installer build 20150422+deb8u4+b2"
X_INSTALLATION_MEDIUM=cdrom
==
Installer hardware-summary:
======
uname -a: Linux edmund 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30)
x86_64 GNU/Linux
lspci -knn:
Source: ntp
Version: 1:4.2.8p10+dfsg-1
Severity: wishlist
I posted a question to debian-users
(https://lists.debian.org/debian-user/2017/03/msg00591.html) and
nobody said "This already works" or "This is a bad idea", so I'm
filing this bug.
It would be nice if clock_gettime(CLOCK_TAI, ...) would
1 - 100 of 421 matches
Mail list logo
