freight missing packages from pool

[magwas]

I have run into a strange problem. Some packages are in the Packages file, but the corresponding file is missing in the pool.
The strange thing about it that is that there are two sets of packages.
When I run freight-cache, in one run set A gets put to the pool, in the next run set B, then set A again and so on.
I tried to delete the pool directory and dists/bionic*
After that set A contains all the packages, and set B is empty to the extent that even the pool directory gets deleted.

it seems that the bionic-* directory does contain all the packages, but the Packages file refers to the pool.

my /etc/freight.conf

# Example Freight configuration.

# Directories for the Freight library and Freight cache.  Your web
# server's document root should be `$VARCACHE`.
VARLIB="/var/lib/freight"
VARCACHE="/var/www/repo/apt"

# Default `Origin`, `Label`, `NotAutomatic`, and
# `ButAutomaticUpgrades` fields for `Release` files.
ORIGIN="Kode Konveyor"
LABEL="KodeKonveyor"
NOT_AUTOMATIC="no"
BUT_AUTOMATIC_UPGRADES="no"

# Cache the control files after each run (on), or regenerate them every
# time (off).
CACHE="off"

# GPG key(s) to use to sign repositories.  This is required by the `apt`
# repository provider.  Use `gpg --gen-key` (see `gpg`(1) for more
# details) to generate a key and put its email address here.
#
# Multiple addresses can be given sign the repository with them all.
GPG="info@kodekonveyor.com"
# GPG="example@example.com another@example.com"

# Message digest algorithm that GPG should use to sign the repository.
# It is not recommended to use SHA1 as new versions of `apt` will report
# that the repository is half-broken due to weak digest.
#
# SHA512 is the default
GPG_DIGEST_ALGO="SHA512"

# Whether to follow symbolic links in `$VARLIB` to produce extra components
# in the cache directory (on) or not (off).
SYMLINKS="off"

[DClabaut]

I can confirm I have the same issue.

How to reproduce:

• Spawn a Freight repo (I can provide a Dockerfile if anyone wants to test it quickly)
• Upload and add one or more packages, then refresh the cache

$ scp -P 4022 cppo* root@127.0.0.1:
cppo_1.3.2-1+b1_amd64.deb                                               100%  240KB  31.6MB/s   00:00    
cppo_1.6.4-3_amd64.deb                                                   100%  313KB  33.6MB/s   00:00

$ ssh root@127.0.0.1 -p 4022 freight-add cppo_1.3.2-1+b1_amd64.deb apt/stable
# [freight] added cppo_1.3.2-1+b1_amd64.deb to apt/stable

$ ssh root@127.0.0.1 -p 4022 freight-add cppo_1.6.4-3_amd64.deb apt/stable
# [freight] added cppo_1.6.4-3_amd64.deb to apt/stable

$ ssh root@127.0.0.1 -p 4022 freight-cache -v apt/stable
# [freight] adding cppo_1.3.2-1+b1_amd64.deb to pool
# [freight] adding cppo_1.6.4-3_amd64.deb to pool

• So far so good
• Upload and add other packages, then refresh the cache again (short version):

$ ssh root@127.0.0.1 -p 4022 freight-cache -v apt/stable
# [freight] adding metacity_3.14.3-1_amd64.deb to pool
# [freight] adding metacity_3.30.1-2_amd64.deb to pool

• ERROR: cppo is no longer available from the repo, only metacity
• Update the cache again

$ ssh root@127.0.0.1 -p 4022 freight-cache -v apt/stable
# [freight] adding cppo_1.3.2-1+b1_amd64.deb to pool
# [freight] adding cppo_1.6.4-3_amd64.deb to pool

• ERROR: Now only cppo is available, metacity is not.
• The issue can be reproduced with just one package, in which case the repo is either empty or containing the package at each cache refresh