Re: Progress on the Alpha distribution at debian-ports
On Sun, Feb 12, 2012 at 02:37:44PM +1300, Michael Cree wrote:
> You may have noticed that we have the majority of the unstable
> distribution (was over 95% a week ago) built at Debian-Ports. It is
> reasonably up-to-date with many problems in the toolchain fixed, the
> kernel up to date, Gnome 3 built and installable [1], and other software
> like iceweasel built and working [2]. I hope some of you have it
> installed and are trying it out!
I seized the occasion of this announcement to try again and figure out a
way past my Gnome 3 upgrade issues, because "apt-get" was stubbornly
refusing to upgrade certain packages without gutting a functional system.
Most of the problem was centered around libgnome-desktop-3-2 and friends,
which I *finally* resolved by specifying a few key packages with it on
an "apt-get install" command. When I saw that "evolution", "gnome-core",
and other essentials would finally be upgraded instead of removed, I knew
I had the solution :-).
> I have put quite a bit of work into this over the last six months, but
> is a work rate that I will not be able to keep up past April this year.
Left to speculation is what kind of work rate you might find sustainable
past April :-). I anticipate being able to take up *some* of the slack
this summer, modulo not having access to a suitable buildd platform to
make debugging more feasible.
> Quite a number of people in this forum were horrified at the
> discontinuation of Debian Linux on Alpha and spoke up for a rear-guard
> action to get another release of the distribution.
The reasons for discontinuation of Debian Linux on Alpha were, and
presumably remain, valid. You, Bill, and I leapt into the breach, and
in my case at least, it was an honest attempt to see exactly what kind
of effort was going to be required to keep the Debian distro reasonably
up-to-date.
> But really it has
> come down to three of us who have been working on this: myself, Bill
> (running buildds) and Bob (testing and writing bug reports). It would
> be really good if others could help with the work.
I'll try to make the sales pitch here... Frankly, it has been a lot of
fun for me to run an Alpha system on the so-called bleeding edge. It
was *made* fun by knowing there were a few key individuals who cared
enough to investigate why things were broken and come up with workarounds
and/or fixes. It was made *possible* by Michael and Bill being willing
to set up and maintain a buildd infrastructure to provide new packages
in a timely manner: if you're still reading this list, you're familiar
with my reports on the resources (including time) required to build some
of the larger packages. Honestly, I would have given up long ago if
forced to rely on my own system to build everything from source. As far
as coding skills required, not really so much... The simple truth is, a
dogged determination to figure out why something doesn't work properly
counts for more in this environment than one might expect. Specific
example: I might not be able to fix a broken optimizer, but I can sure
recognize the effects of one :-), and bring it to the appropriate
maintainer's attention.
Finally, the "truth in advertising" disclaimer: when my Alpha finally
dies in such manner that it cannot be resurrected, I'll likely not get
another one unless I can do so inexpensively. It's only my fondness
for antiques in general, and Alpha systems in particular, that has kept
me active in this community.
> There are number of criteria for architecture recertification one of
> which is having Debian Developers actively working on the port. We have
> none so we have failed before we even start.
Haven't heard from traditional community participants like Ivan
Kokshaysky in many months. While there are other people out there
who know Alpha assembly language pretty well, Ivan was (hopefully still
"is") one of the "go-to" experts I worked with back in 2006 or so (the
strncpy.S fix for Alpha).
> But if people would like I could approach the Debian-Ports FTP master
> about whether an unofficial "testing-like" CD could be cut from the
> Alpha unstable repo at the time of the Wheezy release. It would not
> have any security support but would provide a reasonably up-to-date (as
> far as Debian goes) and comprehensive build of packages for the Alpha.
Would *love* to see this, because restoring my current system from
scratch is too unpleasant to contemplate presently.
> That brings us to another issue, that of an installer. The current
> debian-installer fails to build on Alpha and needs some serious work if
> such a CD is to be of any use. I am not planning to work on the Debian
> installer --- there are plenty of other things to do. I will work on
> aboot to bring it some new features but that is it. Someone else will
> have to step up and do the installer.
In spite of running sid, my Alpha is a major component of my infrastructure.
Even with a known good installer, I wouldn't willingly trash a working
system by installing from scratch. I acknowledge the possibility of
using "debootstrap" to do the work on a spare partition, but would need
to round up some more SCSI storage to have a spare partition. Fortunately
(?) for us, I may have some extra storage available in another month or so.
My primary x86 system is SCSI-based, and will be retired soon when I replace
it with an i7-2600S box: the old system has two 18 GB spindles I could put
in an external enclosure and attach to the PWS 433au QLogic controller.
All that being said, I *didn't* say I would do the installer... I *would*
be able to test it, at least.
> [1] Well, as installable as unstable ever is, that is, while Gnome 3 was
> installable a few days ago, that may or may not be the case now.
Moving targets are generally harder to hit :-).
>
> [2] Provided that you do not use pulseaudio. If pulseaudio is running
> with a newer kernel then iceweasel will crash and will be unuseable.
This is that #$%@! pulseaudio mutex bug we can't seem to get anyone to
fix. There *is* a documented workaround: see Debian bug #649641.
Unfortunately, this *does* require building the pulseaudio package from
source.
Got a new bug I need to file against the "radvd" package: the "radvd"
process ID stored in /var/run/radvd/pid is the predecessor of two child
processes that get spawned (and detach: ppid == 1). Thus, init level
changes don't work correctly as far as locating running radvd processes,
among other anomalies. I run the "gw6c" IPv6 client, which spawns
"radvd" as part of its startup routine. When the IPv6 tunnel collapses
and "gw6c" reopens it, two more running instances of "radvd" appear
because of the broken pidfile <--> running instance(s) relationship.
--Bob
Reply to: