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



## tux2bsd (Apr 29, 2021)

```
root@freebsd-dns:~ # pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.

root@freebsd-dns:~ # 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@freebsd-dns:~ # pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01  
Fetching packagesite.txz: 100%    6 MiB 235.1kB/s    00:26  
Processing entries: 100%
FreeBSD repository update completed. 28965 packages processed.
All repositories are up to date.

root@freebsd-dns:~ # 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@freebsd-dns:~ # pkg audit
0 problem(s) in 0 installed package(s) found.

root@freebsd-dns:~ # pkg autoremove
Checking integrity... done (0 conflicting)
Nothing to do.

root@freebsd-dns:~ # freebsd-version
13.0-RELEASE
```

What on earth is "*1 candidates*" referring to?


----------



## SirDice (Apr 29, 2021)

What does `pkg version -vRL=` tell you? Also check if that candidate isn't a Python 3.7 module or application, that could be potentially upgraded but also left as Python 3.7, since both "flavors" are supported. The default Python version changed recently from 3.7 to 3.8.


----------



## tux2bsd (Apr 29, 2021)

```
root@freebsd-dns:~ # pkg version -vRL=
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.

root@freebsd-dns:~ # pkg info -a | grep py | wc -l
       0
```

I didn't install python and don't think it's in the OS (I imagine it's additional).


----------



## SirDice (Apr 29, 2021)

tux2bsd said:


> I didn't install python and don't think it's in the OS (I imagine it's additional).


It's not part of the base OS, that's correct. It could have been pulled in as a dependency though. At least the `pkg version -vRL=` didn't show anything. That means everything is up to date and you also don't have any 'orphans'. 

You might want to run `pkg autoremove`, perhaps it's an old dependency that's still lingering.


----------



## bsduck (Apr 29, 2021)

I also have that "1 candidates" and in my case it corresponds to a package that is locked.


----------



## SirDice (Apr 29, 2021)

See if that's the case; `pkg lock -l`.


----------



## fjdlr (Apr 29, 2021)

hi, sorry for intrusion, i have the same problem and


> pkg lock -l


Currently, locked packages: 0
Strange


----------



## tux2bsd (May 1, 2021)

Python has nothing to do with it, not (& never) installed.  autoremove was in the original post.


```
root@freebsd-dns:~ # pkg lock -l
Currently locked packages:
root@freebsd-dns:~ #
```

A bug affects pkg, I'm happy to assist in its diagnosis (as I have it exhibiting the odd behavior).


----------



## tux2bsd (May 1, 2021)

```
root@freebsd-dns:~ # freebsd-version
13.0-RELEASE
root@freebsd-dns:~ # uname -av
FreeBSD freebsd-dns 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 06:06:55 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64
root@freebsd-dns:~ # pkg -v
1.16.3
```


----------



## tux2bsd (May 5, 2021)

```
root@freebsd-dns:~ # pkg update
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB 321.6kB/s    00:19    
Processing entries: 100%
FreeBSD repository update completed. 28975 packages processed.
All repositories are up to date.
root@freebsd-dns:~ # 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@freebsd-dns:~ # date
Wed May  5 21:24:15 NZST 2021
```


----------



## SirDice (May 5, 2021)

What does `pkg version -vRx py37` show? Actually, just post the whole thing; `pkg version -vR`


----------



## tux2bsd (May 6, 2021)

SirDice said:


> What does `pkg version -vRx py37` show?


Again, python isn't installed.  The fixation with python is puzzling.



SirDice said:


> Actually, just post the whole thing; `pkg version -vR`


Here's both:

```
root@freebsd-dns:~ # pkg version -vRx py37
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
root@freebsd-dns:~ # pkg version -vR
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
ca_root_nss-3.63                   =   up-to-date with remote
expat-2.2.10                       =   up-to-date with remote
libevent-2.1.12                    =   up-to-date with remote
libnghttp2-1.43.0                  =   up-to-date with remote
pkg-1.16.3                         =   up-to-date with remote
unbound-1.13.1                     =   up-to-date with remote
root@freebsd-dns:~ #
```


----------



## SirDice (May 6, 2021)

tux2bsd said:


> The fixation with python is puzzling.


It's been updated recently and typically a lot of users fall into that trap of not updating properly, which can lead to all sorts of problems.


----------



## tux2bsd (May 6, 2021)

```
pkg/tests/frontend/issue1440.sh:Checking for upgrades (1 candidates):  done
pkg/tests/frontend/issue1440.sh:Processing candidates (1 candidates):  done
```
Smells like satisfying a build test that maybe somehow slipped into the code (edit: or package database )


----------



## tux2bsd (May 6, 2021)

/var/db/pkg/local.sqlite

```
sqlite> select name,version from packages;
pkg|1.16.3
expat|2.2.10
libevent|2.1.12
libnghttp2|1.43.0
unbound|1.13.1
ca_root_nss|3.63
```
Matches above (`pkg version -vR`).

Happy to keep looking, just need pointers.


----------



## SirDice (May 6, 2021)

It's a little drastic perhaps but try removing everything `pkg delete -a` (only pkg(8) itself should remain), then see if you still have that 1 candidate. If that clears it add each package again, checking in the meantime for that candidate. You don't have a lot of packages installed so this should be fairly easy to do.

Perhaps there's still something hiding in your local package database. Hopefully removing everything would clear that. You can also do `pkg delete -af`, that will also delete everything but removes pkg(8) itself too. Then remove or move local.sqlite out of the way and let `pkg bootstrap` create a fresh new one.


----------



## tux2bsd (May 6, 2021)

fjdlr said:


> hi, sorry for intrusion, i have the same problem


fjdlr are you able to try the things SirDice just mentioned?  I'll need to wait until the weekend to attempt it, more than 24 hours away.


----------



## fjdlr (May 6, 2021)

tux2bsd said:


> fjdlr are you able to try the things SirDice just mentioned?  I'll need to wait until the weekend to attempt it, more than 24 hours away.


Hi to day and after two `pkg update & pkg upgrade` the problem is solved
I think that pkg py37 is maybe in question
Thanks


----------



## tux2bsd (May 7, 2021)

fjdlr said:


> `pkg update & pkg upgrade`


fyi you want *&&* there


----------



## tux2bsd (May 7, 2021)

```
root@freebsd-dns:~ # pkg delete -a
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 6 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        ca_root_nss: 3.63
        expat: 2.2.10
        libevent: 2.1.12
        libnghttp2: 1.43.0
        pkg: 1.16.3
        unbound: 1.13.1

Number of packages to be removed: 6

The operation will free 46 MiB.

Proceed with deinstalling packages? [y/N]: y
[1/6] Deinstalling unbound-1.13.1...
[1/6] Deleting files for unbound-1.13.1: 100%
[2/6] Deinstalling ca_root_nss-3.63...
[2/6] Deleting files for ca_root_nss-3.63: 100%
[3/6] Deinstalling expat-2.2.10...
[3/6] Deleting files for expat-2.2.10: 100%
[4/6] Deinstalling libevent-2.1.12...
[4/6] Deleting files for libevent-2.1.12: 100%
[5/6] Deinstalling libnghttp2-1.43.0...
[5/6] Deleting files for libnghttp2-1.43.0: 100%
You may need to manually remove /usr/local/etc/unbound/unbound.conf if it is no longer needed.     
root@freebsd-dns:~ # mv /var/db/pkg/local.sqlite /root/
root@freebsd-dns:~ # pkg bootstrap
pkg already bootstrapped at /usr/local/sbin/pkg
root@freebsd-dns:~ # pkg delete --all --force
pkg: No packages installed.  Nothing to do!
root@freebsd-dns:~ # pkg bootstrap
pkg already bootstrapped at /usr/local/sbin/pkg
root@freebsd-dns:~ # rm /usr/local/sbin/pkg
root@freebsd-dns:~ # pkg bootstrap
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:13:aarch64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.16.3...
Extracting pkg-1.16.3: 100%
root@freebsd-dns:~ # pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
root@freebsd-dns:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
root@freebsd-dns:~ # pkg info -a
pkg-1.16.3                     Package manager
```

No luck and only pkg...  a bug like this, while seemingly benign, shouldn't exist.


----------



## tux2bsd (May 7, 2021)

I've verified it's easily reproducible.

Installed a VM, amd64 bootonly -> next next next finish.  Same behaviour, *(1 candidates)*.






edit: `pkg info -a` that I forgot before:


----------



## fjdlr (May 7, 2021)

tux2bsd said:


> fyi you want *&&* there


Yes sir is true


----------



## tux2bsd (May 7, 2021)

pkg (same version) does the same on FreeBSD 12.2, just tried that in a fresh VM.

Maybe we've just not noticed it before... I'd still like to know what *(1 canditates)* means?  SirDice was recommending `pkg delete -a` which makes me think it's not common knowledge.


----------



## SirDice (May 7, 2021)

It's certainly not common knowledge, maybe it has something to do with the pkg-repo(8) data on the official servers. If I look at my own servers, using my own repositories I get 0 candidates. 

```
root@molly:~ # pkg upgrade
Updating dicelan-server repository catalogue...
dicelan-server repository is up to date.
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.
```
On a quick test setup I also get that 1 candidate, only pkg(8) itself is installed here:

```
root@fbsd-test:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
```

I think I need to have a look at the code to understand where that candidate number is coming from.


----------



## VladiBG (May 7, 2021)

Use debug opt.


----------



## SirDice (May 7, 2021)

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

```
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
```


----------



## tux2bsd (May 7, 2021)

Just to point out it seems independant of what is installed, the candidates number was *1* despite 6 packages or 1 package - from my earlier scenarios. Also independent of architechture (aarch64 vs amd64) or FreeBSD release (13 vs 12.2), `pkg upgrade` exhibits the same behaviour (on an affected/fresh install).


----------



## fjdlr (May 7, 2021)

tux2bsd said:


> Just to point out it seems independant of what is installed, from my earlier scenarios the candidates number was *1* despite 6 packages or 1 package. Also independent of architechture (amd64 vs ASDF) or FreeBSD release 13 vs 12.2, same behaviour.


For info:
To day i make the last PC migrate, FreeBSD 12.2 to 13.0
After the last reboot and`pkg update && pkg upgrade`....

```
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
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.
```


----------



## tux2bsd (May 11, 2021)

SirDice said:


> I think I need to have a look at the code to understand where that candidate number is coming from.


Any luck with this mysterious number?


----------



## SirDice (May 11, 2021)

No, but I've honestly haven't had the time to look through the sources yet.


----------



## bsduck (May 11, 2021)

Maybe this can help your investigation:

I played a bit with DragonFly (a FreeBSD fork that also uses pkg) and noticed that after switching the pkg repository to a mirror closer to me, `pkg upgrade` would suddenly mention a big number of such "candidates" although there was nothing new to upgrade.

This made me understand that pkg considers as a candidate anything that was installed from another repository than what is currently enabled. On FreeBSD, this can typically be locally built packages. I tried unlocking my locked packages and they would still show up as "candidates", so what is relevant is the fact I built them from ports, not the fact they are locked. Maybe it can also be the case of packages which were installed from pkg but are currently not in the repository anymore.

In your case, this may be... pkg itself.
Try `pkg upgrade -f pkg`


----------



## SirDice (May 11, 2021)

bsduck said:


> so what is relevant is the fact I built them from ports


On the tests I did pkg(8) itself was the only package that was installed and it came from the exact same repository.


----------



## mark_j (May 11, 2021)

pkg-install(8)

```
The dependencies of packages in the list are examined and any missing
packages are added to the list for installation.
Such implicitly added packages are flagged as candidates for
autoremoval.
```


----------



## SirDice (May 11, 2021)

Ah. Subtle. So I started off with pkg(8) being the only thing that was installed:

```
root@fbsd-test:~ # pkg version -vR
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB   2.2MB/s    00:03
Processing entries: 100%
FreeBSD repository update completed. 30362 packages processed.
All repositories are up to date.
pkg-1.16.3                         =   up-to-date with remote
```
Then `pkg upgrade` showed that 1 candidate:

```
root@fbsd-test:~ # 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.
```
But pkg(8) doesn't have any dependencies, so where does this candidate come from? And as it's the only package that's installed there's nothing that would pull in any other implicit dependencies, and thus there should be 0 candidates. 

So I did a forced reinstall:

```
root@fbsd-test:~ # pkg install -f pkg
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        pkg-1.16.3 [FreeBSD]

Number of packages to be reinstalled: 1

8 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.16.3.txz: 100%    8 MiB   2.9MB/s    00:03
Checking integrity... done (0 conflicting)
[1/1] Reinstalling pkg-1.16.3...
[1/1] Extracting pkg-1.16.3: 100%
```

And now the candidates is gone:

```
root@fbsd-test:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
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.
```

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.


----------



## tux2bsd (May 12, 2021)

SirDice said:


> So I did a forced reinstall:
> 
> ```
> root@fbsd-test:~ # pkg install -f pkg
> ```


Good thinking to try that.


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.


Makes total sense as an explanation of the undesirable behavior.


----------



## tux2bsd (May 14, 2021)

SirDice said:


> So I did a forced reinstall _(of pkg)_:
> ...
> And now the candidates is gone:


I also just repeated this exercise with the same outcome.


----------



## lynks (May 14, 2021)

the workarround works for me. thanks!!


----------



## tux2bsd (May 15, 2021)

SirDice can you please submit a bug report so that coders can find and fix the bug.


----------



## bsduck (May 16, 2021)

tux2bsd said:


> SirDice can you please submit a bug report so that coders can find and fix the bug.


Do it yourself instead of asking others to.


----------



## tux2bsd (May 16, 2021)

bsduck said:


> Do it yourself instead of asking others to.



I don't know the official process to post a bug report for FreeBSD.  Does my Forum login let me do that?  

I noticed this bug and ultimately demonstrated to it to a FreeBSD staff member, surely that would go somewhere?


----------



## tingo (May 16, 2021)

There is a difference in talking about a problem / bug (including demonstrating it) and reporting it. Talking about it shines a light on it for a short time - it might be forgotten soon. Reporting it keeps it remembered.
Here is how to write problem reports https://docs.freebsd.org/en/articles/problem-reports/


----------



## SirDice (May 16, 2021)

tux2bsd said:


> I don't know the official process to post a bug report for FreeBSD.








						FreeBSD Bugzilla Main Page
					






					bugs.freebsd.org
				






tux2bsd said:


> Does my Forum login let me do that?


No, you need to register an account with the bugtracker. Anyone can sign up and report bugs.



tux2bsd said:


> I noticed this bug and ultimately demonstrated to it to a FreeBSD staff member, surely that would go somewhere?


I'm not a FreeBSD staff member, I'm a user just like you (ok, I do have 20 years more experience than you but you get the idea). I'm an admin on this forum, that's all. The 'Staff member' label refers to my status on the forums, moderators and admins are staff members.  Registered FreeBSD developers will have an @ after their name.


----------



## tux2bsd (May 17, 2021)

Thanks for the links.



SirDice said:


> The 'Staff member' label refers to my status on the forums, moderators and admins are staff members.  Registered FreeBSD developers will have an @ after their name.


That's not stupidly misleading and confusing at all... (this is not directed at you personally)
p.s. normal forum plebs see this from your link:


> Oops! We ran into some problems.​           You do not have permission to view this page or perform this action.


----------



## tux2bsd (May 18, 2021)

Bug reported: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255967


----------



## tux2bsd (May 19, 2021)

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.


I think you should add that to the bug report.  Another person concurring with additional information will help.


SirDice said:


> ok, I do have 20 years more experience than you *with FreeBSD* but you get the idea


You should stop patting yourself on the back... I also added a correction in bold.


----------



## SirDice (May 19, 2021)

It might not be the correct interpretation. I've set up a new server at work, and because I had to do this "offline" before I racked it, I installed all required packages using pkg-add(8). It's now racked and running. Looking at `pkg upgrade` it has 83 packages installed and shows 83 candidates with everything up to date (it has to be up to date because I copied the same repository to a USB stick to install it locally). So it looks like it has something to do with the difference between pkg-add(8) and pkg-install(8). The `pkg bootstrap` also uses pkg-add(8) to install itself.

So the candidate also indicates packages that have been installed _locally_. Compared to a remote repository they're a candidate to upgrade, but because it's already installed and the correct version there's nothing getting updated (it would be a pointless reinstall). If I just run `pkg upgrade -f` to reinstall everything from the remote repository then the candidates return to 0.


----------



## tux2bsd (May 19, 2021)

SirDice said:


> it has 83 packages installed and shows 83 candidates with everything up to date


Interesting but so gross.


----------



## SirDice (May 19, 2021)

tux2bsd said:


> Interesting but so gross.


Not really, it's explainable, pkg(8) keeps track of where packages come from. It's correctly determining those packages are _candidates_ to upgrade, but because they're up to date with the remote repository there's no _need_ to upgrade them.


----------



## tux2bsd (May 21, 2021)

Being explainable doesn't stop something being gross.  Let's not forget it wasn't long ago this wasn't explainable:


SirDice said:


> It's certainly not common knowledge, maybe it has something to do with


At the bare minimum searching the pkg-upgrade man page for 'candidate' should have a bit more explaination.  Maybe SirDice could give the pkg people some words for their man page?

If it is a bug, like I think it is, it could be fixed.


----------



## grahamperrin@ (Dec 4, 2021)

VladiBG said:


> Use debug opt.





SirDice said:


> … the candidate also indicates packages that have been installed _locally_. …



I wonder about three of these four candidates: 


```
% pkg -d upgrade -r poudriere -n
DBG(1)[74170]> pkg initialized
Checking for upgrades (4 candidates): 100%
Processing candidates (4 candidates): 100%
DBG(1)[74170]> Binary> loading //usr/local/poudriere/data/packages/main-default/All/meson-0.60.2.pkg
Checking integrity...DBG(1)[74170]> check integrity for 1 items added
 done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        meson: 0.60.1_1 -> 0.60.2 [poudriere]

Number of packages to be upgraded: 1
% pkg query -a '%o %v %R' | grep unknown | sort
emulators/virtualbox-ose-kmod 6.1.30 unknown-repository
graphics/drm-current-kmod 5.4.144.g20211012 unknown-repository
graphics/drm-kmod g20190710_1 unknown-repository
graphics/gpu-firmware-kmod g20210330 unknown-repository
net/citrix_ica 13.10.0 unknown-repository
sysutils/beadm 1.3.2 unknown-repository
www/waterfox 2019.12.c unknown-repository
x11-fonts/fontconfig 2.13.94_1,1 unknown-repository
x11-toolkits/linux-c7-openmotif 2.3.4_6 unknown-repository
% pkg query -e '%a = 0' '%o %v %R' | grep poudriere | sort
deskutils/recoll 1.31.2 poudriere
editors/linux-wps-office 11.1.0.10161 poudriere
emulators/virtualbox-ose 6.1.30 poudriere
net/td-system-tools 1.2.0 poudriere
ports-mgmt/pkg 1.17.5 poudriere
ports-mgmt/poudriere-devel 3.3.99.20211017_2 FreeBSD
science/linux-zotero 5.0.96.3 poudriere
sysutils/brut 1.55 poudriere
sysutils/cpufetch 1.00 poudriere
sysutils/lsblk 3.7 poudriere
x11-themes/kde-icons-black-and-white 2.0.a poudriere
% pkg query -e '%a = 1' '%o %v %R' | grep poudriere | sort
audio/festlex-oald 1.4.1_1 poudriere
audio/linux-c7-flac 1.3.0_2 poudriere
audio/linux-c7-gsm 1.0.13 poudriere
audio/linux-c7-libogg 1.3.0_1 poudriere
audio/linux-c7-libsndfile 1.0.25_6 poudriere
audio/linux-c7-libvorbis 1.3.3_2 poudriere
audio/linux-c7-pulseaudio-libs 10.0_3 poudriere
devel/binutils 2.37_2,1 poudriere
devel/linux-c7-dbus-glib 0.100_1 poudriere
devel/pcre2 10.39 poudriere
devel/py-six 1.16.0 poudriere
dns/linux-c7-libasyncns 0.8_1 poudriere
ftp/curl 7.80.0 poudriere
graphics/wayland-protocols 1.23 poudriere
lang/vala 0.48.18,1 poudriere
math/fftw3 3.3.9_1 poudriere
multimedia/dav1d 0.9.2 poudriere
multimedia/libdca 0.0.7 poudriere
net/linux-c7-tcp_wrappers-libs 7.6_2 poudriere
textproc/docbook-xml 5.0_3 poudriere
textproc/expat2 2.4.1 poudriere
x11-fonts/libXfont2 2.0.5 poudriere
x11/libX11 1.7.2,1 poudriere
x11/libxshmfence 1.3_1 poudriere
%
```

In my case, most _unknown-repository_ listings are for packages that resulted from a `make installkernel` routine. 

I wondered about version changes that might not require an upgrade. Ploughed through the lists of non-automatic and automatic packages from my poudriere repository, found no discrepancy. For example, `devel/binutils 2.37_2,1` above and: 


```
% pkg rquery '%o %v %R' binutils
devel/binutils 2.37_2,1 FreeBSD
devel/binutils 2.37_2,1 poudriere
%
```

Some of these should help to understand how the number of candidates is calculated: 

Search for upgrade candidates first prior to upgrade. · freebsd/pkg@c163324 (2014-05-28)
Add progressbar for solver. · freebsd/pkg@a20caba (2014-06-06)
Print number of upgrade candidates. · freebsd/pkg@816c5e4 (2014-08-06)
pkg/pkg_jobs.c at master · freebsd/pkg


----------



## tux2bsd (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:
> ...



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.


----------



## grahamperrin@ (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

```
/usr/sbin/pkg repo ${REPO}/${ABI}/latest signing_command: ./${SIGN}.sh
```
... or how is this done in the 'poudriere' provided repositories.


----------



## grahamperrin@ (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.









						pkg-upgrade(8): consider listing candidates when there's debug output with pkg(8) option -d · Issue #2012 · freebsd/pkg
					

Please, is it feasible to present a list of candidates? If not a list: maybe something more verbose than the count (in the example below, 4). % pkg -d upgrade -r poudriere -n DBG(1)[74170]> pkg ...




					github.com


----------



## grahamperrin@ (Apr 8, 2022)

```
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.)


----------



## grahamperrin@ (Apr 8, 2022)

elimelech007 said:


> ```
> root@A9t:/home/luba # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> ...



elimelech007 for your one-candidate case, please run: 

`pkg -ddd upgrade -n`


----------



## tux2bsd (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...


----------



## tux2bsd (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.


----------

