debian-68k  

Messages by Thread

• Upstream issue tracker for m68k created John Paul Adrian Glaubitz
• Bug#1127874: webkit2gtk: Please update no-must-tail.patch to cover all architectures John Paul Adrian Glaubitz
• Bug#1127603: binutils: Please adjust ignore list for regressions on m68k John Paul Adrian Glaubitz
  • Re: Bug#1127603: binutils: Please adjust ignore list for regressions on m68k John Paul Adrian Glaubitz
• Bug#1126521: glibc: FTBFS on m68k with gcc-15 John Paul Adrian Glaubitz
• Bug#1125517: libgit2: Consider switching to llhttp again John Paul Adrian Glaubitz
• Bug#1125380: webkit2gtk: Please include patch to disable mustfail property on m68k and sh4 John Paul Adrian Glaubitz
  • Re: Bug#1125380: webkit2gtk: Please include patch to disable mustfail property on m68k and sh4 John Paul Adrian Glaubitz
• Bug#1125347: webkit2gtk: Please build with GCC options to avoid OOM issues on 32-bit targets John Paul Adrian Glaubitz
• Bug#1125101: RM: xpra [armhf i386] -- RoQA; not built since 2023, still depends on pre-t64 libraries Simon McVittie
• [PATCH 0/2] m68k: Add vDSO support for TLS and clock_gettime64 Stefan
  • [PATCH 2/2] m68k: Enable vDSO clock_gettime64 Stefan
  • [PATCH 1/2] m68k: Use vDSO for thread pointer access Stefan
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Florian Weimer
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Stefan Reinauer
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Florian Weimer
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Adhemerval Zanella Netto
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Stefan Reinauer
  • Re: [PATCH 1/2] m68k: Use vDSO for thread pointer access Adhemerval Zanella Netto
  • Re: [PATCH 0/2] m68k: Add vDSO support for TLS and clock_gettime64 Andreas K. Huettel
• Re: Bug#1066890: rdma-core: don't build docs on minor arches (-DNO_MAN_PAGES=1) John Paul Adrian Glaubitz
  • Re: Bug#1066890: rdma-core: don't build docs on minor arches (-DNO_MAN_PAGES=1) John Paul Adrian Glaubitz
  • Re: Bug#1066890: rdma-core: don't build docs on minor arches (-DNO_MAN_PAGES=1) Benjamin Drung
• Contacto Alejandro Sanchez
• Bug#1124228: libavif: Build-depends on libgav1 which build-depends on architecture-is-little-endian John Paul Adrian Glaubitz
  • Re: Bug#1124228: libavif: Build-depends on libgav1 which build-depends on architecture-is-little-endian John Paul Adrian Glaubitz
• Bug#1123577: nmu: mesa_25.2.8-2: +b3 on !amd64 Simon McVittie
• Re: gimp 3 FTBFS on big-endian Jeremy Bícha
  • Re: gimp 3 FTBFS on big-endian Jeremy Bícha
• Bug#1122804: RM: r-cran-blme [armel armhf i386 mipsel] -- ROM; Please remove for 32 bit architectures (architecture-is-64-bit was added to Build-Depends) Andreas Tille
• Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh John Paul Adrian Glaubitz
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh John Paul Adrian Glaubitz
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh John Paul Adrian Glaubitz
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh John Paul Adrian Glaubitz
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
  • Re: Bug#1122336: libreoffice: Smoketest fails on hppa and powerpc due to missing soffice.sh Rene Engelhard
• Bug#1122205: RM: rhonabwy -- ROM; upstream is no longer maintained and depends on obsolete packages, FTBFS with gnutls 3.8.11 Nicolas Mora
• Bug#1121974: python3.13: Please build with -O1 on m68k to workaround interpretor lockups John Paul Adrian Glaubitz
• Bug#1121970: RM: r-cran-freetypeharfbuzz [armel armhf i386 mipsel] -- ROM; Please remove for 32 bit architectures (architecture-is-64-bit was added to Build-Depends) Andreas Tille
• Bug#1121969: python3.14: Please build with -O1 on m68k to workaround interpretor lockups John Paul Adrian Glaubitz
  • Re: Bug#1121969: python3.14: Please build with -O1 on m68k to workaround interpretor lockups Eero Tamminen
  • Re: Bug#1121969: python3.14: Please build with -O1 on m68k to workaround interpretor lockups John Paul Adrian Glaubitz
