loongarch64, m68k and
sh4.
Would it be possible to package a git snapshot for experimental to be able to
test
these changes? I'm asking since it seems it will still be a long way until
upstream
releases version 2.6.0.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :'
be removed
> from armel.
That sounds a little too drastic to me. I think we should do a little more
investigation to figure out what the actual underlying issue is. Maybe
openal can be configured differently on armel and sh4.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debi
- x32 (has a Rust port, but currently broken)
Please disable python3-orjson on these architectures (similar to i386),
so that mypy can be built again on these architectures.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-
when we
switch the m68k port to 4-byte alignment.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: python3.13-3.13.0/Inc
On Wed, 2024-11-13 at 15:14 +0100, John Paul Adrian Glaubitz wrote:
> does anyone have a solution on how to fix Python 3.13 with 2-byte alignment?
This is the backtrace:
(gdb) r
Starting program:
/home/glaubitz/python3.13-3.13.0/build-static/_bootstrap_python
../Programs/_freeze_module.py
l testing and
> bugfixing (which often requires hardware, not emulators).
I don't buy this argument. Why would your world fall apart if we switch
alignment to 4 bytes. I seriously don't get it.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
no more than 36 MiB, will be able to continue running, not
> just Amigas that have 256 MiB memory. If we're headed toward Linux
> distributions that can only run well enough in QEMU or Aranym, what's
> the point in having old systems at all?
First of all, you can still and will always be able to build yourself a tiny
chroot using Buildroot or Toybox. And, secondly, what's the point of running
the latest and greatest kernel on a system which can't make use of any modern
kernel features anyway?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Wed, 2024-11-13 at 20:55 +0100, John Paul Adrian Glaubitz wrote:
> > Sure, you do pretty much all the work on Debian/68k, so you get to decide.
> >
> > If this involves changes at kernel level (syscall parameter alignment?)
> > however, my recommendation would be to r
e m68k port is to embrace Rust and not to try to fight it. We cannot win such
a
fight.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
fault) - core dumped
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
Segmentation fault
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
so you can expect the same
problems there as well.
> 3) among all 680x0 developers interested in the NetBSD ABI
The alignment issue affects NetBSD as well.
> 4) among all users of EOL'd hardware, so that value may continue to be
>extracted from it (thanks to the efforts of Debia
elp with an ABI change.
Thanks, I will then just do it myself with brute force or drop the port.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Python and golang, I'll do what I can to help.
I honestly don't have to justify myself towards you. I will use the Christmas
holidays to make a decision. I will either drop the m68k port from Debian or
just perform a forced switch.
I don't care anymore what you're posting here. Y
On Mon, 2024-10-28 at 19:44 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > > For Debian, we have superh and i386, out of these. It is entirely
> > > possible that Qt et al. can work with this, but these all have natural
> > &
On Mon, 2024-10-28 at 19:40 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > What ecosystem? Do you honestly care that any hobbyist cares about
> > having to reinstall their retro computers?
> >
>
> The issue is not just o
On Mon, 2024-10-28 at 19:29 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > >
> > > That seems to imply that someone requires that those packages are
> > > ported. But without a bug report from such a user, to say the pa
ts/2024-11-11/
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085949
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
sufficient
> > explicit padding? Has anyone looked at this?
>
> Already basic things like struct stat64 will break.
Chewi made it to work with a minimal patch in glibc:
> https://marc.info/?l=glibc-help&m=169303990426196&w=2
Adrian
--
.''`. John Paul A
ignment patches to upstream projects.
Upstream projects do not take patches which fix code on m68k. They don't care.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
h
> the other “what parts of the toolchain need changing” and
> whether GCC can be switched with little effort.
Did you see how Chewi implemented 32-bit alignment? He actually didn't
use -malign-int but directly patched GCC itself, see:
> https://marc.info/?l=glibc-help&m=169303990426196&w=2
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
e 32-bit architectures that use a natural 8-byte
> alignment are
>
> arm (EABI)
> parisc
> mips
> powerpc
> riscv
> s390
> sparc
> xtensa
>
> m68k is the only architecture supported by linux-6.x that
> does 2-byte alignment, otherwise the two seem to be equ
; SPARC or so.)
>
> > Q. What is the size of this struct, assuming baa.b is naturally aligned?
> >
> > struct baa {
> > int a;
> > long long b;
> > };
>
> For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
> More
tginfo1 {
> struct xt_conntrack_mtinfo2 {
> struct xt_conntrack_mtinfo3 {
> struct xt_entry_match {
> struct xt_entry_target {
> struct xt_error_target {
> struct xt_esp {
> struct xt_helper_info {
> struct xt_hmark_info {
> struct xt_ipcomp {
> struct xt_iprange_mtinfo {
> struct xt_mac_info {
> struct xt_mark_mtinfo1 {
> struct xt_owner_match_info {
> struct xt_realm_info {
> struct xt_secmark_target_info {
> struct xt_secmark_target_info_v1 {
> struct xt_set_info_match_v0 {
> struct xt_set_info_match_v3 {
> struct xt_set_info_target_v0 {
> struct xt_set_info_v0 {
> struct xt_time_info {
> struct xt_tproxy_target_info {
> struct xt_tproxy_target_info_v1 {
> struct xt_u32 {
> struct xt_u32_location_element {
> struct xt_u32_test {
> union __sifields {
> union ethtool_flow_union {
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
; struct definition to be qualified with an explicit data model.
This is a pure academic discussion and not leading anywhere.
Adrian
> > >
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
So natural alignment is portable if you first assume a data model. But the
> struct definition itself is not portable, since it doesn't specify a data
> model.
>
> > More importantly, and relevant for Qt, struct baa is also 8-byte
> > aligned...
> >
>
> If t
t;
> Q. What is the size of this struct, assuming baa.b is naturally aligned?
>
> struct baa {
> int a;
> long long b;
> };
We're dealing with today's software and not something that exists in 50 years.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
become a requirement
> these days, and m68k is the only true outlyer (i386 could in theory, but
> the Unix psABI designers were sensible enough to not do it).
Agreed.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ill just require removing that check.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
effort on patching only those packages that are really required.
Thanks, but I tried that and it doesn't work. I don't want to continue spending
hours on trying to figure out how to fix alignment problems and then maybe send
an email here and there to just never get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 2024-10-25 at 23:38 +0200, Thorsten Glaser wrote:
> On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > as m68k has supported 32-bit alignment through the "-malign-int"
> > switch for a long time.
>
> That switch constitutes a fundamental A
doesn't change the
fact that this is blocking a lot of software now, unfortunately.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
is in practice.
Users with very slow hardware and without accelerators aren't
going to run a modern kernel anyway, so this argument is moot.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 2024-10-25 at 20:06 +1100, Finn Thain wrote:
> On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > the m68k port has reached the point where switching the default
> > alignment from 16-bit to 32-bit is inevitable as the number of packages
> > affected
on to
clean
up the kernel ABI by removing old syscalls and switch the kernel to asm-generic
which
is why I have included Arnd Bergmann in the CC list.
Please join #gentoo-m68k on Libera if you want to discuss this issue.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :'
And, hopefully, these kind of kludges won't be necessary anymore in the
foreseeable
future.
> Thanks for your help !
No, thank you for your kind words and offer!
Adrian
> [1] https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html
--
.''`. John Paul Adrian Glaubitz
: :&#x
specifiers for signed hexadecimal and octal values, unlike for
> decimal values ("%u" vs. "%d").
OK, so if the numbers are never supposed to be negative, then the variables
should
be declared as unsigned in the first place. I would avoid casting the types as
this can o
ge,
make sure to test build on both 32- and 64-bit systems as well as little- and
big-
endian.
I would recommend to test on powerpc and ppc64 (perotto.debian.net) and
barriere.debian.org
(i386 and amd64).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
tracked upstream [1], I'm
just reporting this bug to raise more awareness and help track the issue within
Debian.
Thanks,
Adrian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-
ister pin and launched a build, and it goes past the
> problematic point. We'll see how it goes...
Were you able to complete the build successfully on m68k?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ink A5 is the register that is used for TLS but
Andreas or Geert need to correct me.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
g:
>
>fprintf(stderr, "&caml_state = %p\n", &caml_state);
>
> before the goto and after the "Instruct(BRANCH):".
Hmm, I guess then maybe Andreas Schwab or Geert Uytterhoeven might have an idea
what
the problem with the TLS variable is. I'll CC both.
Adria
Hi Stéphane,
On Wed, 2024-06-19 at 12:37 +0200, Stéphane Glondu wrote:
> Le 19/06/2024 à 09:06, John Paul Adrian Glaubitz a écrit :
> > > To reproduce the problem quickly:
> > > - unpack ocaml 5.2.0 source package
> > > - ./configure --enable-imprecise-c99-fl
ake sure it's not related to the QEMU build environment on the buildds?
If it turns out to be a QEMU bug, we need to report it there instead.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi,
On Sat, 2023-08-26 at 12:51 +0200, John Paul Adrian Glaubitz wrote:
> > The Debian m68k maintainers proposed building their packages with
> > -malign-int
> > last year, aligning to 32-bit instead of 16-bit, which improves
> > compatibility
> > with some p
On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote:
> Hi,
>
> [John Paul Adrian Glaubitz 2020-05-10]
> > I would like to adopt this package. There is a new upstream available and
> > the
> > repository has been moved to Github with some recent activity [1].
-exec:
dh_install \
-Nfdisk-udeb -Nlibblkid1-udeb \
-Nlibfdisk1-udeb -Nlibsmartcols1-udeb -Nlibuuid1-udeb \
-Nutil-linux-udeb
dh_install: warning: Cannot find (any matches for) "usr/bin/enosys" (tried in
., debian/tmp)
Thanks,
Adrian
--
.''`.
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
: :'
rimental and must be passed via
> LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
>
> Please do so ;-) I guess.
Unless we switch to 32-bit alignment, LLVM won't build natively on m68k :-(.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Phys
Hello,
On Mon, 2024-01-29 at 23:41 +, Alberto Garcia wrote:
> On Mon, Jan 29, 2024 at 11:57:31PM +0100, John Paul Adrian Glaubitz wrote:
> > src:webkit2gtk is currently BD-Uninstallable on m68k [1] since
> > libseccomp is currently not available yet.
>
> I guess that the
h4. I assume this also
applies to the build dependencies bubblewrap and xdg-dbus-proxy.
Adrian
> [1] https://buildd.debian.org/status/package.php?p=webkit2gtk&suite=sid
> [2] https://github.com/seccomp/libseccomp/pull/397
--
.''`. John Paul Adrian Glaubitz
: :' : Debi
s for powerpc, ppc64 and sparc64, I
haven't had time for m68k yet since I am currently trying to rebootstrap
ghc for m68k.
I will build and upload fpc for m68k as soon as possible. No need to do
anything.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
Hello!
On Sat, 2023-10-14 at 16:37 +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On Sat, 2023-10-14 at 17:33 +0300, Ilias Tsitsimpis wrote:
> > As a side note, I believe the attached patch is wrong, it changes the
> > semantics of the functions. Notice that __sync
Hi!
On Sat, 2023-10-14 at 17:33 +0300, Ilias Tsitsimpis wrote:
> As a side note, I believe the attached patch is wrong, it changes the
> semantics of the functions. Notice that __sync_val_compare_and_swap()
> returns the initial value of the variable x, whereas
> __atomic_compare_exchange() return
Hello!
On Fri, 2023-09-22 at 09:20 +0200, John Paul Adrian Glaubitz wrote:
> The attached patch fixes the issue for me. The underlying problem is
> the use of legacy atomic functions for which no 64-bit variants exist
> on some architectures [1]. See also the upstream discussio
On Wed, 2023-09-27 at 22:00 +0300, Ilias Tsitsimpis wrote:
> On Fri, Sep 22, 2023 at 09:20AM, John Paul Adrian Glaubitz wrote:
> > The attached patch fixes the issue for me. The underlying problem is
> > the use of legacy atomic functions for which no 64-bit variants ex
build later
fails due to memory exhaustion for which I haven't found a solution
yet.
Thanks,
Adrian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23974
--
.''`. John Paul Adrian Glaubitz
: :' : Debian D
tures mentioned above?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
upstream [1].
Thanks,
Adrian
> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23974
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, 2023-08-28 at 14:29 +0100, James Le Cuirot wrote:
> On Mon, 2023-08-28 at 14:50 +0200, John Paul Adrian Glaubitz wrote:
> > Hi Adhemerval!
> >
> > On Mon, 2023-08-28 at 09:44 -0300, Adhemerval Zanella Netto wrote:
> > > If the idea is really to endeavor on
On Mon, 2023-08-28 at 15:17 +0200, Andreas Schwab wrote:
> On Aug 28 2023, John Paul Adrian Glaubitz wrote:
>
> > The FP failures are most likely the result of the limitations of the FPU
> > emulation
> > in QEMU for m68k. ARAnyM is known to have much better FPU emu
ifferent ABIs that fails to be fully interoperable; but
> I think that if you really want to on this 'gnu32' journey, I think it will be
> better to just deprecate the m68k current ABI, remove it from glibc; and move
> everything to new ABI.
I actually wouldn't have a problem with
On Mon, 2023-08-28 at 12:11 +, Richard wrote:
>
> On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz
> wrote:
> > On Sat, 2023-08-26 at 19:24 +, Richard wrote:
> > > > Not only mold but also most notably the following projects:
> > >
leave the problem to the distros
> > and toolchain developers".
>
> Indeed, the world is slowly turning into "everything is 64-bit little
> endian"...
Well, if we want to prevent that to happen in the future, we should make sure
that
the m68k port is prepared
al shortcomings
> with the existing ABI, including problems which (for all I know) may have
> entirely prevented some people from using it thus far. That is, it should
> consider silicon beyond 680x0.
It's a historic architecture. We don't have to redesign everything. It's enough
to address the most pressing issues and these are 16-bit alignment and 32-bit
time_t.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ics kernel ABIs have been since long pretty
> carefully
> designed to avoid this problems and noone of the mentioned examples should
> touch them anyway.
>
> Thus.. is there any need to change the kernel ABI?
I don't think this mandates changes to the kernel ABI.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
x27;t remember if I also built the Linux kernel
> with -malign-int. Does it need to match? Presumably it would at least give the
> same kind of performance benefit?
I cannot comment on this at the moment, so let's wait for the more experienced
m68k kernel and toolchain folks to chime in.
> Thanks for helping to keep m68k alive.
Thank you, too, and thanks for getting this rolling!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
s.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> [3]
> https://salsa.debian.org/kernel-team/kernel-team/-/tree/master/utils/kconfigeditor2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Carlos!
On Wed, 2023-06-07 at 09:30 +0200, John Paul Adrian Glaubitz wrote:
> On Tue, 2023-06-06 at 21:26 +, Carlos Milán Figueredo wrote:
> > Thanks for the work with the new snapshosts! Is there any update to the
> > Debian Installer images for Amiga? hd-media doesn&#x
nitely be properly tested. We don't gain anything if a
package builds find but doesn't work well for most users.
Adrian
> [1] https://github.com/aranym/aranym/issues/103#issuecomment-1593666173
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
x27;t pass its testsuite on the other architectures?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
changed with OpenJDK 19
which is why we need to move the m68k version sizes-32-linux-m68k.txt as well.
I have done that for the patch m68k-support.diff, so the patch just needs to
be updated in debian/patches to fix the FTBFS of openjdk-19 and newer on m68k.
Thanks,
Adrian
--
.''`.
now the kernel version that the installer uses.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Martin!
On Tue, 2023-06-13 at 09:20 +0200, Martin Steigerwald wrote:
> John Paul Adrian Glaubitz - 13.06.23, 08:47:11 CEST:
> > I was wondering what the current status of the affs driver in the
> > kernel is, did it receive the fixes that Michael(?) was working on? I
> > v
drian
> [1] https://github.com/cnvogelg/amitools
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
e else on this list can remember.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
; [2] https://marc.info/?l=linux-m68k&m=133888043312812&w=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
used
with the NETINST CD image), loads additional kernel modules from the mirror
unlike the NETINST CD image which ships all these files on the CD.
The network installer can only ever work properly when used with a static
archive mirror that you find in stable or partially testing distribution
hared-modules
> new file mode 100644
> index ..cc84b14dcd10
> --- /dev/null
> +++ b/debian/installer/modules/m68k-virt/nic-shared-modules
> @@ -0,0 +1 @@
> +#include
> diff --git a/debian/installer/modules/m68k-virt/ppp-modules
> b/debian/installer/modules/m68k-virt/ppp-modu
Hello Michael!
> On Jun 12, 2023, at 6:43 AM, Michael Schmitz wrote:
>
> Hi Carlos,
>
>> Am 10.06.2023 um 06:29 schrieb Carlos Milán Figueredo:
>> From: John Paul Adrian Glaubitz
>> Sent: Wednesday, June 7, 2023 9:30
>> Subject: Re: Updated installatio
> On Jun 9, 2023, at 11:04 PM, Carlos Milán Figueredo
> wrote:
>
> From: John Paul Adrian Glaubitz
> Sent: Wednesday, June 7, 2023 9:30
> Subject: Re: Updated installation images for Debian Ports 2023-06-06
>
> Hi Adrian,
>
>> Right, this completely
d debian-installer component
- updated core packages
- updated archive GPG keyring
If you want to learn about what's new for Debian Bookworm, see:
> https://wiki.debian.org/NewInBookworm
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physic
n Bookworm, I
cannot commit anything.
Laurent Vivier has also prepared some improvements for qemu-virt which we had to
shelf until after the Bookworm release.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hello!
I have created updated installation images for Debian Ports.
These can be found here:
- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/
I have already successfully tested the sparc64 installer.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : D
pendent parts of later GCC
> versions favor more modern CPUs with larger caches and more RAM in
> general, than typical m68k machines have.)
>
> I.e. newer GCC versions are useful for MiNT mainly due to their support
> for newer C++ versions.
Yes, indeed.
Adrian
--
.&#x
Hello!
On Tue, 2023-05-23 at 11:11 -0600, Stan Johnson wrote:
> On 5/23/23 11:05 AM, John Paul Adrian Glaubitz wrote:
> > ...
> >
> > We don't have any specific patches but we're building our packages using
> > qemu-user and not qemu-system which
68k:
> https://www.youtube.com/watch?v=s_ve0bCC9q4
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
VM which both support the m68k architecture
these days.
Adrian
> [1] http://snapshot.debian.org/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
td.html
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
rsion of libseccomp has been released.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
get/M68k/M68kExpandPseudo.cpp#L245
> [3] https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html
> [4] https://clang.llvm.org/docs/ClangCommandLineReference.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
any !kfreebsd-any],
xdg-dbus-proxy [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
libseccomp-dev [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : De
sion of
the TeX Live distribution.
I will spread the news!
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ful even though I still
> can't code worth a bean.
Not sure whether I can follow: PearPC running on m68k?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
which makes the build fail due to
incorrect
alignment. This issue will be addressed in a different manner hopefully
soon
by switching the default alignment on m68k to 32 bits.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
>
> Running memtest could incur a boot delay but AFAIR that isn't enabled by
> default, and it isn't implicated in the panic log Adrian posted.
I don't have time this weekend to bisect the issue. But I think, I can start
bisecting it on Sunday evening. I will give it a
p symbols in a non-debug kernel?
> I do recall recent changes to the mm code, but that was for NOMMU. I
> wonder whether there was anything else that would introduce an implicit
> assumption about memory starting at 0x0 ...
Sounds like a possible culprit.
Adrian
--
.''`
really should start booting on real Amiga hardware again...
You should ;-).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
rk is 5.10.5.
FWIW, I noticed that the kernel image itself is already over 7 MB, not sure
whether this is a problem.
Anyone else tried a recent kernel on their Amigas?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75
ersistent-template-dev,
Thus, I would suggest removing the white-list and enabling the build
dependencies
for all architectures.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 2023-02-17 at 10:09 -0700, Stan Johnson wrote:
> Would downloading the source from an x86 repository be sufficient, ...?
Yes, there is no architecture-specific source code repository.
Use:
deb-src http://ftp.debian.org/debian/ unstable main
Adrian
--
.''`. John Paul Ad
1 - 100 of 1310 matches
Mail list logo
