Re: dump on a hamm system
In article <6rwwim9bv5.fsf@franz.stat.wisc.edu> you wrote:
: Douglas Bates <bates@stat.wisc.edu> writes:
:> File system dumps have started failing on me after a recent update of
:> packages on a hamm system. I tried to re-build the dump package from
:> the sources but am caught on the dependencies. I think I need
:> e2fslibs-dev which depends on comerr-dev and both these depend on
:> libc5-dev which is no longer available.
: As a temporary fix, downgrading to the dump package from bo
: (dump_0.3-14.deb) provided a working dump.
That's probably the best solution, until libc6 versions of the e2fs packages
are uploaded.
For the curious, here's what happened:
Because I'm working on the Alpha port (which has never had libc5), I've gotten
very libc6-centric lately. I've gotten in the habit of recompiling things
in my dependency chain on the Alpha, and it rubs off on the Intel side as
well. Ergo, I'm running the 1.10-7 e2fs stuff, locally compiled with no
libc5 dependencies... on both my Intel and Alpha systems. Thus, the dump
0.4b4-1 packages I uploaded recently depend on libc6 versions of these e2fs
libraries.
I didn't think about the fact that the .deb files of these libraries in the
unstable tree might still depend on libc5, or I would probably have delayed
releasing the Intel .deb file of this version of dump. It's running fine for
me with libc6 versions of the libraries it depends on on both Alpha and Intel,
so I have confidence that it'll be fine once libc6 versions of the libraries
are uploaded for hamm.
My apologies for any frustration this has caused... I guess that's why we
call it "unstable", 'eh? /o\
Bdale
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: