Hi Otto,
On Fri, 2024-07-05 at 23:00 -0700, Otto Kekäläinen wrote:
> Thanks for the tips. Unfortunately running just the single test
> without any other load on the system still crashes it and system load
> was otherwise zero, so it is not due to slowness.
Single-core performance on SPARC is
Thanks for the tips. Unfortunately running just the single test
without any other load on the system still crashes it and system load
was otherwise zero, so it is not due to slowness.
I also tested explicit debug run and various ways to invoke gdb, but
--debug didn't yield any new info and all
./sql/ha_partition.cc:5657 is coping over a blob of memory.
Could it just be slow? Does running main.partition on its own
generate the same result?
Alternately one of the loop constructs around it got some incorrect
values. Examine local variables (info locals) around what was
executing on
I built the binary in debug mode and that yielded a stacktrace:
***
main.partition w38 [ retry-fail ]
Test ended at 2024-07-06 01:14:43
CURRENT_TEST: main.partition
mysqltest: At line 3010: query 'select id from t1 where data =
Hi!
On Tue, 2 Jul 2024 at 23:24, John Paul Adrian Glaubitz
wrote:
>
> Hello Otto,
>
> On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote:
> > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
> > on sparc64.
> >
> > Are there any sparc64 hackers interested in taking a
Hello Otto,
On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote:
> I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
> on sparc64.
>
> Are there any sparc64 hackers interested in taking a look?
>
> The build itself passed and most of the post-build passes, but some
>
Hi!
I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
on sparc64.
Are there any sparc64 hackers interested in taking a look?
The build itself passed and most of the post-build passes, but some
tests cause the database to crash. Stack traces are visible in the
logs:
Source: mariadb
Version: 1:11.4.2-1
Tags: confirmed, help, ftbfs
X-Debbugs-CC: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64
The builds of MariaDB 1:10.11.8-1 passed fully in
Hi Thorsten,
On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote:
>[ Thorsten Alteholz ]
>* reintroduce time_t changes that were accidentally deleted
> with last upload
> (thanks to Michael Hudson-Doyle for this work)
>* debian/rules: no test on riscv64 (Closes:
Hi
Riccardo Mottola wrote:
> |*Debian GNU/Linux, with Linux 6.8.12-sparc64-smp |
> | Debian GNU/Linux, with Linux 6.8.12-sparc64-smp (recovery mode) |
> | Debian GNU/Linux, with Linux 6.7.7-sparc64-smp |
> | Debian GNU/Linux, with Linux
Hi,
I just did a dist-upgrade on my Netra T2000. I issue a reboot and the
system does not boot and I see the stacktrace coied at the bottom,
cycling on all 32CPUs.. but then restarting.
Grub shows me this
|*Debian GNU/Linux, with Linux 6.8.12-sparc64-smp |
| Debian
Hi Peter,
On Tue, 2024-06-11 at 10:52 +0100, Peter Tribble wrote:
> Sadly, that one fails as well.
OK, then my memory was incorrect.
> I had repeated unpack failures - debootstrap really doesn't like unpacking
> util-linux. And software
> installation eventually failed with
>
> Jun 11
On Mon, Jun 10, 2024 at 4:53 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
>
> Which image did you use? You might have caught a broken image.
>
> The problem with Debian Ports is that the images are generated from Debian
> unstable,
> so there is always a chance of
Source: mailutils
Version: 1:3.17-2
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello,
mailutils fails to build from source on sparc64 due to an outdated symbols file
[1]:
dpkg-gensymbols: warning:
Hi Peter,
On Mon, 2024-06-10 at 15:37 +0100, Peter Tribble wrote:
> I finally got round to trying to install debian-sparc in an LDOM on my T4
> server.
>
> Sadly, this didn't work.
>
> With Debian 12, software installation fails. I see
>
> Jun 10 08:43:02 in-target: The following packages
I finally got round to trying to install debian-sparc in an LDOM on my T4
server.
Sadly, this didn't work.
With Debian 12, software installation fails. I see
Jun 10 08:43:02 in-target: The following packages have unmet dependencies:
Jun 10 08:43:03 in-target: console-setup-linux : Depends:
Source: gcc-14
Version: 14.1.0-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello,
I am currently building a cross-compiler for 32-bit SPARC (sparc) and
noticed that I had to disable Ada by adding "sparc" to "ada_no_cpu"
in
Source: gcc-13
Version: 13.2.0-25
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello,
I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc)
with Ada enabled. The build failed with a linker failure which
Source: git
Version: 1:2.45.1-1
Severity: normal
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello,
the attached patch fixes the Git testsuite on sparc64. I've already
sent it upstream [1]. Could you include it for the
Hi Peter,
On Fri, 2024-05-10 at 12:07 +0100, Peter Tribble wrote:
> Tribblix is built from the last commit that worked (November 2021), with any
> relevant changes
> since cherry-picked on top. So in terms of timeline Tribblix is contemporary
> with 11.4, with
> hardware support matching the
Hi Jan,
> On Friday 2024-05-10 15:59, Rainer Orth wrote:
>>Stuff Received writes:
>>
>>> On 2024-05-10 07:44, Rainer Orth wrote (in part):
>>>
Besides, if John had ever tried to build either GCC 13 or 14 on Solaris
11.3, gcc/configure would have told him about the obsoletion in no
On Friday 2024-05-10 15:59, Rainer Orth wrote:
>Stuff Received writes:
>
>> On 2024-05-10 07:44, Rainer Orth wrote (in part):
>>
>>> Besides, if John had ever tried to build either GCC 13 or 14 on Solaris
>>> 11.3, gcc/configure would have told him about the obsoletion in no
>>> uncertain
Stuff Received writes:
> On 2024-05-10 07:44, Rainer Orth wrote (in part):
>
>> Besides, if John had ever tried to build either GCC 13 or 14 on Solaris
>> 11.3, gcc/configure would have told him about the obsoletion in no
>> uncertain terms.
>
> No, the option --enable-obsolete has allowed me to
Greetings, Rainer.
On 2024-05-10 07:44, Rainer Orth wrote (in part):
Besides, if John had ever tried to build either GCC 13 or 14 on Solaris
11.3, gcc/configure would have told him about the obsoletion in no
uncertain terms.
No, the option --enable-obsolete has allowed me to build on my
Hi Adrian,
>> > While Oracle does no longer provide feature updates to Solaris 11.3, there
>> > is still LTSS security support so that users still receive security updates
>> > so that their systems are continued to be protected against
>> > vulnerabilities.
>>
>> The Solaris 11.3 ESUs
Hi John,
> On Fri, 2024-05-10 at 12:14 +0200, Richard Biener wrote:
>> > Because I wasn't subscribed to gcc-patches and I'm also only subscribed now
>> > without receiving messages due to the large message volume on this list.
>>
>> https://gcc.gnu.org/gcc-13/changes.html
>>
>> > The problem
Hi Richard,
> On Fri, May 10, 2024 at 10:54 AM John Paul Adrian Glaubitz
> wrote:
>>
>> Hello Rainer,
>>
>> On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote:
>> > > > Support for Solaris 11.3 had already been obsoleted in GCC 13.
>> > > > However,
>> > > > since the only Solaris system in
On Fri, May 10, 2024 at 4:29 AM j...@pawlicker.com j...@pawlicker.com <
j...@pawlicker.com> wrote:
> The problem with illumos on SPARC is; illumos is also removing SPARC
> support piece by piece, especially as it gets in the way of what they want
> to do with the OS on x86-64 machines (which is
On Fri, May 10, 2024 at 10:54 AM John Paul Adrian Glaubitz
wrote:
>
> Hello Rainer,
>
> On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote:
> > > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
> > > > since the only Solaris system in the cfarm was running 11.3, I've
On Fri, 2024-05-10 at 12:14 +0200, Richard Biener wrote:
> > Because I wasn't subscribed to gcc-patches and I'm also only subscribed now
> > without receiving messages due to the large message volume on this list.
>
> https://gcc.gnu.org/gcc-13/changes.html
>
> > The problem with announcements
Hi John,
>> Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
>> since the only Solaris system in the cfarm was running 11.3, I've kept
>> it in tree until now when both Solaris 11.4/SPARC and x86 systems have
>> been added.
>>
>> This patch actually removes the Solaris
Hello Rainer,
On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote:
> > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
> > > since the only Solaris system in the cfarm was running 11.3, I've kept
> > > it in tree until now when both Solaris 11.4/SPARC and x86 systems
The problem with illumos on SPARC is; illumos is also removing SPARC support
piece by piece, especially as it gets in the way of what they want to do with
the OS on x86-64 machines (which is what everyone in that community doing the
main development uses). This was due to the lack of having a
Hello Rainer,
> Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
> since the only Solaris system in the cfarm was running 11.3, I've kept
> it in tree until now when both Solaris 11.4/SPARC and x86 systems have
> been added.
>
> This patch actually removes the Solaris
Package: gcc-13
Severity: normal
Tags: patch
X-Debbugs-Cc: debian-sparc@lists.debian.org
sparc64 has some spurios library dependencies due to gcc-as-needed.diff
currently only adding --as-needed to 32bit-only sparc builds, please
append the attached patch to gcc-as-needed.diff
Thanks in advance
On 01/05/2024 15:25, Zach van Rijn wrote:
On Tue, 2024-04-30 at 22:06 +0200, John Paul Adrian Glaubitz
wrote:
Hello,
On Mon, 2024-04-29 at 22:09 +0100, Mark Cave-Ayland wrote:
...
Does anyone know what the current status of these machines
is, or if there are any alternatives available?
On Tue, 2024-04-30 at 22:06 +0200, John Paul Adrian Glaubitz
wrote:
> Hello,
>
> On Mon, 2024-04-29 at 22:09 +0100, Mark Cave-Ayland wrote:
> > ...
> >
> > Does anyone know what the current status of these machines
> > is, or if there are any alternatives available?
>
> The old SPARC T5
Hello,
On Mon, 2024-04-29 at 22:09 +0100, Mark Cave-Ayland wrote:
> Someone mentioned to me that the SPARC gcc compile farm machines are down,
> which
> means getting access to real hardware to test patches for QEMU is proving to
> be tricky.
>
> Does anyone know what the current status of
On 30/04/2024 20:20, Palle Lyckegaard wrote:
sorry - forgot that this is a debian-list... :-)
:D
Complete list of cfarm servers is here:
https://portal.cfarm.net/machines/list/
And the Linux/SPARC machines seems to be unavailable...
Right, I suspect that's what the originator of the
On Tue, 30 Apr 2024, Mark Cave-Ayland wrote:
Solaris LDOM, but I can pass on the information regardless. Is there also an
equivalent Linux LDOM available for testing?
sorry - forgot that this is a debian-list... :-)
Complete list of cfarm servers is here:
On 30/04/2024 18:43, Palle Lyckegaard wrote:
On Mon, 29 Apr 2024, Mark Cave-Ayland wrote:
Does anyone know what the current status of these machines is, or if there are any
alternatives available?
https://portal.cfarm.net/news/50#
both cfarm215.cfarm.net and cfarm216.cfarm.net as online
On Mon, 29 Apr 2024, Mark Cave-Ayland wrote:
Does anyone know what the current status of these machines is, or if there
are any alternatives available?
https://portal.cfarm.net/news/50#
both cfarm215.cfarm.net and cfarm216.cfarm.net as online (as of now)
/Palle
Hi all,
Someone mentioned to me that the SPARC gcc compile farm machines are down, which
means getting access to real hardware to test patches for QEMU is proving to be tricky.
Does anyone know what the current status of these machines is, or if there are any
alternatives available?
ATB,
Control: reopen -1
Hi,
looks like this didn't work:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia=powerpc=6.4.2-11=1705003199=0
Reopening the bug therefore.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0
Source: graphviz
Version: 2.42.2-9
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
librsvg has become extremely unportable, and so only a subset of
architectures have it:
amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
loong64 powerpc ppc64 sparc64
Please whitelist the
On 3/14/24 06:53, Thorsten Glaser wrote:
Dixi quod…
Is there a chance your team could fork the old python-cryptography
source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring
Dixi quod…
>Is there a chance your team could fork the old python-cryptography
>source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust
version of python-cryptography ☹
Source: fsverity-utils
Version: 1.5-1.1
Severity: important
Justification: RC for Debian-Ports
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway)
have a Build-Depends-Arch on pandoc; however, pandoc is an extremely
Jérémy Lal dixit:
>Anyone had experience with the version 3.3 to 38.0 migration ?
>Maybe the API didn't change that much.
We cannot go past 3.4 because newer versions (starting at 38)
have a hard dependency on rust stuff.
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich
Le lun. 11 mars 2024 à 21:53, Thorsten Glaser a écrit :
> Jérémy Lal dixit:
>
> >While I'm very much concerned about architectures and compatibility,
> >it seems that for python-cryptography, it's a sinking boat:
> >The end of a very discussion dates from february, 2021 - 3 years ago:
>
Jérémy Lal dixit:
>While I'm very much concerned about architectures and compatibility,
>it seems that for python-cryptography, it's a sinking boat:
>The end of a very discussion dates from february, 2021 - 3 years ago:
>https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406
Le lun. 11 mars 2024 à 20:17, Thorsten Glaser a écrit :
> Hi,
>
> we have still the situation that the current python-cryptography,
> having rather heavy rust ecosystem dependencies, cannot be built
> on some debian-ports architectures.
>
> This situation is not likely to go away:
>
> • some
Hi,
we have still the situation that the current python-cryptography,
having rather heavy rust ecosystem dependencies, cannot be built
on some debian-ports architectures.
This situation is not likely to go away:
• some ports are unlikely to meet the dependencies soon
• new ports won’t meet them
Source: rakudo
Version: 2022.12-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi,
similar to #1065050 [1], there should be no reason to disable src:rakudo
on any architecture, so please set the architecture fields in debian/
Source: moarvm
Version: 2022.12+dfsg-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi,
the architecture list for moarvm (and rakudo) is limited to a set of
architectures
for no obvious reason. A quick build test on
Greetings! It appears that on sparc alone, I cannot call setjmp
successfully via a pointer to an address returned by dlsym within the
libc.so map. Calling the .plt address appears to work fine. What can
be going on here?
(by successfully, I mean that registers are not restored when returning
Source: glibc
Version: 2.37-15
Severity: important
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc:
debian-sparc@lists.debian.org,ker...@mkarcher.dialup.fu-berlin.de,s...@gentoo.org
Hello,
there is currently a nasty bug on sparc64 that breaks posix_spawn() [1]
and
Hi Gregor,
On Fri, 2024-02-02 at 12:46 +0100, Gregor Riepl wrote:
> Work was stalled previously, because the package was broken and stopped
> building with newer Xorg releases. The Xorg team was also reluctant to
> introduce a maintainer-fixed package that is only relevant for one
> Debian
Hi Adrian,
I can review and sponsor the package for you, I wasn't aware that you had
a package ready.
I checked quickly, upstream is indeed working on fixing this video
driver. They released a new version in December (1.2.3), but there's
more activity on the master branch right now.
I'll
Hi Gregor,
On Thu, 2024-02-01 at 07:57 +0100, Gregor Riepl wrote:
> Just wanted to point out that I forked and patched the Salsa repo a while
> ago: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb
>
> Unfortunately, I couldn't get it reintroduced, not even into Debian ports.
>
On 31 January 2024 19:10:19 CET, Angel wrote:
>Hello,
>
>The Debian fork driver (officially linked in the Wiki) for the Creative 3D
>card in Sun Ultra 10 is broken since at least xorg-xserver 21.
>The repo is very outdated, 10 years without a commit.
>
>The upstream from Xorg is still maintained
Hello,
The Debian fork driver (officially linked in the Wiki) for the Creative
3D card in Sun Ultra 10 is broken since at least xorg-xserver 21.
The repo is very outdated, 10 years without a commit.
The upstream from Xorg is still maintained (last commit 1w ago!). It
would be good to sync it
Source: rustc
Version: 1.70.0+dfsg1-5
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi!
The recently enabled profiler builtin is currently not supported on sparc64
and therefore leads to rustc failing to build from source [1]:
Hello!
I'm happy to announce that the LLVM buildbot for SPARC is back in service
on much faster and newer hardware. Previously, the buildbot was running on
an SPARC T5120 with an 8-core T2 CPU clocked at 1.2 GHz. The new buildbot
is based on an 8-core SPARC T4-1 clocked at 2.85 GHz, so it should
Source: binutils
Version: 2.41.50.20231227-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
The debian/rules file for binutils currently overrides the nocheck build
option with the following code snippet:
ifneq
Source: gtk4,librsvg
Severity: important
Tags: upstream help
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-po...@lists.debian.org
gtk4 had a recent test failure regression on s390x and other big-endian
architectures like ppc64 (#1057782). I sent this upstream to
Hi Adrian,
On Wed, Dec 13, 2023 at 04:14PM, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-11-16 at 20:23 +0200, Ilias Tsitsimpis wrote:
> > Thanks for working on this. I fear that applying this patch will change
> > the ABI for Cabal, and hence we will have to rebuild every Haskell
> > package
Hi Ilias!
On Thu, 2023-11-16 at 20:23 +0200, Ilias Tsitsimpis wrote:
> Thanks for working on this. I fear that applying this patch will change
> the ABI for Cabal, and hence we will have to rebuild every Haskell
> package in Debian. Because of that, I plan on waiting for the current
> transition
Source: openjdk-21
Version: 21.0.1+12-2
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
The attached patch adds SPARCV9 support to OpenJDK. It has been successfully
tested against OpenJDK 21 on
Hi Adrian,
thanks a lot.
Once a new image is available I will try it out.
Cheers
Iggi
On 11/12/23 20:47, John Paul Adrian Glaubitz wrote:
Hi Iggi!
On Fri, 2023-11-10 at 18:56 +, Ignacio Soriano Hernandez wrote:
so installed it with the latest image you had posted. It boots into the
Hi Connor!
On Wed, 2023-11-29 at 21:51 +0100, Connor McLaughlan wrote:
> just for reference, i was experiencing the same usb problem on my
> Ultra 25 as mentioned here:
> https://lists.debian.org/debian-sparc/2022/12/msg0.html
>
> So for newer kernels than 5.6.0 usb is dying during boot
On Sun, Nov 12, 2023 at 8:48 PM John Paul Adrian Glaubitz
wrote:
>
> Hi Iggi!
>
> On Fri, 2023-11-10 at 18:56 +, Ignacio Soriano Hernandez wrote:
> > so installed it with the latest image you had posted. It boots into the
> > login but USB is not supported, so only terminal.
>
> Can you post
Source: perl
Version: 5.36.0-10
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
src:perl currently fails to build from source on sparc64 due to an alignment
issue
which results in two testsuite failures:
Failed 2
Control: retitle -1 'FTBFS on multiple architectures due to incorrect
LD_LIBRARY_PATH'
Control: tags -1 +patch
Hi!
On Tue, 2023-11-28 at 10:13 +0100, John Paul Adrian Glaubitz wrote:
> --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0
> +0200
> +++
Hi!
Testing the following patch now which seems to work:
--- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0
+0200
+++ qscintilla2-2.14.1+dfsg/debian/rules2023-11-28 10:12:29.317757619
+0100
@@ -46,7 +46,7 @@
Python/build-%/configure-stamp:
Hi David!
The issue exists on sparc64 as well [1] and I'm not quite sure why it does not
seem to affect the release architectures:
make[2]: Entering directory '/<>/Python/build-3.11/cfgtest_Qsci'
sparc64-linux-gnu-g++ -c -pipe -g -O2 -ffile-prefix-map=/<>=. \
-fstack-protector-strong -Wformat
Hi!
On Fri, 2023-11-24 at 09:34 +0100, John Paul Adrian Glaubitz wrote:
> After the build system was switched from GNU Make to Hadrian, the configure
> option --disable-ld-override was lost in the process but is still required
> for previously affected architectures powerpc, powerpcspe and
Source: ghc
Version: 9.4.7-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
After the build system was switched from GNU Make to Hadrian, the configure
option --disable-ld-override was lost in the process but is still
Source: openjdk-8
Version: 8u392-ga-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
The native code generator in openjdk-8 currently segfaults on sparc64 and
prevents
a successful build. Removing sparc64 from
Source: ghc
Version: 9.4.7-1
Severity: normal
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi!
As discussed in private, here is a patch which fixes the arch detection for
sparc64 in cabal. Previously, cabal treated
Looks like this needs to be fixed in src:haskell-cabal.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Source: ghc
Version: 9.4.7-1
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi!
src:ghc currently FTBFS on sparc64 since
libraries/ghc-boot/GHC/Platform/ArchOS.hs is
missing the architecture names for sparc and
Hi Iggi!
On Fri, 2023-11-10 at 18:56 +, Ignacio Soriano Hernandez wrote:
> so installed it with the latest image you had posted. It boots into the
> login but USB is not supported, so only terminal.
Can you post the output of "lsusb" and "lspci" so I can see what kind of
USB controller your
Hi!
After a long time since the previous sparc64 porterbox went offline since
it had to move out of the data center at my old university, I am happy
to announce that a new sparc64 porterbox is now available.
The porterbox is a virtual machine (LDOM) hosted on a SPARC T4-1 with 96 GB
of RAM and
Hi Adrian,
so installed it with the latest image you had posted. It boots into the login
but USB is not supported, so only terminal.
What I was feeling is that even 5.16 is very unstable .. a simple apt install
openssh-server crashed the machine.
Btw. What is the recommended way of updating
Hi Adrian,
ok, so I had an "older" D11S64 install CD and retried. Installation went as
you said perfectly (besides the update stuff) and I even could use the kbd
for installation.
Reboot went once (with errors) up to the login but could not use the USB
kbd. Another reboot and it crashed from
Hi Iggi!
On Thu, 2023-11-09 at 15:16 +0100, Ignacio Soriano Hernandez wrote:
> Loading Linux 6.5.0-4-sparc64 ...
> Loading initial ramdisk ...
>
> [ 0.721550] pci :05:1d.0: unsupported PM cap regs version (4)
> [ 7.135075] Unable to handle kernel paging request at virtual address
>
And then rebooting once again this is the next error:
Loading Linux 6.5.0-4-sparc64 ...
Loading initial ramdisk ...
[0.719309] pci :05:1d.0: unsupported PM cap regs version (4)
[ 32.610662] watchdog: BUG: soft lockup - CPU#0 stuck for 26s!
[(udev-worker):90]
[ 56.610662] watchdog:
Progress report :-)
Ok, so initial OBP config on the Sun Ultra 25:
setenv input-device ttya
setenv output.device ttya
(You have to do that hence I had forgotten to do those changes (though
unplugged kbd/mouse) and though connected via serial output had been send
to the screen it was not
Hi Adrian,
the Sun Ultra 25 was the last Sun desktop system they did, no more Sun
propietary connectors just USB. And yes, I did try to connect and
additional Lenovo USB kbd/mouse (additional as else the Sun warns with a
power failure on the USB which it would use to output to the serial port).
Hello Iggi,
On Wed, 2023-11-08 at 11:09 +0100, Ignacio Soriano Hernandez wrote:
> just a short heads-up because I did not find teh Ultra 25 on the list of
> "supported" systems.
We don't really have a list of supported systems, just systems that are known
to work.
> I wanted to give it a try
Hi,
just a short heads-up because I did not find teh Ultra 25 on the list of
"supported" systems.
I wanted to give it a try and can confirm that it boots from CD and gets
into the "Select a language" screen but the keyboard is not working.
System: Sun Ultra 25, 1 GB RAM, 250 GB SATA, XVR-300,
On Saturday 2023-10-28 08:30, Rick Mangus wrote:
>
>The partition table is a Sun disk label, which means that /dev/sda1
>starts at sector 0
(which it does not _have_ to)
>and the filesystem header thus starts in the same
>place as if there were no partition table.
yeah, that kind of speaks
After a recent dist-upgrade, I failed to mount /boot when rebooting.
Further investigation shows that /dev/disk/by-path has an entry for my
/boot as /dev/sda (rather than sda1). Updating to use the by-id in
/etc/fstab solves the problem, but I'm curious what changed and if
this is a known issue.
Hi,
I've tried moving RAM around. It didn't seem to make a difference. FYI.
The package that fails is often different even without moving RAM
around. Solaris 2.5, NetBSD, and OpenBSD all install and function
properly on this machine.
I've had similar success with my Sun Fire V215.
System
On Fri, Oct 20, 2023 at 1:04 AM Gatis Visnevskis wrote:
> Hello,
>
> If you can swap RAM modules between slots, and notice changes, then you
> have some bad RAM.
>
> G
>
>
I've tried moving RAM around. It didn't seem to make a difference. FYI. The
package that fails is often different even
On Sat, Oct 14, 2023 at 11:33 PM Jeremy Leonard
wrote:
>
> On Thu, Oct 12, 2023 at 3:11 AM John Paul Adrian Glaubitz <
> glaub...@physik.fu-berlin.de> wrote:
>
>> Hi Jeremy!
>>
>> On Wed, 2023-10-11 at 16:01 -0400, Jeremy Leonard wrote:
>> > [ 10.116921] Initramfs unpacking failed: write error
On Thu, Oct 12, 2023 at 3:11 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi Jeremy!
>
> On Wed, 2023-10-11 at 16:01 -0400, Jeremy Leonard wrote:
> > [ 10.116921] Initramfs unpacking failed: write error
> > (...)
> > Where should I look to start resolving this?
>
> Your
Hi Jeremy!
On Wed, 2023-10-11 at 16:01 -0400, Jeremy Leonard wrote:
> [ 10.116921] Initramfs unpacking failed: write error
> (...)
> Where should I look to start resolving this?
Your problem is the failed attempt to unpack the initramfs and apparently the
problem is that it's failing to write
I'm working to install Debian on a Sun Ultra1. I get an error and a kernel
panic on boot.
Hardware:
Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard
OpenBoot 3.11, 256 MB memory installed
I've tried using debian-12.0.0-sparc64-NETINST-1.iso from 2023-05-16 09:05
Along with the snapshot from
1 - 100 of 41554 matches
Mail list logo
