On Mon, 2024-09-23 at 09:56 +0200, Ignacio Soriano Hernandez wrote:
> We are at a very stable working configuration with Radeon support on T2 SDE.
>From what I have heard, Rene did not apply any local SPARC-specific patches to
the kernel, so the fact that your machine runs stable with T2 SDE is
Good to hear Gregor.
We are at a very stable working configuration with Radeon support on T2
SDE.
I think combining the efforts will be beneficial for the whole
Linux/SPARC64 community.
Cheers
Iggi
Gregor Riepl schrieb am Mi. 18. Sept. 2024 um 20:17:
> Small update:
>
> I managed to build
Hi Gregor,
On Mon, 2024-09-23 at 00:20 +0200, Gregor Riepl wrote:
> >
> > It's probably due to CONFIG_DEBUG_INFO. Try turning that off. Debian builds
> > the kernel with debug
> > symbols enabled and then runs the strip command afterwards. This way both a
> > debug and a standard
> > kernel pac
It looks very much like it isn't specifically a kernel bug at all, but either
something
wrong with the Debian kernel config, or with newer gcc versions.
I still think it's a kernel bug.
Very well.
Tracing through all possible kernel config parameters is probably not feasible
anyway.
It's p
On Sun, 2024-09-22 at 16:03 +0200, saca...@libero.it wrote:
> thanks,
> I think is a problem booting debian12 from silo.conf into debian9,
> I retrieve into system kernel-4.18.0-1-sparc64 and initrd.img-6.10.7-sparc64
You cannot combine a 4.18.0 kernel with a 6.10.7 initrd, the version numbers
I have a SUN Ultra10, a few years ago I installed debian9 on a disk.
now I tried to install debian12 (with grub) on another disk but it doesn't
boot.
I tried to boot deb12 from deb9 with silo, but it start kernel of debian9
with the " /" of 12
what do you suggest I try?
Adrian has suggest
d non-critical issues, such as this I/O error with 5.14
> (but nothing in dmesg):
>
> $ /usr/sbin/bonnie++
> Writing a byte at a time...done
> Writing intelligently...done
> Rewriting...Can't write block.: Unknown error 2560
> Bonnie: drastic I/O error (re write(2)):
Small update:
I managed to build a 6.10 kernel with gcc 14 now.
I'll do some more stress testing with it, but looks very stable so far.
My kernel config is attached.
It's much smaller than the Debian kernel config config-6.10.7-sparc64-smp, and
now I'm quite convinced that it's really some opti
odd non-critical issues, such as this I/O error with 5.14 (but
nothing in dmesg):
$ /usr/sbin/bonnie++
Writing a byte at a time...done
Writing intelligently...done
Rewriting...Can't write block.: Unknown error 2560
Bonnie: drastic I/O error (re write(2)): Unknown error 2560
6.2 produces this
Control: retitle -1 gtk4: FTBFS with weston 14: many tests fail with
--setup=wayland: Failed to open display
Control: severity -1 serious
(Please remove -ports from cc in replies, this is no longer believed to
be -ports specific)
On Thu, 12 Sep 2024 at 11:48:21 +0100, Simon McVittie wrote:
> gtk
Control: tags -1 + pending
On Wed, 04 Sep 2024 at 18:51:11 +0100, Simon McVittie wrote:
> src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
> around #1010838. Mesa 24.2.x is no longer built with softpipe enabled
24.2.1-4 re-enables softpipe (#1080475) which
Hi Gregor,
On Wed, 2024-09-04 at 01:22 +0200, Gregor Riepl wrote:
> >
> > It's actually pretty simple these days as the kernel.org mirrors provide
> > binary
> > distributions of freestanding toolchains for all major supported
> > architectures
> > of the Linux kernel.
> >
> > To set up on any
I may have some time to do test runs next week.
Could you give me some quick starters for setting up a kernel cross build env on
an amd64 machine, or maybe access to a Sun box I could use?
It's actually pretty simple these days as the kernel.org mirrors provide binary
distributions of freestandi
Hi Gregor,
On Tue, 2024-09-03 at 19:19 +0200, Gregor Riepl wrote:
> > > If you have issues to bi-sect just let us know for any arch. Given T2’s
> > > cross-compile
> > > support and I have most hardware in my museum now, I can usually bisect
> > > issues
> > > within a day or two.
> >
> > I don
If you have issues to bi-sect just let us know for any arch. Given T2’s
cross-compile
support and I have most hardware in my museum now, I can usually bisect issues
within a day or two.
I don't have issues with bisecting, I'm just rather time-constrained at the
moment, so
I'm always happy w
Hello Rene,
On Tue, 2024-09-03 at 11:09 +0200, René Rebe wrote:
> > according to these posts [1][2] by Iggi, you figured out the stability
> > problem
>
> No, we are just sometimes lucky it run that long stable. I was only made aware
> recently that sun4u was not 100% and my fasted UltraSPARC un
On Tue, 20 Aug 2024 at 12:33:22 +0100, Simon McVittie wrote:
> Please see attached. As with the other known regression from 1.6.13-4
> (#1078539), the proposed solution is a change to a conffile, so buildd
> operators could try this manually if desired.
The patch I previously attached here is also
Hello,
On Sun, 2024-08-25 at 12:58 +0200, Ignacio Soriano Hernandez wrote:
> thanks for the updated ISO. So took some hours this morning to do testing on
> the dual Ultra 45.
>
> 1). So no change wrt to being able to install at the console with USB
> kbd/mouse attached. Same behavour as before,
Hello Iggi,
On Sat, 2024-08-24 at 17:25 +0200, Ignacio Soriano Hernandez wrote:
> Wanted to once again try Debian 12 on my Sun Ultra 45 (XVR-2500, USB
> kbd/mouse) and at
> the language selection screen it is stuck (well no kbd input) because i can
> push the
> power buttom and it powers down.
Simon McVittie dixit:
>I was not aware of any mips* buildds still on 4.9 (Debian 9 kernel). The
>only mips family architecture listed on buildd.debian.org is mips64el, for
I think 4.9 is some mipsel buildds. Shortly after the discussion,
which I’m attaching as I don’t know where it’s otherwise ar
On Tue, 20 Aug 2024 at 01:30:55 +0100, Simon McVittie wrote:
> The reason for the regression is probably that /dev/pts/ptmx on the host
> has permissions 000, making it inaccessible (despite being functionally
> equivalent to /dev/ptmx which is available to everyone).
Yes, it seems to be this. I'v
Control: tags -1 + patch
On Tue, 20 Aug 2024 at 12:10:33 +0100, Simon McVittie wrote:
> I'm testing a patch now.
Please see attached. As with the other known regression from 1.6.13-4
(#1078539), the proposed solution is a change to a conffile, so buildd
operators could try this manually if desire
Simon McVittie dixit:
>was rather recent at that time, but hopefully we no longer have any
>machines that are running Debian 8 kernels...
The varios MIPS buildds run 4.19 and some even 4.9 kernels
(AFAIHH due to hardware/patch constraints), which has led
to problems (e.g. I had to disable klibc b
On Tue, 20 Aug 2024 at 00:59:30 +0100, Jessica Clarke wrote:
> On 20 Aug 2024, at 00:23, Simon McVittie wrote:
> > I was unable to reproduce this build failure
...
> > There must presumably be something different about how sbuild-createchroot
> > and schroot are configured or invoked on the affect
On 20 Aug 2024, at 00:23, Simon McVittie wrote:
>
> I'm using Thorsten's regression report in #983423 as my representative
> sample of a package that regressed with schroot 1.6.13-4, because mksh
> builds much more quickly than gcc-14, but I suspect that the same would
> apply equally to Adrian's
Hi Simon,
thanks for testing.
>I'm using Thorsten's regression report in #983423 as my representative
>sample of a package that regressed with schroot 1.6.13-4, because mksh
>builds much more quickly than gcc-14
(You can add mksh-firstbuilt to DEB_BUILD_OPTIONS so it doesn’t build
and test binar
I'm using Thorsten's regression report in #983423 as my representative
sample of a package that regressed with schroot 1.6.13-4, because mksh
builds much more quickly than gcc-14, but I suspect that the same would
apply equally to Adrian's regression report in #856877: the important
factor is proba
Simon McVittie dixit:
>On Mon, 19 Aug 2024 at 16:27:24 +, Thorsten Glaser wrote:
>> mksh actually does things inside script(1) that use the tty
>
>For the purposes of having a test-case for schroot that doesn't require
>mksh, perhaps a good approximation to this would be asserting that
>tty(1)
On Mon, 19 Aug 2024 at 16:27:24 +, Thorsten Glaser wrote:
> mksh actually does things inside script(1) that use the tty
For the purposes of having a test-case for schroot that doesn't require
mksh, perhaps a good approximation to this would be asserting that
tty(1) from coreutils exits success
Simon McVittie dixit:
>On Sun, 18 Aug 2024 at 23:44:57 +, Thorsten Glaser wrote:
>> On three buildds, mksh FTBFS already because the whole
>> /dev/ptmx and /dev/pts stuff is malfunctioning again
>
>Which buildds? Are you referring to -ports builds
>https://buildd.debian.org/status/fetch.php?pk
On Sun, 18 Aug 2024 at 23:44:57 +, Thorsten Glaser wrote:
> On three buildds, mksh FTBFS already because the whole
> /dev/ptmx and /dev/pts stuff is malfunctioning again
Which buildds? Are you referring to -ports builds
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-3
Hi!
> > 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 rather poor, especially on older
> SPARC systems like this
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 rath
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 gdb
./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 timeo
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 = 'a
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 lo
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
> tes
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: #1073
69882] systemd[1]: Finished modprobe@loop.service - Load Kernel Module loop.
[ 39.874003] systemd[1]: Finished systemd-modules-load.service - Load Kernel Modules.
[ 39.876067] systemd[1]: systemd-repart.service - Repartition Root Disk was skipped because no trigger condition checks were me
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 08:34:09
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 downloadin
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 have
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 ori
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 terms.
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 T2000
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 (Extended
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 wit
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 t
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 wh
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 k
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 on
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 11.
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 ha
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 bu
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 11.3
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?
The
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 porterbo
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 the
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 repo
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:
https://portal.cfarm.net/machines/
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 (as
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
Control: reopen -1
Hi,
looks like this didn't work:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia&arch=powerpc&ver=6.4.2-11&stamp=1705003199&raw=0
Reopening the bug therefore.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG
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 the
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 ☹
bye
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 m
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:
> >https://
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
Ouch
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 port
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 port
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 s
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.
> If
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
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 i
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 t
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
log
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 rende
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 t
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
> +++ qscintilla2-2.14.1
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: build-library-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 -We
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 sparc64
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
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 m
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 th
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 ther
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
> 000
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 a
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 for
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 st
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 witho
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 t
I'm also experiencing this problem with the
debian-12.0.0-sparc64-NETINST-1.iso from 2023-05-16 on a SPARC T4-2
(sun4v). Logs are as below; a Debian 11 image from last year works fine
(unfortunately with an unknown burn date).
> Loading ...
>
> [ 2.259595] niu 0001:0a:00.0: can't ioremap BA
ality) where something in the southbridge or
IDE cable must have been messed up enough that reads from harddisk
would bitflip occassionally. So when a .so file was read (or re-read
after pushed out of the pagecache) and it flipped, some instruction
would now access '[eax+0x8002]' ra
Hi Gregor,
On 8/12/23 3:33 AM, Gregor Riepl wrote:
> ... The V215 is very picky about RAM
> (requires buffered DDR-333 modules with ECC).
> I've attached logs from two kernel panics for reference. One happened at
> boot time, the other after some heavy compilation and debugging. Both
> aren't repr
1 - 100 of 20202 matches
Mail list logo
