Hi,

I am still working towards a Devuanized security-tracker but I have come
up against a problem which is blocking further development.  One section
of the process involves nested loops to update the database with current
packages in the devuan repos.  However, some of the
architectures do not exist in all of the repos, some repos do not
contain contrib and/or non-free sections, sources, sub releases etc;
there are also intermittant 404 errors for some repos and a frequent
ceres/contrib 403 error.  All of these events break the loops,
resulting in a failed update process.  For the purposes of getting the
process to the next stage, I have truncated the range of the variables
in each loop, but before the security-tracker could be of any use, the
full range of possible package combinations would need to be restored.
I can crash through some of the broken loops with make -k and get some
kind of output log, although it runs to hundreds of lines and is too
long to post here. Based on the Debian security-tracker, a full update
would look for valid URLs for each of the following permutations
Ceres     m/c/n-f (3)
        archs  (13)
            total            39    
Beowulf    m/c/n-f (3)
        archs (10)
        b/b-s/b-u (3)
            total         90
Ascii    m/c/n-f (3)
        archs (11)
        a/a-s/a-b/a-u/a-p-u (5)
            total            165
Jessie    m/c/n-f (3)
        archs (4)
        j/j-s/j-b/j-u/j-p-u (5)
            total            60
where m=main, c=contrib, n-f=non-free, and *,*-s,*-u,*-b,*-p-u are the
main, -security, -updates, -backports, and -proposed-updates
repositories respectively.  That's a current overhead of
354 URLs plus sources. Presumably, there will soon be added a
b-b and then a whole new family for chimaera within a year or two.  

Would it be possible to fill the 404 'holes' with empty repositories
as suggested
>On Sun, 12 Aug 2018 19:53:43 +0200
>Evilham <devuan@???> wrote:

>To keep the scripts happy, I also limited the
> architectures listed, e.g. there is no
> ascii-updates/non-free/binary-mips in our repos. @parazyd: is this a
> bug in Amprolla or is it by design? Would it make sense to create an
> "empty" repository in those cases?

If the loops could run to completion each time, the tracker would then
be faced with a new batch of bugs and patches on a regular basis. This
would then inform how reliably the devuan tracker can change the
status of a package from 'vulnerable' to 'fixed' once a patched version
is available. I haven't got to the bottom of it, but I think the issue
will involve permanently labelling the (temporally-dependent) 'stable'
bugs and patches to an archived 'ascii, beowulf, chimaera' patch in the
sqlite3 database, and then getting the security-tracker to respect the
new designation. I cannot begin this process until the update-packages
stage is reliable.

As it is, the update-packages script is acting as a 'repository
availability checker'; it may therefore be of some small use as the '403
Forbidden' error first appeared when the repository infrastructure
changed a few weeks ago.

Many thanks

leloft