Mailing List Archive

asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED!
Howdy,

For the past couple weeks, this package has failed to update because it
is the wrong size.  This is from the logs for today.


2021-02-22 07:20:45 (96.2 KB/s) -
‘/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz.__download__’ saved
[1119288]

!!! Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got:      1119288
!!! Expected: 1119318
Refetching... File renamed to
'/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz._checksum_failure_.ngu5ov57'

!!! Couldn't download 'asciidoc-9.0.5.tar.gz'. Aborting.


I found a bug that I think addresses this issue.  It appears it should
be fixed but I've synced twice since then and it still fails.  Here's
the bug.

https://bugs.gentoo.org/770841

I've also tried different versions with no change.  Any one else running
into this?  Is something wrong on my end that is preventing the fix from
reaching me?  Am I missing something else? 

Thanks.

Dale

:-)  :-) 
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
On 2/28/21 4:53 PM, Dale wrote:
> Howdy,
>
> For the past couple weeks, this package has failed to update because it
> is the wrong size.  This is from the logs for today.
>
>
> 2021-02-22 07:20:45 (96.2 KB/s) -
> ‘/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz.__download__’ saved
> [1119288]
>
> !!! Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED!
> !!! Reason: Filesize does not match recorded size
> !!! Got:      1119288
> !!! Expected: 1119318
> Refetching... File renamed to
> '/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz._checksum_failure_.ngu5ov57'
>
> !!! Couldn't download 'asciidoc-9.0.5.tar.gz'. Aborting.
>
>
> I found a bug that I think addresses this issue.  It appears it should
> be fixed but I've synced twice since then and it still fails.  Here's
> the bug.
>
> https://bugs.gentoo.org/770841
>
> I've also tried different versions with no change.  Any one else running
> into this?  Is something wrong on my end that is preventing the fix from
> reaching me?  Am I missing something else?
>
> Thanks.
>
> Dale

I just installed asciidoc-9.0.4 and then 9.0.5 with no problems.
However, something seems odd, since those ebuilds are dated 2/14, so not
recently updated.  That bug looks like they identified the necessary
fixes, but didn't actually apply them yet.  I think what happened is
that upstream made those changes talked about in the bug, but the new
tarballs have not hit all the mirrors yet.  If you happen to hit a
mirror  with the old files, the emerge will work OK.  If you hit a
mirror with the new tarballs, you'll get the failure you got.  Since you
already have the new tarball, maybe you just need to manually edit the
ebuild per the bug, and rerun "ebuild path/to/file.ebuild manifest" to
manually update the hash for the tarball, if you trust the tarball you have.

Jack
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
Jack wrote:
> On 2/28/21 4:53 PM, Dale wrote:
>> Howdy,
>>
>> For the past couple weeks, this package has failed to update because it
>> is the wrong size.  This is from the logs for today.
>>
>>
>> 2021-02-22 07:20:45 (96.2 KB/s) -
>> ‘/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz.__download__’ saved
>> [1119288]
>>
>> !!! Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED!
>> !!! Reason: Filesize does not match recorded size
>> !!! Got:      1119288
>> !!! Expected: 1119318
>> Refetching... File renamed to
>> '/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz._checksum_failure_.ngu5ov57'
>>
>>
>> !!! Couldn't download 'asciidoc-9.0.5.tar.gz'. Aborting.
>>
>>
>> I found a bug that I think addresses this issue.  It appears it should
>> be fixed but I've synced twice since then and it still fails.  Here's
>> the bug.
>>
>> https://bugs.gentoo.org/770841
>>
>> I've also tried different versions with no change.  Any one else running
>> into this?  Is something wrong on my end that is preventing the fix from
>> reaching me?  Am I missing something else?
>>
>> Thanks.
>>
>> Dale
>
> I just installed asciidoc-9.0.4 and then 9.0.5 with no problems.
> However, something seems odd, since those ebuilds are dated 2/14, so
> not recently updated.  That bug looks like they identified the
> necessary fixes, but didn't actually apply them yet.  I think what
> happened is that upstream made those changes talked about in the bug,
> but the new tarballs have not hit all the mirrors yet.  If you happen
> to hit a mirror  with the old files, the emerge will work OK.  If you
> hit a mirror with the new tarballs, you'll get the failure you got. 
> Since you already have the new tarball, maybe you just need to
> manually edit the ebuild per the bug, and rerun "ebuild
> path/to/file.ebuild manifest" to manually update the hash for the
> tarball, if you trust the tarball you have.
>
> Jack
>
>
>


That makes sense.  It explains why the bug says it is fixed but I'm not
getting the results.  So, I did the manifest thing to force it to build
and install anyway.  Now I get this:


