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 <dev...@evilham.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng