Re: The future of an SCC that has been given up on
Thorsten,
> > I fear I don't get your point about arch: any packages and automated builds.
> > What exactly is the problem?
>
> Packages like emile that build for all architectures, so you can build
> e.g. bootable Mac CDs on i386. But maybe LP can do that for us.
I still don't get it - such packages should be submitted to Debian as wishlist
packages for inclusion, from there it's all taken care of, no?
> > side. As far as the userland side is concerned, I remember TLS support being
> > suggested as solution to support generic m68k and coldfire binaries. Your work
> > on TLS would mean that is at least withing reach now?
>
> Uhm, I don’t know what you mean here. Debian/m68k currently uses TLS
> via SYS_333 syscalls.
And CF uses something different?
As I recall it, TLS (in particular VDSOs) were touted as a way of creating a
uniform userland across m68k and CF. Ignore me if I'm wrong.
> > As for setting up autobuilders using sbuild and buildd - while I am sure that
> > can be done both on emulated hardware and real hardware, the core problem for
> > bootstrapping a port with a huge lot of the archive unbuilt is the build
> > database.
>
> Yes, it contains too many “unimportant” packages up first. But still,
> just letting builds churn them would help.
Creating a sub-list of important stuff that is holding back major portions would
be preferred (IIRC Stephen did use to provide that).
> > By far the most annoying thing about buildd used to be packages
> > failing to build because the build dependencies were uninstallable.
>
> That is figured out automatically, AFAICS.
>
> > Finding out which build dependency was at fault was a time consuming
> > manual process that could only be carried out post-mortem on an idle
> > autobuilder.
>
> Ah. But that’s a “was” and “could”. There’s a tool called edos-debcheck
> which you feed a Packages file (or rather, a concatenation of the two
> Packages files from unstable and unreleased), and it gives very detailed
> reasoning for uninstallability of packages. It’s also the tool I use to
> keep the subset of Debian packages in my repository without uninstallabi-
> lities (except for a small set of packages which I “fudge”, i.e. pretend
> they’re there, by copying their records (sans Depends) from unstable),
> see: https://www.freewrt.org/~tg/debs68k/edos-fudge.sid
That's good to have - I wasn't aware of that.
> > Sorting of build priorities based on availability of depencencies was
> > suggested as a solution to this problem, but as long as I has to do
> > with autobuilders this was never solved.
>
> Really? From what I can see on buildd.d.o and buildd.d-p.o this is done.
> Packages with B-D uninstallable as judged by wanna-build aren’t even
> tried.
Packages are only flagged dep-wait by the appropriate log reply to buildd (last
I dealt with it). Manually editing package state was extremely awkward. We
cannot afford trying every package just to find out that 60% are not buildable
because of broken or uninstallable dependencies. Most notably because about 10%
of these attempts will leave the chroot in a broken state in need of manual
cleanup.
I'm sure I'm slighlty exaggerating here but I hope you catch my drift.
> > Unless that problem is tackled I don't see much point in setting up
> > autobuilders.
>
> Even so, there’s a point. People can throw packages at them manually
> and let those be built automatically. Not much difference from
> cowbuilder, except it uses the formal process, and build logs would
> finally end up being uploaded (I *still* wait for people to tell me
> how I can upload those my cowbuilder generates).
The 'throw packages at them manually' would imply a w-b database of some sorts,
wouldn't it?
Uploading logs should be as easy as setting up a mail server to archive them, at
least that's what we used to do.
Uploading the packages to d-p.org should still work I hope.
> > Keeping an up-to-date baseline package list for the build chroots is a crucial
> > requirement for all the above, of course.
>
> No problem there, that’s exactly what I do in my freewrt.org hosted
> APT repository. Baseline plus these uploaded but not yet processed
> by a mini-dak run on leda (d-p.org).
Yep, I've seen that, and kudos to you for that. That makes restarting a whole
lot easier.
> > But these autobuilders need somebody to inspect build logs, sign
> > package uploads and such.
>
> I *think* Wouter *may* have volunteered for that. Maybe whoever else
> used to do that.
Not many of us left I fear.
> Does dpo support autosigning in buildds nowadays, btw? That would
> remove the need to inspect maybe-succeeded builds, in most cases.
I don't know - autosigning (at least semiautomatic) was never the major holdup.
I still have script extracting the changes file from the mail stream and mailing
have either crashed or are unreadable now under kernel 3.4 so I'd have to start
from scratch.
> > This time next year is the earliest I can look at spending time on
> > m68k autobuilding.)
>
> OK.
I'll try to make it earlier depending on the building schedule.
> > For the present, trying to keep up with Geert's pace of kernel
> > releases and merging my Atari patches is all I can cope with, sorry.
>
> That’s important work as well. If you can get everything needed into
> the stock 3.2 stable series as maintained by Ben Hutchings, even better.
> Because that’s what I’ll live with until wheezy is released and sid is
> unfrozen thereafter. We’re talking second half of 2013, I guess. Luckily
> the current Debian kernel is very usable except for lack of EtherNEC/NAT
> drivers on a real-iron Atari, as reported by ragnar76. (But my repo’s
> got a Debian 3.2.6 based kernel beefed up with v3.2-m68k patches, as
> binaries, for all six usual architectures.)
I've just pushed out my 3.4 patches to linux-m68k. The EtherNAT patches should
apply to 3.2 with a minimum of work. The obsolete old EtherNEC one likewise -
the new (mainstream ne.c based) one I'm not so certain about; I'll have to check
that. You may have most of my patches already in the v3.2-m68k patch series.
I'll look into what's missing (does anyone at the Debian kernel team maintain a
git repository with all the Debian patches as separate commits on top of
whatever the base release branch in 3.2 would be? That would save a lot of
manual patch/commit work ...).
Cheers,
Michael
Reply to: