Please build libc6-hppa64 and libc6-hppa64-dev packages; there is no package build-depending on libc6-hppa64-dev, but we need these packages to run the testsuites for binutils and gcc-4.X. Currently these packages are completely untested, although used to build the 64bit flavour of the kernel on hppa.
severity 482902 wishlist tag 482902 + upstream tag 482902 + wontfix thanks Matthias Klose a écrit : There is no upstream support for 64-bit glibc on hppa, so this bug is currently a wontfix. Please provide us a patch.
clone 482902 -1 reassign -1 general severity -1 serious thanks Aurelien Jarno writes: that's fine. in this case we should drop support for hppa for lenny. Matthias
for lenny because hppa doesn't have a 64bit userland?? Can you be a bit more explicit as to what you need given the above? Again I repeat: *there is no hppa 64bit userland runtime*. The only reason why we have 64bit gcc/binutils is to build 64bit kernels needed by some machines. T-Bone
Probably a good idea. I don't think anyone's doing much work with hppa and Debian any more.
I kind of resent that affirmation. Not even questioning its grounds, I'm sure we don't decide to evict an architecture simply based on doubt, and uncertainty? hppa doesn't have any major flaw we're aware of, it has porters dedicated to maintaining it and it keeps up with the archive (99.9% of lenny is built on hppa[0]). I'll just assume this was the expression of your personal opinion, and I'll state mine which is pretty much opposed to what you suggest. In the end I'm sure any decision will be taken based on facts, which is fine with me. Thanks T-Bone [0] http://buildd.debian.org/stats/hppa.txt
Sometimes the truth hurts, I guess. Does it really have porters dedicated to maintaining it? http://wiki.debian.org/hppaLennyReleaseRecertification The Debian port is maintained by the following developers, who actively work on architecture specific issues: 1. KyleMcMartin 2. ThibautVarene 3. ... 4. ... 5. ... I have a fairly good idea what Kyle's been doing recently. What have you done for the hppa port recently? Does anybody else intend to step up to be porter 3, 4 and 5? The developer machines have been unavailable for months, so Debian developers who don't have their own hppa machine are unable to work on their own packages or fix bugs. What is needed here is not some Descartian dialect designed to separate truth from falsehood, but people putting in some work. The port has been coasting for several years now and things are gradually rotting. Do we put a stake in the corpse now, or make an effort to fix some bugs?
On Sun, May 25, 2008 at 06:55:58PM -0600, Matthew Wilcox wrote: ... Good point. HPPA has done a crappy job of recruiting DDs. I'd prefer to see a constructive dialog instead of quibbling. FTR, I happen to know Thibaut is maintaining (and gave public access) to hppa machines for other DDs. Given the unstability of most kernel releases on hppa, that's not as trivial as it should be. I offer to mentor any DDs interested in helping hppa port. Working on a !x86 port is a fun way to learn something about the kernel and RISC architecture. Please contact me off list. We had some machines setup and running last year....what happened to them? Is lamont the only person able to support those? My impression was my and Thibaut's efforts to provide public access to parisc/ia64 machines has covered the visible need. But that's been informal and not a substitute for having official machines up and running. And of course we don't know if anyone just didn't bother to report issues because the official debian machines were down. I agree. parisc-linux no longer has a "mission". IMHO, ditching the CVS tree might have been necessary several years ago but the replacement (kyle's parisc-2.6 git tree) hasn't been as effective. Not because of Kyle. One lesser reason is parisc-2.6 is not advertised or documented on www.parisc-linux.org. The stale website is another symptom of the same problem. See http://www.parisc-linux.org/kernel/index.html . Much of the previous work happened because HP sponsored it or HP employees had an interest in contributing to it. Of that group, most no longer work for HP and only a few spend more than a few hours per week working on parisc-linux issues. I'm as guilty as much as anyone since I left HP. The sad fact is most of the original "core group" was paid to work on hppa and now have other priorities (a few still keep tabs on parisc-linux or debian-hppa). Personally, on _average_, I'm only able to spend 2-3h per week on parisc. That goes to maintaining a test cluster (still hosted by HP!), tulip driver bug fixing, reviewing/testing code changes by others, and occasionally finding time to build/test current kernels. And like kyle, I have several projects I've started but just didn't have time to finish (e.g. disable pa8800 L2 cache). It sucks. And because of that, I've starting to think that if not enough people care, it's not worth doing. It hurts. But that's why I agree with willy. For now, I'm will continue to put time into parisc-linux. Perhaps even if debian reduces hppa to second class citizen. It would certainly change the priorities of how parisc is supported and perhaps I'll have time to experiment with the things I'm more interested in. hth, grant
Thibaut VARENE writes: hppa64 is the only platform on which we currently do not have the ability to test the tools which are used to build one flavour of the kernel. I would not call it "nonsense" to have the ability to test these tools as we do on all other platforms. If we can do that without a libc6-hppa64 that's fine. any help to run these tests on build time is appreciated. Matthias
The DD accessible machine is paer.debian.org and there are a few hppa buildd machines that are just accessible by the buildd folks like lamont. These machines are all supported by DSA and run Debian stable. I am one of the local admins for them, and up until about a year ago, I was the only person who was trying to support kernels on debian stable (then sarge on those machines). Everyone else in the hppa community had moved on to unstable and newer kernels. For quite a while I was able to install unstable kernels directly along with a backport of a few tools (mkinitramfs type stuff), then the unstable kernels required things that weren't so easy to provide... but that could be worked around by hacking the postinst at install time, but eventually it got too difficult to use anything already existing in Debian so we just stuck with the kernels we had and I quit tracking it. Since then DSA has moved the machines to etch, but the etch kernels (older than some of the unstable kernels I has been installing on sarge) had problems. On top of that all the recent kernel security advisories have meant that trying to run anything that wasn't supported by the security team would mean a lot of work. Without someone trying to produce debs to support etch (either fixing the debs in stable or making a working backport), we had no way to keep the machines up and running and up to date with security advisories. This was mentioned on the list and DSA has asked for help a few times, but nobody has worked on it so the machines are still locked down. I'm not sure how Thibaut is generating his kernels and running his machines, but if he can do it in a DSA supportable manner (which means etch userspace and kernel packages up to date with security patches) then maybe he can help get the debian.org machines accessible again. I suspect he is probably running unstable and building kernels by hand though...
(linux-)hppa64 is *not* a platform[0], and will probably never be. I'm no gcc guru and have no clue what these tests are about, but if they involve running pieces of code against a 64bit library, they can just as well be ignored, for this is not happening. I can understand that you do run these tests on "all other platform". Then again, hppa64 is not a platform. I don't know of many other ports which have a need for a toolchain with wider (or narrower) code generation capabilities than what's supported in userland, so any comparison seems a bit biased to me. Anyway, could you provide us with some pointers as to what's needed / missing? This issue was under my radar screen and I don't know where / what to look at / for... HTH T-Bone [0] there is no support for building or running 64bit binaries (other than the kernel), no 64bit libc, no 64bit userspace.
I do build my kernels by hand. I'm generally uninterested in distribution kernels since they really don't fit my needs, which is why I stepped down from maintaining them years ago. Yet I understand the issue and its implications for the hppa port, so I could try tackling it in the short term (fsvo "short", I'm afraid days last only 24h ;-P). I'm not sure I understand this correctly though: what's needed right now is a debian-packaged etch-supported kernel (ie, 2.6.18 if my memory serves me right?) that works on hppa? Is it any different that the kernel package shipped with etch? (I suspect it is since the latter is not being used) If so, how so? If we have that, the security issues will be dealt with by the DSA team as usual? While we're at it, one must not forget that 2.6.18 is IIRC exactly when we had the CVS mess and switched to Git, which is why it's pretty hard to track our arch-specific patches up to that particular kernel... HTH T-Bone
(replying to willy on that specific bit): Though I won't deny the port has been coasting, I don't see why or how it's been rotting. As I pointed out, the archive is built up to unprecedented levels and we don't have any major breakage I'm aware of. ISTR we have had bigger trouble in the past. I'm also happily using parisc-linux on exposed servers (web and mail in particular) without any trouble, so why should I worry? Incidentally, I have a bunch of patches for our website that I intended to commit yesterday, but I forgot to do so (updating the mailing-list page, in particular). I shall do it ASAP. Yet I believe I'm not the only person with write access to the CVS repository that hosts our website source ;-) Is there nobody left at HP who care about parisc-linux? What's HP's stance on the topic (if any)? I certainly agree with you (and willy) on the fact that it's apparent not enough people care about the port. Otoh I believe we have a somewhat nice userbase (the silent crowd) who's using parisc-linux (I have evidence to back that up: mail I receive on the hwdb and pateam mailboxes of installation reports and other general questions). Maybe we could try leveraging that and raising awareness on the fact that the port needs help? The point I do not agree with, though, is the idea that support for the port should be dropped just because it seems nobody cares. I for one don't see a reason to be overly verbose since "everything looks good". i.e. I'm not aware of any major issue (again if there's one, please let us know), save for our current trouble with 2.6.26-rc kernels, but that's another story and we've already been there (remember 2.6.20) and got over it. HTH T-Bone
Thibaut VARENE wrote:
The most major issue I'm aware of is that aptitude will hang (no longer
responds to key input) after it returns from installing packages: #434861.
This seems to be a threading issue, so could be related to what Aurelien
Jarno mentioned about linuxthreads in another post.
It would be great if someone could look into that. Note that the issue on
hppa is somewhat different from other arches as for other arches it is
fixed with newer kernel versions.
that nobody seems to take responsibility for getting the porter machines
back up.
Having an arch fall behind for longer periods is one of the best ways to get
release managers and DDs in general to start thinking about dropping the
port. If nobody who is directly involved with the port cares, then why the
hell should others care?
As most of you probably know I do the basic work to keep the installer
working on hppa, but the total lack of interest from anybody else is
sometimes demotivating. Properly maintaining the installer _does_ require
more architecture-specific knowledge than I have!
Examples:
- Kyle promised a few times to look into what modules should be included for
the installer for current kernels, but that never happened. I've gotten
tired of pinging him about that.
- The hppa bus is one of the few classes of hardware for which modules are
not being autoloaded. I've heard that was being worked on at some point,
but AFAIK that never got submitted upstream.
Cheers,
FJP
[1] There was a 2-month period when hppa was below 90% and was seriously
blocking migration of packages (~ week 14-22):
http://buildd.debian.org/stats/graph-quarter-big.png
Matthias Klose wrote: FWIW, the same was true for MIPS64 until not-so-long ago. I don't think running those tests exposed any problem relevant for a MIPS64 kernel. (AFAIK none of the problems with MIPS64 kernels is related to toolchain bugs.) Thiemo
... [ snip ] Matt, thanks for the explanation. I didn't realize it had gotten that ugly. But I also don't see a way for us to support etch since it feels like we barely have enough people to support kernel.org + unstable (debian). Not unless some new folks wants to volunteer to help. I'd be happy to review patches for this and provide guidance. Yes, as am I (though I'm not a DD). thanks, grant
* Thibaut VARENE: We see issues with the stable-security buildd (peri); it's often not available when we need it. IIRC, those are caused by kernel stability issues, but my memory is a bit foggy. For lenny, there are a couple of Berkeley DB issues that could need some attention. I'd also prefer if all architectures could provide the full threading API, with cross-process mutexes and stuff like that (which presumably would enable us to use that to fix the Berkeley DB bugs).