Re: The future of an SCC that has been given up on
schmitz dixit:
> Regarding bug tracking, I fully support your proposal to ask LP for help with a
> solution.
OK.
> 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.
> For all of you that have followed linux-m68k, you will have seen a huge amount
> of activity related to merging coldfire MMU and generic MMU code on the kernel
Yeah, m68k has been pretty active on the Linux kernel side, and CF
on the GCC side.
> 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.
> 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.
> 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
> 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.
> 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).
> 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).
> 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.
Does dpo support autosigning in buildds nowadays, btw? That would
remove the need to inspect maybe-succeeded builds, in most cases.
> This time next year is the earliest I can look at spending time on
> m68k autobuilding.)
OK.
> 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.)
bye,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
Reply to: