> Could someone with a desktop installed on their sparc64 box please
> test the firefox package from experimental and check whether the
> alignment-related crash is still present [1]?
I have bad news, unfortunately. :(
firefox crashes (reproduceably) right after launch, and it seems it might be
> It's an assertion that's triggered from here:
>
>> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp
>
> Did you install the debug package so we can see where it actually
> crashes in ProcessExecutableMemory.cpp?
Yes, otherwise the backtrace wouldn't have
On 08/09/2018 02:41 PM, Gregor Riepl wrote:
>> Could someone with a desktop installed on their sparc64 box please
>> test the firefox package from experimental and check whether the
>> alignment-related crash is still present [1]?
>
> I have bad news, unfortunately. :(
>
> firefox crashes
On 08/09/2018 03:25 PM, Gregor Riepl wrote:
>> It's an assertion that's triggered from here:
>>
>>> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp
>>
>> Did you install the debug package so we can see where it actually
>> crashes in
> Yes, I know. But that means extra work with Vnc unless I want the pain that
> is X11 tunneling.
ssh -X doesn't work for you?
It's usually relatively painless... usually.
On 08/09/2018 04:54 PM, Gregor Riepl wrote:
>> Yes, I know. But that means extra work with Vnc unless I want the pain that
>> is X11 tunneling.
>
> ssh -X doesn't work for you?
> It's usually relatively painless... usually.
Of course, it does. It's just awfully slow.
--
.''`. John Paul
On 08/09/2018 07:18 PM, Gregor Riepl wrote:
>> qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets
>> segfault at startup
>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970
>
> I think this one is reported upstream and you already found a workaround for
> it?
> qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets
> segfault at startup
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970
I think this one is reported upstream and you already found a workaround for
it? https://bugreports.qt.io/browse/QTBUG-56264
Unless it's
> I agree. I haven't had the time yet to upstream my patch to Qt yet. There
> are a couple of other issues in upstream Qt code that I wanted to fix.
In the meantime, are you going to push a patch to the Debian repo, or do you
need any help?
> It's a binutils bug:
On 08/09/2018 11:49 PM, Gregor Riepl wrote:
>> Feel free to take this part over:
>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635
>
> Umm, ok. That's pushing it a bit.
> Where is that fix you mentioned in your last message, and what needs to be
> done to get it working? Or, are you
> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
>
> Upstream intentionally removed a.out and coff support. I protested, it didn't
> help.
Looking at https://sourceware.org/ml/binutils/2018-08/msg00166.html - I think
it's likely a.out will be gone for good. Even
> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
>
> Upstream intentionally removed a.out and coff support. I protested, it didn't
> help.
Further down, someone suggested switching to elftoaout - does that tool still
exist? Do we need to package it?
On 08/09/2018 08:31 PM, Gregor Riepl wrote:
> Still, I believe that at least newer OpenBoot versions actually support
> loading ELF binaries, but I have no clue about sun4u.
> Maybe I could try this on my Ultra 10, or have you verified that it really
> doesn't work?
That might be the case. But we
On 08/09/2018 08:03 PM, Gregor Riepl wrote:
>> I agree. I haven't had the time yet to upstream my patch to Qt yet. There
>> are a couple of other issues in upstream Qt code that I wanted to fix.
>
> In the meantime, are you going to push a patch to the Debian repo, or do you
> need any help?
On 08/09/2018 08:37 PM, Gregor Riepl wrote:
>> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
>>
>> Upstream intentionally removed a.out and coff support. I protested, it
>> didn't help.
>
> Further down, someone suggested switching to elftoaout - does that tool
Source: rustc
Version: 1.28.0+dfsg1-2
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
Hello!
With version 1.28, the Rust compiler has regressed in the sense that
it generates code with unaligned access [1].
This problem existed in the past and was supposed to
On 08/10/2018 12:36 AM, Gregor Riepl wrote:
>> We could modify sparc-utils maybe that it builds on the release
>> architectures similar to what the hppa porters do with their palo package.
>
> I'll have a look. It doesn't look like this package would only build/work on
> sparc. Usefulness is a
> Huh? sparc64 *is* UltraSPARC. Any SPARC machine made around the mid-90ies
> is an UltraSPARC. Are you confusing sun4u and sun4v?
Maybe; I was referring to sun4u vs. other, older sparc32 architectures.
I had SparcStation at one point, and those were certainly not sparc64.
These are (obviously)
> Feel free to take this part over:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635
Umm, ok. That's pushing it a bit.
Where is that fix you mentioned in your last message, and what needs to be
done to get it working? Or, are you going to finish this before your vacation?
Also,
19 matches
Mail list logo
