snapshots and bad major error

[fstef]

today i've installed the 24 feb 2015 05:32 snapshot and in my .profile i've defined the PKG_PATH to /snapshots/packages/'machine -a'/
then i've tried to install elinks (24 feb 2015 13:07) whit this result:

Can't install elinks.0.11.7p8 because of libraries
| library crypto.30.4 not found /usr/lib/libcrypt.so.32.0 (system):bad major

and the same for the ssl library.

according to FAQ 5.2 "The OpenBSD Team puts out new snapshots based on -current code on a very regular basis for all platforms. It is likely this will be all you need for running -current." so if i understand correctly i don't need to compile the system from source, i can just run snapshot, right?

but according to FAQ 5.1 "It is possible, tough hopefully unlikely, you may uncover bugs in snapshots, this is the reason they are built and distributed."

so, because everything is in sync, is this a possible bug?

thanks
fstef

[fstef]

now i tried to install elvis, just because don't have dependency. the installation process is error free but when i launch the program:

Segmentation fault (core dump)

so now, i'm lost

fstef

[blackhole]

Originally Posted by fstef

today i've installed the 24 feb 2015 05:32 snapshot and in my .profile i've defined the PKG_PATH to /snapshots/packages/'machine -a'/

Well that PKG_PATH is not going to work, it needs to be a full url to the mirror, e.g.

http://your.mirror.here/pub/OpenBSD/...s/'machine -a'/

Originally Posted by fstef

then i've tried to install elinks (24 feb 2015 13:07) whit this result:

Can't install elinks.0.11.7p8 because of libraries
| library crypto.30.4 not found /usr/lib/libcrypt.so.32.0 (system):bad major

and the same for the ssl library.

It seems to me that your ports/packages and base system might be out of sync. It looks like the elinks you are trying to install expects crypto 30.4 whereas your base system has 32.0

[J65nko]

The snapshot packages are built by a different team (Marc Espie, Naddy Weisgerber c.s. in Europe) than the base system snapshots (Theo c.s. in Canada). The large set of packages take a longer time to compile then the base system.

The snapshot packages builders first have to install (or upgrade) the latest base system, and only then can start the package build.

In the mean time there could be a major or minor increase of the version number of a base library. When Theo then creates a new snapshot (which does not take as long as the thousands of packages) and this snapshot hits the mirror ftp sites, then you can encounter problems like mismatching of base library

A package is compiled/built against a certain version of a library in the base system. It can not run when that specific lib version is not present. It is a run-rime dependency,
When pkg_add cannot find that specific version, it will complain that it cannot find it.

Can't install elinks.0.11.7p8 because of libraries
| library crypto.30.4 not found /usr/lib/libcrypt.so.32.0 (system):bad major

Somehow you installed a base system with /usr/lib/libcrypt.so.32.0 while elinks at run-time needs version 30.4 of that lib.

Which arch did you install? Which mirror did you use?

[fstef]

Originally Posted by J65nko

Which arch did you install? Which mirror did you use?

i've a loongson machine and i use the http://ftp.openbsd.dk mirror.
BTW my PKG_PATH is complete, in my first post i abbreviate the path, sorry.

i understand compile packages need time, what i don't understand is if the base system is complete at 05:39 in the morning and the package is compiled at 13:07 i expect this package is compiled using the new library. if not, for me, don't make sense and is impossible debuggin. i know the loongson architecture is something "rare" but i'm using it :-)

thank you both for the reply

fstef

[jggimi]

The "snapshot packages" are really misnamed. They are built against -current, but it is almost always going to be a different -current than the -current used to build snapshots. This is because the -current branch is a constantly moving target, and different systems are used to build snapshots and these packages

They are provided as a convenience, only, with no guarantee that they will be in sync with any available snapshot. The project does not have the resources to do so.

Users of -current are expected to occasionally build ports themselves, in order to get around this synchronization issue, which occurs from time to time, in particular with major library "bumps".

I'd like the project to offer synchronized snapshots/packages. But they don't have the resources to do so.

I use i386, and had the opposite issue yesterday. The "snapshot package" collection for that architecture was built against libcrypto 32, but the snapshots available at that time had not yet been built against the new major library.

[ibara]

Originally Posted by fstef

i've a loongson machine and i use the http://ftp.openbsd.dk mirror.

It takes about 12 hours to build a loongson snapshot. It takes about a month to build packages. See the disconnect?

Originally Posted by fstef

i understand compile packages need time, what i don't understand is if the base system is complete at 05:39 in the morning and the package is compiled at 13:07 i expect this package is compiled using the new library. if not, for me, don't make sense and is impossible debuggin. i know the loongson architecture is something "rare" but i'm using it :-)

No. The base system was uploaded at that time. Likewise, the package build was uploaded at that time. It says nothing as to when a compile was finished. Because of the way bulk packages are built, the whole tree is built at once.
So it looks like this:
Install new snapshot->build the entire ports tree->upload all packages
For really fast architectures it might only take a day to build all the packages and therefore packages have a good chance of lining up. For loongson it means the smapshot used to build the packages is already a month old by the time the final packages are uploaded. But development doesn't stop (and neither does making newer snapshots).
TLDR: don't expect snapshots and snapshot packages to ever line up for slow archs.

[J65nko]

Sorry, but I cannot do anything about this

Please note, that you also cannot be sure that the dates are the file creation date. The date could be the time that they were uploaded or copied to the ftp server.

To handle this kind of situation I first do a test install in a Virtual Machine, or on another non-critical machine. I set the PKG_CACHE variable, so the packages are also saved.

Only if that install is successful, then I dare to install that new snapshot on my desktop.

Even using this method I have to use an installation method that does not use a "live" public ftp mirror, because there is not any guarantee that the contents of a ftp mirror has not changed or will change half-way during the second install

Maybe I should write a guide for new snapshot users, detailing the 'gotcha's' and precautions that you can take to prevent or work-around this type of situation.

One method is to keep an archive of older snapshots so I can use an older one:

ls -l /home/www/snapshots      
total 80
drwxr-xr-x  2 root  wheel  512 Feb 25 14:41 amd64
drwxr-xr-x  2 root  wheel  512 Feb  3 01:29 amd64.2015-02-01T20:52Z
drwxr-xr-x  2 root  wheel  512 Feb  2 22:01 amd64.2015-02-02T22:01Z
drwxr-xr-x  2 root  wheel  512 Feb  3 10:04 amd64.2015-02-03T10:04Z
drwxr-xr-x  2 root  wheel  512 Feb  8 02:40 amd64.2015-02-04T02:26Z
drwxr-xr-x  2 root  wheel  512 Feb 13 02:09 amd64.2015-02-07T17:32Z
drwxr-xr-x  2 root  wheel  512 Feb 16 01:46 amd64.2015-02-11T00:44Z
drwxr-xr-x  2 root  wheel  512 Feb 19 02:14 amd64.2015-02-13T20:30Z
drwxr-xr-x  2 root  wheel  512 Feb 22 00:13 amd64.2015-02-17T20:54Z
drwxr-xr-x  2 root  wheel  512 Feb 20 15:00 amd64.2015-02-20T15:00Z
drwxr-xr-x  2 root  wheel  512 Feb 22 11:30 amd64.2015-02-22T11:30Z

[IdOp]

Possibly a dumb question, but why don't the snapshot builders provide a copy of the snapshots that were used to do the building on their part of the site? Sure they may not be the latest, but for those who don't care about that it would avoid some sync problems. I'm not saying they should do this, just wondering why it seems they don't.

[ibara]

Saying you found a bug in a month old snapshot is just going to return "use the latest snapshot."
Eliminates one round of bug hunting.

[IdOp]

Originally Posted by ibara

Saying you found a bug in a month old snapshot is just going to return "use the latest snapshot."
Eliminates one round of bug hunting.

True. Though for those not continually updating to the latest snapshot, that extra round will likely be there anyway. But, yes, I can see that with -current being the development branch, they could want to steer people to using the latest at the point of entry.

Thank you for your helpful reply.

[fstef]

Originally Posted by ibara

It takes about 12 hours to build a loongson snapshot. It takes about a month to build packages. See the disconnect?


No. The base system was uploaded at that time. Likewise, the package build was uploaded at that time. It says nothing as to when a compile was finished. Because of the way bulk packages are built, the whole tree is built at once.
So it looks like this:
Install new snapshot->build the entire ports tree->upload all packages

i get it, so this means on a daily used loongson machine the best is using -release, -stable. following -current is a waste of time

Originally Posted by ibara

For really fast architectures it might only take a day to build all the packages and therefore packages have a good chance of lining up. For loongson it means the smapshot used to build the packages is already a month old by the time the final packages are uploaded. But development doesn't stop (and neither does making newer snapshots).
TLDR: don't expect snapshots and snapshot packages to ever line up for slow archs.

ok, but if this is the state of the art the process of build packages on top of snapshot in very slow architectures is usefull?

sorry, everytime i've a lot of questions but i really hope i can understand the OpenBSD world

thank you
fstef

[jggimi]

Originally Posted by fstef

...following -current is a waste of time

I disagree.

1. Following -current on sow architectures may require you to build your own ports more often than for fast architectures.
2. Following -current can require an extra effort for all users, of every architecture, when major library bumps occur. Major bumps are used when APIs change.

Prior to the advent of "snapshot packages" all -current users had to build their own ports. When these packages were first initiated as a service by the project, they were only available for the more popular architectures. All minor architecture users still had to build their own ports, and, the lucky users of snapshot packages still had to build them at the time of major library changes. We "fast" architecture users still have to build our own ports from time to time. I mentioned this in my post above.


If you never wish to build a port, you should not be a -current user, regardless of your architecture.

[ibara]

Originally Posted by IdOp

True. Though for those not continually updating to the latest snapshot, that extra round will likely be there anyway. But, yes, I can see that with -current being the development branch, they could want to steer people to using the latest at the point of entry.

There is a subtle but important difference between people happening to run outdated snapshots (which obviously we can't prevent) and implicitly saying "it's ok to be running this old snapshot" by having something old available for download.

Originally Posted by fstef

i get it, so this means on a daily used loongson machine the best is using -release, -stable. following -current is a waste of time

Following -current is absolutely not a waste of time. All of my loongson machines track -current.

Originally Posted by fstef

ok, but if this is the state of the art the process of build packages on top of snapshot in very slow architectures is usefull?

Extremely: we learn what builds, what doesn't (since a release is never more than 6 months away this is good to know). That's just one reason; there's actually a multitude of really good reasons even slow archs should be building full package sets between releases. (Think: catching bugs)

[fstef]

thank you everyone for the reply, really help me to understand a lot

fstef