The future of an SCC that has been given up on
Hi m68k porters,
what are we going to do now? The Debian Project has apparently
given up on m68k citing lack of progress (although the TLS things
were only started during the squeeze release process, so IMHO
everything before doesn’t count), and we’ve been denied using
Debbugs for our packages that aren’t in Debian already (things
like atari-bootstrap), and now m68k-specific packages that can
be used on other architectures.
On the other hand, now’s a *very* good time to set up buildds,
ARAnyM buildds if must be, and get to build a newer X11 stack,
as pygobject just became unbuildable due to too old cairo, whose
newer versions in turn need the new X stack, etc.
I can’t deal with buildd. I’m too busy keeping the rest and the
toolchain alive. So please step forward and revive the zlin*
bunch, at least.
As for bugtracking of packages like atari/amiga/mac68k bootloaders,
I’d like to ask someone from Launchpad I’ve got connections to to
set up Debian-Ports as a “distribution” there, similar to how Ubuntu
is set up, plus an eMail address reportbug can send mails to that
are parsed and entered in the system (no idea if they have something
like that yet). The mechanism to add that to the packages is to add
a Bugs: line to the source package debian/control file. (It works.
I’ve been using that on my personal packages for a while. Example:
tg@zigo:~ $ apt-cache show arngc
Package: arngc
Version: 20120509
Architecture: all
Origin: WTF
Bugs: mailto:wtf@mirbsd.org
Maintainer: Thorsten Glaser <tg@mirbsd.de>
Installed-Size: 76
Depends: mksh (>= 35~), procps, rng-tools, stunnel
Suggests: sudo
Enhances: rng-tools
Conflicts: stunnel4 (<= 3:4.29-1~~)
Filename: dists/sid/wtf/Pkgs/arngc/arngc_20120509_all.deb
Size: 5190
MD5sum: 079e51534b6b782ad5418c403671e948
SHA1: 0e68e9776498fafc4361da46699b2777c9cdf720
SHA256: 4e871d385a3fb71d18c486bfa32f37ac7c67ebe6303c11e62375f3edc64eef8b
Section: admin
Priority: extra
Multi-Arch: foreign
Description: arc4random-pool transfer over the network
This package contains a client for transferring entropy over
the network and an example of how to configure the server side
on a machine running MirBSD.
tg@zigo:~ $ reportbug arngc
*** Welcome to reportbug. Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.
Using 'Thorsten Glaser <tg@mirbsd.de>' as your from address.
Getting status for arngc...
Checking for newer versions at madison, incoming.debian.org and http://ftp-master.debian.org/new.html
Unknown origin WTF; will send to wtf@mirbsd.org.
Maintainer for arngc is 'Thorsten Glaser <tg@mirbsd.de>'.
Looking up dependencies of arngc...
[…])
By using that, we retain the ability to track bugs on m68k (or
other debian-ports architectures) specific packages. I’ve been
dealing, test-wise, with LP for some of my projects, and while
it’s not that great, it’s not too disappointing either, and they
definitely said “use LP, we don’t care if you do or don’t, so
use it” at LSM/RMLL 2010, and that’s a gift offer.
My agenda is as follows:
• try to fix gcj
• collect and submit to doko linux-m68k specific patches for
binutils and gcc (sent gdb to zumbi already)
• if you agree, set up d-p.o for LP bugtracking
• get atari-bootstrap built
‣ package mintlib
‣ get a working m68k-mint-gcc cross toolchain
• collect and submit to doko mint-m68k specific patches for
binutils and gcc (guillem applied dpkg’s already)
• package atari-bootstrap and emile, new, for d-p.o unreleased
(using debian-68k@ as maintainer address for now I suppose,
unless people like Roman, Christian, Stephen and Wouter step
up and request to retain their current Maintainer line on
the packages)
• package EmuTOS, then try to get mintlib, EmuTOS and the cross
toolchain into Debian
• all the while during that, keep building some packages
This can only work if
• people get buildds running, yes, plural (Wouter, I’m looking
at you, mostly)
• people get things on real iron running and tested (from the
recent mails to the list, I don’t see a problem there)
• we agree on either my proposal for handling packages in
unreleased or someone else proporses something agreeable
• outstanding bugs get fixed, such as the locale issue in libc
(let me plug a big thanks to everyone who helped fixing our
bugs in the past here, I know I did much less in that area
than many others, but to my excuse, I’m busy compiling…)
• someone deals with the removal of lam and fixes either
openmpi or mpich2 (cf. src:mpi-defaults, #651041, #405929)
• looks at guile: #649718
• and other broken core-ish packages
Current and prospective packages in unreleased:
• architecture specific, mostly good, packaging could be freshened
‣ atari-fdisk
• bootloaders, mostly just an NMU to get them out of unstable,
need checking whether they work
‣ m68k-vme-tftplilo
‣ m68kboot
→ amiboot
‣ vmelilo
‣ vmelilo-installer
• bootloaders, known to need work and cross-toolchain availability
‣ atari-bootstrap
‣ emile
I’d like to put all the above under “debian-68k@ team” maintainership,
LP bugtracking and possibly freshen them up a little if needed.
(Note I have a strong preference for the non-dh7 debhelper style,
so don’t convert to dh7 or *shudder* cdbs and chances are bigger
I work on them.)
• patched packages
‣ dpkg
– already in guillem’s tree
‣ gdb
– sent to zumbi
‣ php5
– sent to ondrej
‣ libffi
– sent to doko
‣ binutils
‣ gcc-4.6
– need splitting up and sending to doko
• already dealt with
‣ mysql-5.1 (only changed b-d from gcc-4.5 to gcc-4.4)
– will be replaced with mysql-5.5 soon
‣ python-numpy (circular b-d with python-matplotlib)
– bootstrap issue solved, cf. #655014
– need to rebuild both packages, are their other B-D available?
‣ qt4-x11 – #660963 (atomics, using generic)
‣ libdrm – #654329 (atomics, using libatomic-ops-dev)
• packages needing GCC atomic builtins (which are not in gcc-4.6)
‣ mesa
• others (mostly patching b-d and optional features away to get them building)
‣ avahi (disable UI)
‣ libwmf (drop gdk-pixbuf: our GTK+2 too old)
‣ libxcb (throw out stuff)
‣ pygtk (lower GTK+2)
except it did not work, my repo on freewrt.org contains a hex-edited
version of the binaries, only removed two symbol imports that should
not have been in there except the buildsystem apparently didn’t like
all of my patches, but this will be fixed once we have newer X anyway
‣ systemd (disable GUI (GTK+2) and libnotify), needed for dbus nowadays :(
My repository on freewrt.org contains more hacked-in-place packages:
gvfs and poppler, to keep build dependencies installable. You’ll also
want the /etc/apt/preferences list I’ve built, until newer X is available,
which pulls in older versions of some arch:all X packages since the newer
ones break our arch:m68k packages.
BUT! These are almost all hacks that go away once we’ve got enough newer
packages built. Kibi said that armhf and s390x did not have any trouble
getting X bootstrapped from nothing using just buildd/wanna-build.
One more note on debian-ports.org: it is NOT normally possible to
debootstrap a system from it, even if all packages needed are in
unstable and not unreleased: the Packages file often contains two
versions of the same package for one or two six-hour blocks after
a newer version of the package got ACCEPTED, which is something
debootstrap totally chokes on. So use my repo to debootstrap or,
better, use the ARAnyM image or the base.cow tarball to start from
(especially since I personally cleaned these up and, save the key-
ring package, they contain no hacked or other not-in-Debian stuff).
The base.cow tarball is run with --variant=buildd so it’s ideal to
use for an sbuild chroot dir. (My repo may temporarily also not be
usable for debootstrap, but usually I clean up and regenerate the
Release file late at European night, so during European morning,
it should be usable.)
So, do I get any responses now? ;-)
My current dilemma is: I could, of course, deal with the other
stuff, but in the meantime, other things would suffer (like the
toolchain), which I deem more important. (Aside from hacking on
my other projects, having a life in general, and a dayjob.) The
emile removal was (save me sort of forgetting about it…) mostly
that: a decision between the small and important things. It turns
out that Debian wants you to fix the small things and leave the
important things broken for longer because they are not in as
much danger of removal. *sigh*
Note that using Launchpad doesn’t mean anything other than the
obvious “you can track (some) bugs for $foo on Launchpad”. In
fact, for example, mksh, one of the most BSD-ish projects you
will find, uses LP as an *optional* bugtracker. You can still
submit bugs using the mailing list or IRC. It has nothing to
do with Canonical, and I still can’t stand *buntu. But it’s
good for users, good to have an overview over (some) bugs, and
it’s got a (bizarre, erm, bazaar) mirror of the CVS source tree.
So, why not. I mean, if they annoy us, we can just drop LP.
In a jiffy.
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (245 (264) bugs: 0 RC, 173 (187) I&N, 72 (77) M&W, 0 F&P)
‣ src:dash (75 (87) bugs: 3 RC, 31 (35) I&N, 41 (49) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
Reply to: