Re: The future of an SCC that has been given up on
Michael Schmitz dixit:
>> There is no Debian/m68k on CF ;-)
>
>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.
>> >Creating a sub-list of important stuff that is holding back major portions would
>> >be preferred (IIRC Stephen did use to provide that).
>>
>> Right now, that’s one thing: X.org (and subsequently, the whole shit
>> fd.org/gnome stack). I’ve done everything else keeping us back manually.
>
>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. ;-)
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.
>While I think X could be built (sorting out the correct build order of
>all pieces up front) I doubt it will be useful before the frame buffer
>support has been readded.
Useful for whom? I “just” need the whole X set *except* the
server. And xvfb. (Besides, ssh with X forwarding is also
useful. And, for now, you could, say, run one of the old
XFree86® servers, if you really want graphical output, if
the x.org stuff doesn’t work. This is *really* not a problem
for the buildds, though.)
>Even then - I have maxed out my Falcon with 512 MB RAM
>and that won't nearly be enough for a modern desktop system.
My laptop’s not got much more. (But then, my modern desktop
system usually comprises of evilwm or icewm, some xterms,
GNU screen, sirc, lynx, pine, ssh, and the occasional GUI
webbrowser if really needed.)
>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.)
>> Ah. While at it, I’d like to get a way to tell W-B to take its hands
>> off certain packages, e.g. while I’m building them, or while there’s
>
>w-b --take (IIRC). Then just sit on it (while building or not). If you really
>want to push it, run a cron job to take new versions as they appear (overriding
>other takers as needed).
OK, thanks.
>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.
>Same - though you could set those ones not-for-us as well (and clear that state
>once the patches are in).
Ah right, that makes sense.
>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.
>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.
>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 ☺
And if you’ve got time to spare, disable nocheck from DEB_BUILD_OPTIONS
and let them run the testsuites.
>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.
>> >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
>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.
>My solution was pine specific.
;-)
Still, the sheer size of such mails is an issue.
>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…)
>One release branch per architecture
Think four.
>rebasing each branch after fetch and merging cherry-picked commits
Not really. Most patches are shared between those. But whatever,
this isn’t our responsibility. I treat the things Debian does to
the Linux kernel as one big commit on top of the vanilla kernel
whenever I have to do patchwork with that. This WFM.
>matching baseline vanilla git checkout, adding one commit per patch, and then
One commit per patch is a lot of work ;-)
>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.
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.)
>> >> Some time ago (last year or so?) I converted vivaldi and arrakis to use the
>> >> newer kernels. Maybe I should do some upgrade again, but basically these
>> >> machines are running for some time now without doing actual work as a
>>
>> Which kernels are they running?
>
>Ingo's machines? Some recent 3.2 Debian release kernel IIRC.
Well that’s good then, no need to upgrade them again then ;)
>I'll give that a shot - in fact I'll install that one on my Falcon now :-)
Have fun!
>Again, I will not have much time for any of this in the near future. I'll check
>back in September or so; by then I should have a good overview how hectic the
>next year will be.
OK.
Finn Thain dixit:
>Yet you can buy new FPGA hardware and run a soft-core 68020! That kind of
>new hardware is easy to find.
How fast would that be? Are there sort-of off-the-shelf solutions
with that, i.e. adding support peripherals (keyboard and graphics
or serial console, network, disc/compactflash)?
>If new CF hardware was common, and justified release-architecture status,
>there would be real demand for an archive of un-compromised, CF-native
>packages (instead of compromised hybrid binaries).
What exactly are you talking about when you say hybrid binaries?
In my world, that’s a term for the Mach-O “fat binaries” that
contain two versions of a thing. Aren’t you meaning generic or
common-subset?
>So the hybrid approach is a long term prospect if and only if CF never
>becomes common enough to justify a CF-native port.
Yes. But you underestimate the work to make a new port here,
as well as the masses that would rather stick to the 680x0 port,
and (according to what was said earlier) overestimate the CF gain
when in fact the 680x0 are those that would benefit from optimisation.
On the other hand, there’s always the option to rebuild a Debian
release (ONCE WE HAVE ONE) as flavoured build, with other compiler
options. That’d be a very usable way, keep the regular Debian sid
(including testing and the-next-stable) generic and offer flavoured
full-archive rebuilds of formal releases to those interested.
>In other words, the hybrid strategy bets against CF -- whilst
>simultaneously claiming CF hardware justifies release-arch status!?
I don’t think that’s taking all aspects into account.
I had hoped for release in wheezy+1 without even taking CF into
account, but I can’t do something like that by myself, and, the
climate for non-mainstream architectures in general doesn’t look
so good lately.
bye,
//mirabilos – not interested in a Coldfire flamewar, tyvm
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallooooo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooooooohhh"). [aus dasr]
Reply to: