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
