te invitamos a escuchar "Respira": la canción que te hará vibrar.
¡Hola !
Esperamos que estés teniendo un día maravilloso. Queríamos escribirte para
compartir contigo algo muy especial que nos hace muchísima ilusión: ¡nuestra
última canción, "Respira"!
"Respira" es una canción que nos
Source: mariadb
Version: 1:10.11.5-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64
Builds on sparc64 repeatedly failed on tests main.ctype_binary
main.ctype_latin1 with error message:
main.ctype_binary
Hi,
Errors were encountered while processing:
linux-image-6.5.0-1-sparc64-smp
linux-image-sparc64-smp
E: Sub-process /usr/bin/dpkg returned an error code (1)
In the console I see:
Generating grub configuration file ...
/etc/grub.d/10_linux: 1: version_find_latest: not found
run-parts:
Source: ghc
Version: 9.4.6-1
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
When upstream dropped NGC support for SPARC, they also accidentally removed
build support
for unregisterised builds by removing
Source: suitesparse
Version: 1:7.1.0+dfsg-3
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
suitesparse FTBFS on loong64 and sparc64 due a packaging issue with an implicit
CUDA
dependency. The failing build step is
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
On Saturday 2023-08-12 15:29, Stan Johnson wrote:
>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
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
Hi,
I've finally managed to set some time aside to test the latest installer
images and kernel 6.4 on a Fire V215. I haven't had time to try it out
on my Ultra 10 yet.
The good news is that the previous problems I had with SMP are now gone.
The SMP kernel was basically unusable before,
Update:
Well, I was wrong about the size of the initrd.img file causing the
"Fast Data Access MMU Miss" (it only happens with some kernels).
This combination (the default Debian SID vmlinux and initrd.img) fails:
# ls -l *6.4.0*
-rw-r--r-- 1 root root 186222 Jul 29 22:50 config-6.4.0-1-sparc64
Hello,
On 7/31/23 1:06 PM, Stan Johnson wrote:
> ... "Fast Data Access MMU Miss" while loading the initrd
After doing some more testing (and accidentally erasing my system disk
-- sda is the lower drive, not the upper one!), it's looking like the
"Fast Data Access MMU Miss" error is not caused
Hi Adrian,
On 7/31/23 9:15 AM, John Paul Adrian Glaubitz wrote:
>
>
>> On Jul 31, 2023, at 4:33 PM, Stan Johnson wrote:
>>
>> I don't think a kernel bisect will identify the issue, since the kernel
>> boots ok. This has something to do with the initrd, and I don't know how
>> to troubleshoot
> On Jul 31, 2023, at 2:46 PM, Riccardo Mottola
> wrote:
>
> after several reboots, I could not reproduce "that" looping crash anymore,
> but I always got into maintenance mode.
> Is that a kernel issue too?
Yes, see the other thread which also reports a regression on older SPARCs.
There
> On Jul 31, 2023, at 4:33 PM, Stan Johnson wrote:
>
> I don't think a kernel bisect will identify the issue, since the kernel
> boots ok. This has something to do with the initrd, and I don't know how
> to troubleshoot that. Any recommendations?
It can still be a bug in the kernel,
Update:
Sorry it's taken me a while to start looking at this issue; my Ultra-30
was unavailable for about 5 days while it was updating Gentoo (I need to
configure a QEMU host for Sparc 64 to build and update my Debian and
Gentoo root filesystems).
Anyway, this morning I upgraded Debian SID again
Hi Adrian
John Paul Adrian Glaubitz wrote:
Kernel regressions should be reported to the sparclinux kernel mailing list [1].
Also, a bisect would be helpful to determine which commit broke the kernel.
after several reboots, I could not reproduce "that" looping crash
anymore, but I always
Hi Riccardo!
On Mon, 2023-07-31 at 12:21 +0200, Riccardo Mottola wrote:
> I have a Fire T2000 which has been stable for my usage for months.
> Now I upgraded kernel (and userland) in debian to:
>
> Yesterday, when hooking up a serial console, i was getting asked for
> root password and dropped
Hi,
I have a Fire T2000 which has been stable for my usage for months.
Now I upgraded kernel (and userland) in debian to:
Yesterday, when hooking up a serial console, i was getting asked for
root password and dropped into maintenance mode.
Today I hooked up better through a console with
On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 16:09 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
On Tue, Jul 25, 2023 at 12:36:57PM +, Ignacio Soriano Hernandez wrote:
> Hi,
>
> interesting error as the latest Openindiana/SPARC (Beta)
> (https://dlc.openindiana.aurora-opencloud.org/SPARC/release) was showing the
> same error BUT in a MP environment.
>
> ERROR: Last Trap: Fast Data
Hi,
interesting error as the latest Openindiana/SPARC (Beta)
(https://dlc.openindiana.aurora-opencloud.org/SPARC/release) was showing the
same error BUT in a MP environment.
ERROR: Last Trap: Fast Data Access MMU Miss
Cheers
Iggi
Am 25.07.23, 12:07 schrieb "Joacim Nilsson"
On Mon, Jul 24, 2023 at 03:46:12PM -0600, Stan Johnson wrote:
> Hello,
>
> The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
> Ultra 30 with the following error at the PROM:
>
> -
> ...
> Loaded kernel version 6.4.4
> Loading initial ramdisk (23022746 bytes at 0x6400
Hi Stan!
On Mon, 2023-07-24 at 15:46 -0600, Stan Johnson wrote:
> The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
> Ultra 30 with the following error at the PROM:
>
> -
> ...
> Loaded kernel version 6.4.4
> Loading initial ramdisk (23022746 bytes at 0x6400 phys,
Hello,
The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
Ultra 30 with the following error at the PROM:
-
...
Loaded kernel version 6.4.4
Loading initial ramdisk (23022746 bytes at 0x6400 phys, 0x40C0
virt)...
Fast Data Access MMU Miss
ok
-
I have been
Hello,
On 7/23/23 3:27 AM, Joacim Nilsson wrote:
> ...
>>>
>>> Loading Linux 6.3.0-2-sparc64 ...
>>> Loading initial ramdisk ...
>>>
>>> Failed to get cgroup, ignoring: No medium found
>>> /dev/sda2: recovering journal
>>> /dev/sda2: clean, 32037/15204352 files, 1785366/60804430 blocks
>>> [
Hi!
On Sun, 2023-07-23 at 11:36 +0200, Joacim Nilsson wrote:
> Never done it before.
> i found this
> https://wiki.debian.org/DebianKernel/GitBisect
Yes, this basically explains how to do it.
However, I would recommend using a fast x86_64 machine for cross-compiling the
kernel as building the
On Sun, Jul 23, 2023 at 11:29:43AM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On Sun, 2023-07-23 at 11:27 +0200, Joacim Nilsson wrote:
> > To get more information i booted the 6.1.0-9 kernel
> > That one works!
>
> OK, so it seems we have found a kernel regression here.
>
> Do you know
Hi!
On Sun, 2023-07-23 at 11:27 +0200, Joacim Nilsson wrote:
> To get more information i booted the 6.1.0-9 kernel
> That one works!
OK, so it seems we have found a kernel regression here.
Do you know how to bisect a kernel?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian
On Sun, Jul 23, 2023 at 08:30:52AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Joacim!
>
> On Sat, 2023-07-22 at 22:53 +0200, Joacim Nilsson wrote:
> > Hi!
> > After installning debian-12.0.0-sparc64-NETINST-1.iso
> > on my Sun Ultra 5
> >
> > i get
> >
> > Loading Linux 6.3.0-2-sparc64 ...
>
Hi Joacim!
On Sat, 2023-07-22 at 22:53 +0200, Joacim Nilsson wrote:
> Hi!
> After installning debian-12.0.0-sparc64-NETINST-1.iso
> on my Sun Ultra 5
>
> i get
>
> Loading Linux 6.3.0-2-sparc64 ...
> Loading initial ramdisk ...
>
> Failed to get cgroup, ignoring: No medium found
> /dev/sda2:
Hi!
After installning debian-12.0.0-sparc64-NETINST-1.iso
on my Sun Ultra 5
i get
Loading Linux 6.3.0-2-sparc64 ...
Loading initial ramdisk ...
Failed to get cgroup, ignoring: No medium found
/dev/sda2: recovering journal
/dev/sda2: clean, 32037/15204352 files, 1785366/60804430 blocks
[
On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote:
>
> Am 22.07.23 um 14:02 schrieb Andreas Schwab:
> > On Jun 18 2023, Rene Engelhard wrote:
> >
> >> For riscv64 I already pointed that out in the thread starting at
> >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
Hi,
Am 22.07.23 um 16:09 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
On Jul 22 2023, Rene Engelhard wrote:
> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Does opensuse have some public git/$VCS?
>> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
>
> Thanks...
>
>
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
> (Though I would more bet of some system evironment thingy)
Perhaps it is a matter of using a good java. Have
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
Thanks...
But maybe I am too blind.
I don't see the actual
Hi,
Am 22.07.23 um 15:07 schrieb Andreas Schwab:
Which gives the smoketest test failure here I pointed out (again) in my
other mail.
$ find /usr/lib64/libreoffice/ -name "*smoke*"
/usr/lib64/libreoffice/program/classes/smoketest.jar
How can I run that?
You can't from that, ttbomk. You miss
Hi,
Am 22.07.23 um 15:02 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
appear as bundled extensions.
$ unopkg list --bundled
On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 14:28 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
>>> though)
>> On openSUSE Factory, libreoffice is built with the usual compiler
On Jul 22 2023, Rene Engelhard wrote:
> https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
> thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
> appear as bundled extensions.
$ unopkg list --bundled
All deployed bundled extensions:
Identifier:
On Jul 22 2023, Rene Engelhard wrote:
> And that includes LibreOffice-bundled extensions like the
> english,hungarian,russian grammar checker for example. Ot external finnish
> spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
>
> And those are extensions written in python
On Jul 22 2023, Rene Engelhard wrote:
> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
> though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Jul 22 2023, Rene Engelhard wrote:
> Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for
Hi,
Am 22.07.23 um 14:34 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
And that includes LibreOffice-bundled extensions like the
english,hungarian,russian grammar checker for example. Ot external finnish
spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
Hi,
Am 22.07.23 um 14:28 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
Hi,
Am 22.07.23 um 14:25 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
Do you run the testsuite?
Especially the smoketest?
And you are replying to
Hi,
Am 22.07.23 um 14:09 schrieb Rene Engelhard:
And that included packaged extensions so if they install but don't work
that's a grave bug.
And that includes LibreOffice-bundled extensions like the
english,hungarian,russian grammar checker for example. Ot external
finnish spellchecking,
On Jun 18 2023, Rene Engelhard wrote:
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any
Hi,
Am 22.07.23 um 14:02 schrieb Andreas Schwab:
On Jun 18 2023, Rene Engelhard wrote:
For riscv64 I already pointed that out in the thread starting at
https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
other architectures there is the mail now. riscv64 is different
On Fri, Jul 21, 2023 at 06:14:04PM +1000, Finn Thain wrote:
>
> I'm not blaming the unstable API for the bugs, I'm blaming it for the
> workload. A stable API (like a userspace API) decreases the likelihood
> that overloaded maintainers have to orphan a filesystem implementation.
You are
On Fri, 21 Jul 2023, Matthew Wilcox wrote:
>
> You've misunderstood. Google have decided to subject the entire kernel
> (including obsolete unmaintained filesystems) to stress tests that it's
> never had before. IOW these bugs have been there since the code was
> merged. There's nothing to
On Fri, Jul 21, 2023 at 11:03:28AM +1000, Finn Thain wrote:
> On Fri, 21 Jul 2023, Dave Chinner wrote:
>
> > > I suspect that this is one of those catch-22 situations: distros are
> > > going to enable every feature under the sun. That doesn't mean that
> > > anyone is actually _using_ them
On Fri, 21 Jul 2023, Dave Chinner wrote:
> > I suspect that this is one of those catch-22 situations: distros are
> > going to enable every feature under the sun. That doesn't mean that
> > anyone is actually _using_ them these days.
I think the value of filesystem code is not just a question
On Thu, 20 Jul 2023 at 15:37, Matthew Wilcox wrote:
>
> I think you're missing the context. There are bugs in how this filesystem
> handles intentionally-corrupted filesystems. That's being reported as
> a critical bug because apparently some distributions automount HFS/HFS+
> filesystems
On Thu, Jul 20, 2023 at 05:38:52PM -0400, Jeffrey Walton wrote:
> On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote:
> >
> > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > >
On Thu, Jul 20, 2023 at 02:27:50PM -0400, Jeff Layton wrote:
> On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote:
> > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > > MAINTAINERS
On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote:
>
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we
On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote:
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we
On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > MAINTAINERS and if distros are going to do such a damnfool thing,
> > then we must stop them.
>
> Both HFS and HFS+ work perfectly fine. And if
Hi,
On 11/07/2023 10:21, John Paul Adrian Glaubitz wrote:
On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote:
Hi,
On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote:
While we're currently not building Debian for 32-bit SPARC (sparc),
it's still being bootstrapped in the Debian
Hi!
On Tue, 2023-07-11 at 20:59 +0200, John Paul Adrian Glaubitz wrote:
> With the above fix for the audit tests, the tests to ignore should be:
>
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/isomac
Just verified this. With
On Tue, 2023-07-11 at 20:57 +0200, Aurelien Jarno wrote:
> > Correction: These two tests should be ignored as well:
> >
> > FAIL: elf/tst-rtld-run-static
> > FAIL: nptl/tst-cancel24-static
>
> Noted.
>
> > So, it's only this failure that just got fixed today upstream [1]:
> >
> > FAIL:
Hi!
On Tue, 2023-07-11 at 20:52 +0200, Aurelien Jarno wrote:
> > According to upstream, the following audit tests are not going to be
> > fixed soon since the SPARC ABI makes it more difficult:
> >
> > FAIL: elf/tst-audit24a
> > FAIL: elf/tst-audit24b
> > FAIL: elf/tst-audit24c
> > FAIL:
Hi,
On 2023-07-11 14:33, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote:
> > These are going to be fixed upstream soon, the fixes are supposedly
> > trivial:
> >
> > FAIL: elf/tst-rtld-run-static
> > FAIL: nptl/tst-cancel24-static
>
Hi!
On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote:
> The list of currently failing tests on sparc64 is:
>
> FAIL: elf/tst-audit24a
> FAIL: elf/tst-audit24b
> FAIL: elf/tst-audit24c
> FAIL: elf/tst-audit24d
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static
>
Hi Matthew!
On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote:
> Hi,
>
> On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote:
>
> > While we're currently not building Debian for 32-bit SPARC (sparc),
> > it's still being bootstrapped in the Debian rebootstrap project [1].
> >
> > The CI
Source: glibc
Version: 2.37-5
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi!
The list of currently failing tests on sparc64 is:
FAIL: elf/tst-audit24a
FAIL: elf/tst-audit24b
FAIL: elf/tst-audit24c
FAIL: elf/tst-audit24d
Source: glibc
Version: 2.37-3
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
On sparc64, the following tests for the 32-bit build have been failing for a
while now:
FAIL: elf/tst-audit24a
FAIL: elf/tst-audit24b
FAIL:
On 7/3/23 05:47, John Paul Adrian Glaubitz wrote:
Hello!
On Mon, 2023-07-03 at 05:28 -0400, Dennis Clarke wrote:
I don't think that's true. Since it has been reported that these machines
run OpenBSD, it should be a matter of reading the OpenBSD kernel sources
and add the missing bits and
On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
> > > what about the
> > > following:
> > > - make all test failures fatal on a*64 (since upstream tests these), and
> > > - make smoketest failures fatal on all architectures
Hi,
Am 03.07.23 um 21:31 schrieb Rene Engelhard:
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
That was implemented (+ two
Hi,
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
That was implemented (+ two more important tests) in experimental. See
Hello!
On Mon, 2023-07-03 at 05:28 -0400, Dennis Clarke wrote:
> > I don't think that's true. Since it has been reported that these machines
> > run OpenBSD, it should be a matter of reading the OpenBSD kernel sources
> > and add the missing bits and pieces for the SPARC64 VII(+) machines to the
On 7/2/23 17:19, John Paul Adrian Glaubitz wrote:
Hi Dennis!
Good day to you Sir!
On Sun, 2023-07-02 at 14:34 -0400, Dennis Clarke wrote:
You are likely kicking a dead horse. That M4000 is similar to my M3000
and you will never ever get Linux to run there. Ever. Unless you have a
few
Hi Dennis!
On Sun, 2023-07-02 at 14:34 -0400, Dennis Clarke wrote:
> You are likely kicking a dead horse. That M4000 is similar to my M3000
> and you will never ever get Linux to run there. Ever. Unless you have a
> few million dollars for research and development and then be able to
> push all
On 7/2/23 06:35, Vocalía Infraestructura TIC CEEINA wrote:
Hi,
We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server
(SPARC64 VII+), but, after selecting normal / expert / secure install mode,
we get this error message and the installer quits:
*ERROR: Last Trap: Division by
Hi,
Sure. This is what we are getting when trying to install Debian 9.0 Sparc64:
---
> *{0} ok boot cdrom*
>
> *Boot device: /pci@0,60/pci@0/pci@8/pci@0/scsi@1/disk@3,0:f File and
> args:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *SILO
Hi,
On 02.07.23 16:35, Vocalía Infraestructura TIC CEEINA wrote:
Hi Frank,
Thank you for your fast answer. I also thought when installing that it
was an incompatibility problem with the processor architecture, as you
stated.
However, having a look at the wiki
Hi Frank,
Thank you for your fast answer. I also thought when installing that it was
an incompatibility problem with the processor architecture, as you stated.
However, having a look at the wiki (https://wiki.debian.org/Sparc64) it
seems to me that machines with a sun4u SPARC VII+ processor
Hi,
On 02.07.23 12:35, Vocalía Infraestructura TIC CEEINA wrote:
Hi,
We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server
(SPARC64 VII+), but, after selecting normal / expert / secure install
mode, we get this error message and the installer quits:
/ERROR: Last Trap:
Hi,
We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server
(SPARC64 VII+), but, after selecting normal / expert / secure install mode,
we get this error message and the installer quits:
*ERROR: Last Trap: Division by Zero*
*%TL:1 %TT:28 %TPC:43056c %TnPC:430570
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have
On Sat, 2023-06-24 at 13:04 +0200, John Paul Adrian Glaubitz wrote:
> For the bug report, please include:
>
> - the full URL to the build log of the affected package on buildd.debian.org
> - an excerpt from the build log like the one above that shows the actual
> build error
> - a mention of the
Hello!
There are still many packages in Debian that fail to build from source on
sparc64,
so I thought it might be a good idea to ask the community for help reporting
these
bugs upstream.
The list of affected packages can be found by following this link:
>
Source: libwebm
Version: 1.0.0.29-1
Tags: sid
Severity: important
X-Debbugs-CC: debian-s...@lists.debian.org debian-h...@lists.debian.org
debian-powe...@lists.debian.org debian-sparc@lists.debian.org
vasek.ge...@gmail.com
Hi all,
Package libwebm was introduced into Debian in 2021 for .webm
On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote:
> Can I suggest that if you file a few bugs and add some information in
> it so that maybe someone can look at it? If it only affects one
> architecture, send a mail to that list asking for help.
PS: when filing architecture-specific bugs,
Can I suggest that if you file a few bugs and add some information in it so
that maybe someone can look at it? If it only affects one architecture, send a
mail to that list asking for help.
Kurt
Hi,
Am 20.06.23 um 16:52 schrieb Kurt Roeckx:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> >
> > And have Format->Character in Impress crash
Stop sending these emails please!
Sent from my iPhone
> On 20 Jun 2023, at 09:42, Adrian Bunk wrote:
>
> On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
>> Hi,
>>
>> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> >
> > And have Format->Character in Impress crash
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote:
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There
Hi,
Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
You can usually uncover them by building the package with CFLAGS=" ...
-fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
". The UBsan sanitizer operates on real data. There are no false
positives.
I'd personally assume
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep
On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> I won't be of much help here unfortunately, except
> maybe testing patches, but then again there's porterboxes
>...
You are the only one who could realistically debug many of these.
E.g. on armel it says:
Fatal exception:
Hi,
Am 19.06.23 um 23:19 schrieb Adrian Bunk:
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
...
I won't be of much help here unfortunately, except
maybe testing patches, but then again there's porterboxes
...
You are the only one who could realistically debug many of these.
On Sunday 2023-06-18 23:37, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3
>>> and
>>> the AGPL have been rejected soundly by most developers" and talked about
>>> how he
>>> regretted the move and the
On 6/18/23 15:19, Rene Engelhard wrote:
> Besides that it would also have been clear from actually reading the IRC
> log which incidentially also says
Good to know what the expectations for participation are.
>> This is the same GPLv3 package that Red Hat just dropped support for?
>
> As I
101 - 200 of 41554 matches
Mail list logo
