The reason for the failure to update the package is an update to libc, which makes the package out-of-date.

Snapshots of the OS are created on an as-needed basis. For popular architectures during normal day-to-day development periods, this may be daily, or every few days. But during hackathons, the frequency of snapshots may be every several hours. A hackathon is going on right now in Edmonton -- see the OpenBSD Journal for some recent information.

Snapshot packages, on the other hand, are updated less frequently. Understand that there are around 5000 packages to build, and that it can take days, depending on architecture and build platforms. On popular archs, this may be every couple of weeks. On less-popular archs, there are no snapshot packages created at all. On those architectures, -current users must build all their packages from ports themselves.

Snapshot packages are created for convenience. There is no synchronization with any particular snap of the OS.

The best practice for those who use snapshot packages is, in my humble opinion:

Log console output, using script(1) or a similar facility

Use "# pkg_add -iu" to update those packages which will update cleanly.

Review the console output, and manually build packages from ports which are out of sync and fail to update.

Use "# pkg_add -ir <list of packages>" for those packages which failed to update due to a dependent package which was out of sync but will update cleanly once the dependent package is updated.

Run ports/infrastructure/build/out-of-date, and build any out-of-date packages for any ports which do not have packages built for them, either due to FLAVOR or licensing. I ignore packages marked out-of-date if they updated cleanly from the most recent snapshot package updates.

1. Postfix was disabled
-- Killed Sendmail
-- re-enabled postfix
-- I have a transport file -- postmap transport
For some reason port 25 was still in use and postfix
would not start..
Reboot fixed it.. Postfix now happy..

Note to self:
find out how to see what process has port X locked..
This way I could avoid the reboot...

2. Amavisd had some changes
-- Fortunately, I had just done an install on another
box and have the current configuration files for
- amavisd.conf
- clamd.conf
- freshclam.conf

3. Squid was also changed.. haven't gotten that fixed yet..
My squid conf file is only used for remote tunneling so should be
a simple fix..

It sure looks like
rebuilding the binaries with the most current src fixed the issue..

Be aware that your list only updates the kernel. While there is some latitude, you should also consider rebuilding the userland as well. Getting the kernel & userland too far out of synchronization can lead to other problems.

These ports, for example, do not have packages due to licensing, and appear here because your local ports/packages hierarchy is not in your PKG_PATH. As I recommended, the ports/infrastructure/build/out-of-date script will tell you if packages like these require rebuilding.

Quote:

Originally Posted by roundkat

Note to self:
find out how to see what process has port X locked..

The fstat(1) command can help with that, e.g.:

$ fstat | grep :25

Quote:

Originally Posted by ocicat

Be aware that your list only updates the kernel...

I believe he described a "make build" after rebooting, which would regenerate userland.

These ports, for example, do not have packages due to licensing, and appear here because your local ports/packages hierarchy is not in your PKG_PATH. As I recommended, the ports/infrastructure/build/out-of-date script will tell you if packages like these require rebuilding.The fstat(1) command can help with that, e.g.:[INDENT]$ fstat | grep :25

Thx to both for responses..

jggimi:
The ports you listed are required by amavisd...
-- freeze is really old and won't need to be updated..
-- the other archivers will though..

I didn't forget but I was going step by step..
i.e. changing one thing at at time..

I haven't gotten to that part yet but going there now..

fstat.. that is a new one for me..

ocicat:
I did understand the building the kernel and keeping userland
in "sync" but it was definitely worth mentioning..

Not all for -current
Most important are the libgc bumps, current should be /usr/lib/libc.so.45.0
whether you made upgrades properly or not, you would end up with a full list ranging from i.e.: libc.so.42.0 to libc.so.45.0

Another ennoying one (among many others) is that some packages rely on /usr/X11R6/lib/libexpat.so.8.0 which on current is /usr/lib/libexpat.so.9.0
(had such a problem with x11/roxterm and the databases/evolution-data-server not upgrading from 2.12 to 2.22).

No big problems as you can symlink a library to the next one (in most cases).
Read the corresponding library file (the one ending in *.la) for hints.

-current code just got changed after the Japan hackaton, now busy including code from the Edmonton hackaton.
If you are not a seasoned -current litterate, stay away from -current for a while, until dust settles.

In OpenBSD, when you pkg_add -u (or make update), failed and/or left-overs of intallations will be written as hidden files under /var/db/pkg
mostly libs, hence

ls -dl /var/db/pkg/.lib*

which you can pkg_delete as any other package, but these are there for a reason: some packages still rely upon and are listed as usual under

/var/db/pkg/.lib* /+REQUIRED_BY

So, you have two choices (as the economists say, 1,2,3

1- Take the long (learning) way, pkg_delete the offenders (+REQUIRED_BY) and pkg_delete the ls -dl /var/db/pkg/.lib* when they are not needed anymore (no mere +REQUIRED_BY).

2- Delete all packages, re-check the FAQ upgrade entries

3- As I say in many cases, best upgrade is newfs.

This situation is very exceptional on OpenBSD, but as any other *nix, there has been a major gettext/libiconv change.
I guess July will have both correctly snapshots and snapshots/packages on the fast track again.

On a speculative note, as libc is marked with version 45, will there ever be an OpenBSD 4.4
If the hackathon codes keep coming in in such high numbers, next version could as well be the 5.0

Another annoying one (among many others) is that some packages rely on /usr/X11R6/lib/libexpat.so.8.0 which on current is /usr/lib/libexpat.so.9.0
(had such a problem with x11/roxterm and the databases/evolution-data-server not upgrading from 2.12 to 2.22).

No big problems as you can symlink a library to the next one (in most cases).

Read the corresponding library file (the one ending in *.la) for hints.

This I did not know.. thx

Quote:

-current code just got changed after the Japan hackaton, now busy including code from the Edmonton hackaton.
If you are not a seasoned -current litterate, stay away from -current for a while, until dust settles.

I don't do upgrades on ports /packages but I decided to step out of my comfort zone (-stable) and try -current..
Realizing that there are many new things I would have to learn..
That being said.. I will probably just hold off until then..

Quote:

In OpenBSD, when you pkg_add -u (or make update), failed and/or left-overs of installations will be written as hidden files under /var/db/pkg
mostly libs, hence

ls -dl /var/db/pkg/.lib*

which you can pkg_delete as any other package, but these are there for a reason: some packages still rely upon and are listed as usual under

/var/db/pkg/.lib* /+REQUIRED_BY

I will also look a this..

Quote:

So, you have two choices (as the economists say, 1,2,3

1- Take the long (learning) way, pkg_delete the offenders (+REQUIRED_BY) and pkg_delete the ls -dl /var/db/pkg/.lib* when they are not needed anymore (no mere +REQUIRED_BY).

2- Delete all packages, re-check the FAQ upgrade entries

3- As I say in many cases, best upgrade is newfs.

I am going for option 1 here..

Quote:

This situation is very exceptional on OpenBSD, but as any other *nix, there has been a major gettext/libiconv change.
I guess July will have both correctly snapshots and snapshots/packages on the fast track again.

I am so totally impressed with the "minimal discomfort" of upgrading and
what a stellar job the OpenBSD devs have done..

I *never* do upgrades on anything.. Always reinstall..
As previously stated.. that was my comfort zone..

Quote:

On a speculative note, as libc is marked with version 45, will there ever be an OpenBSD 4.4
If the hackathon codes keep coming in in such high numbers, next version could as well be the 5.0

I can go home now.. as I am not learning anymore today..
My brain is full...

Not to worry, OpenBSD 4.5 will be released November 1. OpenBSD release numbers are incremented by 0.1 twice each year. "4.0" was released 6 months after "3.9" as it was the next sequential release number. It had the usual enhancement and improvements.

jggimi is aware of libc.so.45.0 so, I join him when he writes OpenBSD 4.5

My speculation is that there now are so many changes a sequential increment of the version number would not be sufficient to get noticed, hence users not reading upgrading or warnings.

My upgrade (<U> choice) last weekend with -sbapshots as of June 3rd and snapshots/packages as of June 7 was made through
pkg_add -ui
and my system did not break: thumbs up!
But I had in excess of 25 /var/db/pkg/.lib*

----
Edit: right, forgot:
made a fresh install on a WS (sole libc.so.45.0 )
updated ports tree (and make index, just to mention, x11/pbrowser core dumped because /usr/ports/INDEX was corrupt. Must be one of the rare apps reading the INDEX and INDEX is not updated very often. Anyway, just use pbrowser for browsing the tree and get noticed of flavors).
still had the libexpat.so.8.0 problem an had to make a link to libexpat.so.9.0

My upgrade (<U> choice) last weekend with -sbapshots as of June 3rd and snapshots/packages as of June 7 was made through
pkg_add -ui
and my system did not break: thumbs up!
But I had in excess of 25 /var/db/pkg/.lib*

The best practice for those who use snapshot packages is, in my humble opinion:

Log console output, using script(1) or a similar facility

Use "# pkg_add -iu" to update those packages which will update cleanly.

Review the console output, and manually build packages from ports which are out of sync and fail to update.

Use "# pkg_add -ir <list of packages>" for those packages which failed to update due to a dependent package which was out of sync but will update cleanly once the dependent package is updated.

Run ports/infrastructure/build/out-of-date, and build any out-of-date packages for any ports which do not have packages built for them, either due to FLAVOR or licensing. I ignore packages marked out-of-date if they updated cleanly from the most recent snapshot package updates.

Updated the 3 ports
- unarj
- unrar
- freeze (even though freeze did not change versions it still needed
to be updated)

Rapid development during Hackathons is normally expected. Even when theo@ calls for testing during Hackations, I recommend those brand new to -current should delay until after the pace of development returns to normal.

Rapid development during Hackathons is normally expected. Even when theo@ calls for testing during Hackations, I recommend those brand new to -current should delay until after the pace of development returns to normal.

Looks like the Hackathons are over.. and -current has reached
4.4 beta..
Is it safe to upgrade..??