pkg upgrade # What is "(1 candidates)"? [reproducible]

Deleted member 65380 · Dec 4, 2021

The number of candidates must mean something in some context to developers of pkg, outside of that it's useless.

from: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255967#c1

> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%

There is actually no need to print anything more than:

Checking for upgrades: 100%
Processing candidates: 100%

Until (N candidates) means something definitive it is meaningless and should not be output.

Maybe also via --debug...

Alexander Mishin · Dec 4, 2021

I accidentally found another reason for "candidates" - when the repository contains several versions of the same package. Here is my story:

 

# pkg upgrade

Updating FreeBSD repository catalogue...

FreeBSD repository is up to date.

Updating GPIO repository catalogue...

GPIO repository is up to date.

All repositories are up to date.

Checking for upgrades (1 candidates): 100%

Processing candidates (1 candidates): 100%

Checking integrity... done (0 conflicting)

Your packages are up to date.



# pkg version -vRL=

Updating FreeBSD repository catalogue...

FreeBSD repository is up to date.

Updating GPIO repository catalogue...

GPIO repository is up to date.

All repositories are up to date.

go-bindata-3.1.2                   ?   orphaned: devel/go-bindata

go14-1.4.3_6                       ?   orphaned: lang/go14

py38-Wand-0.6.7_1                  ?   orphaned: graphics/py-wand

tm1637-cuse-g20211129              >   succeeds remote (remote has g20211128)

This is my home repository for my home projects.

 

# pkg query '%o %v %R' | grep tm1637

misc/tm1637-clock g20211125 GPIO

misc/tm1637-cuse g20211129 GPIO

misc/tm1637-kmod g20211122 GPIO



# ls ./FreeBSD:13:armv7/latest/All/ | grep tm1637-cuse

tm1637-cuse-g20211128.pkg

tm1637-cuse-g20211128.txz

tm1637-cuse-g20211129.pkg

tm1637-cuse-g20211129.txz

After I removed the old package with version g20211128 and re-signed the repository everything was OK:

 

# pkg upgrade

Updating FreeBSD repository catalogue...

FreeBSD repository is up to date.

Updating GPIO repository catalogue...

Fetching meta.conf: 100%    163 B   0.2kB/s    00:01

Fetching packagesite.pkg: 100%    3 KiB   3.4kB/s    00:01

Processing entries: 100%

GPIO repository update completed. 7 packages processed.

All repositories are up to date.

Checking for upgrades (0 candidates): 100%

Processing candidates (0 candidates): 100%

Checking integrity... done (0 conflicting)

Your packages are up to date.

I want to say that the reason may not necessarily be on the side of the FreeBSD owner, especially when using multiple repositories with the same set of packages.

Cath O'Deray · Dec 5, 2021

Alexander Mishin said:
I removed the old package

With rm(1)?

Alexander Mishin · Dec 5, 2021

grahamperrin said:
With rm(1)?

Yes, it is a local repository but on my other host. Then

Bash:

/usr/sbin/pkg repo ${REPO}/${ABI}/latest signing_command: ./${SIGN}.sh

... or how is this done in the 'poudriere' provided repositories.

Cath O'Deray · Apr 8, 2022

tux2bsd said:
It's stupid. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255967

It's a nit, but I don't imagine a fix in the near future.

As far as I know, there's no adverse effect on the ability to upgrade.

{link removed}

Cath O'Deray · Apr 8, 2022

Code:

root@mowa219-gjp4-8570p-freebsd:~ # pkg -d upgrade -r poudriere -n
DBG(1)[68850]> pkg initialized
Updating poudriere repository catalogue...
DBG(1)[68850]> PkgRepo: verifying update for poudriere
DBG(1)[68850]> Pkgrepo, begin update of '/var/db/pkg/repo-poudriere.sqlite'
DBG(1)[68850]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/meta.conf
DBG(1)[68850]> Fetch: fetcher chosen: file
DBG(1)[68850]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/packagesite.pkg
DBG(1)[68850]> Fetch: fetcher chosen: file
DBG(1)[68850]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/packagesite.txz
DBG(1)[68850]> Fetch: fetcher chosen: file
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[68850]> Binary> loading //usr/local/poudriere/data/packages/main-default/All/drm-devel-kmod-5.7.19.g20220223.pkg
Checking integrity...DBG(1)[68850]> check integrity for 1 items added
 done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        drm-devel-kmod-5.7.19.g20220223 [poudriere] (options changed)

Number of packages to be reinstalled: 1
root@mowa219-gjp4-8570p-freebsd:~ # pkg lock -l
Currently locked packages:
root@mowa219-gjp4-8570p-freebsd:~ # pkg lock drm-devel-kmod
drm-devel-kmod-5.7.19.g20220223: lock this package? [y/N]: y
Locking drm-devel-kmod-5.7.19.g20220223
root@mowa219-gjp4-8570p-freebsd:~ # pkg -d upgrade -r poudriere -n
DBG(1)[68899]> pkg initialized
Updating poudriere repository catalogue...
DBG(1)[68899]> PkgRepo: verifying update for poudriere
DBG(1)[68899]> Pkgrepo, begin update of '/var/db/pkg/repo-poudriere.sqlite'
DBG(1)[68899]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/meta.conf
DBG(1)[68899]> Fetch: fetcher chosen: file
DBG(1)[68899]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/packagesite.pkg
DBG(1)[68899]> Fetch: fetcher chosen: file
DBG(1)[68899]> Request to fetch file:///usr/local/poudriere/data/packages/main-default/packagesite.txz
DBG(1)[68899]> Fetch: fetcher chosen: file
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[68899]> problem has no requests
Checking integrity...DBG(1)[68899]> check integrity for 0 items added
 done (0 conflicting)
Your packages are up to date.
root@mowa219-gjp4-8570p-freebsd:~ #

(I forgot to lock the package after my most recent update of the OS from source.)

Cath O'Deray · Apr 8, 2022

elimelech007 said:

Code:

root@A9t:/home/luba # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
root@A9t:/home/luba #

How to calculate what has not been updated there and why?

elimelech007 for your one-candidate case, please run:

pkg -ddd upgrade -n

Deleted member 65380 · Apr 9, 2022

grahamperrin said:
I don't imagine a fix in the near future.

It's been the best part of a year already. "ignore it" is the easiest thing until it is fixed because you can't trust that the candidates number won't go non-zero at another point...

Deleted member 65380 · Apr 9, 2022

grahamperrin said:
tux2bsd do you have a one-candidate situation at the moment?

Nope. I just remember how dumb it was (and still is) and that the bug still needs fixing.

zostj · Mar 27, 2023

SirDice said:
So what I think might happen here is that the pkg(7) bootstrap causes pkg itself to be registered as an implicit dependency, thus 1 candidate. But it's already installed so nothing needs to be done. By doing a re-install using the "proper" pkg(8) tool this implicit dependency was removed and consequently also removed that 1 candidate.

Your explanation and solution to pkg upgrade's quirkiness is still easing troubled minds in 2023.

As someone who is new to FreeBSD, this really cleared things up for me.

Márcio Rezende · Sep 26, 2024

SirDice said:

Doesn't provide much clues where it's coming from:

Code:

root@fbsd-test:~ # pkg -d upgrade
DBG(1)[24465]> pkg initialized
Updating FreeBSD repository catalogue...
DBG(1)[24465]> PkgRepo: verifying update for FreeBSD
DBG(1)[24465]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
DBG(1)[24465]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/meta.conf
DBG(1)[24465]> opening libfetch fetcher
DBG(1)[24465]> Fetch > libfetch: connecting
DBG(1)[24465]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/meta.conf with opts "i"
DBG(1)[24465]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.txz
DBG(1)[24465]> opening libfetch fetcher
DBG(1)[24465]> Fetch > libfetch: connecting
DBG(1)[24465]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.txz with opts "i"
FreeBSD repository is up to date.
All repositories are up to date.
DBG(1)[24465]> want to get an advisory lock on a database
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[24465]> problem has no requests
Checking integrity...DBG(1)[24465]> check integrity for 0 items added
 done (0 conflicting)
Your packages are up to date.
DBG(1)[24465]> release an advisory lock on a database

Same problem here. I've locked dwm, sterm and dmenu2. So 3 candiates appear outdated but the repo was updated. So I've unlocked dwm and sterm but dwmenu didn't showed up.

After pkg -d upgrade it poped out.

Code:

FreeBSD repository is up to date.

All repositories are up to date.
DBG(1)[2154]> want to get an advisory lock on a database
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libfreetype.so.6

DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libfontconfig.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXrender.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXinerama.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXft.so.2
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libX11.so.6
DBG(1)[2154]> problem has no requests
Checking integrity...DBG(1)[2154]> check integrity for 0 items added
 done (0 conflicting)
Your packages are up to date.

DBG(1)[2154]> release an advisory lock on a database

So I removed dmenu2... Problem solved.

fernandel · Sep 26, 2024

Márcio Rezende said:

Same problem here. I've locked dwm, sterm and dmenu2. So 3 candiates appear outdated but the repo was updated. So I've unlocked dwm and sterm but dwmenu didn't showed up.

After pkg -d upgrade it poped out.

Code:

FreeBSD repository is up to date.

All repositories are up to date.
DBG(1)[2154]> want to get an advisory lock on a database
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libfreetype.so.6

DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libfontconfig.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXrender.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXinerama.so.1
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libXft.so.2
DBG(1)[2154]> solver: for package: dmenu2 cannot find provide for requirement: libX11.so.6
DBG(1)[2154]> problem has no requests
Checking integrity...DBG(1)[2154]> check integrity for 0 items added
 done (0 conflicting)
Your packages are up to date.

DBG(1)[2154]> release an advisory lock on a database

So I removed dmenu2... Problem solved.

I have also "candidates" but those are applications which I build from ports and locked them.

Márcio Rezende · Sep 30, 2024

fernandel said:
I have also "candidates" but those are applications which I build from ports and locked them.

Same case of mine. I've locked dwm/sterm to avoid default customizations overlap mine after updates.

So I jump over my laziness and redefine those 2 setups I've patched on the new config.h code (for dwm and sterm), basically color, fontsize. And recompiled.

No more locks on my package database.

I used to have two options

- accept defaults, lose my config

- avoid updates, keep my config

Now I have just one:

- update and re-customize.

gnath · 2025-02-03T14:22:48+0000

fernandel said:
I have also "candidates" but those are applications which I build from ports and locked them

I have 21 nos. candidate today. I have simple package system, no locked one. Using pkg -d upgrade gave 12 nos. affected packages only for " cannot find provide for requirement " . I used pkg install -f packges for those and have to pkg upgrade -f for the rest. The question is why those errors.

fernandel · 2025-02-03T15:01:34+0000

gnath said:
I have 21 nos. candidate today. I have simple package system, no locked one. Using pkg -d upgrade gave 12 nos. affected packages only for " cannot find provide for requirement " . I used pkg install -f packges for those and have to pkg upgrade -f for the rest. The question is why those errors.

Whick pkg version? Did you try pkg query '%o %v %R', pkg version -vRL=, pkg upgrade -dd?
You will see the problem. I did it when I have a problem witk pkg 2.
https://forums.freebsd.org/threads/pkg-2-0-0-problems.96540/

SirDice · 2025-02-03T17:11:23+0000

gnath said:
I used pkg install -f packges for those and have to pkg upgrade -f for the rest.

There's no need to force install a couple of individual packages first, everything will get reinstalled with pkg upgrade -f.

pkg upgrade # What is "(1 candidates)"? [reproducible]

Deleted member 65380

Guest

Alexander Mishin

Cath O'Deray

Alexander Mishin

Cath O'Deray

Cath O'Deray

Cath O'Deray

Deleted member 65380

Guest

Deleted member 65380

Guest

zostj

Márcio Rezende

fernandel

Márcio Rezende

gnath

fernandel

SirDice

Administrator