+
From: Simon McVittie <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: linux-2.6: snd-powermac should depend on i2c-powermac
Package: linux-2.6
Followup-For: Bug #356933
I also experienced the modprobe segfault and kernel Oops reported in bug
Package: gdb
Version: 11.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: ppc64el powerpc ppc64
gdb 11 is not migrating to testing because t
On Wed, 08 Jun 2022 at 12:24:45 +0100, Simon McVittie wrote:
> > make[4]: Entering directory '/<>/build/default/sim/ppc'
> > make[4]: *** No rule to make target 'info'. Stop.
I think the solution to this might be upstream commit acbf56d7 (trying it
now on t
Control: tags -1 + fixed-upstream patch
On Wed, 08 Jun 2022 at 12:53:42 +0100, Simon McVittie wrote:
> I think the solution to this might be upstream commit acbf56d7 (trying it
> now on the ppc64el porterbox).
That seems to have been successful. MR available here:
https://salsa.debian.o
On Sun, 25 Sep 2022 at 15:41:04 +0200, John Paul Adrian Glaubitz wrote:
> Could you blacklist the test
>
> “ large-arraybuffers/basic.js”
>
> on all affected big-endian targets (powerpc, ppc64, sparc64)?
>
> The test is blacklist on s390x and fails on powerpc and ppc64 as well.
I'm not intendin
Source: gtk4
Version: 4.8.2+ds-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org
Control: clone -1 -2
Control: retitle -2 gtk+3.0: FTBFS on big-endian: some
Source: librsvg
Version: 2.54.5+dfsg-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org,
ru...@packages.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/
On Sun, 18 Jun 2023 at 13:40:09 +0100, Simon McVittie wrote:
> librsvg 2.54.5+dfsg-2 failed to build on s390x, powerpc and ppc64 with
> multiple test failures. At first glance, they seem to be the same test
> failures, meaning this is about endianness rather than any specific
>
On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
> have triggered a regression between September 2022 and now.
It would be h
Control: severity -1 important
On Sun, 18 Jun 2023 at 14:52:18 +0100, Simon McVittie wrote:
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> > I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> > confirm that 2.54.5+dfsg-1 now fails in b
On Sun, 18 Jun 2023 at 15:58:10 +0200, John Paul Adrian Glaubitz wrote:
> TIL about debbisect. I can try to bisect this on big-endian PowerPC,
> I have root on multiple big-endian machines.
Were you able to do this?
Thanks,
smcv
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
https://gitlab.gnome.org/GNOME
Source: glib2.0
Version: 2.79.0+git20240110~g38f5ba3c-1
Severity: serious
Tags: ftbfs experimental
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x
I recently uploaded a snapshot of GLib 2.79.x to experimental (in
prepar
On Sat, 13 Jan 2024 at 15:21:02 +, Simon McVittie wrote:
> I recently uploaded a snapshot of GLib 2.79.x to experimental (in
> preparation for NEW processing) and it failed tests on s390x and on
> the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means
> it's
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Control: tags -1 + help
On Sat, 13 Jan 2024 at 16:21:46 +, Simon McVittie wrote:
> On Sat, 13 Jan 2024 at 15:21:02 +0000, Simon McVittie wrote:
> > I recently uploaded a snapshot of GLib 2.79.x to experim
Control: severity -1 important
On Sat, 13 Jan 2024 at 19:32:58 +, Simon McVittie wrote:
> On Sat, 13 Jan 2024 at 16:21:46 +0000, Simon McVittie wrote:
> > On Sat, 13 Jan 2024 at 15:21:02 +0000, Simon McVittie wrote:
> > > I recently uploaded a snapshot of GLib 2.79.x t
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
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
dds and
my attempt to set up a mockup of a buildd. Please could a buildd operator
provide more details of how something resembling the -ports buildd
environment can be replicated in a test VM?
On Mon, 19 Aug 2024 at 17:02:33 +0100, Simon McVittie wrote:
> On Sun, 18 Aug 2024 at 23:44:57 +00
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 configu
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 man
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 t
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 attache
Source: gtk4
Version: 4.14.4+ds-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org,
debian-powerpc@lists.debian.org, debian-sp...@lists.debian.org
User: debian-m...@list
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
Source: gtk4
Version: 4.14.4+ds-8
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-po...@lists.debian.org
Until recently, gtk4 was not buildable on any -ports architectures because
its build-dependency, weston, was uninstallable. Now it's installable, and
building and testing can be attem
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
Package: qemu-user
Version: 1:9.0.2+ds-2+b1
Severity: normal
User: debian-powerpc@lists.debian.org
Usertags: ppc64el
X-Debbugs-Cc: debian-powerpc@lists.debian.org
The new cross-exe-wrapper package in src:architecture-properties runs
binaries from a foreign architecture, either directly or via qemu
Source: libgl1-mesa-dri
Version: 24.2.2-1
Severity: normal
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: powerpc
Similar to the situation on sparc64.
To reproduce:
- install gtk4 build-dependencies on powerpc porterbox with no access to a
real GPU
Source: gtk4
Version: 4.16.1+ds-2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: powerpc
gtk4 passes most of its test suite on powerpc, but fails one test:
https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=powerpc&
Source: mozjs52
Version: 52.3.1-4
Severity: normal
X-Debbugs-Cc: debian-powerpc@lists.debian.org
Build-time test suite failures for mozjs52 have been made non-fatal on
ppc64el because the tests time out. This is clearly a bug, but it isn't
clear what the severity of that bug is: it could be anythi
On Thu, 12 Oct 2017 at 01:31:08 +0100, Simon McVittie wrote:
> powerpc64 (pizzetti) gets the same test failures as s390x (zelenka),
> suggesting that they are something that happens on big-endian 64-bit.
> hppa doesn't seem to have a porterbox and sparc64's (notker) was
> un
Version: 52.3.1-9
On Thu, 12 Oct 2017 at 20:51:59 +0100, Simon McVittie wrote:
> Build-time test suite failures for mozjs52 have been made non-fatal on
> ppc64el because the tests time out.
According to buildd logs and #905199, this seems to have been fixed,
so I'm going to try
On Mon, 24 Sep 2018 at 21:18:47 +0100, Simon McVittie wrote:
> Most of the test cases provided with mozjs60 crash:
>
> grep '^TEST-' s390x.log | cut -d' ' -f1 | sort | uniq -c
>1714 TEST-KNOWN-FAIL
>6923 TEST-PASS
> 28635 TEST-UNEXPECTED-FAIL
This
Source: librsvg
Version: 2.44.15-1
Severity: serious
Tags: ftbfs
User: debian-powerpc@lists.debian.org
Usertags: ppc64el
https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=ppc64el&ver=2.44.15-1&stamp=1570485722&raw=0
> ERROR: rsvg-test
>
>
> thread '' panicked at 'asserti
On Wed, 11 Mar 2020 at 01:20:56 -0400, Daniel Kahn Gillmor wrote:
> ModuleNotFoundError: No module named 'giscanner._giscanner'
I think this is the python3.8 transition, combined with powerpc not having
built gobject-introspection since #950267 was fixed.
The powerpc binary for gobject-introspect
Source: gettext
Version: 0.21-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Control: block 967026 by -1
X-Debbugs-Cc: debian-powerpc@lists.debian.org
https://buildd.debian.org/status/fetch.php?pkg=gettext&arch=ppc64el&ver=0.21-2&stam
d an untested patch to disable Altivec on the architectures
+where it isn't guaranteed to be present, or is guaranteed not to be
+present. Closes: #701561, if it works.
+
+ -- Simon McVittie Tue, 04 Jun 2013 10:05:29 +0100
+
ioquake3 (1.36+u20130504+g42eeb75-2) unstable; urgency=l
On 04/06/13 13:58, thinkbr...@gmail.com wrote:
> One thing I'd suggest is that
> altivec is enabled based on the CPU itself, and not just PPC vs PPC64.
Sorry, I'm not going to do significant development on this myself, but
if you or another powerpc porter want to put a patchset together,
upstream
On 04/06/13 15:37, thinkbr...@gmail.com wrote:
> I did some tinkering with runtime detection when I was working on
> getting PPC64 support under Quake II, so I'll see if I can make
> something work. Maybe *ppcaltivec.so, *ppc.so, and *ppc64.so
The reason I suggested that *ppc.so should be the Alt
On Tue, 04 Jun 2013 at 14:58:34 +0100, Simon McVittie wrote:
> What I'm more concerned about is whether the PowerPC JIT for the Quake 3
> bytecode language (code/qcommon/vm_powerpc*) emits Altivec opcodes - I
> have no idea how I'd determine that. That's why I'm spec
Source: pygobject
Version: 3.50.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-s...@lists.debian.org
Usertags: s390x
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org,
debian-sp...@lists.debian
Control: forwarded -1 https://github.com/kcat/openal-soft/issues/1061
On Tue, 19 Nov 2024 at 09:33:52 +0100, Matthias Klose wrote:
> /<>/common/pffft.cpp: In function ‘void
> {anonymous}::uninterleave2(v4sf, v4sf, v4sf&, v4sf&)’:
...
> /<>/common/pffft.cpp:130:12: error: ‘tmp’ was not declared in
Source: openal-soft
Version: 1.24.0-1
Severity: normal
Tags: upstream
Justification: fails to build from source on non-release architectures
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: powerpc ppc64
https://buildd.debian.org/status/fetch.php?pkg=op
Source: pcre2
Version: 10.44-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org, debian-h...@lists.debian.org,
debian-powerpc@lists.debian.org, b...@debian.org
User: debian-...@lists.debian.org
Us
45 matches
Mail list logo