• Bug#1121780: Please revert 3.13.9 version bump to help m68k Adrian Bunk
  • Re: Bug#1121780: Please revert 3.13.9 version bump to help m68k John Paul Adrian Glaubitz
  • Re: Bug#1121780: Please revert 3.13.9 version bump to help m68k John Paul Adrian Glaubitz
  • Re: Bug#1121780: Please revert 3.13.9 version bump to help m68k Jeffrey Walton
• OMP fixed in the llvm-21 packaging Matthias Klose
• gcc-16, first packaging bits Matthias Klose
• Re: internal compiler error while building sqlite3 for m68k Matthias Klose
• What does the publishing charged? stephanie M.pigg
• Bug#1118058: scipy: m68k fails: sparsetools/bsr.h unable to find a register to spill in class ‘ADDR_REGS’ Drew Parsons
  • Re: Bug#1118058: scipy: m68k fails: sparsetools/bsr.h unable to find a register to spill in class ‘ADDR_REGS’ John Paul Adrian Glaubitz
  • Re: Bug#1118058: scipy: m68k fails: sparsetools/bsr.h unable to find a register to spill in class ‘ADDR_REGS’ Drew Parsons
• Bug#1119819: mesa: FTBFS on alpha, hppa, m68k, sh4: R600 Gallium driver configured to require LLVM Simon McVittie
• Hard Rust requirements from May onward Julian Andres Klode
  • Re: Hard Rust requirements from May onward Jeffrey Walton
  • Re: Hard Rust requirements from May onward Julian Andres Klode
  • Re: Hard Rust requirements from May onward Joerg Jaspert
  • Re: Hard Rust requirements from May onward Julian Andres Klode
  • Re: Hard Rust requirements from May onward Joerg Jaspert
  • Re: Hard Rust requirements from May onward Sean Whitton
  • Re: Hard Rust requirements from May onward Bill Allombert
  • Re: Hard Rust requirements from May onward Jeffrey Walton
  • Re: Hard Rust requirements from May onward Nelson H. F. Beebe
• scpiy m68k build failure Matthias Klose
• Architecture baseline for Forky Bastian Blank
  • Re: Architecture baseline for Forky Tony Rodriguez
  • Re: Architecture baseline for Forky Marco d'Itri
  • Re: Architecture baseline for Forky Jan-Daniel Kaplanski
  • Re: Architecture baseline for Forky Simon Richter
  • Re: Architecture baseline for Forky Tony Rodriguez
  • Re: Architecture baseline for Forky Geert Uytterhoeven
  • Re: Architecture baseline for Forky kiruthikaanbusuresh
  • Re: Architecture baseline for Forky Marcin Juszkiewicz
  • Re: Architecture baseline for Forky Rob Landley
  • Re: Architecture baseline for Forky Marc Haber
  • Re: Architecture baseline for Forky Tony Rodriguez
  • Re: Architecture baseline for Forky Rob Landley
  • Re: Architecture baseline for Forky Aurelien Jarno
  • Re: Architecture baseline for Forky Milan Kupcevic
  • Re: Architecture baseline for Forky Kurt Roeckx
  • Planned obsolescence ? (was: Re: Architecture baseline for Forky) Romain Dolbeau
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Marc Haber
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) John Paul Adrian Glaubitz
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Diederik de Haas
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Marc Haber
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Diederik de Haas
  • Re: Planned obsolescence ? (OpenBSD) jbranso
  • Re: Planned obsolescence ? (OpenBSD) Paul Tagliamonte
  • Re: Planned obsolescence ? (OpenBSD) John David Anglin
  • Re: Planned obsolescence ? (OpenBSD) Philipp Kern
  • Re: Planned obsolescence ? (*BSD, Rust) Jan-Daniel Kaplanski
  • Re: Planned obsolescence ? (*BSD, Rust) David Starner
  • Re: Planned obsolescence ? (*BSD, Rust) Jan-Daniel Kaplanski
  • Re: Planned obsolescence ? (*BSD, Rust) David Starner
  • Re: Planned obsolescence ? (*BSD, Rust) Christopher Huhn
  • Re: Planned obsolescence ? (*BSD, Rust) Riccardo Mottola
  • Re: Planned obsolescence ? (*BSD, Rust) Dr. Arne Babenhauserheide
  • Re: Planned obsolescence ? (*BSD, Rust) Falco Girgis
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) John Paul Adrian Glaubitz
  • AW: Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Jan-Daniel Kaplanski
  • Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky) Marc Haber
  • Re: Planned obsolescence ? Riccardo Mottola
  • Re: Planned obsolescence ? Jaromír Cápík
  • Re: Planned obsolescence ? Riccardo Mottola
  • Re: Architecture baseline for Forky John Klos
  • Re: Architecture baseline for Forky Sicelo
  • Re: Re: Architecture baseline for Forky Hermann . Lauer
  • Re: Re: Architecture baseline for Forky John Klos
  • Re: Architecture baseline for Forky Peter Green
  • Re: Architecture baseline for Forky Lucas Nussbaum
  • Re: Architecture baseline for Forky Holger Levsen
  • Re: Architecture baseline for Forky Adrian Bunk
  • Re: Architecture baseline for Forky Lucas Nussbaum
  • Re: Architecture baseline for Forky Rob Landley
  • Re: Architecture baseline for Forky Gerardo Ballabio
  • Re: Architecture baseline for Forky John Paul Adrian Glaubitz
• Re: Bug#1111823: dupeguru FTBFS on m68k Stefano Rivera
• Bug#1117741: python3.14: Please include patch to fix build with GCC 15 on m68k John Paul Adrian Glaubitz
• quick question Miguel Crovari
• Re: Removing dpkg arch definition for tos-mint? Thorsten Glaser
• qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) Thorsten Glaser
  • Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) John Paul Adrian Glaubitz
  • Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) Michael Tokarev
  • Re: qemu-user viability Thorsten Glaser
  • Re: qemu-user viability Michael Tokarev
  • Re: qemu-user lost its entire viability Thorsten Glaser
  • Re: qemu-user lost its entire viability Michael Tokarev
  • Re: qemu-user lost its entire viability Thorsten Glaser
  • Re: qemu-user lost its entire viability Michael Tokarev
  • Re: qemu-user security trade-offs by dynamic configuration John Scott
  • Re: qemu-user security trade-offs by dynamic configuration Michael Tokarev
  • Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) Bastian Blank
  • Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) Rob Landley
  • Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update) Geert Uytterhoeven
  • Re: qemu-system-sh4eb build has something hinky in the ethernet Philippe Mathieu-Daudé
  • Re: qemu-system-sh4eb build has something hinky in the ethernet Rob Landley
  • 64mb limitation of qemu-system-sh4 board Philippe Mathieu-Daudé
  • Re: 64mb limitation of qemu-system-sh4 board John Paul Adrian Glaubitz
• Re: [PATCH 1/1] hung_task: fix warnings by enforcing alignment on lock structures John Paul Adrian Glaubitz
• Bug#1107416: gcc-14: Please build with -fno-fold-mem-offsets on m68k John Paul Adrian Glaubitz
  • Re: Bug#1107416: gcc-14: Please build with -fno-fold-mem-offsets on m68k John Paul Adrian Glaubitz
• DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux Andreas Schwab
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux Jeff Law
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux Andreas Schwab
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux Andreas Schwab
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux Andreas Schwab
  • Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux John Paul Adrian Glaubitz
• Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jeffrey Walton
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jeffrey Walton
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jason Thorpe
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jean-Michel Hautbois
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jean-Michel Hautbois
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Geert Uytterhoeven
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Anders Magnusson
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Martin Husemann
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Geert Uytterhoeven
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Finn Thain
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Anders Magnusson
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Anders Magnusson
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Klos
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jason Thorpe
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Andreas Schwab
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Jason Thorpe
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Finn Thain
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Finn Thain
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k Martin Husemann
  • Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k John Paul Adrian Glaubitz

• Earlier messages