On dc., juny 19 2019, fsmithred@??? wrote:

> On 6/17/19 5:31 PM, Ivan J. wrote:
>> On Mon, Jun 17, 2019 at 11:26:28PM +0200, Ivan J. wrote:
>>> On Sun, Jun 16, 2019 at 04:10:20PM -0400, fsmithred wrote:
>>>> 2019-06-16 pkgmaster is not getting security updates. This
>>>> was fixed, now
>>>> it's broken again. Can someone figure out why it keeps
>>>> happening?
>>>>
>>>> https://dev1galaxy.org/viewtopic.php?pid=16504#p16504
>>>>

>>>> $ apt-cache policy thunderbird
>>>> 1:60.7.1-1~deb9u1 500
>>>>          500 http://auto.mirror.devuan.org/merged 
>>>>          ascii-security/main amd64
>>>> Packages
>>>> 1:60.7.0-1~deb9u1 500
>>>>          500 http://pkgmaster.devuan.org/merged 
>>>>          ascii-security/main amd64
>>>> Packages

>>>
>>> Picked this up today. The issue was an unhandled exception in
>>> net.py.
>>>
>>> I've pushed a fix to Gitlab[0] and applied this in production
>>> for both
>>> pkgmaster.do and packages.do.
>>>
>>> [0]
>>> https://git.devuan.org/devuan-infrastructure/amprolla3/commit/0c33c2d195c702f928e0e4299fed9ca8252eb85f
>>
>> The amprolla logs[1] are there for a reason :)
>> Just grep it for 'ERR' to see what's wrong.
>>
>> [1] https://pkgmaster.devuan.org/amprolla.txt
>>
>>
>
>
> There's still (again?) a problem. Thunderbird is now the latest
> version,
> but firefox-esr is lagging behind in pkgmaster. Log shows a
> bunch of 404
> errors.

Those 404 are alright (there's only the compressed files now).


This probably isn't:

# curl -s https://pkgmaster.devuan.org/amprolla.txt | tail -n 1
2019/06/17 21:20:03 [INFO] Total incremental update time:
2.0730831623077393


These also probably aren't:

https://www.debian.org/security/2019/dsa-4465

# apt policy linux-image-amd64
linux-image-amd64:
Installed: 4.9+80+deb9u7
Candidate: 4.9+80+deb9u7


https://www.debian.org/security/2019/dsa-4466

# apt policy firefox-esr
firefox-esr:
Installed: (none)
Candidate: 60.7.0esr-1~deb9u1


https://www.debian.org/security/2019/dsa-4467
# apt policy vim
vim:
Installed: 2:8.0.0197-4+deb9u1
Candidate: 2:8.0.0197-4+deb9u1



Shot in the dark: Amprolla *could* be stuck in an endless loop
since this change (time stamp of commit and lass amprolla update
are nearly identical).

>>> [0]
>>> https://git.devuan.org/devuan-infrastructure/amprolla3/commit/0c33c2d195c702f928e0e4299fed9ca8252eb85f

It doesn't seem to have a way to detect endless `download(uri)`
loops when for whatever reason one of the caught exceptions are
thrown (e.g. because of a server rate-limiting).


Then again, maybe everything *is* ok :-).
--
Evilham