On Wed, Nov 13, 2024 at 7:36 AM Stuart Henderson <s...@spacehopper.org>
wrote:

> On 2024/11/12 21:12, David Higgs wrote:
> > On Tue, Nov 12, 2024 at 3:34 PM Alexander Bluhm <bl...@openbsd.org>
> wrote:
> >
> >     CVSROOT:        /cvs
> >     Module name:    src
> >     Changes by:     bl...@cvs.openbsd.org   2024/11/12 13:33:38
> >
> >     Modified files:
> >             lib/libexpat   : Changes README.md shlib_version
> >             lib/libexpat/doc: reference.html
> >             lib/libexpat/examples: element_declarations.c
> >             lib/libexpat/lib: expat.h xmlparse.c
> >             lib/libexpat/tests: basic_tests.c common.c common.h
> handlers.c
> >                                 handlers.h misc_tests.c
> >
> >     Log message:
> >     Update libexpat to version 2.6.4.
> >
> >     Relevant for OpenBSD are security fix #915, other changes #905 #902
> >     #904 #317 #918 #914.  Major library bump is necessary as new error
> >     constant has been added to a public header file.  CVE-2024-50602
> >
> >     OK matthieu@ tb@ deraadt@
> >
> >
> > I suspect I ran sysclean at exactly the wrong time, and now I can't
> easily fix python (or git,
> > according to pkg_check).
>
> If you don't have another machine handy to copy from, simplest fix is
> probably to cvs up to before the update (cd /usr/src/lib/libexpat;
> cvs up -D 2024/11/11), and build it (make obj; make clean; make includes;
> make; make install).
>

This is not my daily driver nor do I compile from source, so it will be
faster/easier to wait for a package update.  Thanks for the tips though.

I wouldn't expect sysclean to suggest removing an old version while
> you still have installed ports referencing it though..
>

My ports were already in a sorry state - I was attempting to upgrade, ran
out of space, answered the prompt to delete before upgrading, and then
still ran out of space.  I was playing fast and loose, and then used the
wrong approach to fix it.

FWIW, I still have a pkg_info entry for python but it isn't in my $PATH
anymore.  I wouldn't expect sysclean to perfectly handle when the package
database is not reflecting reality, so I don't blame it at all.

--david

Reply via email to