Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Robin H. Johnson]

On Sat, Nov 05, 2016 at 05:45:06PM +1300, Kent Fredric wrote:
> dev-python/google-api-python-client-1.1: robbat2gentoo.org 
> net-nds/nsscache-0.23*: robbat2gentoo.org 
Old ebuilds removed.

> dev-vcs/git-2*: robbat2gentoo.org polynomial-cgentoo.org 
gcode was already a backup to the other SRC_URI, but is removed now
anyway.

> dev-util/rats-2.3: robbat2gentoo.org 
I emailed the original upstream to see about it.

> net-misc/memcached-1.2.8-r1: robbat2gentoo.org 
> prometheanfiregentoo.org 
> net-misc/memcached-1.3.3-r5: robbat2gentoo.org 
> prometheanfiregentoo.org 
Upstream contacted.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Zac Medico]

On 11/05/2016 03:22 PM, Michał Górny wrote:
> On Sat, 5 Nov 2016 15:11:10 -0700
> Zac Medico  wrote:
> 
>> On 11/05/2016 02:50 PM, Michał Górny wrote:
>>> On Sat,  5 Nov 2016 13:43:15 -0700
>>> Zac Medico  wrote:
>>>   
 This is necessary in order to avoid "There are too many unreachable
 loose objects" warnings from automatic git gc calls.

 X-Gentoo-Bug: 599008
 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
 ---
  pym/portage/sync/modules/git/git.py | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/pym/portage/sync/modules/git/git.py 
 b/pym/portage/sync/modules/git/git.py
 index f288733..c90cf88 100644
 --- a/pym/portage/sync/modules/git/git.py
 +++ b/pym/portage/sync/modules/git/git.py
 @@ -101,6 +101,12 @@ class GitSync(NewBase):
writemsg_level(msg + "\n", level=logging.ERROR, 
 noiselevel=-1)
return (e.returncode, False)
  
 +  # For shallow fetch, unreachable objects must be pruned
 +  # manually, since otherwise automatic git gc calls will
 +  # eventually warn about them (see bug 599008).
 +  subprocess.call(['git', 'prune'],
 +  cwd=portage._unicode_encode(self.repo.location))
 +
git_cmd_opts += " --depth %d" % self.repo.sync_depth
git_cmd = "%s fetch %s%s" % (self.bin_command,
remote_branch.partition('/')[0], git_cmd_opts)  
>>>
>>> Does it have a performance impact?  
>>
>> Yes, it takes about 20 seconds on my laptop. I suppose we could make
>> this an optional thing, so that those people can do it manually if they
>> want.
> 
> So we have improvement from at most few seconds for normal 'git pull'
> to around a minute for shallow pull?

Well we've got a least 3 resources to consider:

1) network bandwidth
2) disk usage
3) sync time

For me, sync time doesn't really matter that much, but I suppose it
might for some people.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Michał Górny]

On Sat, 5 Nov 2016 15:11:10 -0700
Zac Medico  wrote:

> On 11/05/2016 02:50 PM, Michał Górny wrote:
> > On Sat,  5 Nov 2016 13:43:15 -0700
> > Zac Medico  wrote:
> >   
> >> This is necessary in order to avoid "There are too many unreachable
> >> loose objects" warnings from automatic git gc calls.
> >>
> >> X-Gentoo-Bug: 599008
> >> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
> >> ---
> >>  pym/portage/sync/modules/git/git.py | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/pym/portage/sync/modules/git/git.py 
> >> b/pym/portage/sync/modules/git/git.py
> >> index f288733..c90cf88 100644
> >> --- a/pym/portage/sync/modules/git/git.py
> >> +++ b/pym/portage/sync/modules/git/git.py
> >> @@ -101,6 +101,12 @@ class GitSync(NewBase):
> >>writemsg_level(msg + "\n", level=logging.ERROR, 
> >> noiselevel=-1)
> >>return (e.returncode, False)
> >>  
> >> +  # For shallow fetch, unreachable objects must be pruned
> >> +  # manually, since otherwise automatic git gc calls will
> >> +  # eventually warn about them (see bug 599008).
> >> +  subprocess.call(['git', 'prune'],
> >> +  cwd=portage._unicode_encode(self.repo.location))
> >> +
> >>git_cmd_opts += " --depth %d" % self.repo.sync_depth
> >>git_cmd = "%s fetch %s%s" % (self.bin_command,
> >>remote_branch.partition('/')[0], git_cmd_opts)  
> > 
> > Does it have a performance impact?  
> 
> Yes, it takes about 20 seconds on my laptop. I suppose we could make
> this an optional thing, so that those people can do it manually if they
> want.

So we have improvement from at most few seconds for normal 'git pull'
to around a minute for shallow pull?

-- 
Best regards,
Michał Górny


pgpLtvazW4Jsz.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Zac Medico]

On 11/05/2016 02:50 PM, Michał Górny wrote:
> On Sat,  5 Nov 2016 13:43:15 -0700
> Zac Medico  wrote:
> 
>> This is necessary in order to avoid "There are too many unreachable
>> loose objects" warnings from automatic git gc calls.
>>
>> X-Gentoo-Bug: 599008
>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
>> ---
>>  pym/portage/sync/modules/git/git.py | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/pym/portage/sync/modules/git/git.py 
>> b/pym/portage/sync/modules/git/git.py
>> index f288733..c90cf88 100644
>> --- a/pym/portage/sync/modules/git/git.py
>> +++ b/pym/portage/sync/modules/git/git.py
>> @@ -101,6 +101,12 @@ class GitSync(NewBase):
>>  writemsg_level(msg + "\n", level=logging.ERROR, 
>> noiselevel=-1)
>>  return (e.returncode, False)
>>  
>> +# For shallow fetch, unreachable objects must be pruned
>> +# manually, since otherwise automatic git gc calls will
>> +# eventually warn about them (see bug 599008).
>> +subprocess.call(['git', 'prune'],
>> +cwd=portage._unicode_encode(self.repo.location))
>> +
>>  git_cmd_opts += " --depth %d" % self.repo.sync_depth
>>  git_cmd = "%s fetch %s%s" % (self.bin_command,
>>  remote_branch.partition('/')[0], git_cmd_opts)
> 
> Does it have a performance impact?

Yes, it takes about 20 seconds on my laptop. I suppose we could make
this an optional thing, so that those people can do it manually if they
want.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Michał Górny]

On Sat,  5 Nov 2016 13:43:15 -0700
Zac Medico  wrote:

> This is necessary in order to avoid "There are too many unreachable
> loose objects" warnings from automatic git gc calls.
> 
> X-Gentoo-Bug: 599008
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
> ---
>  pym/portage/sync/modules/git/git.py | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/pym/portage/sync/modules/git/git.py 
> b/pym/portage/sync/modules/git/git.py
> index f288733..c90cf88 100644
> --- a/pym/portage/sync/modules/git/git.py
> +++ b/pym/portage/sync/modules/git/git.py
> @@ -101,6 +101,12 @@ class GitSync(NewBase):
>   writemsg_level(msg + "\n", level=logging.ERROR, 
> noiselevel=-1)
>   return (e.returncode, False)
>  
> + # For shallow fetch, unreachable objects must be pruned
> + # manually, since otherwise automatic git gc calls will
> + # eventually warn about them (see bug 599008).
> + subprocess.call(['git', 'prune'],
> + cwd=portage._unicode_encode(self.repo.location))
> +
>   git_cmd_opts += " --depth %d" % self.repo.sync_depth
>   git_cmd = "%s fetch %s%s" % (self.bin_command,
>   remote_branch.partition('/')[0], git_cmd_opts)

Does it have a performance impact?

-- 
Best regards,
Michał Górny


pgpxPy9bIdGpf.pgp
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Zac Medico]

This is necessary in order to avoid "There are too many unreachable
loose objects" warnings from automatic git gc calls.

X-Gentoo-Bug: 599008
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
---
 pym/portage/sync/modules/git/git.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/pym/portage/sync/modules/git/git.py 
b/pym/portage/sync/modules/git/git.py
index f288733..c90cf88 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -101,6 +101,12 @@ class GitSync(NewBase):
writemsg_level(msg + "\n", level=logging.ERROR, 
noiselevel=-1)
return (e.returncode, False)
 
+   # For shallow fetch, unreachable objects must be pruned
+   # manually, since otherwise automatic git gc calls will
+   # eventually warn about them (see bug 599008).
+   subprocess.call(['git', 'prune'],
+   cwd=portage._unicode_encode(self.repo.location))
+
git_cmd_opts += " --depth %d" % self.repo.sync_depth
git_cmd = "%s fetch %s%s" % (self.bin_command,
remote_branch.partition('/')[0], git_cmd_opts)
-- 
2.7.4

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

On Sat, 5 Nov 2016 12:43:31 +0100
Ulrich Mueller  wrote:

> I still don't see why you must (ab)use the revision for that. With
> virtuals, the whole PV is at your disposal, so you could append .5.22
> to it, or even use a suffix like _p522.

Incidentally, I did use _p522 for the one case we had pressing need to do this
immediately.

And shortly after I fell afoul of the whole "used ~ when I should have
used =ATOM*" thing, and then was told we shouldn't use "_p" because it
was supposed to reflect "upstream patching" not "gentoo patching",
because "gentoo stuff" is supposed to be "-r"

The only reason I'm terrified of using "The whole space" is because its
too hard to anticipate what upstream will do tomorrow.

_p was the only place I was safe without the concern that upstream could 
somehow
make life hard for everyone.

Because If we put

  =virtual/perl-Foo-0.13.0.522

In tree, luck would have it upstream would decide to ship "Foo
0.13.0.10" a week later, and we'd be in a fun "downgrade to upgrade" hell.

> The purpose of the revision is really for incremental changes of the
> ebuild within one upstream version.

Well, this is sort of what I'm mentally trying to do really.

Because all versions upstream could make next are "legal", I'm trying to stand
between this version, and smallest possible increment upstream could 
conceivably make.

It does seem paranoid overall, but I've seen my share of horrors with
upstream special-snowflaking versions that the overall desire is to
treat $PV as a black box (with normalisation) which Gentoo doesn't have
any interference with.

> About the only situation where using large steps (like 100) in
> revision numbers is justified is when ebuilds in different slots
> would otherwise collide.

Maybe we need another token legal in PV,

  _gentoo[0-9]+

?

Then GTK and friends could use

1.23.4_gentoo2-r1 
1.23.4_gentoo3-r1 

And Perl virtuals would be 

perl-Foo, perl-Foo-r1, perl-Foo_gentoo522, perl-Foo_gentoo522-r1


Where

1.0.0 < 1.0.0_gentoo1 < 1.0.0_p1 < 1.0.0_p1_gentoo1 

_gentoo is of course just a placeholder for which many bike sheds can
be painted for naming.




pgpA9j9Mjs0KO.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: net-print/foomatic-filters

[Manuel Rüger]

# Manuel Rüger  (05 Nov 2016)
# Masked for removal in 30 days, bug #568980
# Unmaintained and deprecated.
# Use net-print/cups-filters as a replacement
net-print/foomatic-filters



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Manuel Rüger]

On 05.11.2016 00:15, Zac Medico wrote:
> On 11/04/2016 03:55 PM, Zac Medico wrote:
>> On 11/04/2016 03:47 PM, Brian Dolbec wrote:
>>> On Fri, 4 Nov 2016 13:53:02 -0700
>>> Zac Medico  wrote:
>>>
 On 11/04/2016 01:43 PM, Michał Górny wrote:
> On Fri, 4 Nov 2016 13:19:39 -0700
> Zac Medico  wrote:
>   
>> On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
>>> On Thu, 3 Nov 2016 15:55:23 -0700
>>> Zac Medico  wrote:
>>> 
 In about a week, portage-2.3.2 will be eligible for a stable
 request.

 The only potential problem that I've noticed is the complaint
 about changes from bug 552814 causing issues for people using
 git sync with overlay filesystems, but setting sync-depth = 0
 gives those users a workaround. There's also bug 597838, about
 the sync-depth setting being ineffective, but I only know of a
 couple of people that have been able to reproduce that.

 So, do we want to do a stable request portage-2.3.2 when the time
 comes?
>>>
>>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
>>> stabled? 
>>
>> There are just 4 commits since 2.3.2, and they all look good.
>> Maybe we should just cut a 2.3.3 release and wait another 30 days
>> (we also need to stabilize app-crypt/gkeys since it's needed by
>> emerge-webrsync now).  
>
> Wouldn't it be better to have a really working version of gkeys
> before it's stabilized? Like one that could be used without having
> to create custom configuration files and/or run it as root?  

 Well, gkeys stabilization is not really mandatory, since
 emerge-webrsync has a --insecure option.
>>>
>>> Why don't I/we work on whatever changes are needed to merge the
>>> meta-manifest code to both portage and gkeys.  I'll push out another
>>> release.  I also had some initial code that added gkeys use to verify
>>> the pkg Manifest file, but I don't know if that is needed still, the
>>> meta-manifest system will need to run a verify at the end of the sync.
>>>
>>> We'll have to poke Robin some more to get some new infra keys setup.
>>>
>>> If I have to, maybe I'll create some ansible scripts to run the dev
>>> seeds update on vulture, transfer it to my system to push --sign to
>>> api.g.o or break down and get Kristian to help me get key forwarding
>>> better setup so I can do it from vulture.
>>
>> Sounds good, but I think we should cut a portage 2.3.3 release before we
>> make any more changes. Maybe do a release branch that includes
>> everything except the emerge-webrsync change.
> 
> Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3
> release on the master branch.
> 

Will repoman be released with the same tag as well or is the portage and
repoman version not going to be syncronized?

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

> On Sun, 6 Nov 2016, Kent Fredric wrote:

> So the strategy that I was considering was to "split" each logical
> upstream virtual into several pieces:

>   virtual/perl-Foo-N  to virtual/perl-Foo-N-r99 : "Always pull perl core/*"

>   virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 
> 5.22 and remove perl-core/*"

>   virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 
> 5.24 and remove perl-core/*"

I still don't see why you must (ab)use the revision for that. With
virtuals, the whole PV is at your disposal, so you could append .5.22
to it, or even use a suffix like _p522.

The purpose of the revision is really for incremental changes of the
ebuild within one upstream version. About the only situation where
using large steps (like 100) in revision numbers is justified is when
ebuilds in different slots would otherwise collide.

> This idea was hoped to be more predictable than a monolithic virtual
> that had all those outcomes as possibilities which then caused
> portage to be confused.

Really, if it is a portage bug then that should be fixed, instead of
inventing complicated schemes to work around it.

Ulrich


pgpzCqCtHxUYj.pgp
Description: PGP signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

On Sat, 5 Nov 2016 11:13:35 +0100
Ulrich Mueller  wrote:

> revision component must not be used for upstream versions:

The problem is we have *2* upstream versions.

 virtual/perl-Foo-N

Maps to

  perl-core/Foo-N

And

  dev-lang/perl-Y ( for possibly more than one value of Y )

And Y does not equal N

Presently, this is "not a problem", because there is only 1 of each "N"
for virtual/perl-Foo-N

And it maps with this horrible magic of

  || ( =dev-lang/perl-Y4* =dev-lang/perl-Y3* =dev-lang/perl-Y2* 
~perl-core/Foo-N )
  !perl-core/Foo-N-r999

Which is "logically correct", however, as seen in bug #584238[1],
portage does not always do the right thing, and it makes a real mess of
things having one package virtualising multiple different keywords. ( I
had to get into graphing tools to work out what the hell was actually
happening )

*especially* in cases where we need to indicate an "upstream merge in a 
virtual" as with 584238

So the strategy that I was considering was to "split" each logical upstream 
virtual into several pieces:

  virtual/perl-Foo-N  to virtual/perl-Foo-N-r99 : "Always pull perl core/*"

  virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 
5.22 and remove perl-core/*"

  virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 
5.24 and remove perl-core/*"


Which allows us to control which outcome a user gets by keeping keywords 
consistent across the board, as
we'd stabilize/keyword all '-r522**' with perl 5.22

  virtual/perl-Foo-N to virtual/perl-Foo-N-r99

would thus be "Getting multiprovided things at newer versions than is available 
in your shipped perl", and that
-r range would only be stabilized to fast-track security issues or to provide 
those versions for dependents
before the respective perl is stabilized ( that is, the fallback to perl-core 
is done with maximum reluctance )

This idea was hoped to be more predictable than a monolithic virtual
that had all those outcomes as possibilities which then caused portage to be 
confused.
 
( I hope this explanation is more clear than the last one, but its OK
if you're still confused, it took me a few weeks to get my head around
it the first time, but I implore you to read the related bug and pay
careful attention to its attached images )

1: https://bugs.gentoo.org/show_bug.cgi?id=584238


pgpUIseOoq5LQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Sergei Trofimovich]

On Sat, 5 Nov 2016 00:54:25 +0100
Jonas Stein  wrote:

> Dear all,
> 
> Google announced in 2015 to close the "Google Code" repositories [1].
> 
> They will provide the repositories in read only state till end of 2016.
> 
> Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree
> [2] and should get these fixed before end of 2016.

Thanks!

I suggest adding repoman check for those ebuilds
if it does not already exist. It will allow users spot
ticking bombs in their overlays.

-- 

  Sergei


pgpch6caZPdKz.pgp
Description: Цифровая подпись OpenPGP

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

> On Sat, 5 Nov 2016, Kent Fredric wrote:

>> I would assume  to be high enough, even if you use multiples of
>> 100 to label the slot. Or do you expect having more than 100 slots
>> for Perl?

> Well, the desire is for the -r (or similar) part correspond to
> something representative of which version of Perl the virtual is an
> "underwriter" for.

This would contradict existing policy already, which says that the
revision component must not be used for upstream versions:
https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

Ulrich


pgpDMGIHGCCLH.pgp
Description: PGP signature

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Fri, Nov 4, 2016 at 11:48 PM, Christopher Head  wrote:
> On Thu, 27 Oct 2016 10:25:39 -0400
> Rich Freeman  wrote:
>
>> It would be nice if standards like USB incorporated some kind of GUID.
>> I ended up having to write a udev rule for a pl2303 RS232 adapter to
>> tie it to a specific USB port precisely so that I could have more than
>> one and know which one talked to which device.
>>
>> I'd argue that the udev network interface names were a better (if
>> painful to transition to) solution to a problem created by somebody
>> else.  Being able to use wildcards in configuration files is probably
>> an adequate solution for those who are using a single device.
>>
>
> You mean like a device serial number? Which is totally part of the USB
> standard, but many devices don’t bother to include one because they
> would have to be serially programmed in the factory? If your device has
> a serial number, you can generally see it as a udev attribute and use
> it to set up meaningful persistent names for multiple
> otherwise-identical devices.

++
Though stuff like this is why sometimes it makes sense to make things
a required part of the standard.  If the device had access to some
source of randomness perhaps it could at least flash one on first
powerup.  Of course the only thing that would be worse than not having
a unique ID would be having a unique ID that isn't unique...

-- 
Rich

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Michał Górny]

On Sat, 5 Nov 2016 08:38:22 +0100
"Paweł Hajdan, Jr."  wrote:

> On 05/11/2016 00:54, Jonas Stein wrote:
> > Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree
> > [2] and should get these fixed before end of 2016.
> > 
> > [3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code  
> 
> The wiki page seems to indicate some sense of urgency. I'm not sure how
> much of that is needed.
> 
> Brainstorming mentions just cloning the URLs, but don't existing Gentoo
> Mirrors have the same effect? My understanding is fetching will not
> break even if original URLs go down.

Thou shalt not rely on the mirrors! Though mirrors as a temporary
solution are acceptable. As long as you don't turn it into 'wrong
SRC_URI is fine, the file is on the mirrors'.

> I'm also not fully convinced by the manpower argument. It seems the same
> work needs to be done, one way or another.
> 
> For the parts that can be automated and done in batch, this is indeed
> more effective than 500 individual bugs.
> 
> However, I'm not sure if finding the new homepage and download URL can
> be that easily automated. In fact, users may do some work for us and
> help point to the right page.

Also, it would be nice not to have the berlios -> sourceforge crap
repeated. If software is dead-dead, we should lastrite it or revive it,
not point to some dead copy by malware hosting provider.

-- 
Best regards,
Michał Górny



pgphIkyAzZUIj.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Paweł Hajdan , Jr .]

On 05/11/2016 00:54, Jonas Stein wrote:
> Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree
> [2] and should get these fixed before end of 2016.
> 
> [3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code

The wiki page seems to indicate some sense of urgency. I'm not sure how
much of that is needed.

Brainstorming mentions just cloning the URLs, but don't existing Gentoo
Mirrors have the same effect? My understanding is fetching will not
break even if original URLs go down.

I'm also not fully convinced by the manpower argument. It seems the same
work needs to be done, one way or another.

For the parts that can be automated and done in batch, this is indeed
more effective than 500 individual bugs.

However, I'm not sure if finding the new homepage and download URL can
be that easily automated. In fact, users may do some work for us and
help point to the right page.

HTH

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] dev-python/pssi package masked for removal in 30 days

[Alon Bar-Lev]

# Alon Bar-Lev  (05 Nov 2016)
# Masked for removal in 30 days, bug#598982.
# Upstream does not publish releases, no tags, last publish is on
# google code, no dependencies.
dev-python/pssi