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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
