Michael Schmitz dixit: >> 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?
No, since Debian no longer accepts packages that are only of use only to m68k users (even if those packages are run on !m68k systems), if they have other issues (like needing a special toolchain to build, or build their arch:all part only on m68k, i.e. aranym would be kept). >> Uhm, I don’t know what you mean here. Debian/m68k currently uses TLS >> via SYS_333 syscalls. > >And CF uses something different? There is no Debian/m68k on CF ;-) >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. VDSO ≠ TLS But yes, a VDSO could solve a whole heck of issues (things like, using the right cmpxchg sequence, which CPU flavour do we run on?, fast lookup of the TLS map base, oh and, classical, fast time). >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. >Packages are only flagged dep-wait by the appropriate log reply to buildd >(last >I dealt with it). Could you please check if that is still so? At least on stock Debian, I believe otherwise. We might need to invest some into d-p.org infra- structure, but the main archive looks like it has what’s cool. >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. Right. Can such edit process be automated? Possibly hack something with edos-debcheck. (Of course, B-D trial on the W-B side would be infinitely preferrable.) 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 a newer version in the archive that would build cleanly but lack the platform specific patches because I’ve not sent them in yet (gcc, at the moment) or they weren’t included yet (gdb). >Most notably because about 10% of these attempts will leave the chroot >in a broken state in need of manual cleanup. Ouch! Is sbuild so fragile? (If so, is it *still* so fragile?) In which case you should probably invest on doing throwaway-chroot builds. I know for sure that several official buildds are running that, while others still do the removal of B-D after the build. >I'm sure I'm slighlty exaggerating here but I hope you catch my drift. Sure – I’m just saying this is not necessarily your grandfather’s Debian any more. In fact, with all the recent work and the very active kernel development (not to forget gcc development, but that doesn’t contribute to this), m68k has been BETTER than some release architectures in some parts! >The 'throw packages at them manually' would imply a w-b database of some >sorts, No. You can tell sbuild to build a package. I’m not too clear about the specifics because I think sbuild is still from when m68k was the only “other” architecture, and cowbuilder is in- finitely more clear to use (but still shows its age). >Uploading logs should be as easy as setting up a mail server to archive them, >at >least that's what we used to do. Ouch. My three fastest VMs run on my workstation at work, and due to our shit new firewall policies I can’t mail out from them. Not even to [email protected] which sucks. Also, sending mails is a total waste of bandwidth… IMHO, there should be some rsync-over-ssh (or at least ssh, with compression) pickup site. >Uploading the packages to d-p.org should still work I hope. That’s what I’m doing all the time. >> 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 Mh. Such a scenario won’t work for my specific (private) mail setup, either, so I’m not volunteering as buildd manager. (It’s way too mutt specific.) >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 - Are you willing to maintain them inside Debian’s 3.2 as well, which includes tests on the hardware? If so, contact the kernel team. They do accept patches, but usually only if they’re already in Linus’ tree in some form. >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 ...). There’s an SVN (waldi’s working on converting to git) with the packaging. As patches are applied in order, conditionally, and even UNAPPLIED in between versions, and Debian kernels always ship all patches that were ever applied to a specific upstream version, a single git branch to work against is not possible. What you _can_ do is run something like 'debian/rules ARCH=m68k patch' or something (would need to look up the exact command) to get a tree with all patches applied, then move the .git directory from a vanilla checkout into it, 'git add .' and 'git commit -m "add debian patches"', then you can hack on this branch, and then do a format-patch only back to the commit making a debian tree out of a vanilla tree. This is how I occasionally worked. DO NOT MERGE v3.2-m68k on top of it and make a format-patch from that. Instead, cherry-pick or rebase or 'git am' and make a format-patch from that – otherwise, the patches WILL NOT APPLY because their baseline would not be correct. schmitz dixit: >> 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? > Rebuild the chroot systems from scratch based on Thorsten's current > repository, > I'd guess. I've lost my notes on how to use debootstrap to install a chroot > long ago. Maybe there's something useful in the buildd/sbuild docs these days. Just use the base.cow as chroot. It’s the result of a clean debootstrap. (Purge the wtf-debian-keyring package inside first, to make it contain only original Debian and Debian-Ports/unreleased matherial. Then run apt-get update and apt-get --purge dist-upgrade --no-install-recommends inside, then install any additional packages needed by sbuild, if any; the chroot contains --variant=buildd, ie. minbase+build-essential.) http://people.debian.org/~tg/f/m68k/base.cow-m68k-20120420.tgz http://people.debian.org/~tg/f/m68k/base.cow-m68k-20120420.tgz.sig bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
