Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

5, at 19:28, Mark Millard wrote: >>>> >>>>> . . . >>>>> >>>> . . . >>>> >>> >>> . . . >>> >>>> . . . > . . . > > I'll note that ampere2's main-arm64has started its 15th day > of building (341 hrs+) and still had 6748 packag

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

gt;>>>> In separate list messages I've provided multiple examples >>>>> of the time-taking issue that do not depend on what is >>>>> running in parallel on the machines, no parallel builds >>>>> involved. >>>>> >>&

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

the >>>>> performance changes depending on what is happening in parallel on the >>>>> machines. >>>> >>>> In separate list messages I've provided multiple examples >>>> of the time-taking issue that do not depend on what is >>

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

king to provide more detailed timing comparisons with > pkg 2.0.6 I noticed another context with a sizable delta > timing difference for building the packages, here using > www/rt50 as an example, just the one package being > built in each case. > > # poudriere ports -l > PORTSTRE

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

NOTE on something newly noticed while preparing this (a top post to keep it separate): In looking to provide more detailed timing comparisons with pkg 2.0.6 I noticed another context with a sizable delta timing difference for building the packages, here using www/rt50 as an example, just the one

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

ages I've provided multiple examples > of the time-taking issue that do not depend on what is > running in parallel on the machines, no parallel builds > involved. > > Part of the issue is that there are thousands of examples of > "small build-step time" packages for w

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes]

n what is running in parallel on the machines, no parallel builds involved. Part of the issue is that there are thousands of examples of "small build-step time" packages for which the build-depends, lib-depends, run-depends combination, takes notable time, given that the total tim

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {build,lib,run}-depends timings for bulk -a --and some other aarch64 timings]

ncies are normally >>> involve for the package builds. >>> >>> A property of the dependency based ordering of builds is that >>> the earlier builds tend of have fewer dependencies and the later >>> builds tend to have more. >>> >>> For b

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {build,lib,run}-depends timings for bulk -a --and some other aarch64 timings]

of the dependency based ordering of builds is that >> the earlier builds tend of have fewer dependencies and the later >> builds tend to have more. >> >> For building around 36000 packages, even a mean rate of around >> 1 extra second per is around 10 hrs of extra time. (

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

www/gitlab >> >> The factor of 37 24 instead >> is large enough to be unlikely to have only >> load averages on beefy17 as a major contributor. It is still unlikely that beefy17 had load averages of anywhere in the ballpark of 20 times the number of FreeBSD cpus. >&

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

On Mon 07 Apr 15:59, Poul-Henning Kamp wrote: > > Baptiste Daroussin writes: > > > Listing like this is clearly not any useful, the problem we have is the > > performance changes depending on what is happening in parallel on the > > machines. > > Sounds like increased memory footprint t

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {patch,build,lib}-depends timings for bulk -a --and related notes]

dependencies and the later > builds tend to have more. > > For building around 36000 packages, even a mean rate of around > 1 extra second per is around 10 hrs of extra time. (But normal > extra times are not generally near the mean-extra-time.) > > It appears that a big factor in

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {patch,build,lib}-depends timings for bulk -a --and related notes]

tably contributing. This is later when dependencies are normally involve for the package builds. A property of the dependency based ordering of builds is that the earlier builds tend of have fewer dependencies and the later builds tend to have more. For building around 36000 packages, even a mean

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Just notes based on various official www/gitlab@ee and @ce build times]

The below indicates that whatever is taking the extra time is not strongly tied to processor performance. www/gitlab@ee and www/gitlab@ce turn out to be good for seeing larger scale elapsed time multiplication factors. That allows seeing this. I'll note that when, for example, www/gitlab@ee is bui

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

of 37 > > 24 instead > >>> is large enough to be unlikely to have only >>> load averages on beefy17 as a major contributor. > > It is still unlikely that beefy17 had load averages > of anywhere in the ballpark of 20 times the number > of FreeBSD cpus. > >&

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

gitlab-ee www/gitlab > > The factor of 37 is large enough to be unlikely to have only > load averages on beefy17 as a major contributor. Given the > evidence about the count of dependencies, I will see. what > I get. > > The test environment is a Apple Silicon M4 MAX system

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

oad averages on beefy17 as a major contributor. Given the evidence about the count of dependencies, I will see. what I get. The test environment is a Apple Silicon M4 MAX system with FreeBSD running under Parallels in macOS. [00:00:07] Building 943 packages using up to 14 builders OOPS (via checkin

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

Baptiste Daroussin writes: > Listing like this is clearly not any useful, the problem we have is the > performance changes depending on what is happening in parallel on the > machines. Sounds like increased memory footprint to me ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

On Apr 6, 2025, at 21:11, Gleb Popov <6year...@gmail.com> wrote: > On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote: >> >> So: 2 min 31 sec or so difference for overall somewhat over an >> hour, i.e., 151 sec or so. That is under 1 sec per package >> built. > > If the slowdown comes from handl

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor]

On Mon 07 Apr 08:07, Mark Millard wrote: > On Apr 6, 2025, at 21:11, Gleb Popov <6year...@gmail.com> wrote: > > > On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote: > >> > >> So: 2 min 31 sec or so difference for overall somewhat over an > >> hour, i.e., 151 sec or so. That is under 1 sec per pa

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer

anges) > >>> > >>> Host OSVERSION: 1500035 > >>> Jail OSVERSION: 1500035 > >>> > >>> So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . > >>> > >>> === > >>> Mark Millard > >&g

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64]

On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote: > > So: 2 min 31 sec or so difference for overall somewhat over an > hour, i.e., 151 sec or so. That is under 1 sec per package > built. If the slowdown comes from handling shlib provides/requires, then this obviously depends on the amount of dep

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64]

6_14h16m21s] [committing] Time: 01:07:27 Queued: 265 Inspected: 0 Ignored: 0 Built: 265 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 0 So: 2 min 31 sec or so difference for overall somewhat over an hour, i.e., 151 sec or so. That is under 1 sec per package built. At 1 sec or so per packa

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64]

> [01:07:28] [release-aarch64-alt] [2025-04-06_14h16m21s] [committing] Time: > 01:07:27 > Queued: 265 Inspected: 0 Ignored: 0 Built: 265 Failed: 0 Skipped: 0 > Fetched: 0 Remaining: 0 > > > So: 2 min 31 sec or so difference for overall somewhat over an > hour,

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer

gt;> >> >> >> yes this is known and expected, because ofnthe support of provide/requires >> in a way the ports tree can use it (pkg add) we added some code which >> introduce performance penalty, we expect to be able to improve performance >> again by

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer

> > > yes this is known and expected, because ofnthe support of provide/requires in > a way the ports tree can use it (pkg add) we added some code which introduce > performance penalty, we expect to be able to improve performance again by > using those features in the ports

Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer

Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit : >[This is an update of earlier notes, now that I've noticed what >is different for the contexts that not seeing larger time frames >in the Mar-29/Apr-01 bulk build starts of official package builds.] > >The context here is the official bul

UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer

[This is an update of earlier notes, now that I've noticed what is different for the contexts that not seeing larger time frames in the Mar-29/Apr-01 bulk build starts of official package builds.] The context here is the official bulk builds started 2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-0

Re: Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

ports-mgmt/poudriere-devel | > poudriere-devel-3.4.99.20250209 > [00:00:46] [01] [00:00:03] Finished ports-mgmt/poudriere-devel | > poudriere-devel-3.4.99.20250209: Success ending TMPFS: 2.96 GiB > [00:00:47] Stopping 5 builders > [00:00:47] Creating pkg repository > mount

Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

t_nullfs: /usr/local/poudriere/data/.m/main-ZNV4-default/ref/packages: Resource deadlock avoided [00:00:47] Error: /usr/local/share/poudriere/bulk.sh:mount_packages:7:Failed to mount the packages directory It later reports: [00:00:47] Unmounting file systems Error: (50608) rm:rm:1: /usr/loc

PkgBase after LLVM 19 update: various packages still have old dates (and content)

https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/?C=M&O=D has various .pkg files that still date back to: 2024-Oct-22 2024-Oct-20 2024-Oct-15 2024-Oct-14 2024-Oct-11 Includes *-libstdbuf-* *-libsdp-* *-libpathconv-* and various others Includes *-lib32-* and *-dbg-* variants 2024-Oc

Using package build records at pkg-status.freebsd.org (was: pkg: No packages available to install matching)

On 03/01/2023 17:45, Vladimir Boldin wrote: Can't findnet-im/telegram-desktop with|pkg search … | |Via : | || | ///Using package build records at pkg-status.freebsd.org/| || | | ||

pkg: No packages available to install matching

et-im/telegram-desktop| |Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. pkg: No packages available to install matching 'net-im/telegram-desktop' have been found in the repositories| |root@beast:/home/user # pkg install telegram-desk

updating of prebuilt packages with pkg

o not have the /usr/src/ or /usr/ports/ trees installed in order to save space. For policy reasons these use pre-built packages and I will never compile anything from source on these systems. This one is on 12.3-RELEASE . Recently I encountered that the usual cadence of pkg update pkg upgraade pkg

Re: Building packages with poudriere fails after `zfs upgrade`

From: Samy Mahmoudi Subject: Re: Building packages with poudriere fails after `zfs upgrade` Date: Thu, 29 Oct 2020 20:54:13 -0400 > Have you tried to work around the issue by creating a new jail with > poudriere, > or even by changing the value of ZROOTFS in poudriere.conf ? T

Re: Building packages with poudriere fails after `zfs upgrade`

Hi, Have you tried to work around the issue by creating a new jail with poudriere, or even by changing the value of ZROOTFS in poudriere.conf ? Best regards, Samy Mahmoudi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/li

Building packages with poudriere fails after `zfs upgrade`

Hello, I tried `zfs upgrade zroot` on my 13-CURRENT r366977 host and after that building packages with poudriere fails as following. [00:04:55] [02] [00:00:00] Building security/libtasn1 | libtasn1-4.16.0 [00:05:10] [02] [00:00:15] Finished security/libtasn1 | libtasn1-4.16.0: Success [00:05:10

Re: New external GCC toolchain ports/packages

wrote: > > > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > > > >> > > > > >> In the interest of supporting newer versions of GCC for a base system > > > > >&

Re: New external GCC toolchain ports/packages

d, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > > >> > > > >> In the interest of supporting newer versions of GCC for a base system > > > >> toolchain, I've renamed the external GCC packages from -gcc > > > >> to -gcc6. These are built

Re: New external GCC toolchain ports/packages

erest of supporting newer versions of GCC for a base system > > >> toolchain, I've renamed the external GCC packages from -gcc > > >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > > >> port. The xtoolchain package is not used for these

Re: New external GCC toolchain ports/packages

On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > On 12/19/19 12:06 PM, Ryan Libby wrote: > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > >> > >> In the interest of supporting newer versions of GCC for a base system > >> toolchain, I&

Re: New external GCC toolchain ports/packages

On 12/19/19 12:06 PM, Ryan Libby wrote: > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: >> >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built a

Re: New external GCC toolchain ports/packages

On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtool

Re: New external GCC toolchain ports/packages

On 12/18/19 4:16 PM, Mark Millard wrote: > > > On 2019-Dec-18, at 13:48, John Baldwin wrote: > >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are buil

Re: New external GCC toolchain ports/packages

On 2019-Dec-18, at 13:48, John Baldwin wrote: > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain pa

New external GCC toolchain ports/packages

In the interest of supporting newer versions of GCC for a base system toolchain, I've renamed the external GCC packages from -gcc to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 port. The xtoolchain package is not used for these new packages, instead one does 'pkg in

Re: make packages broken

On Mon, Jun 3, 2019 at 10:40 AM Andreas Nilsson wrote: > Hello all, > > It was time for the weekly update so git gave > me: c7cdb4a80779a0451dc2c04c3d6b30769049d402 . > > It compiled fined, but when I tried to build packages I get: > make -C /usr/src PKG_VERSION=13.0

make packages broken

Hello all, It was time for the weekly update so git gave me: c7cdb4a80779a0451dc2c04c3d6b30769049d402 . It compiled fined, but when I tried to build packages I get: make -C /usr/src PKG_VERSION=13.0.s20190603083918 real-packages make[5]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk&

Re: base packages and 12 -> 13 upgrade

On 03.11.2018 18:05, Mikaël Urankar wrote: Le sam. 3 nov. 2018 à 15:45, Boris Samorodov a écrit : Hi All, A have a base package server and upgraded some of my home servers to use base packages. Now when the package builder builds packages for 13-current, what is the procedure to upgrade base

Re: base packages and 12 -> 13 upgrade

Le sam. 3 nov. 2018 à 15:45, Boris Samorodov a écrit : > > Hi All, > > A have a base package server and upgraded some of my home servers > to use base packages. Now when the package builder builds packages > for 13-current, what is the procedure to upgrade base packag

base packages and 12 -> 13 upgrade

Hi All, A have a base package server and upgraded some of my home servers to use base packages. Now when the package builder builds packages for 13-current, what is the procedure to upgrade base packages from 12 to 13? Whenever I try to install/upgrade packages I get: --- pkg-static: wrong

Re: make packages fails recent -current

On 11.09.2018 16:20, Andreas Nilsson wrote: On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar wrote: 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : Hello, I have for about a week been trying to get new (base)packages built. make buildworld/buildkernel works as expected, however make packages

Re: make packages fails recent -current

On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar wrote: > 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : > >> Hello, >> >> I have for about a week been trying to get new (base)packages built. make >> buildworld/buildkernel works as expected, however mak

Re: make packages fails recent -current

2018-09-10 17:45 GMT+02:00 Andreas Nilsson : > Hello, > > I have for about a week been trying to get new (base)packages built. make > buildworld/buildkernel works as expected, however make packages has been > failing: > > ===> Creating FreeBSD-runtime-12.0.s2018091

make packages fails recent -current

Hello, I have for about a week been trying to get new (base)packages built. make buildworld/buildkernel works as expected, however make packages has been failing: ===> Creating FreeBSD-runtime-12.0.s20180910124534 pkg: duplicate directory listing: /boot, ignoring pkg: duplicate directory list

Re: New conflict between the FreeBSD-libnv-development and FreeBSD-runtime-development packages

On Mon, Jul 9, 2018 at 4:58 AM, Tobias Kortkamp wrote: > Hi, > > there's a new conflict between the FreeBSD-{libnv,runtime}-development > base packages. This was for r336096 but the problem must have been > introduced after r335966 as the packages from that revision were

New conflict between the FreeBSD-libnv-development and FreeBSD-runtime-development packages

Hi, there's a new conflict between the FreeBSD-{libnv,runtime}-development base packages. This was for r336096 but the problem must have been introduced after r335966 as the packages from that revision were fine. Checking integrity... done (1 conflicting) - FreeBSD-libnv-development

Re: ci.freebsd.org's FreeBSD-head-i386-testvm fails for: pkg: No packages available to install matching 'scapy' have been found in the repositories

pository catalogue... > 22:34:39 FreeBSD repository is up to date. > 22:34:39 All repositories are up to date. > 22:34:39 Updating database digests format: . done > 22:34:39 pkg: No packages available to install matching 'scapy' have been > found in the repositories > 22

ci.freebsd.org's FreeBSD-head-i386-testvm fails for: pkg: No packages available to install matching 'scapy' have been found in the repositories

repositories are up to date. 22:34:39 Updating database digests format: . done 22:34:39 pkg: No packages available to install matching 'scapy' have been found in the repositories 22:34:39 Build step 'Execute shell' marked build as failure 22:34:39 FTP: Current build result is [FAILUR

create-kernel-packages-extra-flavor-debug: *** Error code 70: Unable to open plist

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On recent CURRENT with recent CURRENT sources (r334490), building FreeBSD packages for FreeBSD-base fails on arm64.aarch64 with a custom kernel (see below). WITH_META_MODE is used. Such problems do not occur when building "make package

Re: pkg, drm-next-kmod and base packages

10.05.2018 19:05, Andreas Nilsson пишет: > On Thu, May 10, 2018 at 5:30 PM, Theron wrote: > >> On 05/10/18 03:45, Johannes Dieterich wrote: >> >>> Hi >>> >>> On Wednesday, May 9, 2018, Boris Samorodov wrote: >>> >>>> Hi All, >

Re: pkg, drm-next-kmod and base packages

On Thu, May 10, 2018 at 5:30 PM, Theron wrote: > On 05/10/18 03:45, Johannes Dieterich wrote: > >> Hi >> >> On Wednesday, May 9, 2018, Boris Samorodov wrote: >> >>> Hi All, >>> >>> I use self-built base packages. How can I test/use drm-n

Re: pkg, drm-next-kmod and base packages

On 05/10/18 03:45, Johannes Dieterich wrote: Hi On Wednesday, May 9, 2018, Boris Samorodov wrote: Hi All, I use self-built base packages. How can I test/use drm-next-kmod? Packages for kernel and drm-nex-kmod are in conflict: - Checking integrity... done (1 conflicting) - drm-next-kmod

Re: pkg, drm-next-kmod and base packages

Hi On Wednesday, May 9, 2018, Boris Samorodov wrote: > Hi All, > > I use self-built base packages. How can I test/use drm-next-kmod? > Packages for kernel and drm-nex-kmod are in conflict: > - > ╰→ sudo pkg install drm-next-kmod-4.11.g20180224 > > Updating FreeBSD-b

pkg, drm-next-kmod and base packages

Hi All, I use self-built base packages. How can I test/use drm-next-kmod? Packages for kernel and drm-nex-kmod are in conflict: - ╰→ sudo pkg install drm-next-kmod-4.11.g20180224 Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. Updating FreeBSD repository

Re: Conflict between FreeBSD-binutils and FreeBSD-lld packages

On Sun, Mar 4, 2018, at 02:38, Ed Maste wrote: > On 2 March 2018 at 04:34, Tobias Kortkamp wrote: > > Building pkgbase packages with r330236 results in FreeBSD-binutils and > > FreeBSD-lld packages conflicting with each other. Both want to > > install /usr/share/man/man1/ld

Re: Conflict between FreeBSD-binutils and FreeBSD-lld packages

On 2 March 2018 at 04:34, Tobias Kortkamp wrote: > Building pkgbase packages with r330236 results in FreeBSD-binutils and > FreeBSD-lld packages conflicting with each other. Both want to > install /usr/share/man/man1/ld.1.gz Thanks for the report; this should be fixed as o

Conflict between FreeBSD-binutils and FreeBSD-lld packages

Building pkgbase packages with r330236 results in FreeBSD-binutils and FreeBSD-lld packages conflicting with each other. Both want to install /usr/share/man/man1/ld.1.gz For now I'm working around it by manually extracting FreeBSD-lld. FreeBSD-binutils should install its man page as ld.bfd

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On Thu, Jan 18, 2018 at 11:32:26AM -0500, Ryan Stone wrote: > On Wed, Jan 10, 2018 at 1:53 PM, Baptiste Daroussin wrote: > > One has to specify pkg -o OSVERSION=1200055 to allow packages built on > > 1200055 > > to install on 1200054. > > This workaround doesn't

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On Wed, Jan 10, 2018 at 1:53 PM, Baptiste Daroussin wrote: > One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055 > to install on 1200054. This workaround doesn't appear to work for pkg bootstrap: # pkg -o OSVERSION=1200055 bootstrap The package management

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On Thu, Jan 11, 2018 at 08:57:34AM -0700, Ian Lepore wrote: > On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > > > > > Hi All, > > > > > > I use self built base p

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > > > Hi All, > > > > I use self built base packages. Seems that I have a problem with pkg. > > Today I've got this: > &g

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

(distupgrade vs upgrade) to perform complete version upgrades. Ideally, the proper fix would probably be to depend on a base package version, rather than OSVERSION, and if the base packages are not being used to synthesise a phantom set of base package metadata based on OS

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

10.01.2018 21:53, Baptiste Daroussin пишет: > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: >> Hi All, >> >> I use self built base packages. Seems that I have a problem with pkg. >> Today I've got this: >> === >> % sudo pkg update -f &

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > Hi All, > > I use self built base packages. Seems that I have a problem with pkg. > Today I've got this: > === > % sudo pkg update -f > Updating FreeBSD-base repository catalogue... > Fetching meta

[self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

Hi All, I use self built base packages. Seems that I have a problem with pkg. Today I've got this: === % sudo pkg update -f Updating FreeBSD-base repository catalogue... Fetching meta.txz: 100%268 B 0.3kB/s00:01 Fetching packagesite.txz: 100% 29 KiB 29.4kB/s00:01 Proce

CUURENT: Cross-build for 11.1-RELENG (base packages) fails: *** [create-kernel-packages] Error code 70

/kernel.GENERIC-debug.plist *** [create-kernel-packages] Error code 70 make[5]: stopped in /pool/sources/11.1-RELENG/src 1 error make[5]: stopped in /pool/sources/11.1-RELENG/src *** [create-kernel-packages] Error code 2 ___ freebsd-current@freebsd.org

base packages and subdirs with no regular files

Hi All! I use base package for more then a year now. It works mostly fine. However today I noticed that (some?) blank subdirectories are not removed while updating: --- % LANG=C ls -l /usr/lib/clang drwxr-xr-x 4 root wheel 4 Dec 22 2016 3.9.1 drwxr-xr-x 4 root wheel 4 Mar 3 2017 4.0.0 drw

[base packages] [r325303 -> r325351] install: hcsecd.conf: Permission denied

Hi All, I create packages (as an ordinary user with command "make packages") for HEAD once a day. Today I've got a regression: --- rev. 325351 regression --- install -U -M /usr/obj/usr/src/amd64.amd64/worldstage//METALOG -D /usr/obj/usr/src/amd64.amd64/worldstage -T package=runt

Re: [pkg base][pormaster] Origin for base packages = "base"

Hi Ilya, I saw same issue yesterday. I suppose it's easy to fix postmaster, but pkgbase is still experimental. Best regards, Michael 14 авг. 2017 г. 2:57 ПП пользователь "Ilya A. Arkhipov" написал: > Hi there, > > After upgrade my system(r322368) to pkg-base syst

[pkg base][pormaster] Origin for base packages = "base"

Hi there, After upgrade my system(r322368) to pkg-base system(have 780 packages for world and kernel) I got next issue: [11:53am] root:/root # portmaster -a ===>>> Gathering distinfo list for installed ports ===>>> Starting check of installed ports for

Re: status of and/or url to check base packages repo somewhere?

g fetch ... pkg add ...' which would substitute for the > buildworld > cycle? Also, one would be rebooted into a GENERIC kernel, ... and other > details ? > There is no public repository for base packages as of yet. It is still highly considered a 'beta' feature at thi

status of and/or url to check base packages repo somewhere?

As the Subject: is there a canonical url to check, and a procedure in place yet, to, for instance, if one cannot buildworld on 12.0-CURRENT, to access the package .txz or whatever and 'pkg fetch ... pkg add ...' which would substitute for the buildworld cycle? Also, one would be rebooted

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

vised to upgrade your system past r318736 soon or avoid using > official packages until you do. Portmgr may upgrade the package > builders at any time and without much notice. I had forgotten a detail here. The package builds are all automated. The source jails are automatically updated b

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

On 26 May 2017 at 12:18, Kurt Jaeger wrote: > Hi! > >> For those running FreeBSD head, the ABI was majorly changed in r318736 >> for 64-bit inodes. This change was *backwards compatible* but not >> *forward compatible*. This is normal and expected. > > Is any fall-out from this change already ha

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

Hi! > For those running FreeBSD head, the ABI was majorly changed in r318736 > for 64-bit inodes. This change was *backwards compatible* but not > *forward compatible*. This is normal and expected. Is any fall-out from this change already handled or is it wise to wait a few more days ? -- p..

(head users) 64-bit inodes: Packages heads up and Poudriere errors

For those running FreeBSD head, the ABI was majorly changed in r318736 for 64-bit inodes. This change was *backwards compatible* but not *forward compatible*. This is normal and expected. For Pkg users: You are advised to upgrade your system past r318736 soon or avoid using official packages

Re: base packages, ino64 and upgrade

24.05.2017 16:00, Glen Barber пишет: > On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote: >> Hi All, >> >> Does anyone know the procedure to upgrade for those using base packages? > > 'pkg install FreeBSD-kernel-generic' (or whatever your kern

Re: base packages, ino64 and upgrade

On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote: > Hi All, > > Does anyone know the procedure to upgrade for those using base packages? > 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is called), reboot, 'pkg upgrade'. G

base packages, ino64 and upgrade

Hi All, Does anyone know the procedure to upgrade for those using base packages? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman

pkg, base packages and subdirectories

Hi All, I've created my base repo and installed the OS from packages. All in all it all went rather smooth! As for pkg it seems to not pay attention to base library subdirs: - # pkg check -Ba Checking all packages: 3% (FreeBSD-kernel-sm-12.0.s20170128125723) /boot/kernel/k

Re: why 100 packages are evil

re) for freebsd-update to jump one major release. After that, > it takes pkg a minute or two to update the 2-3GB of packages that need > upgrading. Minor releases can often take tens of minutes on these system. > > The many files issue can cause inode exhaustion. One one machine, I j

Re: why 100 packages are evil

e patchlevel to the next are pretty straightforward, but on both the VMs that I use for FreeBSD and a slow AMD machine with ZFS it takes around an hour (sometimes more) for freebsd-update to jump one major release. After that, it takes pkg a minute or two to update the 2-3GB of packages that nee

Re: why 100 packages are evil

On 25/04/2016 08:39, Miroslav Lachman wrote: Gerrit Kühn wrote on 04/25/2016 07:48: On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? Yes. It will be replaced by '

Re: why 100 packages are evil

Gerrit Kühn wrote on 04/25/2016 07:48: On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that

Re: why 100 packages are evil

On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? > Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's > the plan for 11.0-RELEASE. Hm.

Re: why 100 packages are evil

On 23/04/2016 17:19, Poul-Henning Kamp wrote: > > In message , Lyndon > Neren > berg writes: > >> With freebsd-update, an announcement comes out that says 'update'!. So we >> do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record >> of why and how this happened. > >

Re: why 100 packages are evil

In message , Lyndon Neren berg writes: >With freebsd-update, an announcement comes out that says 'update'!. So we >do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record >of why and how this happened. Is freebsd-update going away as result of the new packaging ? --

Re: why 100 packages are evil

On Fri, Apr 22, 2016 at 08:41:06PM -0700, Lyndon Nerenberg wrote: > But the dependency base will be huge. Yet you fail to explain how. > Right now I can count on a very limited set of dependencies for > anything I ship as a 3rd party package. How is this different than the existing model? What

Re: why 100 packages are evil

Same as it is now for releases. Packages will be available for SAs/ENs. There is no intention to change this model. I get that. But the dependency base will be huge. Right now I can count on a very limited set of dependencies for anything I ship as a 3rd party package. Doing that for n>

  1   2   3   4   >