>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-text/asciidoc-9.0.5::gentoo
>>> Failed to emerge app-text/asciidoc-9.0.5, Log file:
>>>  '/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'
>>> Jobs: 0 of 1 complete, 1 failed                 Load avg: 10.9,
10.6, 10.7
 * Package:    app-text/asciidoc-9.0.5
 * Repository: gentoo
 * Maintainer: marcec@gmx.de proxy-maint@gentoo.org
 * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux
python_single_target_python3_8 userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 * Using python3.8 to build
>>> Unpacking source...
>>> Unpacking asciidoc-9.0.5.tar.gz to
/var/tmp/portage/app-text/asciidoc-9.0.5/work
>>> Source unpacked in /var/tmp/portage/app-text/asciidoc-9.0.5/work
 * ERROR: app-text/asciidoc-9.0.5::gentoo failed (prepare phase):
 *   The source directory
'/var/tmp/portage/app-text/asciidoc-9.0.5/work/asciidoc-py3-9.0.5'
doesn't exist
 *
 * Call stack:
 *            ebuild.sh, line  762:  Called __ebuild_main 'prepare'
 *   phase-functions.sh, line 1050:  Called __dyn_prepare
 *   phase-functions.sh, line  384:  Called die
 * The specific snippet of code:
 *              die "The source directory '${S}' doesn't exist"
 *
 * If you need support, post the output of `emerge --info
'=app-text/asciidoc-9.0.5::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=app-text/asciidoc-9.0.5::gentoo'`.
 * The complete build log is located at
'/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'.
 * For convenience, a symlink to the build log is located at
'/var/tmp/portage/app-text/asciidoc-9.0.5/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/app-text/asciidoc-9.0.5/temp/environment'.
 * Working directory: '/var/tmp/portage/app-text/asciidoc-9.0.5/homedir'
 * S: '/var/tmp/portage/app-text/asciidoc-9.0.5/work/asciidoc-py3-9.0.5'
 *
 * The following package has failed to build, install, or execute postinst:
 *
 *  (app-text/asciidoc-9.0.5:0/0::gentoo, ebuild scheduled for merge),
Log file:
 *   '/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'
 *
root@fireball / #


It seems the ebuild or the tarball I'm getting isn't right.  By the way,
when I look, that directory is there.  I'm not sure why it says it
doesn't exist.  It seems this is a much bigger problem or I need to sync
and get tarballs from somewhere else.  Something fishy somewhere. 

Thanks for the help.  Will try changing server sources next. 

Dale

:-)  :-) 
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
Dale wrote:
> Jack wrote:
>> On 2/28/21 4:53 PM, Dale wrote:
>>> Howdy,
>>>
>>> For the past couple weeks, this package has failed to update because it
>>> is the wrong size.  This is from the logs for today.
>>>
>>>
>>> 2021-02-22 07:20:45 (96.2 KB/s) -
>>> ‘/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz.__download__’ saved
>>> [1119288]
>>>
>>> !!! Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED!
>>> !!! Reason: Filesize does not match recorded size
>>> !!! Got:      1119288
>>> !!! Expected: 1119318
>>> Refetching... File renamed to
>>> '/var/cache/portage/distfiles/asciidoc-9.0.5.tar.gz._checksum_failure_.ngu5ov57'
>>>
>>>
>>> !!! Couldn't download 'asciidoc-9.0.5.tar.gz'. Aborting.
>>>
>>>
>>> I found a bug that I think addresses this issue.  It appears it should
>>> be fixed but I've synced twice since then and it still fails.  Here's
>>> the bug.
>>>
>>> https://bugs.gentoo.org/770841
>>>
>>> I've also tried different versions with no change.  Any one else running
>>> into this?  Is something wrong on my end that is preventing the fix from
>>> reaching me?  Am I missing something else?
>>>
>>> Thanks.
>>>
>>> Dale
>> I just installed asciidoc-9.0.4 and then 9.0.5 with no problems.
>> However, something seems odd, since those ebuilds are dated 2/14, so
>> not recently updated.  That bug looks like they identified the
>> necessary fixes, but didn't actually apply them yet.  I think what
>> happened is that upstream made those changes talked about in the bug,
>> but the new tarballs have not hit all the mirrors yet.  If you happen
>> to hit a mirror  with the old files, the emerge will work OK.  If you
>> hit a mirror with the new tarballs, you'll get the failure you got. 
>> Since you already have the new tarball, maybe you just need to
>> manually edit the ebuild per the bug, and rerun "ebuild
>> path/to/file.ebuild manifest" to manually update the hash for the
>> tarball, if you trust the tarball you have.
>>
>> Jack
>>
>>
>>
>
> That makes sense.  It explains why the bug says it is fixed but I'm not
> getting the results.  So, I did the manifest thing to force it to build
> and install anyway.  Now I get this:
>
>
>>>> Verifying ebuild manifests
>>>> Emerging (1 of 1) app-text/asciidoc-9.0.5::gentoo
>>>> Failed to emerge app-text/asciidoc-9.0.5, Log file:
>>>>   '/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'
>>>> Jobs: 0 of 1 complete, 1 failed                 Load avg: 10.9,
> 10.6, 10.7
>  * Package:    app-text/asciidoc-9.0.5
>  * Repository: gentoo
>  * Maintainer: marcec@gmx.de proxy-maint@gentoo.org
>  * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux
> python_single_target_python3_8 userland_GNU
>  * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>  * Using python3.8 to build
>>>> Unpacking source...
>>>> Unpacking asciidoc-9.0.5.tar.gz to
> /var/tmp/portage/app-text/asciidoc-9.0.5/work
>>>> Source unpacked in /var/tmp/portage/app-text/asciidoc-9.0.5/work
>  * ERROR: app-text/asciidoc-9.0.5::gentoo failed (prepare phase):
>  *   The source directory
> '/var/tmp/portage/app-text/asciidoc-9.0.5/work/asciidoc-py3-9.0.5'
> doesn't exist
>  *
>  * Call stack:
>  *            ebuild.sh, line  762:  Called __ebuild_main 'prepare'
>  *   phase-functions.sh, line 1050:  Called __dyn_prepare
>  *   phase-functions.sh, line  384:  Called die
>  * The specific snippet of code:
>  *              die "The source directory '${S}' doesn't exist"
>  *
>  * If you need support, post the output of `emerge --info
> '=app-text/asciidoc-9.0.5::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=app-text/asciidoc-9.0.5::gentoo'`.
>  * The complete build log is located at
> '/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'.
>  * For convenience, a symlink to the build log is located at
> '/var/tmp/portage/app-text/asciidoc-9.0.5/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/app-text/asciidoc-9.0.5/temp/environment'.
>  * Working directory: '/var/tmp/portage/app-text/asciidoc-9.0.5/homedir'
>  * S: '/var/tmp/portage/app-text/asciidoc-9.0.5/work/asciidoc-py3-9.0.5'
>  *
>  * The following package has failed to build, install, or execute postinst:
>  *
>  *  (app-text/asciidoc-9.0.5:0/0::gentoo, ebuild scheduled for merge),
> Log file:
>  *   '/var/log/portage/app-text:asciidoc-9.0.5:20210301-003627.log'
>  *
> root@fireball / #
>
>
> It seems the ebuild or the tarball I'm getting isn't right.  By the way,
> when I look, that directory is there.  I'm not sure why it says it
> doesn't exist.  It seems this is a much bigger problem or I need to sync
> and get tarballs from somewhere else.  Something fishy somewhere. 
>
> Thanks for the help.  Will try changing server sources next. 
>
> Dale
>
> :-)  :-) 
>


I tried syncing with different servers, I think some are bad out of
date, but it hasn't helped.  I either run into a failed verify or the
error about a directory not existing, that does exist by the way.  If
someone else runs into this, my temporary solution is to stick with
asciidoc-9.0.2 and mask the rest.  Maybe when it updates to 9.0.6 or
something, it will be fixed. 

I'm not sure what is going on with the servers but when I switched to
one of them, recent updates didn't even exist.  I just did a KDE and I
think Firefox and neither seemed to be in the tree from those servers. 
Thing is, I didn't note which server it was.  If someone notices that
their syncing isn't working right, may want to switch and find one that
is up to date.  There's something fishy going on and I don't know what
to report.  I might add, I found a bad mirror not long ago and it was
removed.  It is the US based servers.  I didn't try the other
countries.  If someone has a way to test them, I used mirrorselect -r -i
to select a server. 

Thanks Jack for the reply.  It helped to get info from someone else. 

Dale

:-)  :-) 
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
On Sun, 28 Feb 2021 22:29:49 -0600, Dale wrote:

> I'm not sure what is going on with the servers but when I switched to
> one of them, recent updates didn't even exist.  I just did a KDE and I
> think Firefox and neither seemed to be in the tree from those servers. 
> Thing is, I didn't note which server it was.  If someone notices that
> their syncing isn't working right, may want to switch and find one that
> is up to date.

Alternatively, switch to syncing from github and you'll always be as up
to date as possible - and it's much faster.

% cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo

[gentoo]
priority = 20
location = /var/portage
sync-type = git
sync-uri = https://github.com/gentoo-mirror/gentoo
auto-sync = yes


--
Neil Bothwick

Windows Error #09: Game Over. Exiting Windows.
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
On 3/1/21 3:43 AM, Neil Bothwick wrote:
> On Sun, 28 Feb 2021 22:29:49 -0600, Dale wrote:
>> I'm not sure what is going on with the servers but when I switched to
>> one of them, recent updates didn't even exist.  I just did a KDE and I
>> think Firefox and neither seemed to be in the tree from those servers.
>> Thing is, I didn't note which server it was.  If someone notices that
>> their syncing isn't working right, may want to switch and find one that
>> is up to date.
> Alternatively, switch to syncing from github and you'll always be as up
> to date as possible - and it's much faster.
>
> % cat /etc/portage/repos.conf/gentoo.conf
> [DEFAULT]
> main-repo = gentoo
>
> [gentoo]
> priority = 20
> location = /var/portage
> sync-type = git
> sync-uri = https://github.com/gentoo-mirror/gentoo
> auto-sync = yes

Syncing won't help until the ebuilds are fixed, and the bug does not say
that has happened.  The problem is not (yet) syncing your portage tree,
it is with the mirrors, some of which have the old tarballs and some of
which have the new tarballs.  If the ebuild gets updated, and you pull
one of the old tarballs, you will have essentially the same errors
trying to emerge.  You need an ebuild and Manifest that match the
tarball you are trying to use.
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
On Mon, 1 Mar 2021 10:45:32 -0500, Jack wrote:

> > Alternatively, switch to syncing from github and you'll always be as
> > up to date as possible - and it's much faster.

> Syncing won't help until the ebuilds are fixed, and the bug does not
> say that has happened.  The problem is not (yet) syncing your portage
> tree, it is with the mirrors, some of which have the old tarballs and
> some of which have the new tarballs.

So it's the source mirrors that are out of date rather than the
rsync mirrors?

> If the ebuild gets updated, and
> you pull one of the old tarballs, you will have essentially the same
> errors trying to emerge.  You need an ebuild and Manifest that match
> the tarball you are trying to use.

This sort of issue should only last an hour or so, after which time
everything should be in sync. if it is still there the next day,
something is wrong with the mirror you are using.


--
Neil Bothwick

Top Oxymorons Number 11: Terribly pleased
Re: asciidoc Fetched file: asciidoc-9.0.5.tar.gz VERIFY FAILED! [ In reply to ]
On Mon, Mar 1, 2021 at 11:03 AM Neil Bothwick <neil@digimed.co.uk> wrote:
>
> On Mon, 1 Mar 2021 10:45:32 -0500, Jack wrote:
>
> > > Alternatively, switch to syncing from github and you'll always be as
> > > up to date as possible - and it's much faster.
>
> > Syncing won't help until the ebuilds are fixed, and the bug does not
> > say that has happened. The problem is not (yet) syncing your portage
> > tree, it is with the mirrors, some of which have the old tarballs and
> > some of which have the new tarballs.
>
> So it's the source mirrors that are out of date rather than the
> rsync mirrors?
>

Not exactly.

There are three files here:
1. The ebuild/mainfest - which uses hash/size of an old version of the source.
2. The distfile mirrors - which contain the corresponding old version
of the source.
3. The upstream SRC_URI - which contains a newer version of the source.

Nothing has been fixed as of the time of sending this email, so you
can sync your repo all you want and it will do no good.

If you use a Gentoo distfile mirror you should be fine, because you're
fetching an old version of the source, which matches what the ebuild
is expecting.
However, if you don't use a Gentoo distfile mirror then you're
directly fetching the upstream source, which DOESN'T match the ebuild,
and so you'll get an error.

The Gentoo mirrors are going to reject any attempts to fetch the newer
source, because they will only mirror a file if they match the Gentoo
manifest.

Usually these bugs do get fixed quickly, but there were changes in the
upstream source files, so the maintainer probably wants to do some
testing before updating the manifests. That is a GOOD thing and that
is exactly why we have those manifests in the first place. They
protect you, the user, in case upstream goes and changes a file out
for any reason - Portage will reject this as this is not the file that
was used by the package maintainer when doing all their QA activities.
The biggest risk is malware getting snuck into an upstream file, but
in this case it sounds like upstream changed something without
versioning it. At the very least the maintainer is going to want to
make sure it still works - you can't necessarily expect the same
ebuild to work if upstream changes the sources.

--
Rich