pkg(8) fails to upgrade to different branches of software

[Ben Woods]

Hi everyone,

The recent change of postgresql default version from 9.3 to 9.5 in r444116
required pkg to replace any postgresql93-* packages with postgresql95-*
packages, and also reinstall any ports which changed their dependency from
the 93 version to the 95 version.

This did not succeed automatically with "pkg upgrade -y" as can be seen
below. I realise the UPDATING entry explained to first remove the old
packages and then install the new packages, but I would like to ask if
there is a way this can be improved so it works automatically, and if there
is a plan in place to improve this?

This problem appears to have 2 issues:
1. pkg is not recognising the CONFLICTS when initially determining the
upgrade path (they are specified in the master port
databases/postgresql92-server/Makefile)
2. once the packages have been fetched and pkg notices the file conflict,
the solver does not decide to remove the pkg with the lower version

# pkg upgrade -y
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
All repositories are up to date.
Checking for upgrades (8 candidates):  done
Processing candidates (8 candidates): 
done
The following 9 package(s) will be affected (of 0
checked):

New packages to be INSTALLED:
postgresql95-client: 9.5.7 [FreeBSD-ports]

Installed packages to be UPGRADED:
vim: 8.0.0642 -> 8.0.0670 [FreeBSD-ports]
qt5-script: 5.7.1_1 -> 5.7.1_2 [FreeBSD-ports]
llvm40: 4.0.1.r1_5 -> 4.0.1 [FreeBSD-ports]
libreoffice: 5.3.3_2 -> 5.3.4 [FreeBSD-ports]
gutenprint: 5.2.12_1 -> 5.2.12_2 [FreeBSD-ports]
freebsd-release-manifests: 20170617 -> 20170624 [FreeBSD-ports]

Installed packages to be REINSTALLED:
rubygem-pg-0.21.0 [FreeBSD-ports] (direct dependency changed:
postgresql95-client)
gimp-gutenprint-5.2.12 [FreeBSD-ports] (direct dependency changed:
perl5)

Number of packages to be installed: 1
Number of packages to be upgraded: 6
Number of packages to be reinstalled: 2

The process will require 10 MiB more space.
370 MiB to be downloaded.
[1/9] Fetching vim-8.0.0670.txz: .. done
[2/9] Fetching rubygem-pg-0.21.0.txz: .. done
[3/9] Fetching qt5-script-5.7.1_2.txz: .. done
[4/9] Fetching llvm40-4.0.1.txz: .. done
[5/9] Fetching libreoffice-5.3.4.txz: .. done
[6/9] Fetching gutenprint-5.2.12_2.txz: .. done
[7/9] Fetching gimp-gutenprint-5.2.12.txz: .. done
[8/9] Fetching freebsd-release-manifests-20170624.txz: ... done
[9/9] Fetching postgresql95-client-9.5.7.txz: .. done
Checking integrity... done (1 conflicting)
  - postgresql95-client-9.5.7 [FreeBSD-ports] conflicts with
postgresql93-client-9.3.17 [installed] on /usr/local/bin/clusterdb
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 12 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
postgresql95-client: 9.5.7 [FreeBSD-ports]

Installed packages to be UPGRADED:
gutenprint: 5.2.12_1 -> 5.2.12_2 [FreeBSD-ports]
vim: 8.0.0642 -> 8.0.0670 [FreeBSD-ports]
qt5-script: 5.7.1_1 -> 5.7.1_2 [FreeBSD-ports]
llvm40: 4.0.1.r1_5 -> 4.0.1 [FreeBSD-ports]
libreoffice: 5.3.3_2 -> 5.3.4 [FreeBSD-ports]
freebsd-release-manifests: 20170617 -> 20170624 [FreeBSD-ports]

Installed packages to be REINSTALLED:
pkg-1.10.1 [FreeBSD-ports]
rubygem-pg-0.21.0 [FreeBSD-ports] (direct dependency changed:
postgresql95-client)
gimp-gutenprint-5.2.12 [FreeBSD-ports] (direct dependency changed:
perl5)

Number of packages to be installed: 1
Number of packages to be upgraded: 6
Number of packages to be reinstalled: 3

The process will require 10 MiB more space.
3 MiB to be downloaded.
[1/12] Fetching pkg-1.10.1.txz: .. done
[1/12] Fetching postgresql93-client-9.3.17.txz: .. done
[1/12] Deinstalling postgresql93-client-9.3.17...
Deleting files for postgresql93-client-9.3.17: .. done
[1/12] Upgrading gutenprint from 5.2.12_1 to
5.2.12_2...

Extracting gutenprint-5.2.12_2: .. done
[1/12] Installing postgresql95-client-9.5.7...
Extracting postgresql95-client-9.5.7: .. done
Installing postgresql93-client-9.3.17...
pkg: postgresql93-client-9.3.17 conflicts with
postgresql95-client-9.5.7 (installs files into the same place).
Problematic file: /usr/local/bin/clusterdb



Note that this appears to effectively remove the old postgresql93-client
port, so a subsequent pkg run succeeds:

# pkg info | grep postgres
postgresql95-client-9.5.7  PostgreSQL database (client)
rubygem-postgres_ext-3.0.0 PostgreSQL data types ext

lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

[Mark Millard]

The following is based mostly on an extraction from a
private exchange in which a question was asked and my
answer was unsettling: incompatibilities within the
11.* family. I would not normally send to re but doing
so was explicitly mentioned. Hopefully this example is
reasonable for doing that.


Aspect #0: what is broken currently (and in the future?)
   within the 11.* family?

lang/gcc* packages built on release/11.0.1/ to not work
fully on stable/11/ or on the drafts of
release/11.1.0/ . (I leave releng/11.*/'s implicit.)

-r313194 in head and was describied with:

> Define the vm_ooffset_t and vm_pindex_t types as machine-independend.
> 
> The types are for the byte offset and page index in vm object.  They
> are similar to off_t, which is defined as 64bit MI integer.  Using MI
> definitions will allow to provide consistent MD values of vm
> object-related maximum sizes.

The known issue is the generation of header dependencies
in the lang/gcc* builds on release/11.0.1/ that when
used on stable/11/ or release/11.0.1/ generate reports
like:

/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9:
 error: '__vm_ooffset_t' does not name a type
typedef __vm_ooffset_t vm_ooffset_t;
^
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9:
 error: '__vm_pindex_t' does not name a type
typedef __vm_pindex_t vm_pindex_t;
^
*** [CoinFactorization2.lo] Error code 1

Unfortunately UPDATING was not updated
for head/'s -r313194 (2017-Feb-4) --nor for
stable/11/'s -r313574 (2017-Feb-11), the MFC.
(No MFC was made to stable/10/ or to
release/10.3.0 as far as I found.)

(These changes predate the INO64 issue in head/ .
Head ends up with more issues than I'm dealing
with here.)


Aspect #1: what 11.* version builds the pre-built packages
   targeting 11.* and the apparent consequences
   (given the vm_ooffset_t and vm_pindex_t changes
and the lang/gcc* build behavior)

This is the unsettling part for pre-built
packages:  incompatibilities within the 11.*
family for the lang/gcc* packages.

http://portsmon.freebsd.org/portoverview.py?category=%3Bamng=gcc5=

shows categories for builds for

8.4
9.3
10.1
10.3
11.0
head

(Nothing for stable/*/ .)

But the 10.3 rows show no package
builds. I would guess that they
start once 10.1 stops
(approximately).

So it may be that 11.1 will not
get package builds until 11.0
stops (approximately).

If so unless lang/gcc* are changed
to bootstrap differently they will
configure to match release/11.0.1/
and will not be compatible with the
vm_ooffset_t and vm_pindex_t changes
in stable/11/ and release/11.1.0/ .

But as I understand updating how the
lang/gcc* builds work to remove such
dependencies is under investigation.
I do not know any timing relative to
release/11.1.0/ if my understanding
is right.

Until then (if I was right):

Unless there are separate packages made for
targeting release/11.0.1/ vs. release/11.1.0/
it is not obvious when lang/gcc* packages
will be generally compatible with various
folks choices about what to install as the
system version within the release/11.*/
and stable/11/ family. This would likely
be true even if they were built on
release/11.1.0/ : then release/11.0.1/
likely would have compatibility problems.

The ABI versioning does not cover the specific
issues involved based on how vm_ooffset_t and
vm_pindex_t were changed and what the
lang/gcc* builds do relative to such changes.
Yet there is incompatibility for some
fairly-significant-usage ports.


Aspect #2: stable/10/ and release/10.4.0/

Just covered for completeness:

I do not see a MFC of -r313194 to stable/10/ :
its sys/sys/types.h dates back to 2015-Oct-10.
So it looks like 10.x has a permanent difference
in this area: 10.x continues to get separate
lang/gcc* package builds from 11.x and later.
No problem for this context as far as I know.




Note: To simplify I choose to not be explicit
about what authors wrote what original text.
If that becomes an issue, it is correctable.

Blame me for any errors in the above.

===
Mark Millard
markmi at dsl-only.net

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

Re: Easytag crashes with SIGABRT - stack overflow

[Bob Eager]

Sorry, I always leave something out!

i386

On Sat, 24 Jun 2017 22:54:56 +0100
Steven Hartland  wrote:

> amd64 or i386?
> 
> On 24/06/2017 22:15, Bob Eager wrote:
> > Before I submit an actual bug report, I wanted advice as to whether
> > I'm doing something silly!
> >
> > I've been using Easytag for about 3 years now. All has been fine.
> >
> > I recently upgraded from 10.3-RELEASE to 11.0-STABLE. I also updated
> > the ports (built locally).
> >
> > Easytag now crashes as soon as I try to look at an album. SIGABRT -
> > and a kernel message about stack overflow. I've tried increasing
> > the stack size (via sysctl and reboot) by 50%, and there is no
> > change.
> >
> > Am I missing something?
> >  
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to
> "freebsd-ports-unsubscr...@freebsd.org"

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

Re: Easytag crashes with SIGABRT - stack overflow

[Steven Hartland]

amd64 or i386?

On 24/06/2017 22:15, Bob Eager wrote:

Before I submit an actual bug report, I wanted advice as to whether I'm
doing something silly!

I've been using Easytag for about 3 years now. All has been fine.

I recently upgraded from 10.3-RELEASE to 11.0-STABLE. I also updated
the ports (built locally).

Easytag now crashes as soon as I try to look at an album. SIGABRT - and
a kernel message about stack overflow. I've tried increasing the stack
size (via sysctl and reboot) by 50%, and there is no change.

Am I missing something?



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

Easytag crashes with SIGABRT - stack overflow

[Bob Eager]

Before I submit an actual bug report, I wanted advice as to whether I'm
doing something silly!

I've been using Easytag for about 3 years now. All has been fine.

I recently upgraded from 10.3-RELEASE to 11.0-STABLE. I also updated
the ports (built locally).

Easytag now crashes as soon as I try to look at an album. SIGABRT - and
a kernel message about stack overflow. I've tried increasing the stack
size (via sysctl and reboot) by 50%, and there is no change.

Am I missing something?

-- 
Bob

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

clamav-unofficial-sigs

[Carmel NY]

The port version of "clamav-unofficial-sigs" is 5.3.2; however a newer
version 5.6.2 is available. The port version is quite old. Are there
any plans to update the port?

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

Re: security/libressl not API-compatible with OpenSSL, breaks www/apache24

[Walter Schwarzenfeld]

There is a working patch:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61184
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: security/libressl not API-compatible with OpenSSL, breaks www/apache24

[Adam Weinberger]

> On 24 Jun, 2017, at 3:27, Peter Jeremy  wrote:
> 
> In , libressl-2.5.4 specifies
> #define OPENSSL_VERSION_NUMBER  0x2000L
> but doesn't provide an API compatible with OpenSSL.  In particular,
> it's missing (at least) SSL_CTX_set_max_proto_version() and
> SSL_CTX_set_min_proto_version(), which were added in OpenSSL 1.1.0.
> This breaks (at least) apache-2.4 which includes the code:
> #if OPENSSL_VERSION_NUMBER >= 0x1010L
>SSL_CTX_set_max_proto_version(ssl_ctx, max_prot);
>SSL_CTX_set_min_proto_version(ssl_ctx, min_prot);
> #endif
> 
> Does anyone have a suggestion, other than switching from LibreSSL back to
> OpenSSL?
> 
> -- 
> Peter Jeremy

Try changing it to
#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org



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

Re: GNU libffcall 1.13 is released

[Jov]

Hi Bruno,
 Thanks for your work！I submitted an update PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220250,and add you to the
CC list.

Jov

2017-06-24 19:27 GMT+08:00 Bruno Haible :

> Hi,
>
> GNU libffcall 1.13 is released. You find the download link at the homepage
> https://www.gnu.org/software/libffcall/
>
> New in 1.13:
>
> * The license has been changed from GPLv2 to GPLv2+.
>
> * Added support for the following platforms:
>   (Previously, a build on these platforms failed.)
>   - x86_64: Mac OS X 64-bit.
>   - x86_64: Solaris 64-bit.
>   - x86_64: Linux with x32 ABI: CC="gcc -mx32".
>   - arm: Linux 32-bit, without hardware floats.
>   - arm64: Linux 64-bit.
>   - s390x: Linux 64-bit.
>   - powerpc: AIX 64-bit.
>   - mips: IRIX 6.5 with CC="cc -32".
>   - sparc: Solaris 64-bit.
>
> * Fixed support for the following platforms:
>   (Previously, a build on these platforms appeared to succeed but was
> buggy.)
>   - x86_64: Linux.
>   - arm: Linux 32-bit, with hardware floats.
>   - powerpc: Linux 64-bit.
>   - mips: Linux with CC="gcc -mabi=32".
>   - mips: Linux with CC="gcc -mabi=n32".
>   - mips: Linux with CC="gcc -mabi=64".
>   - mips: IRIX 6.5 with CC="gcc -mabi=n32".
>   - s390: Linux.
>   - sparc: Linux 64-bit.
>   - ia64: Linux.
>   - hppa: HP-UX 32-bit.
>
> * Verified support for the following platforms:
>   (A build on these platforms worked and still works.)
>   - i386: Linux, Solaris, Mac OS X.
>   - powerpc: Linux 32-bit.
>   - powerpc: AIX 32-bit.
>   - powerpc: MacOS X.
>   - mips: IRIX 6.5 with CC="cc -n32".
>   - sparc: Solaris 32-bit.
>   - sparc: Linux 32-bit: CC="gcc -m32".
>   - alpha: Linux.
>
> * Support for a security feature: On Linux and FreeBSD platforms, linking
> with
>   the libffcall libraries no longer causes the stack to become executable.
>
>
> According to [1][2], you are packaging libffcall for FreeBSD.
>
> I invite you to upgrade to version 1.13.
> With it, you can remove the BROKEN_* lines from [2].
> Also, you will no longer need patch-avcall_avcall-sparc64.S [3].
>
> NOTE! Libffcall is usually packaged as a non-shared library. If so, you
> need
> to rebuild the packages that depend on it (in particular, GNU clisp).
>
> Best regards,
>
>Bruno
>
> [1] http://www.freshports.org/devel/ffcall
> [2] https://svnweb.freebsd.org/ports/head/devel/ffcall/
> Makefile?revision=439720=markup
> [3] https://svnweb.freebsd.org/ports/head/devel/ffcall/files/
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

GNU libffcall 1.13 is released

[Bruno Haible]

Hi,

GNU libffcall 1.13 is released. You find the download link at the homepage
https://www.gnu.org/software/libffcall/

New in 1.13:

* The license has been changed from GPLv2 to GPLv2+.

* Added support for the following platforms:
  (Previously, a build on these platforms failed.)
  - x86_64: Mac OS X 64-bit.
  - x86_64: Solaris 64-bit.
  - x86_64: Linux with x32 ABI: CC="gcc -mx32".
  - arm: Linux 32-bit, without hardware floats.
  - arm64: Linux 64-bit.
  - s390x: Linux 64-bit.
  - powerpc: AIX 64-bit.
  - mips: IRIX 6.5 with CC="cc -32".
  - sparc: Solaris 64-bit.

* Fixed support for the following platforms:
  (Previously, a build on these platforms appeared to succeed but was buggy.)
  - x86_64: Linux.
  - arm: Linux 32-bit, with hardware floats.
  - powerpc: Linux 64-bit.
  - mips: Linux with CC="gcc -mabi=32".
  - mips: Linux with CC="gcc -mabi=n32".
  - mips: Linux with CC="gcc -mabi=64".
  - mips: IRIX 6.5 with CC="gcc -mabi=n32".
  - s390: Linux.
  - sparc: Linux 64-bit.
  - ia64: Linux.
  - hppa: HP-UX 32-bit.

* Verified support for the following platforms:
  (A build on these platforms worked and still works.)
  - i386: Linux, Solaris, Mac OS X.
  - powerpc: Linux 32-bit.
  - powerpc: AIX 32-bit.
  - powerpc: MacOS X.
  - mips: IRIX 6.5 with CC="cc -n32".
  - sparc: Solaris 32-bit.
  - sparc: Linux 32-bit: CC="gcc -m32".
  - alpha: Linux.

* Support for a security feature: On Linux and FreeBSD platforms, linking with
  the libffcall libraries no longer causes the stack to become executable.


According to [1][2], you are packaging libffcall for FreeBSD.

I invite you to upgrade to version 1.13.
With it, you can remove the BROKEN_* lines from [2].
Also, you will no longer need patch-avcall_avcall-sparc64.S [3].

NOTE! Libffcall is usually packaged as a non-shared library. If so, you need
to rebuild the packages that depend on it (in particular, GNU clisp).

Best regards,

   Bruno

[1] http://www.freshports.org/devel/ffcall
[2] 
https://svnweb.freebsd.org/ports/head/devel/ffcall/Makefile?revision=439720=markup
[3] https://svnweb.freebsd.org/ports/head/devel/ffcall/files/

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Fine. Considering that maintainers already apply patches to the latest
quarterly branch. If there were to be OS version branches, it would
mean that maintainers apart from what they are doing now would
additionally need to apply selected patches to those OS version
branches?

"OS version branches" would be a complete waste of time and resources, and it
would remove some level of separation/independence between the base and ports.
The crux of the problem here is so called "stable ports", not necessarily
tying them to the life cycle of a base release. It doesn't make sense to tie
version of a port to the base release. Especially with the new releng support
schedule that would mean 5 years per major version which is quite a lot.

(snip)

I personally can't see the rationale of many OS version branches of ports: far 
too much work.

I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
order, considering that pkgsrc has been ported to many OSes besides NetBSD.

Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
FreeBSD, Linux, etc.

I only follow the current branch of FreeBSD ports and pkgsrc, though now I have 
also become interested in pkgsrc-synth.

Tom



Are there any advantages of using pkg instead of pkgsrc on FreeBSD?

Instead of having branches by OS version, would having ports LTS 
branches independent of the base system be a better solution?


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

security/libressl not API-compatible with OpenSSL, breaks www/apache24

[Peter Jeremy]

In , libressl-2.5.4 specifies
#define OPENSSL_VERSION_NUMBER  0x2000L
but doesn't provide an API compatible with OpenSSL.  In particular,
it's missing (at least) SSL_CTX_set_max_proto_version() and
SSL_CTX_set_min_proto_version(), which were added in OpenSSL 1.1.0.
This breaks (at least) apache-2.4 which includes the code:
#if OPENSSL_VERSION_NUMBER >= 0x1010L
SSL_CTX_set_max_proto_version(ssl_ctx, max_prot);
SSL_CTX_set_min_proto_version(ssl_ctx, min_prot);
#endif

Does anyone have a suggestion, other than switching from LibreSSL back to
OpenSSL?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Vlad K:

> On 2017-06-23 23:09, Grzegorz Junka wrote:

> > Fine. Considering that maintainers already apply patches to the latest
> > quarterly branch. If there were to be OS version branches, it would
> > mean that maintainers apart from what they are doing now would
> > additionally need to apply selected patches to those OS version
> > branches?

> "OS version branches" would be a complete waste of time and resources, and it
> would remove some level of separation/independence between the base and ports.

> The crux of the problem here is so called "stable ports", not necessarily
> tying them to the life cycle of a base release. It doesn't make sense to tie
> version of a port to the base release. Especially with the new releng support
> schedule that would mean 5 years per major version which is quite a lot.
(snip)

I personally can't see the rationale of many OS version branches of ports: far 
too much work.

I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
order, considering that pkgsrc has been ported to many OSes besides NetBSD.

Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
FreeBSD, Linux, etc.

I only follow the current branch of FreeBSD ports and pkgsrc, though now I have 
also become interested in pkgsrc-synth.

Tom

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