Re: The future of an SCC that has been given up on
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 submit@bugs.d.o 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
Reply to: