Re: Pkg dependency strangeness

[Walter Parker]

I appear to have found a solution:

I used pkg check -d and it said

pecl-memcached2 has a missing dependency: php56-session
pecl-memcached2 has a missing dependency: php56-json
policyd2 has a missing dependency: php56-pdo_pgsql


php56-session dependency failed to be fixed
php56-json dependency failed to be fixed
php56-pdo_pgsql dependency failed to be fixed

So use pkg remove to delete pecl-memcached2 and policyd2 and now when I
use  pkg it appears to work as expected

[root@natasha /usr/local/etc/postfix]# pkg install alpine

New packages to be INSTALLED:
alpine: 2.21.

Number of packages to be installed: 1

The process will require 8 MiB more space.
2 MiB to be downloaded.




On Thu, Dec 27, 2018 at 2:04 PM Walter Parker  wrote:

> Hi Matthew,
>
> I ran pkg upgrade -n
>
> New packages to be INSTALLED:
> xorgproto: 2018.4
> wayland: 1.16.0
> libepoll-shim: 0.0.20180530
> libXtst: 1.2.3_2
> postgresql95-client: 9.5.15_2
> mysql56-client: 5.6.42_1
> php72-pdo_sqlite: 7.2.13
> (lots of p5-s)
>
> Installed packages to be UPGRADED:
> (lots of py36 s
> (lots of p5-s)
> dspam: 3.10.2_4 -> 3.10.2_5
> dovecot-pigeonhole: 0.4.21_1 -> 0.5.4_1
> dovecot: 2.2.33.2_4 -> 2.3.4_3
>
> Installed packages to be REINSTALLED:
> roundcube-php72-1.3.8_1,1 (options changed)
> php72-pgsql-7.2.13_1 (direct dependency changed:
> postgresql95-client)
> php72-pdo_pgsql-7.2.13_1 (direct dependency changed:
> postgresql95-client)
> php72-openssl-7.2.13 (direct dependency changed: php72)
>
> Note, the system is currently running postgresql96. I used postmaster to
> install the php72-pgsql & php72-pdo_pgsql ports and to install
> postgresql96-client and server.
>
> Ran pkg version -vRL=
> Found several ophaned packages, most seem be because I remove the
> xproto packages per the UPDATING instructions
> ImageMagick-nox11-6.9.9.28,1   ?   orphaned: graphics/ImageMagick-nox11
> bigreqsproto-1.1.2 ?   orphaned: x11/bigreqsproto
> Also, my X appears to be out of date (system runs headless so that is a
> lower concern)
> libXext-1.3.3_1,1  <   needs updating (remote has
> 1.3.3_3,1)
> libXfixes-5.0.3<   needs updating (remote has 5.0.3_2)
> libXfont-1.5.2,2   <   needs updating (remote has
> 1.5.4_2,2)
> libXft-2.3.2_1 <   needs updating (remote has 2.3.2_3)
> lha-1.14i_7?   orphaned: archivers/lha
> p5-Net-SMTP-SSL-1.04   ?   orphaned: mail/p5-Net-SMTP-SSL
> pecl-imagick-3.4.3_2   ?   orphaned: graphics/pecl-imagick
> pecl-memcached2-2.2.0_5?   orphaned: databases/pecl-memcached2
> roundcube-sieverules-2.1.2,1   ?   orphaned: mail/roundcube-sieverules
>
> When I run pkg install phppgadmin-php72, it tells me that I'm on the most
> recent version of the package. So I removed it and tried a reinstall
>
> [root@natasha /usr/ports/mail/postfixadmin]# pkg install phppgadmin-php72
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> The following 7 package(s) will be affected (of 0 checked):
>
> New packages to be INSTALLED:
> phppgadmin-php72: 5.1_5
> php56-session: 5.6.39
> php56: 5.6.39
> postgresql95-client: 9.5.15_2
> php56-json: 5.6.39
> php56-pdo_pgsql: 5.6.39_1
> php56-pdo: 5.6.39
>
> Number of packages to be installed: 7
>
> I stopped this and did a portmaster -B -D databases/phppgadmin it it
> installed
> ===>>> All dependencies are up to date
>
> ===>  Cleaning for phppgadmin-php72-5.1_5
> ===>  Cleaning for phppgadmin-php56-5.1_5
> ===>  Cleaning for phppgadmin-php71-5.1_5
> ===>  Cleaning for phppgadmin-php73-5.1_5
> # you can customize the installation directory
> # by setting PGADMDIR in /etc/make.conf
> ===>  License GPLv2 accepted by the user
> ===>   phppgadmin-php72-5.1_5 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by phppgadmin-php72-5.1_5 for building
> ===>  Extracting for phppgadmin-php72-5.1_5
> => SHA256 Checksum OK for phpPgAdmin-5.1.tar.bz2.
> ===>  Patching for phppgadmin-php72-5.1_5
>
>
> Thank you,
>
>
> Walter
>
> On Thu, Dec 27, 2018 at 5:08 AM Matthew Seaman 
> wrote:
>
>> On 27/12/2018 01:45, Walter Parker wrote:
>> > I've just upgraded an existing FreeBSD 11.1 system with php56 to FreeBSD
>> > 11.2 and php72.
>> >
>> > In order to do this, I used a mix of ports and packages to delete php56
>> and
>> > all of the php56 extensions and replace them with php72 and php72
>> > extensions. Everything is working now, but when I try to install
>> anything
>> > using pkg, it wants to reinstall php56 and serveral php56 extensions.
>> This
>> > happens for packages that don't have php56 as a dependency.
>> >
>> > For example
>> >  pkg install alpine
>> >
>>
>> As far as I can tell, this is 

Unable to build 12.0-STABLE release

[David Boyd]

While attempting to build 12.0-STABLE release images, the following
error message sequence occurs:

make[2]: don't know how to make CHECKSUM.SHA512-FreeBSD-12.0-STABLE-
amd64.asc. Stop.

make[2]: stopped in /usr/doc/en_US.ISO8859-1/htdocs/releases/12.0R
*** Error code 2

Stop.
make[1]: stopped in /usr/src/release
*** Error code 1

Stop.
make: stopped in /usr/src/release

The build of 12.0-RELEASE release images was successful.

The only change made to release.conf.sample was
CHROOTDIR="/u/1/scratch".

The host is 12.0-RELEASE-p1.

I don't have a log of the build, but will acquire one if that would be
useful.

Thanks.

David.



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error upgrading 11-STABLE to 12-STABLE in ifunc resolver

[Warner Losh]

On Thu, Dec 27, 2018, 4:11 PM Konstantin Belousov  On Thu, Dec 27, 2018 at 09:41:06PM +0100, Thierry Thomas wrote:
> > Hello,
> >
> > Trying to upgrade a machine from
> >
> > 11.2-STABLE #0 r337833: Wed Aug 15 12:50:47 CEST 2018
> >
> > to 12-STABLE as:
> >
> > Working Copy Root Path: /usr/src
> > URL: https://svn.freebsd.org/base/stable/12
> > Relative URL: ^/stable/12
> > Repository Root: https://svn.freebsd.org/base
> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > Revision: 342558
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: kp
> > Last Changed Rev: 342545
> > Last Changed Date: 2018-12-26 13:56:36 +0100 (Wed, 26 Dec 2018)
> >
> > aborts due to this error:
> >
> > /usr/local/libexec/ccache/world/cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -DNO__SCCSID
> -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include
> -I/usr/src/lib/libc/amd64 -DNLS  -D__DBINTERFACE_PRIVATE
> -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6
> -I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv
> -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd
> -I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime
> -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP
> -DNS_CACHING -DSYMBOL_VERSIONING -g -MD  -MF.depend.amd64_set_fsbase.o
> -MTamd64_set_fsbase.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unuse
>  d-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil
> -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src
> -c /usr/src/lib/libc/amd64/sys/amd64_set_fsbase.c -o amd64_set_fsbase.o
> > --- amd64_get_fsbase.o ---
> > /usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc
> resolver function must have no parameters
> > DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static)
> > ^
> > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note:
> expanded from macro 'DEFINE_UIFUNC'
> > qual ret_type name args __attribute__((ifunc(#name "_resolver")));  \
> >
> > cc is:
> > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
> LLVM 6.0.1)
> >
> > This problem has already been reported in
> > <
> https://lists.freebsd.org/pipermail/freebsd-current/2018-November/071980.html
> >
> > and should be fixed with clang 7, but I'm surprised that it seems
> > impossible to upgrade from 11-STABLE to 12-STABLE; did I miss something?
>
> Yes, you should update to the latest stable/11.  More details, you need
> to have host clang which includes the r339284 commit.
>

We either need to fix this problem, or we need to bump the minimum in
Makefile.inc1.

Warner

___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Pkg dependency strangeness

[Walter Parker]

Hi Matthew,

I ran pkg upgrade -n

New packages to be INSTALLED:
xorgproto: 2018.4
wayland: 1.16.0
libepoll-shim: 0.0.20180530
libXtst: 1.2.3_2
postgresql95-client: 9.5.15_2
mysql56-client: 5.6.42_1
php72-pdo_sqlite: 7.2.13
(lots of p5-s)

Installed packages to be UPGRADED:
(lots of py36 s
(lots of p5-s)
dspam: 3.10.2_4 -> 3.10.2_5
dovecot-pigeonhole: 0.4.21_1 -> 0.5.4_1
dovecot: 2.2.33.2_4 -> 2.3.4_3

Installed packages to be REINSTALLED:
roundcube-php72-1.3.8_1,1 (options changed)
php72-pgsql-7.2.13_1 (direct dependency changed:
postgresql95-client)
php72-pdo_pgsql-7.2.13_1 (direct dependency changed:
postgresql95-client)
php72-openssl-7.2.13 (direct dependency changed: php72)

Note, the system is currently running postgresql96. I used postmaster to
install the php72-pgsql & php72-pdo_pgsql ports and to install
postgresql96-client and server.

Ran pkg version -vRL=
Found several ophaned packages, most seem be because I remove the
xproto packages per the UPDATING instructions
ImageMagick-nox11-6.9.9.28,1   ?   orphaned: graphics/ImageMagick-nox11
bigreqsproto-1.1.2 ?   orphaned: x11/bigreqsproto
Also, my X appears to be out of date (system runs headless so that is a
lower concern)
libXext-1.3.3_1,1  <   needs updating (remote has 1.3.3_3,1)
libXfixes-5.0.3<   needs updating (remote has 5.0.3_2)
libXfont-1.5.2,2   <   needs updating (remote has 1.5.4_2,2)
libXft-2.3.2_1 <   needs updating (remote has 2.3.2_3)
lha-1.14i_7?   orphaned: archivers/lha
p5-Net-SMTP-SSL-1.04   ?   orphaned: mail/p5-Net-SMTP-SSL
pecl-imagick-3.4.3_2   ?   orphaned: graphics/pecl-imagick
pecl-memcached2-2.2.0_5?   orphaned: databases/pecl-memcached2
roundcube-sieverules-2.1.2,1   ?   orphaned: mail/roundcube-sieverules

When I run pkg install phppgadmin-php72, it tells me that I'm on the most
recent version of the package. So I removed it and tried a reinstall

[root@natasha /usr/ports/mail/postfixadmin]# pkg install phppgadmin-php72
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 7 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
phppgadmin-php72: 5.1_5
php56-session: 5.6.39
php56: 5.6.39
postgresql95-client: 9.5.15_2
php56-json: 5.6.39
php56-pdo_pgsql: 5.6.39_1
php56-pdo: 5.6.39

Number of packages to be installed: 7

I stopped this and did a portmaster -B -D databases/phppgadmin it it
installed
===>>> All dependencies are up to date

===>  Cleaning for phppgadmin-php72-5.1_5
===>  Cleaning for phppgadmin-php56-5.1_5
===>  Cleaning for phppgadmin-php71-5.1_5
===>  Cleaning for phppgadmin-php73-5.1_5
# you can customize the installation directory
# by setting PGADMDIR in /etc/make.conf
===>  License GPLv2 accepted by the user
===>   phppgadmin-php72-5.1_5 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by phppgadmin-php72-5.1_5 for building
===>  Extracting for phppgadmin-php72-5.1_5
=> SHA256 Checksum OK for phpPgAdmin-5.1.tar.bz2.
===>  Patching for phppgadmin-php72-5.1_5


Thank you,


Walter

On Thu, Dec 27, 2018 at 5:08 AM Matthew Seaman  wrote:

> On 27/12/2018 01:45, Walter Parker wrote:
> > I've just upgraded an existing FreeBSD 11.1 system with php56 to FreeBSD
> > 11.2 and php72.
> >
> > In order to do this, I used a mix of ports and packages to delete php56
> and
> > all of the php56 extensions and replace them with php72 and php72
> > extensions. Everything is working now, but when I try to install anything
> > using pkg, it wants to reinstall php56 and serveral php56 extensions.
> This
> > happens for packages that don't have php56 as a dependency.
> >
> > For example
> >  pkg install alpine
> >
>
> As far as I can tell, this is nothing to do with alpine itself, which
> doesn't seem to depend on PHP at all.  My guess is that you have some
> other PHP-based application installed which has an unmet dependency on
> php56.
>
> If you run 'pkg upgrade -n' without trying to install anything new, what
> happens?  Also try 'pkg version -vRL=' Do you have any orphaned packages?
>
> See if you can work out what it is you've installed that wants to pull
> in php56.  Judging by the dependencies in your original post, it could
> be something like databases/phppgadmin or a similar PHP application that
> uses a postgresql back-end. I'm going to use phppgadmin as the example
> package in what follows: you should substitute the actual package or
> packages that are relevant in your case.
>
> What can happen is the pkg(8) fails to handle the change from an
> unflavoured PHP package to a flavoured one.  It doesn't grok that an
> un-flavoured 'phppgadmin' package was essentially the same 

Re: Error upgrading 11-STABLE to 12-STABLE in ifunc resolver

[Konstantin Belousov]

On Thu, Dec 27, 2018 at 09:41:06PM +0100, Thierry Thomas wrote:
> Hello,
> 
> Trying to upgrade a machine from
> 
> 11.2-STABLE #0 r337833: Wed Aug 15 12:50:47 CEST 2018
> 
> to 12-STABLE as:
> 
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/stable/12
> Relative URL: ^/stable/12
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 342558
> Node Kind: directory
> Schedule: normal
> Last Changed Author: kp
> Last Changed Rev: 342545
> Last Changed Date: 2018-12-26 13:56:36 +0100 (Wed, 26 Dec 2018)
> 
> aborts due to this error:
> 
> /usr/local/libexec/ccache/world/cc -target x86_64-unknown-freebsd12.0 
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -DNO__SCCSID 
> -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include 
> -I/usr/src/lib/libc/amd64 -DNLS  -D__DBINTERFACE_PRIVATE 
> -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 
> -I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv 
> -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd 
> -I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime 
> -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP 
> -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING 
> -DSYMBOL_VERSIONING -g -MD  -MF.depend.amd64_set_fsbase.o 
> -MTamd64_set_fsbase.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
> -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign 
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
> -Wno-tautological-compare -Wno-unuse
 d-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 
-I/usr/src/lib/msun/src -c /usr/src/lib/libc/amd64/sys/amd64_set_fsbase.c -o 
amd64_set_fsbase.o
> --- amd64_get_fsbase.o ---
> /usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc resolver 
> function must have no parameters
> DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static)
> ^
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: 
> expanded from macro 'DEFINE_UIFUNC'
> qual ret_type name args __attribute__((ifunc(#name "_resolver")));  \
> 
> cc is:
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
> 6.0.1)
> 
> This problem has already been reported in
> 
> and should be fixed with clang 7, but I'm surprised that it seems
> impossible to upgrade from 11-STABLE to 12-STABLE; did I miss something?

Yes, you should update to the latest stable/11.  More details, you need
to have host clang which includes the r339284 commit.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Error upgrading 11-STABLE to 12-STABLE in ifunc resolver

[Thierry Thomas]

Hello,

Trying to upgrade a machine from

11.2-STABLE #0 r337833: Wed Aug 15 12:50:47 CEST 2018

to 12-STABLE as:

Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/stable/12
Relative URL: ^/stable/12
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 342558
Node Kind: directory
Schedule: normal
Last Changed Author: kp
Last Changed Rev: 342545
Last Changed Date: 2018-12-26 13:56:36 +0100 (Wed, 26 Dec 2018)

aborts due to this error:

/usr/local/libexec/ccache/world/cc -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -DNO__SCCSID 
-DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include 
-I/usr/src/lib/libc/amd64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 
-I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd 
-I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime 
-I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING 
-DSYMBOL_VERSIONING -g -MD  -MF.depend.amd64_set_fsbase.o -MTamd64_set_fsbase.o 
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 
-I/usr/src/lib/msun/src -c /usr/src/lib/libc/amd64/sys/amd64_set_fsbase.c -o 
amd64_set_fsbase.o
--- amd64_get_fsbase.o ---
/usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc resolver 
function must have no parameters
DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static)
^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: expanded 
from macro 'DEFINE_UIFUNC'
qual ret_type name args __attribute__((ifunc(#name "_resolver")));  \

cc is:
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
6.0.1)

This problem has already been reported in

and should be fixed with clang 7, but I'm surprised that it seems
impossible to upgrade from 11-STABLE to 12-STABLE; did I miss something?

Thanks.
-- 
Th. Thomas.


signature.asc
Description: PGP signature

Re: Success updating stable/11 to /12; a couple things to note

[David Wolfskill]

On Thu, Dec 27, 2018 at 10:56:57AM -0700, Ian Lepore wrote:
>  
> I must have missed the part where you were using DESTDIR= during the
> install. In that case, the right magic is to add DB_FROM_SRC=yes to the
> make installworld command. There were a couple proposals to automate
> that somehow, but I didn't see anything proposed that didn't basically
> subvert the entire purpose of that check for whether the user exists.
> 
> -- Ian
> 

Ah; good to knw: thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Beyond some threshold, should presidential lies become impeachable offenses?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Success updating stable/11 to /12; a couple things to note

[Ian Lepore]

On Thu, 2018-12-27 at 08:30 -0800, David Wolfskill wrote:
> On Thu, Dec 27, 2018 at 09:13:09AM -0700, Ian Lepore wrote:
> > 
> > On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote:
> > > 
> > > * I found that I actually needed to create the ntpd user on the
> > >   running system prior to "make installworld" -- having run
> > >   "mergemaster -U" against the target (DESTDIF) was insufficient.
> > The correct update sequence involves running mergemaster twice,
> > once
> > with the -p option, then again later without it. It's detailed at
> > the
> > bottom of UPDATING. People get in the habit of skipping the -p step
> > because it's only really needed once every few years, such as when
> > a
> > new user is added to the base system.
> > 
> > -- Ian
> > 
> Yes, but the one after "make installworld" isn't likely to affect the
> "make installworld".  :-)
> 
> The sequence of events:
> 
> mount -u -r /
> mount -u -r /usr
> mount /dev/ada0s1a /S1
> mount /dev/ada0s1d /S1/usr
> mount -u -w /S1
> mount -u -w /S1/usr
> ln -fhs /var /S1/var
> mount -o ro freebeast:/usr/src /usr/src
> mount -o ro freebeast:/usr/obj /usr/obj
> id
> mount
> cd /usr/src
> uname -a
> date
> make LD=ld.lld installkernel DESTDIR=/S1
> date
> mergemaster -U -u 0022 -p -D /S1
> date
> rm -fr /S1/usr/include.old
> date
> mv -f /S1/usr/include /S1/usr/include.old
> date
> rm -fr /S1/usr/share/man
> date
> make installworld DESTDIR=/S1
> date
> mergemaster -F -U -u 0022 -i -D /S1
> date
> make delete-old DESTDIR=/S1
> date
> date
> df -k
> date
> 
> 
> My point was that running "mergemaster -U" against the new image
> (/S1,
> in the case above) is not sufficient for "make installworld
> DESTDIR=/S!"
> to work: it is necessary that the *running* system be aware of the
> "ntpd" user (I presume, to allow ownership of files to be set by the
> "ntpd" name, vs. the numeric "123").
> 
> Peace,
> david


I must have missed the part where you were using DESTDIR= during the
install. In that case, the right magic is to add DB_FROM_SRC=yes to the
make installworld command. There were a couple proposals to automate
that somehow, but I didn't see anything proposed that didn't basically
subvert the entire purpose of that check for whether the user exists.

-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Success updating stable/11 to /12; a couple things to note

[David Wolfskill]

On Thu, Dec 27, 2018 at 09:13:09AM -0700, Ian Lepore wrote:
> On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote:
> > * I found that I actually needed to create the ntpd user on the
> >   running system prior to "make installworld" -- having run
> >   "mergemaster -U" against the target (DESTDIF) was insufficient.
> 
> The correct update sequence involves running mergemaster twice, once
> with the -p option, then again later without it. It's detailed at the
> bottom of UPDATING. People get in the habit of skipping the -p step
> because it's only really needed once every few years, such as when a
> new user is added to the base system.
> 
> -- Ian
> 

Yes, but the one after "make installworld" isn't likely to affect the
"make installworld".  :-)

The sequence of events:

mount -u -r /
mount -u -r /usr
mount /dev/ada0s1a /S1
mount /dev/ada0s1d /S1/usr
mount -u -w /S1
mount -u -w /S1/usr
ln -fhs /var /S1/var
mount -o ro freebeast:/usr/src /usr/src
mount -o ro freebeast:/usr/obj /usr/obj
id
mount
cd /usr/src
uname -a
date
make LD=ld.lld installkernel DESTDIR=/S1
date
mergemaster -U -u 0022 -p -D /S1
date
rm -fr /S1/usr/include.old
date
mv -f /S1/usr/include /S1/usr/include.old
date
rm -fr /S1/usr/share/man
date
make installworld DESTDIR=/S1
date
mergemaster -F -U -u 0022 -i -D /S1
date
make delete-old DESTDIR=/S1
date
date
df -k
date


My point was that running "mergemaster -U" against the new image (/S1,
in the case above) is not sufficient for "make installworld DESTDIR=/S!"
to work: it is necessary that the *running* system be aware of the
"ntpd" user (I presume, to allow ownership of files to be set by the
"ntpd" name, vs. the numeric "123").

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Beyond some threshold, should presidential lies become impeachable offenses?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Success updating stable/11 to /12; a couple things to note

[Ian Lepore]

On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote:
> * I found that I actually needed to create the ntpd user on the
>   running system prior to "make installworld" -- having run
>   "mergemaster -U" against the target (DESTDIF) was insufficient.

The correct update sequence involves running mergemaster twice, once
with the -p option, then again later without it. It's detailed at the
bottom of UPDATING. People get in the habit of skipping the -p step
because it's only really needed once every few years, such as when a
new user is added to the base system.

-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mps and LSI SAS2308: controller resets on 12.0 - IOC Fault 0x40000d04, Resetting

[Mark Martinec]

2018-12-26 22:26, Terry Kennedy wrote:

The earlier LSI P20 releases were pretty flakey in some cases - try
flashing 20.00.07.00.



Indeed.

I have upgraded LSI SAS2308 firmware from 20.00.02.00 to 20.00.07.00
a week ago, left it running for a while with 11.2, then upgraded again
to 12.0, and the controller is stable now, even with the new mps driver
that came with 12.0.

To recap:

 - mps driver from FreeBSD 11.2 and earlier is stable with SAS2308 
firmware

   20.00.02.00 _and_ 20.00.07.00

 - mps driver from FreeBSD 12.0 causes frequent controller resets
   with SAS2308 firmware 20.00.02.00 (and ZFS can't cope with that),
   but is stable with 20.00.07.00.

Mark




2018-12-17 16:52, je Mark Martinec napisal

One of our servers that was upgraded from 11.2 to 12.0 (to RC2
initially, then to RC3
and lastly to a 12.0-RELEASE) is suffering severe instability of a
disk controller,
resetting itself a couple of times a day, usually associated with high
disk usage
(like poudriere buils or zfs scrub or nightly file system scans). The 
same setup

was rock-solid under 11.2 (and still/again is).

The disk controller is LSI SAS2308. It has four disks attached as 
JBODs,
one pair of SSDs and one pair of hard disks, each pair forming its own 
zpool.

A controller reset can occur regardless of which pair is in heavy use.

The following can be found in logs, just before machine becomes 
unusable
(although not logged always, as disks may be dropped before syslog has 
a chance

of writing anything):

  xxx kernel: [2382] mps0: IOC Fault 0x4d04, Resetting
  xxx kernel: [2382] mps0: Reinitializing controller
  xxx kernel: [2383] mps0: Firmware: 20.00.02.00, Driver: 
21.02.00.00-fbsd

  xxx kernel: [2383] mps0: IOCCapabilities:
5a85c
  xxx kernel: [2383] (da0:mps0:0:0:0): Invalidating pack

The IOC Fault location is always the same. Apparently the disk
controller resets,
all disk devices are dropped and ZFS finds itself with no disks. The
machine still
responds to ping, and if logged-in during the event and running zpool
status -v 1,
zfs reports loss of all devices for each pool:

  pool: data0
 state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
 action: Make sure the affected devices are connected, then run 'zpool 
clear'.

   see: http://illumos.org/msg/ZFS-8000-HC
   scan: scrub repaired 0 in 0 days 03:53:41 with 0 errors on Sat Nov
17 00:22:38 2018
config:

NAME  STATE READ WRITE CKSUM
data0 UNAVAIL  0 0 0
  mirror-0UNAVAIL  024 0
 2396428274137360341   REMOVED  0 0 0  was
/dev/gpt/da2-PN1334PCKAKD4S
 16738407333921736610  REMOVED  0 0 0  was
/dev/gpt/da3-PN2338P4GJ1XYC

(and similar for the other pool)

At this point the machine is unusable and needs to be hard-reset.

My guess is that after the controller resets, disk devices come up 
again
(according to the report seen on the console, stating 'periph 
destroyed'

first, then listing full info on each disk) - but zfs ignores them.

I don't see any mention of changes of the mps driver in the 12.0 
release notes,
although diff-ing its sources between 11.2 and 12.0 shows plenty of 
nontrivial

changes.

After suffering this instability for some time, I finally downgraded 
the OS

to 11.2, and things are back to normal again!

This downgrade path was nontrivial, as I have foolishly upgraded pool 
features
to what comes with 12.0, so downgrading involved hacking with 
dismantling

both zfs mirror pools, recreating pools without the two new features,
zfs send/receive copying, while having a machine hang during some of
these operations. Not something for the faint at heart. I know, foolish
of me to upgrade pools after just one day of uptime with 12.0.

Some info on the controller:

kernel: mps0:  port 0xf000-0xf0ff
mem 0xfbe4-
  0xfbe4,0xfbe0-0xfbe3 irq 64 at device 0.0 numa-domain 1 
on pci11

kernel: mps0: Firmware: 20.00.02.00, Driver: 21.02.00.00-fbsd

mpsutil shows:

  mps0 Adapter:
Board Name: LSI2308-IT
Board Assembly:
Chip Name: LSISAS2308
Chip Revision: ALL
BIOS Revision: 7.39.00.00
Firmware Revision: 20.00.02.00
Integrated RAID: no


So, what has changed in the mps driver for this to be happening?
Would it be possible to take mps driver sources from 11.2, transplant
them to 12.0, recompile, and use that? Could the new mps driver be
using some new feature of the controller and hits a firmware bug?
I have resisted upgrading SAS2308 firmware and its BIOS, as it is
working very well under 11.2.

Anyone else seen problems with mps driver and LSI SAS2308 controller?

(btw, on another machine the mps driver with LSI SAS2004 is working
just fine under 12.0)

  Mark

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail 

Re: firefox-64.0_3,1 SEGV in stable/12 @r342472

[David Wolfskill]

After a refresh of stable/12 to r342545, I no longer see the issue.

FWIW, ports updated yesterday were:

Upgrade of eigen-3.3.5 to eigen-3.3.7
Upgrade of orc-0.4.25 to orc-0.4.28
Upgrade of ImageMagick6-6.9.10.16,1 to ImageMagick6-6.9.10.20,1
Upgrade of qt5-network-5.12.0_2 to qt5-network-5.12.0_3

and this morning:

Upgrade of libatomic_ops-7.6.4 to libatomic_ops-7.6.8
Upgrade of boehm-gc-7.6.8_1 to boehm-gc-8.0.2
Upgrade of libva-2.3.0_1 to libva-2.3.0_2
Upgrade of ffmpeg-4.1_2,1 to ffmpeg-4.1_3,1
Installation of devel/libinotify (libinotify-20180201_1)
Upgrade of openjdk8-8.192.26_1 to openjdk8-8.192.26_3
Upgrade of py27-sphinx_rtd_theme-0.4.0 to py27-sphinx_rtd_theme-0.4.2
Upgrade of groff-1.22.3_1 to groff-1.22.4
Upgrade of mutt-1.11.1 to mutt-1.11.1_1

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Yes, Mr. Trump, your behavior IS a disgrace -- to put it very nicely.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Success updating stable/11 to /12; a couple things to note

[David Wolfskill]

I update my "production" systems here at home by use of a dedicated
(non-production) "build machine," mounting its /usr/src & /usr/obj
read-only via NFS and performing (essentially) "make installkernel"
and "make installworld" -- details on the process may be found at


I finally got my test machine operational again, and used it to test the
above process for upgrading from stable/11 to stable/12.

I'm happy to report success. :-)

I did encounter some bumps along the way; perhaps pointing them out now
may help someone else avoid them later on, so:

* I needed to change the script I use for performing the "make
  installkernel" so instead of:

make installkernel DESTDIR=${DESTDIR}

  it does:

make LD=ld.lld installkernel DESTDIR=${DESTDIR}


* I found that I actually needed to create the ntpd user on the
  running system prior to "make installworld" -- having run
  "mergemaster -U" against the target (DESTDIF) was insufficient.


* I needed to tell the build machine to actually build the additional
  .cf files for the target systems.  (Yes, I still use sendmail.
  Intentioanlly.)

That last is probably not something many others would encounter...  :-)

For amusement, here are the "uname -a" outputs from "before" and "after":

FreeBSD pogo.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #848  
r342366M/342366: Sat Dec 22 03:35:40 PST 2018 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64

FreeBSD pogo.catwhisker.org 12.0-STABLE FreeBSD 12.0-STABLE #63 
r342545M/342550: Thu Dec 27 03:50:26 PST 2018 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/ALBERT  
amd64


(Note that I have not yet updated the installed ports; I have the
misc/compat11x port installed (via a locally-built package).  I expect
to perform that part of the upgrade after a week or so of "shakedown.")

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Yes, Mr. Trump, your behavior IS a disgrace -- to put it very nicely.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Pkg dependency strangeness

[Matthew Seaman]

On 27/12/2018 01:45, Walter Parker wrote:
> I've just upgraded an existing FreeBSD 11.1 system with php56 to FreeBSD
> 11.2 and php72.
> 
> In order to do this, I used a mix of ports and packages to delete php56 and
> all of the php56 extensions and replace them with php72 and php72
> extensions. Everything is working now, but when I try to install anything
> using pkg, it wants to reinstall php56 and serveral php56 extensions. This
> happens for packages that don't have php56 as a dependency.
> 
> For example
>  pkg install alpine
> 

As far as I can tell, this is nothing to do with alpine itself, which
doesn't seem to depend on PHP at all.  My guess is that you have some
other PHP-based application installed which has an unmet dependency on
php56.

If you run 'pkg upgrade -n' without trying to install anything new, what
happens?  Also try 'pkg version -vRL=' Do you have any orphaned packages?

See if you can work out what it is you've installed that wants to pull
in php56.  Judging by the dependencies in your original post, it could
be something like databases/phppgadmin or a similar PHP application that
uses a postgresql back-end. I'm going to use phppgadmin as the example
package in what follows: you should substitute the actual package or
packages that are relevant in your case.

What can happen is the pkg(8) fails to handle the change from an
unflavoured PHP package to a flavoured one.  It doesn't grok that an
un-flavoured 'phppgadmin' package was essentially the same thing as
'phppgadmin-php56' and also that 'phppgadmin-php56' can be replaced by
'phppgadmin-php72'. You need to prod it into doing the right thing by
making it install exactly the flavour of phppgadmin you want.

So, assuming phppgadmin was the culprit, you simply need to run 'pkg
install phppgadmin-php72'

Cheers,

Matthew







signature.asc
Description: OpenPGP digital signature