Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Kent Fredric]

On Fri, 27 Jan 2017 13:20:10 +
"M. J. Everitt"  wrote:

> I don't think anyone truly wants a /_desert_/ Rich, but perhaps you
> meant a /*dessert*/ ?!

You never know, he could be a giant sand worm, digging through the deserts
of spice on Dune.


pgpyt9mdKwDff.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[james]

On 01/27/2017 07:41 AM, Rich Freeman wrote:

On Fri, Jan 27, 2017 at 7:06 AM, Dirkjan Ochtman  wrote:


On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny  wrote:

I should point out that:

1) CI is detecting this kind of issues much faster than you are,
and reporting them both to the committer and to a *dedicated* mailing
list, so your mail is completely redundant and delayed.


That sounds like a somewhat better solution, although sometimes it can
make sense to send email to where the developers are already, rather
than putting the onus on them to join a separate mailing list.



I don't think the idea is to put the onus on people to join a separate
list so much as to give people the freedom to NOT join that list.


Hey thanks guys for pointing out that list concerned with CI.


Why is it necessary to notify every developer that somebody has not
run repoman?  For everybody who does what they're supposed to do,
there is no lesson to learn, and it is just noise.

For people interested in building tree-wide QA tools or who are
interested in overall trends, then they can mine the list archives.
If they have significant observations they can always post here or on
planet or whatever, and that would have a much higher S/N ratio.


2) Spamming the developer mailing list is completely unprofessional
here. If you are unhappy about those mails, just disable them, and stop
blaming people for your misery. Trying to prove others incompetent
helps nobody.


Come on... I think it's fair game to share news about people breaking
things on the gentoo-dev mailing list. Naming & shaming can be useful
sometimes.


I think naming and shaming is a short-term game.  It might have
immediate effects, but it tends to create a culture where nobody wants
to get involved, because they don't want to be the person getting
named and shamed.

We should certainly provide information to people about their errors
so that they can fix them.  We should certainly have this information
available to people making tools that can help people avoid errors,
since error is human nature.  There is no need to hide this
information, but we shouldn't have a culture where we're making it an
emphasis so that we can all go around pointing fingers.


H. Sure I agree that folks with aspiring skills, particular to 
gentoo, might need a bit of coddling and encouragement at times, as 
opposed to the back of the hand sort of management. Me, I'm rather 
thick-skinned, so a good public 'smacking' only means a dev cares and 
has higher expectations from his comrade? But, what comes around, goes 
around for this old fart. Kids now-a-days, not so much.



I have avoided the gentoo-CI project (building my own server-cluster) 
pretty much for the reason to avoid this sort of thread focused on 
myself (an ounce of prevention). My take is that this thread is 
justification that the gentoo-CI project needs more documentation, 
participation and dissemination so as to make it a community tool for 
devs and strong users alike. In fact, could not repoman be an option for 
a gentoo-cluster-CI configuration?




If somebody is a consistent problem and is impervious to attempts to
work with them (whatever the ultimate reason), we don't need to make
them a social pariah until they decide to quit.  We just need to have
QA revoke their commit rights.

I'm a little concerned that stuff like this starts to end up working
like collective punishment.  Fred over here broke the tree, so nobody
gets to have desert or recess today; you all know what to do with Fred
when he's looking to sit next to somebody at lunch and when the bus
drops you off at home later today.

I don't think that was the original motivation; I think frustration
with this being a frequent problem is more the issue and is quite
understandable.  I just don't think this is the right solution.



I have posted several times (I think) about the Gentoo CI being tuned 
into a straight forward project, where anyone with a few systems (or VMs 
or containers) can build a gentoo cluster and run it local. Folks, 
whether dev or experience user, could then run their own 
"gentoo-cluster-CI" leveraging the work of the devs involved and then 
selecting packages that they care most about. Automating much of what a 
proxy-dev does noting the results and studying the components, would 
make an excellent training system and help infuse folks with gentoo 
expertise into the wider software intensive industries. Thus it would 
greatly enhance gentoo's appeal and tend to subsequently attract younger 
folks with aspirations, imho.



This thread only reinforces that this idea, to make a gentoo-cluster-CI 
better documented and available for all of us with an interest. Granted, 
I'm still waiting a bit more to attempt that sort effort; but I do 
believe there would be strong interest, particularly if packaged up as 
stage-4 for the user base, proxy folks and those with not quite dev 
level skills. I 

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[M. J. Everitt]

On 27/01/17 12:41, Rich Freeman wrote:
> 
> I'm a little concerned that stuff like this starts to end up working
> like collective punishment.  Fred over here broke the tree, so nobody
> gets to have desert or recess today; you all know what to do with Fred
> when he's looking to sit next to somebody at lunch and when the bus
> drops you off at home later today.
>
>
Purely in the interests of pedantry (!) ..

I don't think anyone truly wants a /_desert_/ Rich, but perhaps you
meant a /*dessert*/ ?!

:]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Rich Freeman]

On Fri, Jan 27, 2017 at 7:06 AM, Dirkjan Ochtman  wrote:
>
> On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny  wrote:
>> I should point out that:
>>
>> 1) CI is detecting this kind of issues much faster than you are,
>> and reporting them both to the committer and to a *dedicated* mailing
>> list, so your mail is completely redundant and delayed.
>
> That sounds like a somewhat better solution, although sometimes it can
> make sense to send email to where the developers are already, rather
> than putting the onus on them to join a separate mailing list.
>

I don't think the idea is to put the onus on people to join a separate
list so much as to give people the freedom to NOT join that list.

Why is it necessary to notify every developer that somebody has not
run repoman?  For everybody who does what they're supposed to do,
there is no lesson to learn, and it is just noise.

For people interested in building tree-wide QA tools or who are
interested in overall trends, then they can mine the list archives.
If they have significant observations they can always post here or on
planet or whatever, and that would have a much higher S/N ratio.

>> 2) Spamming the developer mailing list is completely unprofessional
>> here. If you are unhappy about those mails, just disable them, and stop
>> blaming people for your misery. Trying to prove others incompetent
>> helps nobody.
>
> Come on... I think it's fair game to share news about people breaking
> things on the gentoo-dev mailing list. Naming & shaming can be useful
> sometimes.

I think naming and shaming is a short-term game.  It might have
immediate effects, but it tends to create a culture where nobody wants
to get involved, because they don't want to be the person getting
named and shamed.

We should certainly provide information to people about their errors
so that they can fix them.  We should certainly have this information
available to people making tools that can help people avoid errors,
since error is human nature.  There is no need to hide this
information, but we shouldn't have a culture where we're making it an
emphasis so that we can all go around pointing fingers.

If somebody is a consistent problem and is impervious to attempts to
work with them (whatever the ultimate reason), we don't need to make
them a social pariah until they decide to quit.  We just need to have
QA revoke their commit rights.

I'm a little concerned that stuff like this starts to end up working
like collective punishment.  Fred over here broke the tree, so nobody
gets to have desert or recess today; you all know what to do with Fred
when he's looking to sit next to somebody at lunch and when the bus
drops you off at home later today.

I don't think that was the original motivation; I think frustration
with this being a frequent problem is more the issue and is quite
understandable.  I just don't think this is the right solution.

-- 
Rich

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Dirkjan Ochtman]

Wow, Michał, this email comes off as pretty harsh to me... Is that
really necessary?

On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny  wrote:
> I should point out that:
>
> 1) CI is detecting this kind of issues much faster than you are,
> and reporting them both to the committer and to a *dedicated* mailing
> list, so your mail is completely redundant and delayed.

That sounds like a somewhat better solution, although sometimes it can
make sense to send email to where the developers are already, rather
than putting the onus on them to join a separate mailing list.

> 2) Spamming the developer mailing list is completely unprofessional
> here. If you are unhappy about those mails, just disable them, and stop
> blaming people for your misery. Trying to prove others incompetent
> helps nobody.

Come on... I think it's fair game to share news about people breaking
things on the gentoo-dev mailing list. Naming & shaming can be useful
sometimes. And even if you wanted to make this point, you should have
made it more constructively.

> That said, if you forward yet another mail with the same purpose,
> I will file a formal complaint at ComRel and request suspending your
> mailing list access.

This is completely out of line for me. It seems to me that Doug has
the best intentions. If you disagree with his approach, can we not
have a civilized discussion about it rather than going straight into
attack mode?

Cheers,

Dirkjan

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Michał Górny]

On Thu, 26 Jan 2017 18:48:39 -0500
Doug Freed  wrote:

> This particular issue has already been fixed, but I'll be forwarding
> all these emails to the list from now on (I have to do that manually,
> because there are some that aren't anybody's fault, and I don't need
> to spam you about those).

I should point out that:

1) CI is detecting this kind of issues much faster than you are,
and reporting them both to the committer and to a *dedicated* mailing
list, so your mail is completely redundant and delayed.

2) Spamming the developer mailing list is completely unprofessional
here. If you are unhappy about those mails, just disable them, and stop
blaming people for your misery. Trying to prove others incompetent
helps nobody.

That said, if you forward yet another mail with the same purpose,
I will file a formal complaint at ComRel and request suspending your
mailing list access.

-- 
Best regards,
Michał Górny



pgpAN0k4LmfPd.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Ian Stakenvicius]

On 26/01/17 06:48 PM, Doug Freed wrote:
> This is the email I get when a Manifest is missing DIST entries; it's
> more verbose than it needs to be, but I'd rather have more than less.
> In this particular case, the developer that made the bad commit likely
> had something they were working on in sys-cluster/torque added to the
> git index (ie, they did git add), and then needed to make an unrelated
> change, and didn't stash their changes beforehand.  You should always
> check 'git status' output before running repoman commit and/or git
> commit.  It's probably best to check before you start on a change, and
> then you can 'git stash -u' right away (the -u includes untracked
> files, which is useful if your in progress change is adding something
> new), and then after you've committed the change you wanted to get
> done right away, you can 'git stash pop' to get back to the state you
> were in before.
> 

A maintainer/committer directed email would definitely help with this,
yes; otherwise maybe an RSS feed we could subscribe to would be more
fitting than list emails?

The problem was definitely me, however i'm not sure what I messed up
in this particular case.  What I had done was 'git reset *' and 'git
checkout -- *' within sys-cluster/torque/ to trash all of the
non-committed work.  I'll definitely be more careful in the future.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[M. J. Everitt]

On 27/01/17 00:55, NP-Hardass wrote:
> On 01/26/2017 06:48 PM, Doug Freed wrote:
>> This is the email I get when a Manifest is missing DIST entries; it's
>> more verbose than it needs to be, but I'd rather have more than less.
>> In this particular case, the developer that made the bad commit likely
>> had something they were working on in sys-cluster/torque added to the
>> git index (ie, they did git add), and then needed to make an unrelated
>> change, and didn't stash their changes beforehand.  You should always
>> check 'git status' output before running repoman commit and/or git
>> commit.  It's probably best to check before you start on a change, and
>> then you can 'git stash -u' right away (the -u includes untracked
>> files, which is useful if your in progress change is adding something
>> new), and then after you've committed the change you wanted to get
>> done right away, you can 'git stash pop' to get back to the state you
>> were in before.
>>
>> This particular issue has already been fixed, but I'll be forwarding
>> all these emails to the list from now on (I have to do that manually,
>> because there are some that aren't anybody's fault, and I don't need
>> to spam you about those).
>>
>> -Doug
>>
>>
>> -- Forwarded message --
>> From: (Cron Daemon) 
>> Date: Thu, Jan 26, 2017 at 5:39 PM
>> Subject: Cron  /usr/local/bin/pidlock -s rsync-gen
>> /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh
>> To: infra-gmir...@gentoo.org
>>
>>
>> [ERROR/ForkPoolWorker-7] sys-cluster/torque is missing DIST entries!
>> Traceback (most recent call last):
>>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
>> 23, in _open_file
>> encoding=_encodings['fs'], errors='strict'), 'rb')
>> FileNotFoundError: [Errno 2] No such file or directory:
>> b'/var/empty/torque-6.1.0.tar.gz'
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/usr/local/bin/mastermirror/thicken-manifests.py", line 122,
>> in maybe_thicken_manifest
>> manifest.create(assumeDistHashesAlways=True)
>>   File "/usr/lib64/python3.4/site-packages/portage/manifest.py", line
>> 506, in create
>> self.fhashdict["DIST"][f] = perform_multiple_checksums(fname, 
>> self.hashes)
>>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
>> 426, in perform_multiple_checksums
>> rVal[x] = perform_checksum(filename, x, calc_prelink)[0]
>>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
>> 390, in perform_checksum
>> myhash, mysize = hashfunc_map[hashname](myfilename)
>>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
>> 52, in __call__
>> with _open_file(filename) as f:
>>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
>> 31, in _open_file
>> raise portage.exception.FileNotFound(filename)
>> portage.exception.FileNotFound: b'/var/empty/torque-6.1.0.tar.gz'
>>
>> !!! A file listed in the Manifest could not be found:
>> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque/torque-6.0.1.ebuild
>> /usr/local/bin/mastermirror/rsync-gen.sh: A Manifest has a failure!
>> /var/tmp/gmirror-rsync/logs/regen/regen-run-20170126-2238.log.validate:
>>
>> RepoMan scours the neighborhood...
>>   digest.missing [fatal]1
>>
>> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque::torque-6.1.0.tar.gz
>>   digest.unused 1
>>   file.size 69
>>   manifest.bad [fatal]  1
>>sys-cluster/torque/Manifest
>> Please fix these important QA issues first.
>> RepoMan sez: "Make your QA payment on time and you'll never see the
>> likes of me."
>>
> While increasing QA is a laudable goal, I'm not sure spamming the list
> every time you detect a QA issue is the right way to proceed with
> improving QA.  I'm much rather you adopt a strategy similar to mgorny's
> QA tool, and email the dev responsible for the commit that they broke
> the repo.   Find a package with an issue, extract the last commit on
> that directory, get the committer, and send them the email.  In all
> likelihood, these kinds of errors aren't intentional, and public shaming
> isn't really necessary in this case.  Simply notifying the developer so
> that they can rectify the issue should be sufficient, unless I'm missing
> something.
>
I think this is a useful tool, but I made the suggestion on a previous
thread to post to the "gentoo-automated-testing" ML where anyone
interested can subscribe. There may be potential in the suggestion of
mailing the dev concerned, but perhaps just having somewhere 'visible'
where it can be checked, or devs can be 'pointed' would be a reasonable
'first step'.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[NP-Hardass]

On 01/26/2017 06:48 PM, Doug Freed wrote:
> This is the email I get when a Manifest is missing DIST entries; it's
> more verbose than it needs to be, but I'd rather have more than less.
> In this particular case, the developer that made the bad commit likely
> had something they were working on in sys-cluster/torque added to the
> git index (ie, they did git add), and then needed to make an unrelated
> change, and didn't stash their changes beforehand.  You should always
> check 'git status' output before running repoman commit and/or git
> commit.  It's probably best to check before you start on a change, and
> then you can 'git stash -u' right away (the -u includes untracked
> files, which is useful if your in progress change is adding something
> new), and then after you've committed the change you wanted to get
> done right away, you can 'git stash pop' to get back to the state you
> were in before.
> 
> This particular issue has already been fixed, but I'll be forwarding
> all these emails to the list from now on (I have to do that manually,
> because there are some that aren't anybody's fault, and I don't need
> to spam you about those).
> 
> -Doug
> 
> 
> -- Forwarded message --
> From: (Cron Daemon) 
> Date: Thu, Jan 26, 2017 at 5:39 PM
> Subject: Cron  /usr/local/bin/pidlock -s rsync-gen
> /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh
> To: infra-gmir...@gentoo.org
> 
> 
> [ERROR/ForkPoolWorker-7] sys-cluster/torque is missing DIST entries!
> Traceback (most recent call last):
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 23, in _open_file
> encoding=_encodings['fs'], errors='strict'), 'rb')
> FileNotFoundError: [Errno 2] No such file or directory:
> b'/var/empty/torque-6.1.0.tar.gz'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/local/bin/mastermirror/thicken-manifests.py", line 122,
> in maybe_thicken_manifest
> manifest.create(assumeDistHashesAlways=True)
>   File "/usr/lib64/python3.4/site-packages/portage/manifest.py", line
> 506, in create
> self.fhashdict["DIST"][f] = perform_multiple_checksums(fname, self.hashes)
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 426, in perform_multiple_checksums
> rVal[x] = perform_checksum(filename, x, calc_prelink)[0]
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 390, in perform_checksum
> myhash, mysize = hashfunc_map[hashname](myfilename)
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 52, in __call__
> with _open_file(filename) as f:
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 31, in _open_file
> raise portage.exception.FileNotFound(filename)
> portage.exception.FileNotFound: b'/var/empty/torque-6.1.0.tar.gz'
> 
> !!! A file listed in the Manifest could not be found:
> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque/torque-6.0.1.ebuild
> /usr/local/bin/mastermirror/rsync-gen.sh: A Manifest has a failure!
> /var/tmp/gmirror-rsync/logs/regen/regen-run-20170126-2238.log.validate:
> 
> RepoMan scours the neighborhood...
>   digest.missing [fatal]1
>
> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque::torque-6.1.0.tar.gz
>   digest.unused 1
>   file.size 69
>   manifest.bad [fatal]  1
>sys-cluster/torque/Manifest
> Please fix these important QA issues first.
> RepoMan sez: "Make your QA payment on time and you'll never see the
> likes of me."
> 

While increasing QA is a laudable goal, I'm not sure spamming the list
every time you detect a QA issue is the right way to proceed with
improving QA.  I'm much rather you adopt a strategy similar to mgorny's
QA tool, and email the dev responsible for the commit that they broke
the repo.   Find a package with an issue, extract the last commit on
that directory, get the committer, and send them the email.  In all
likelihood, these kinds of errors aren't intentional, and public shaming
isn't really necessary in this case.  Simply notifying the developer so
that they can rectify the issue should be sufficient, unless I'm missing
something.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Doug Freed]

This is the email I get when a Manifest is missing DIST entries; it's
more verbose than it needs to be, but I'd rather have more than less.
In this particular case, the developer that made the bad commit likely
had something they were working on in sys-cluster/torque added to the
git index (ie, they did git add), and then needed to make an unrelated
change, and didn't stash their changes beforehand.  You should always
check 'git status' output before running repoman commit and/or git
commit.  It's probably best to check before you start on a change, and
then you can 'git stash -u' right away (the -u includes untracked
files, which is useful if your in progress change is adding something
new), and then after you've committed the change you wanted to get
done right away, you can 'git stash pop' to get back to the state you
were in before.

This particular issue has already been fixed, but I'll be forwarding
all these emails to the list from now on (I have to do that manually,
because there are some that aren't anybody's fault, and I don't need
to spam you about those).

-Doug


-- Forwarded message --
From: (Cron Daemon) 
Date: Thu, Jan 26, 2017 at 5:39 PM
Subject: Cron  /usr/local/bin/pidlock -s rsync-gen
/bin/bash /usr/local/bin/mastermirror/rsync-gen.sh
To: infra-gmir...@gentoo.org


[ERROR/ForkPoolWorker-7] sys-cluster/torque is missing DIST entries!
Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
23, in _open_file
encoding=_encodings['fs'], errors='strict'), 'rb')
FileNotFoundError: [Errno 2] No such file or directory:
b'/var/empty/torque-6.1.0.tar.gz'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/mastermirror/thicken-manifests.py", line 122,
in maybe_thicken_manifest
manifest.create(assumeDistHashesAlways=True)
  File "/usr/lib64/python3.4/site-packages/portage/manifest.py", line
506, in create
self.fhashdict["DIST"][f] = perform_multiple_checksums(fname, self.hashes)
  File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
426, in perform_multiple_checksums
rVal[x] = perform_checksum(filename, x, calc_prelink)[0]
  File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
390, in perform_checksum
myhash, mysize = hashfunc_map[hashname](myfilename)
  File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
52, in __call__
with _open_file(filename) as f:
  File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
31, in _open_file
raise portage.exception.FileNotFound(filename)
portage.exception.FileNotFound: b'/var/empty/torque-6.1.0.tar.gz'

!!! A file listed in the Manifest could not be found:
/var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque/torque-6.0.1.ebuild
/usr/local/bin/mastermirror/rsync-gen.sh: A Manifest has a failure!
/var/tmp/gmirror-rsync/logs/regen/regen-run-20170126-2238.log.validate:

RepoMan scours the neighborhood...
  digest.missing [fatal]1
   
/var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque::torque-6.1.0.tar.gz
  digest.unused 1
  file.size 69
  manifest.bad [fatal]  1
   sys-cluster/torque/Manifest
Please fix these important QA issues first.
RepoMan sez: "Make your QA payment on time and you'll never see the
likes of me."