Re: The future of an SCC that has been given up on
Thorsten,
But CF was touted as the way out in relation to the 'you can still buy the
hardware' rule. Efforts were underway to unify the CF user space and Debian. I
might have misunderstood though.
I understood the same, but I’ve yet to see those efforts.
Or realise I’ve seen them if I did.
As Finn pointed out, the idea of compatibility binaries is self
defeating and won't happen. Fair enough.
As Geert has mentioned, X lacks support for the Atari abd Amiga frame buffer
data formats.
Oh, and the kernel lacks support for radeonfb on the Atari ;-)
In fact, when booting on an Atari with a PCI Radeon it doesn’t
display anything at all. ;-)
That's possible - I don't think I paid much attention to the atafb
'external' framebuffer variants. Not sure these would work in your case
- and I've not ever looked at radeonfb from an Atari perspective. Didn't
even know there is Atari support in there.
I cannot work on drivers where I don't have the hardware myself. The
patches for NetUSBee USB support are a one-off result of the EtherNAT
USB patches - if they work, good. If they don't, over to those that can
test them.
But really, getting output from an X server onto the screen is
absolutely not the point here, since I was talking about build-
and runtime-dependencies.
So there are non-X packages that depend on X as build dependencies? Odd ...
Might just run with loads of swapping but not really useful.
Again, useful for whom. This thread had the context of build-
depends, not of actual graphical usability of the X server.
(And, nowadays, way too much depends on X libraries at the
very least. Think cmake. I got them installable with a few
pinnings right now, but once rebuilding them is started, it
needs to be finished before we can continue building anything
depending on X, or anything depending on something run-time
depending on X.)
I begin to understand the nightmare. X will have to be built then. I'll
look at a edos-builddebcheck run on the m68k packages list.
I presume you do have ssh access to the w-b running on d-p.org, of course.
Not yet, but Aurélien said I could get that. Right now, I don’t bother
with it.
Once more than one person starts building packages, w-b helps keeping
organized.
Since we are going to use our own w-b for the forseeable future, a --hold could
be added that will ignore future versions as well.
Thanks for this lesson in w-b ;-) this is all new for me.
My pleasure.
edos-builddebcheck does make things easier but it would need to be run in
concert with w-b. That could help a lot. Otherwise, it sure looks like what I
knew and hated five years ago.
I’d hate that too. Let’s hope someone already figured that out.
Still waiting for someone else to pipe up.
You still need to know _what_ packages to
throw at it that have a more than even chance of succeeding.
Yes, but that’s what I’ve been doing for some… ugh, already two years?
It would at least ensure the machines don’t idle ☺
Granted - it does work well if you don't start scaling up the number of
build hosts.
And if you’ve got time to spare, disable nocheck from DEB_BUILD_OPTIONS
and let them run the testsuites.
That option is news to me - running testsuites used to be mandatory.
KISS. Mail no longer being a viable option sucks whales through nanotubes but
don't switch to something that sucks whales through monoatomic layers. We want
something that makes it easy to add new build hosts without extensive key
exchange. The requirement for package signing keys is enough of a hassle really.
SSH keys are not a problem. Trying to get a 10 MiB build log sent by
eMail is a problem, even if eMail in general works.
I was wondering about build logs exclusively here, though.
Yep, that's a bit excessive for mail.
Uploading the packages to d-p.org should still work I hope.
That’s what I’m doing all the time.
What protocol does that use?
This one: http://wooledge.org:8000/FtpMustDie
Doesn't seem to specify the protocol clearly. Yes, I know FTP sucks. But
what's the simple alternative for anonymous uploads?
We could possibly upload logs the same way
Not unless they’re PGP signed and… ugh, no, please, no more FTP.
It should have been long dead.
I’d be in favour of something like this:
ssh -C -l user logpickupbox 'logpickupcommand' <foo_1.2-3_m68k.build
The logpickupcommand would then move them someplace.
dupload used to have a ssh upload queue option. Even a rsync over ssh
one. If we use either, I don't see the need for signed log files.
I can only test on one particular variant of Atari. Hardly any of the
interesting bits are in Linus' tree yet. Unless the kernel team is willing to
pull patches from the m68k tree, I don't think it will be easy.
Mh. Try to get them into Linus’ tree first. That makes things so much
easier in Debian. (And the patches as applied to 3.2 need not be the
same as submitted to Linus, only do the same…)
I have to convince Paul Gortmaker that my solution to use the EtherNEC
(which does not have an interrupt) is better than using generic netpoll
(which I have been unable to get working on any setup). Didn't manage to
convince him last I tried.
matching baseline vanilla git checkout, adding one commit per patch, and then
One commit per patch is a lot of work ;-)
But it allows cherry picking only those needed using the list of patches
from the build config. I may be off base there.
about it a bit. Anyway, if the kernel team does not want to acceot patches
outside Linus' tree the whole thing is pointless and I'll set up a git server
for the Atari branch somewhere.
No it isn’t – it just tells you to get your (and Geert’s) focus on
getting things submitted to Linus. Isn’t the 3.5 merge window open
by now? Whatever he accepts you can get into Debian.
See above - it's not that easy. I'll try again but it won't be in 3.5.
Maybe the EtherNAT (smc91x) is going to be less controversial.
You can bet that it's my priority to get patches merged upstream. We'd
still use the old EtherNAT and EtherNEC code otherwise.
And kernels not built from stock Debian source will always be less
useful. (Also think of packages like linux-libc-dev; any new defi-
nitions you add to header files will not be available inside Debian.)
Can't see me tampering with header files in a way that has an effect on
libc-dev.
I'll give that a shot - in fact I'll install that one on my Falcon now :-)
Have fun!
I'll have to install a lot of stuff still to make it bootable - that'll
have to wait. But it definitely is a good start. I'm sure it will serve
as chroot just fine.
Cheers,
Michael
Reply to: