New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkg 1.8.7 looks broken #1451

Closed
msiebeneicher opened this Issue Jul 6, 2016 · 12 comments

Comments

Projects
None yet
5 participants
@msiebeneicher

msiebeneicher commented Jul 6, 2016

We recognized that since this night some of our package installation are broken. It's looks like that this is related to pkg 1.8.7.

# uname -a
FreeBSD vagrant-api-trv 10.2-RELEASE-p18 FreeBSD 10.2-RELEASE-p18 #0: Sat May 28 08:53:43 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

# pkg --version
1.8.7

# pkg install -y p5-Socket
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating SaltStack repository catalogue...
SaltStack repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    p5-Socket: 2.021 [FreeBSD]

Number of packages to be installed: 1
[1/1] Installing p5-Socket-2.021...
[1/1] Extracting p5-Socket-2.021:   0%/usr/local/lib/libpkg.so.3: Undefined symbol "utimensat"

Because your travis-ci build also fail with a similar error message this issues looks pkg related: https://travis-ci.org/freebsd/pkg/jobs/140207378

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jul 6, 2016

Member

travis is onrelated it is broken for other various reasons (and testing non freebsd targets)

the configure script check if you are building on a system that supports utimensat, if you end up with that issue it is because you are using a version of pkg that has been built on a system with utimensat but running on a system without.

given utimensat was introduced in freebsd 10.3 that means you may have built it on 10.3 and run it on 10.2, which is a non supported configuration.

Note that on the official repositories it is built on 10.1 which will run perfectly fine on 10.2

Member

bapt commented Jul 6, 2016

travis is onrelated it is broken for other various reasons (and testing non freebsd targets)

the configure script check if you are building on a system that supports utimensat, if you end up with that issue it is because you are using a version of pkg that has been built on a system with utimensat but running on a system without.

given utimensat was introduced in freebsd 10.3 that means you may have built it on 10.3 and run it on 10.2, which is a non supported configuration.

Note that on the official repositories it is built on 10.1 which will run perfectly fine on 10.2

@msiebeneicher

This comment has been minimized.

Show comment
Hide comment
@msiebeneicher

msiebeneicher Jul 6, 2016

We are using the official portstree 'http://pkg.freebsd.org/freebsd:10:x86:64/quarterly/' for the first initial bootstrapiing of our VMs, which was updated yesterday.

Did that means that we can't use that anymore if they are using a FreeBSD >= 10.3 for compiling the packages?

msiebeneicher commented Jul 6, 2016

We are using the official portstree 'http://pkg.freebsd.org/freebsd:10:x86:64/quarterly/' for the first initial bootstrapiing of our VMs, which was updated yesterday.

Did that means that we can't use that anymore if they are using a FreeBSD >= 10.3 for compiling the packages?

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jul 6, 2016

Member

not at all
the official packages from the quarterly branch should be built on 10.1 there is no reason that this happens I will dig into it and come back to you

Member

bapt commented Jul 6, 2016

not at all
the official packages from the quarterly branch should be built on 10.1 there is no reason that this happens I will dig into it and come back to you

@msiebeneicher

This comment has been minimized.

Show comment
Hide comment
@msiebeneicher

msiebeneicher Jul 6, 2016

@bapt perfect - thx alot! in the meantime we can confirm that everything working fine with FreeBSD 10.3

msiebeneicher commented Jul 6, 2016

@bapt perfect - thx alot! in the meantime we can confirm that everything working fine with FreeBSD 10.3

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jul 6, 2016

Member

pkg 1.8.7 is yet available in the quarterly branches at the time I'm writting so you did not get the package from the official repo

I do not know where you are getting your 1.8.7 package from but it was not built on the cluster for sure and probably have been built on a FreeBSD 10.3

Member

bapt commented Jul 6, 2016

pkg 1.8.7 is yet available in the quarterly branches at the time I'm writting so you did not get the package from the official repo

I do not know where you are getting your 1.8.7 package from but it was not built on the cluster for sure and probably have been built on a FreeBSD 10.3

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jul 6, 2016

Member

quarterly packages that is

Member

bapt commented Jul 6, 2016

quarterly packages that is

@msiebeneicher

This comment has been minimized.

Show comment
Hide comment
@msiebeneicher

msiebeneicher Jul 6, 2016

ah - looks like that the saltstack bootstrap script adding also a own package repository: http://repo.saltstack.com/freebsd/10amd64-default/

maybe there is the issue.

update: yes - pkg 1.8.7 can be found there: http://repo.saltstack.com/freebsd/10amd64-default/

msiebeneicher commented Jul 6, 2016

ah - looks like that the saltstack bootstrap script adding also a own package repository: http://repo.saltstack.com/freebsd/10amd64-default/

maybe there is the issue.

update: yes - pkg 1.8.7 can be found there: http://repo.saltstack.com/freebsd/10amd64-default/

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jul 6, 2016

Member

and they do probably built their repo on FreeBSD 10.3

Member

bapt commented Jul 6, 2016

and they do probably built their repo on FreeBSD 10.3

@bapt bapt closed this Jul 6, 2016

@msiebeneicher

This comment has been minimized.

Show comment
Hide comment
@msiebeneicher

msiebeneicher Jul 6, 2016

ok - i will create them an issue with a link to this conversation.
thx alot for your investigation!

msiebeneicher commented Jul 6, 2016

ok - i will create them an issue with a link to this conversation.
thx alot for your investigation!

@wedgemartin

This comment has been minimized.

Show comment
Hide comment
@wedgemartin

wedgemartin Jan 28, 2017

Just updated pkg and seeing this problem on FreeBSD buh.shutdown.com 10.2-RELEASE-p14 FreeBSD 10.2-RELEASE-p14 #0: Wed Mar 16 20:46:12 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

wedgemartin commented Jan 28, 2017

Just updated pkg and seeing this problem on FreeBSD buh.shutdown.com 10.2-RELEASE-p14 FreeBSD 10.2-RELEASE-p14 #0: Wed Mar 16 20:46:12 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

@infracaninophile

This comment has been minimized.

Show comment
Hide comment
@infracaninophile

infracaninophile Jan 28, 2017

Member

10.2-RELEASE is out of support, which means that official FreeBSD packages are being built on 10.3-RELEASE now. Consequently the pkg binary is using the utimensat(2) function available in libc from 10.3-RELEASE onwards. This means the compiled version of pkg in the official FreeBSD pkg repositories will not work on 10.2-RELEASE or older.

You have two choices:

  1. Compile pkg yourself from ports

  2. Upgrade to at least 10.3-RELEASE

Member

infracaninophile commented Jan 28, 2017

10.2-RELEASE is out of support, which means that official FreeBSD packages are being built on 10.3-RELEASE now. Consequently the pkg binary is using the utimensat(2) function available in libc from 10.3-RELEASE onwards. This means the compiled version of pkg in the official FreeBSD pkg repositories will not work on 10.2-RELEASE or older.

You have two choices:

  1. Compile pkg yourself from ports

  2. Upgrade to at least 10.3-RELEASE

@glaszig

This comment has been minimized.

Show comment
Hide comment
@glaszig

glaszig Feb 18, 2017

i hate to tell you folks but the actual solution to this problem is easier than upgrading the entire os:

# freebsd-version
10.2-RELEASE-p10

# pkg --versoin
1.9.4

# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  enabled: yes
}

# pkg delete -f pkg
# pkg install -y pkg
# pkg --version
1.5.4

http://glasz.org/sheeplog/2017/02/freebsd-usrlocalliblibpkgso3-undefined-symbol-utimensat.html

glaszig commented Feb 18, 2017

i hate to tell you folks but the actual solution to this problem is easier than upgrading the entire os:

# freebsd-version
10.2-RELEASE-p10

# pkg --versoin
1.9.4

# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  enabled: yes
}

# pkg delete -f pkg
# pkg install -y pkg
# pkg --version
1.5.4

http://glasz.org/sheeplog/2017/02/freebsd-usrlocalliblibpkgso3-undefined-symbol-utimensat.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment