"Florian M. Weps" <[EMAIL PROTECTED]> a tapoté :
> On Wed, Apr 16, 2003 at 03:31:57PM +0200, Mathieu Roy wrote:
> > Apparently, pdbv 2.0.2 cannot be installed on hurd-i386 and sh (?). Is
> > it harmless?
>
> The Hitachi SuperH port ("sh") is not very complete it seems; but the
> hurd port is quite advanced (I have a soft sport for the hurd - I have
> one hurd box in my zoo). But the hurd does not have a /proc filesystem,
> and thus the package procps is not available.
>
> Possible solutions are: get rid of the procps dependency (at least for
> the hurd version of pdbv); or add procps support to the hurd. I think
> the former would be possible, but would require changes to pdbv.
Minor changes. What pdbv use is the command free, to grab the RAM
usage status. Which is absolutely not a must-have feature ; but do you
now how to get those data without procps, without read /proc?
>
>
> None of the two ports are stable yet; so you might as well choose to
> ignore them.
>
> > (as the problem is the fact pdbv depends on package not available in
> > hurd-i386, I guess it means that pdbv is no longer available for all ;
> > but this issue does not depends on us).
>
> Yes - at least for the sh port this is true.
I already worked on pdbv1 package. If we can release such package, as
a backward solution, I think we should do it.
You can check the current cvs
(cvs [EMAIL PROTECTED] co pdbv.bash)
Normally it creates a correct tarball (lintian check or ; just
complain about pdbvrc, nothing critical). If you are fine with it, you
can tag this cvs module with rel_1-2-7_2 and upload it (if, obviously,
it's possible to add this package in debian)
--
Mathieu Roy
<< Profile << http://savannah.gnu.org/users/yeupou <<
>> Homepage >> http://yeupou.coleumes.org >>
<< GPG Key << http://stock.coleumes.org/gpg <<
