Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Tim Harder
On 2019-12-06 Fri 02:15, Michał Górny wrote:
> > I think that is not an apt description in my understanding of your original 
> > post on the matter. The package.deprecated file is supposed to contain not 
> > just (qualified) package names, but some sort of package dependency 
> > specifications (PMS 8.2.6).
> > 
> > Perhaps the examples should also reflect this.
> > 
> 
> I haven't tested anything but bare package names.  Feel free to test
> and let me know how much of the dep syntax works.

Speaking for pkgcheck, it supports the standard atom dep spec, i.e.
anything that works in package.mask should also work in
package.deprecated.

However, note that a matching pkg found both in the base package.mask
and package.deprecated won't be flagged as deprecated as it's currently
assumed those are mutually exclusive entries (and such entries might be
flagged at a later time).

Tim



Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Michał Górny
On Fri, 2019-12-06 at 01:36 +0100, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > +
> > +#
> > +# This file specifies packages that are considered deprecated
> 
> I think that is not an apt description in my understanding of your original 
> post on the matter. The package.deprecated file is supposed to contain not 
> just (qualified) package names, but some sort of package dependency 
> specifications (PMS 8.2.6).
> 
> Perhaps the examples should also reflect this.
> 

I haven't tested anything but bare package names.  Feel free to test
and let me know how much of the dep syntax works.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Kent Fredric
On Thu, 5 Dec 2019 09:40:50 -0500
Aaron Bauman  wrote:

> Wonderful response, William.

Just because its EOL, doesn't mean it stops working.

It just means *support* for defects and security problems is dropped.

It doesn't prevent us from:

a) vendor patching bugs 
b) vendor patching security issues

So as much as I'm fervently annoyed by needing python 2 on my system
and want to get rid of it post-haste, I too think this move is too
aggressive.

It seems more sensible to me to remove things on the basis of a
*credible problem*, not on the basis of a conjecture that one could
appear in the future.

I'm not averse to change, I just understand for change to be executed
successfully, gradual and careful adjustments have to be made.

Though I deeply suspect once package.deprecated becomes a thing we can use,
we can relegate py2-only stuff there.


pgpwXYrvELPBz.pgp
Description: OpenPGP digital signature


[gentoo-dev] media-sound/abcde mask seems unnecessary

2019-12-05 Thread Ashley Dixon
media-sound/abcde was added to the package.mask due to the lack of python3
support on one of its dependencies, dev-python/eyeD3. Since that has been fixed,
and eyeD3 is no longer masked, why the abcde mask ? From a quick look, it
doesn't need any packages which have no python3 implementation.

[I can't find any mention of workerpool, python-fastcgi, or numdisplay in the
abcde dependencies, but maybe I'm missing something]

Thanks.

-- 

Ashley Dixon

suugaku.co.uk
github.com/ashleydixon




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:

+
+#
+# This file specifies packages that are considered deprecated


I think that is not an apt description in my understanding of your original 
post on the matter. The package.deprecated file is supposed to contain not 
just (qualified) package names, but some sort of package dependency 
specifications (PMS 8.2.6).


Perhaps the examples should also reflect this.


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-portage-dev] [PATCH] repoman: support profiles/package.deprecated (bug 702100)

2019-12-05 Thread Zac Medico
Bug: https://bugs.gentoo.org/702100
Signed-off-by: Zac Medico 
---
 repoman/cnf/qa_data/qa_data.yaml  | 1 +
 repoman/cnf/repository/qa_data.yaml   | 1 +
 repoman/lib/repoman/modules/scan/depend/_depend_checks.py | 5 +
 repoman/lib/repoman/scanner.py| 4 
 repoman/man/repoman.1 | 3 +++
 5 files changed, 14 insertions(+)

diff --git a/repoman/cnf/qa_data/qa_data.yaml b/repoman/cnf/qa_data/qa_data.yaml
index 6aad56b8c..9a807aaf3 100644
--- a/repoman/cnf/qa_data/qa_data.yaml
+++ b/repoman/cnf/qa_data/qa_data.yaml
@@ -26,6 +26,7 @@ qahelp:
 badinexp: "User-visible ebuilds with unsatisfied dependencies (matched 
against *visible* ebuilds) in experimental arch"
 badmaskedinexp: "Masked ebuilds with unsatisfied dependencies (matched 
against *all* ebuilds) in experimental arch"
 badtilde: "Uses the ~ dep operator with a non-zero revision part, 
which is useless (the revision is ignored)"
+deprecated: "Ebuild has a dependency that refers to a deprecated 
package"
 equalsversion: "Suspicious =-dependency with a specific version and no 
rev. Please either use ~ if any revision is acceptable, or append -r0 to 
silence the warning."
 missingslot: "RDEPEND matches more than one SLOT but does not specify 
a slot and/or use the := or :* slot operator"
 perlcore: "This ebuild directly depends on a package in perl-core; it 
should use the corresponding virtual instead."
diff --git a/repoman/cnf/repository/qa_data.yaml 
b/repoman/cnf/repository/qa_data.yaml
index c96ce46a9..464482056 100644
--- a/repoman/cnf/repository/qa_data.yaml
+++ b/repoman/cnf/repository/qa_data.yaml
@@ -44,6 +44,7 @@ qawarnings:
 - dependency.badindev
 - dependency.badmaskedindev
 - dependency.badtilde
+- dependency.deprecated
 - dependency.equalsversion
 - dependency.missingslot
 - dependency.perlcore
diff --git a/repoman/lib/repoman/modules/scan/depend/_depend_checks.py 
b/repoman/lib/repoman/modules/scan/depend/_depend_checks.py
index 690b95aa0..226cfec83 100644
--- a/repoman/lib/repoman/modules/scan/depend/_depend_checks.py
+++ b/repoman/lib/repoman/modules/scan/depend/_depend_checks.py
@@ -108,6 +108,11 @@ def _depend_checks(ebuild, pkg, portdb, qatracker, 
repo_metadata, qadata):
not atom.cp.startswith("virtual/"):
unknown_pkgs.add((mytype, 
atom.unevaluated_atom))
 
+   if not atom.blocker and atom.cp in 
repo_metadata['package.deprecated']:
+   qatracker.add_error(
+   'dependency.deprecated',
+   ebuild.relative_path + ": '%s'" 
% atom)
+
if pkg.category != "virtual":
if not is_blocker and \
atom.cp in 
qadata.suspect_virtual:
diff --git a/repoman/lib/repoman/scanner.py b/repoman/lib/repoman/scanner.py
index 06234b0ad..f1c3601a1 100644
--- a/repoman/lib/repoman/scanner.py
+++ b/repoman/lib/repoman/scanner.py
@@ -93,6 +93,10 @@ class Scanner(object):
'profile_list': profile_list,
'pmaskdict': global_pmaskdict,
'lic_deprecated': liclist_deprecated,
+   'package.deprecated': set(atom.cp for atom in
+   
portage.util.stack_lists([portage.util.grabfile_package(
+   os.path.join(path, 'profiles', 
'package.deprecated'), recursive=True)
+   for path in self.portdb.porttrees], 
incremental=True))
}
 
self.repo_settings.repoman_settings['PORTAGE_ARCHLIST'] = ' 
'.join(sorted(kwlist))
diff --git a/repoman/man/repoman.1 b/repoman/man/repoman.1
index 7bd440a4c..a6a9937e5 100644
--- a/repoman/man/repoman.1
+++ b/repoman/man/repoman.1
@@ -315,6 +315,9 @@ experimental arch
 Uses the ~ dep operator with a non-zero revision part, which is useless (the
 revision is ignored)
 .TP
+.B dependency.deprecated
+Ebuild has a dependency that refers to a deprecated package
+.TP
 .B dependency.syntax
 Syntax error in dependency string (usually an extra/missing space/parenthesis)
 .TP
-- 
2.21.0




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Aaron Bauman
On Thu, Dec 05, 2019 at 05:09:57PM +0100, Michał Górny wrote:
> Signed-off-by: Michał Górny 
> ---
>  profiles/package.deprecated | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 profiles/package.deprecated
> 
> diff --git a/profiles/package.deprecated b/profiles/package.deprecated
> new file mode 100644
> index ..b4803a4ce68f
> --- /dev/null
> +++ b/profiles/package.deprecated
> @@ -0,0 +1,17 @@
> +
> +#
> +# This file specifies packages that are considered deprecated (but not
> +# masked yet).  It will trigger pkgcheck warnings whenever other
> +# packages depend on them.
> +#
> +# When you add an entry to the top of this file, add your name, the date
> +# in the UTC timezone, and an explanation of why something is getting
> +# deprecated.
> +#
> +## Example:
> +##
> +## # Dev E. Loper  (2019-07-01)
> +## # This is no longer supported upstream, please switch to dev-foo/bar.
> +## dev-foo/foo
> +
> +#--- END OF EXAMPLES ---
> -- 
> 2.24.0
> 
> 

Thank you for putting this together!

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 5:23 PM David Seifert  wrote:
>
> And that's exactly the straw-man argument I've been making. You can
> always come up with an excuse to delay action on python 2, because
> "someone, somewhere, will maintain it".

Hey, if somebody actually does want to maintain it I don't see any
reason it can't stick around forever.  Of course maintain means
maintain, not just ignore bugs/etc if it causes grief for other
packages and so on, or allow security issues to fester.

So far I'm getting the impression that everybody wants somebody else
to maintain it, and that is when it becomes an issue.  "WE ought to do
this" - where "WE" usually means "not me."  There is no nebulous
"Gentoo" out there who will maintain ebuilds.  If they are to stay in
the repo then somebody has to actually tend them.

If somebody wants to keep around 2.7 for a long time IMO the most
straightforward thing to do is announce a desire to do it with a plan.
I really doubt that anybody is likely to interfere, and if they do it
can always be escalated to Council.  But, again, it has to be done
right and not cause issues for other packages (at least at the start
that shouldn't be a huge problem).

Personally I've always admired the Wikipedia policy:
https://en.wikipedia.org/wiki/WP:BOLD

If you want to see a change, go about it in a positive way.  If such a
change bothers you, assume good faith, but point out the issues.
Don't over-react in either direction.  This is how 99% of everything
positive that has ever happened in Gentoo has come about.  Most of our
improvements are the result of "unsanctioned crusades."  That doesn't
mean that you should go around breaking systems left and right, but in
this case we're just talking about a mask, or announcing an intent to
do a project.

But, such a thing will certainly involve work.  IMO it is work for
diminishing returns.  If it is an itch that bothers you, though, you
can always scratch it...

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread David Seifert
On Thu, 2019-12-05 at 21:56 +0100, Thomas Deutschmann wrote:
> On 2019-12-05 21:31, David Seifert wrote:
> > > On another topic, I'd prefer for python 2.7 not to be removed
> > > from
> > > gentoo. Tons of code still uses it.
> > > 
> > Sorry, but I'll have to disagree with you on this.
> > 
> > We're removing Java too from Gentoo (more implicitly than
> > explicitly),
> > because the Maven/Gradle ecosystem doesn't seem to scale. There's
> > tons
> > of code that uses java and java binaries too, and yet we're
> > removing
> > it. Python 2 is EOL in a few weeks. We have also removed Qt4 and
> > lost a
> > number of useful applications with it. At some point, we're not
> > going
> > to maintain a dead interpreter anymore.
> 
> For the records: Nobody in this discussion or IRC chat said
> 
> > Keep Python 2 forever.

Again, disagree. You'll hear lots of voices that are along the lines of

  "So much enterprise code won't get ported to py3, and RedHat will be
  maintaining RHEL 7 and 8 for the next 10 years, so we'll always have
  security patches to rely on. Let's just keep Python 2 for the
  foreseeable future."

many Gentoo devs have voiced that opinion, so asserting that noone says
"Keep Python 2 forever" is false, and not by a negligible margin.

> 
> It's about timing. From my POV and I read
> 
> > Tons of code still uses it.
>^
> the same,  there is no need to mask any Python 2 stuff _today_.

When we started removing Qt4, tons of code still used it. To put things
in perspective:

grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
cache/ | wc -l

gives me 7070 ebuilds currently. 7070 is easily more than one and
closer to two orders of magnitude more ebuilds using python 2 than Qt4
back in the days. Removing python2 will turn into a multi-year,
monumental effort of epic proportions, and I'm willing to bet
€1000 that we'll still be stuck with it in 3 years. It will be one of
the largest undertakings of Gentoo, probably more involved than getting
rid of EAPI=5 ebuilds. Removing maintainer-needed and other semi-dead
packages is part of a proactive strategy in continuously removing and
treecleaning stale stuff from the tree. Tons of java stuff also still
works, yet we're removing it because the ebuilds are ancient and
unmaintained.

> 
> Especially when new Python project lead sent a mail [1] to this list
> few
> weeks ago stating that there will be a _new_ last Python 2 release in
> April 2020 (120 days away!).
> 
> Now please explain to me and any Gentoo user depending on Py2-only
> software why you are taking actions 120(!) days in advance.
> 
> Again, nobody wants to keep Python 2 forever but starting to kill
> *working* software 120 days in *advance* deserves at least an honest
> justification.

So what do you propose? Starting to remove/fix 7070 ebuilds after April
2020 then? Why start in April 2020? Let's just wait till May 2029, when
RHEL 8 goes into end of maintenance support. That's a good time point
then? It doesn't matter what time point you think is suitable, *any*
time point will be arbitrary to someone. Every change breaks somebody's
workflow.

> 
> PS: And given that a release in April won't break the next day, we
> are
> actually talking about more than 120 days in advance. Security
> argument
> is not valid because if there will be any serious vulnerability in
> Py2
> found after this release (which will be surprising after so many
> years)
> you can expect backports because other distributions still have to
> support Py2 two more years at minimum.

And that's exactly the straw-man argument I've been making. You can
always come up with an excuse to delay action on python 2, because
"someone, somewhere, will maintain it". Heck, if RHEL 8 abandons python
2 in 2029, let's just swap in Tauthon then, then we can use python 2
packages till 2100!

> 
> 
> [1]
> https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179
> 
> 




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Alexis Ballier
On Thu, 2019-12-05 at 19:04 +0100, Michał Górny wrote:
> On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote:
> > On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote:
> > > On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote:
> > > > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > > > > +
> > > > > 
> > > > > 
> > > > > +#
> > > > > +# This file specifies packages that are considered
> > > > > deprecated
> > > > > (but
> > > > > not
> > > > > +# masked yet).  It will trigger pkgcheck warnings whenever
> > > > > other
> > > > > +# packages depend on them.
> > > > > 
> > > > 
> > > > repoman would be more useful for this
> > > > 
> > > 
> > > Then feel free to take repoman over, and start maintaining
> > > it.  I've
> > > lost interest in contributing to the project after the last
> > > pointless
> > > refactoring made adding anything even more effort, and it doesn't
> > > seem
> > > that anyone else has.
> > > 
> > > Given that pkgcheck is a. faster by design, b. running checks
> > > in parallel, c. has sane API making contributing a pleasure, I
> > > don't
> > > really see a point in putting any more effort to support a dead
> > > repoman.
> > > 
> > 
> > it's not about who's maintaining what here...
> > just s/pkgcheck/QA tools/ and be done with it
> 
> Oh, I've listed pkgcheck there because it's the only tool
> implementing
> the file at the moment.  I'm happy to replace it with larger list or
> something more generic once there are other tools.  However, I
> believe
> that saying 'pkgcheck' right now has the advantage that devs know
> which
> tool to use to see the result.

IMHO maintaining such a list is better suited for devmanual or wiki;
just like skel.ebuild could be improved by removing portage references
and refer to PMS


> > pkgcheck is mostly used by your CI checks for
> > producing huge reports, which is nice but addresses a different
> > problem
> 
> There is nothing stopping you from running pkgcheck locally.  In
> fact,
> it should work out of the box these days.  If you have any problems,
> please report them and I'm sure they will be addressed promptly.

Sure I did that to get reports like what CI does for me now but that's
always been a different usecase; I wasn't aware pkgcheck had the
equivalent of repoman commit


> > i could see this file being useful for auto-generating lists on qa-
> > reports like for eapis too
> 
> I don't think there's really a point in duplicating this.

For now certainly not. Once someone wants to wipe a deprecated package
this could come in handy instead of searching a huge html page, but
sure this could be fixed the other way by having this in the per-check
reports like what is on the left side of the current CI reports




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Thomas Deutschmann
On 2019-12-05 21:31, David Seifert wrote:
>> On another topic, I'd prefer for python 2.7 not to be removed from
>> gentoo. Tons of code still uses it.
>>
> Sorry, but I'll have to disagree with you on this.
> 
> We're removing Java too from Gentoo (more implicitly than explicitly),
> because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
> of code that uses java and java binaries too, and yet we're removing
> it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
> number of useful applications with it. At some point, we're not going
> to maintain a dead interpreter anymore.

For the records: Nobody in this discussion or IRC chat said

> Keep Python 2 forever.

It's about timing. From my POV and I read

> Tons of code still uses it.
   ^

the same,  there is no need to mask any Python 2 stuff _today_.

Especially when new Python project lead sent a mail [1] to this list few
weeks ago stating that there will be a _new_ last Python 2 release in
April 2020 (120 days away!).

Now please explain to me and any Gentoo user depending on Py2-only
software why you are taking actions 120(!) days in advance.

Again, nobody wants to keep Python 2 forever but starting to kill
*working* software 120 days in *advance* deserves at least an honest
justification.


PS: And given that a release in April won't break the next day, we are
actually talking about more than 120 days in advance. Security argument
is not valid because if there will be any serious vulnerability in Py2
found after this release (which will be surprising after so many years)
you can expect backports because other distributions still have to
support Py2 two more years at minimum.


[1]
https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread David Seifert
On Thu, 2019-12-05 at 14:59 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman  wrote:
> > On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld  > > wrote:
> > > Hi,
> > > 
> > > Aaron has marked tons of important and useful Python 2.7 packages
> > > for removal:
> > > 
> > > Can we not do this prematurely? I've revered this commit until
> > > such a
> > > thing an be appropriately agreed upon.
> > 
> > Might make sense to wait to mask them at the same time as masking
> > python 2.7 itself?  Maybe file a bug if not already done to make
> > maintainers aware that this is coming?
> > 
> > I assume the python team is the one deciding when python 2.7 has to
> > go
> > (after all, who else is going to maintain it?).  The fact that this
> > is
> > about a month off did come up in another recent thread but I don't
> > think it was intended as a formal announcement.
> 
> It's one thing to mask python libraries in general. If gentoo isn't
> going to support 2.7, then those libraries don't make sense to  keep
> around.
> 
> It's quite another to mask random packages that have USE flags to
> optionally support whatever python 2.7 library. If you're going to
> last rites these, talk with the maintainer first, and only then, send
> emails one at a time. Doing that en masse isn't appropriate.
> 
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
> 

Sorry, but I'll have to disagree with you on this.

We're removing Java too from Gentoo (more implicitly than explicitly),
because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
of code that uses java and java binaries too, and yet we're removing
it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
number of useful applications with it. At some point, we're not going
to maintain a dead interpreter anymore.




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Gerion Entrup
Am Donnerstag, 5. Dezember 2019, 19:04:50 CET schrieb Michał Górny:
> On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote:
> > unless i missed something, repoman is still the standard for pre-commit 
> > checks and raising everyone's attention on potential
> > improvements/issues;
> 
> Nope.  Per quite recent Council meeting pkgcheck is fully acceptable
> alternative, and to my knowledge a number of devs have switched already.
> Because they value their time and good package quality.

As a side note:
In this case, can someone with knowledge how to use pkgcheck please update
https://wiki.gentoo.org/wiki/GitHub_Pull_Requests#Step_4:_User_updates_the_local_repository

I have always used it as first address when making (occasional) pull requests.

Thanks,
Gerion



signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: app-laptop/nvidiabl

2019-12-05 Thread Michał Górny
# Michał Górny  (2019-12-05)
# Last maintainer activity in 2016.  Does not build for quite some time
# already.  Needs a version bump, at the very least.
# Removal in 30 days.  Bug #602024.
app-laptop/nvidiabl

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Alec Warner
On Thu, Dec 5, 2019 at 8:10 AM Michał Górny  wrote:

> Signed-off-by: Michał Górny 
> ---
>  profiles/package.deprecated | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 profiles/package.deprecated
>
>
This looks great Michał, thanks for putting it together.

-A


> diff --git a/profiles/package.deprecated b/profiles/package.deprecated
> new file mode 100644
> index ..b4803a4ce68f
> --- /dev/null
> +++ b/profiles/package.deprecated
> @@ -0,0 +1,17 @@
> +
> +#
> +# This file specifies packages that are considered deprecated (but not
> +# masked yet).  It will trigger pkgcheck warnings whenever other
> +# packages depend on them.
> +#
> +# When you add an entry to the top of this file, add your name, the date
> +# in the UTC timezone, and an explanation of why something is getting
> +# deprecated.
> +#
> +## Example:
> +##
> +## # Dev E. Loper  (2019-07-01)
> +## # This is no longer supported upstream, please switch to dev-foo/bar.
> +## dev-foo/foo
> +
> +#--- END OF EXAMPLES ---
> --
> 2.24.0
>
>
>


[gentoo-portage-dev] [PATCH] emerge: add --implicit-system-deps option (bug 681312)

2019-12-05 Thread Zac Medico
Assume that packages may have implicit dependencies on packages which
belong to the @system set. This option is enabled by default. One of
the effects of disabling this option is to allow the --jobs option
to spawn jobs without accounting for the possiblity of implicit
dependencies on packages that belong to the @system set (this causes
the @system set to behave more like the @profile set).

Bug: https://bugs.gentoo.org/681312
---
 lib/_emerge/Scheduler.py  | 4 
 lib/_emerge/create_depgraph_params.py | 4 
 lib/_emerge/depgraph.py   | 7 ---
 lib/_emerge/main.py   | 6 ++
 man/emerge.1  | 7 +++
 5 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/lib/_emerge/Scheduler.py b/lib/_emerge/Scheduler.py
index 7fa3992e7..98eaf3bcc 100644
--- a/lib/_emerge/Scheduler.py
+++ b/lib/_emerge/Scheduler.py
@@ -499,6 +499,10 @@ class Scheduler(PollScheduler):
added to the graph and traversed deeply (the depgraph "complete"
parameter will do this, triggered by emerge --complete-graph 
option).
"""
+   params = create_depgraph_params(self.myopts, None)
+   if not params["implicit_system_deps"]:
+   return
+
deep_system_deps = self._deep_system_deps
deep_system_deps.clear()
deep_system_deps.update(
diff --git a/lib/_emerge/create_depgraph_params.py 
b/lib/_emerge/create_depgraph_params.py
index 7d8da9065..81edcb9c0 100644
--- a/lib/_emerge/create_depgraph_params.py
+++ b/lib/_emerge/create_depgraph_params.py
@@ -32,6 +32,8 @@ def create_depgraph_params(myopts, myaction):
#   packages, so that they do not trigger dependency resolution
#   failures, or cause packages to be rebuilt or replaced.
# ignore_world: ignore the @world package set and its dependencies
+   # implicit_system_deps: Assume that packages may have implicit 
dependencies
+   #   on packages which belong to the @system set.
# with_test_deps: pull in test deps for packages matched by arguments
# changed_deps: rebuild installed packages with outdated deps
# changed_deps_report: report installed packages with outdated deps
@@ -87,6 +89,8 @@ def create_depgraph_params(myopts, myaction):
if dynamic_deps:
myparams["dynamic_deps"] = True
 
+   myparams["implicit_system_deps"] =  
myopts.get("--implicit-system-deps", "y") != "n"
+
if myaction == "remove":
myparams["remove"] = True
myparams["complete"] = True
diff --git a/lib/_emerge/depgraph.py b/lib/_emerge/depgraph.py
index f80b077bc..b6acf0b71 100644
--- a/lib/_emerge/depgraph.py
+++ b/lib/_emerge/depgraph.py
@@ -7399,6 +7399,8 @@ class depgraph(object):
For optimal leaf node selection, promote deep system runtime 
deps and
order nodes from highest to lowest overall reference count.
"""
+   if not self._dynamic_config.myparams["implicit_system_deps"]:
+   return
 
node_info = {}
for node in mygraph.order:
@@ -8043,10 +8045,9 @@ class depgraph(object):
# by a normal replacement 
operation then abort.
skip = False
try:
-   for atom in 
root_config.sets[
-   
"system"].iterAtomsForPackage(task):
+   if 
(self._dynamic_config.myparams["implicit_system_deps"] and
+   
any(root_config.sets["system"].iterAtomsForPackage(task))):
skip = True
-   break
except 
portage.exception.InvalidDependString as e:
portage.writemsg("!!! 
Invalid PROVIDE in " + \

"'%svar/db/pkg/%s/PROVIDE': %s\n" % \
diff --git a/lib/_emerge/main.py b/lib/_emerge/main.py
index 8c72cdf9c..95855ef2d 100644
--- a/lib/_emerge/main.py
+++ b/lib/_emerge/main.py
@@ -525,6 +525,12 @@ def parse_opts(tmpcmdline, silent=False):
"choices" : true_y_or_n
},
 
+   "--implicit-system-deps": {
+   "help": "Assume that packages may have implicit 
dependencies on"
+   "packages which belong to the @system set",
+   "choices": y_or_n
+   },
+
"--jobs": {
 
"shortopt" : "-j",
diff --git 

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Michał Górny
On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote:
> On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote:
> > On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote:
> > > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > > > +
> > > > 
> > > > +#
> > > > +# This file specifies packages that are considered deprecated
> > > > (but
> > > > not
> > > > +# masked yet).  It will trigger pkgcheck warnings whenever other
> > > > +# packages depend on them.
> > > > 
> > > 
> > > repoman would be more useful for this
> > > 
> > 
> > Then feel free to take repoman over, and start maintaining it.  I've
> > lost interest in contributing to the project after the last pointless
> > refactoring made adding anything even more effort, and it doesn't
> > seem
> > that anyone else has.
> > 
> > Given that pkgcheck is a. faster by design, b. running checks
> > in parallel, c. has sane API making contributing a pleasure, I don't
> > really see a point in putting any more effort to support a dead
> > repoman.
> > 
> 
> it's not about who's maintaining what here...
> just s/pkgcheck/QA tools/ and be done with it

Oh, I've listed pkgcheck there because it's the only tool implementing
the file at the moment.  I'm happy to replace it with larger list or
something more generic once there are other tools.  However, I believe
that saying 'pkgcheck' right now has the advantage that devs know which
tool to use to see the result.

> unless i missed something, repoman is still the standard for pre-commit 
> checks and raising everyone's attention on potential
> improvements/issues;

Nope.  Per quite recent Council meeting pkgcheck is fully acceptable
alternative, and to my knowledge a number of devs have switched already.
Because they value their time and good package quality.

>  pkgcheck is mostly used by your CI checks for
> producing huge reports, which is nice but addresses a different problem

There is nothing stopping you from running pkgcheck locally.  In fact,
it should work out of the box these days.  If you have any problems,
please report them and I'm sure they will be addressed promptly.

> i could see this file being useful for auto-generating lists on qa-
> reports like for eapis too

I don't think there's really a point in duplicating this.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Alexis Ballier
On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote:
> On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote:
> > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > > +
> > > 
> > > +#
> > > +# This file specifies packages that are considered deprecated
> > > (but
> > > not
> > > +# masked yet).  It will trigger pkgcheck warnings whenever other
> > > +# packages depend on them.
> > > 
> > 
> > repoman would be more useful for this
> > 
> 
> Then feel free to take repoman over, and start maintaining it.  I've
> lost interest in contributing to the project after the last pointless
> refactoring made adding anything even more effort, and it doesn't
> seem
> that anyone else has.
> 
> Given that pkgcheck is a. faster by design, b. running checks
> in parallel, c. has sane API making contributing a pleasure, I don't
> really see a point in putting any more effort to support a dead
> repoman.
> 

it's not about who's maintaining what here...
just s/pkgcheck/QA tools/ and be done with it


unless i missed something, repoman is still the standard for pre-commit 
checks and raising everyone's attention on potential
improvements/issues; pkgcheck is mostly used by your CI checks for
producing huge reports, which is nice but addresses a different problem

i could see this file being useful for auto-generating lists on qa-
reports like for eapis too


as for your current views on repoman vs pkgcheck, i have nothing
against stopping using repoman and switching to pkgcheck, but AFAIK
this has yet to happen at a policy level




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Mikle Kolyada
+1

5 декабря 2019 г. 19:09:57 GMT+03:00, "Michał Górny"  пишет:
>Signed-off-by: Michał Górny 
>---
> profiles/package.deprecated | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644 profiles/package.deprecated
>
>diff --git a/profiles/package.deprecated b/profiles/package.deprecated
>new file mode 100644
>index ..b4803a4ce68f
>--- /dev/null
>+++ b/profiles/package.deprecated
>@@ -0,0 +1,17 @@
>+
>+#
>+# This file specifies packages that are considered deprecated (but not
>+# masked yet).  It will trigger pkgcheck warnings whenever other
>+# packages depend on them.
>+#
>+# When you add an entry to the top of this file, add your name, the
>date
>+# in the UTC timezone, and an explanation of why something is getting
>+# deprecated.
>+#
>+## Example:
>+##
>+## # Dev E. Loper  (2019-07-01)
>+## # This is no longer supported upstream, please switch to
>dev-foo/bar.
>+## dev-foo/foo
>+
>+#--- END OF EXAMPLES ---
>-- 
>2.24.0

-- 
Простите за краткость, создано в K-9 Mail.

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Michał Górny
On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote:
> On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > +
> > +#
> > +# This file specifies packages that are considered deprecated (but
> > not
> > +# masked yet).  It will trigger pkgcheck warnings whenever other
> > +# packages depend on them.
> > 
> 
> repoman would be more useful for this
> 

Then feel free to take repoman over, and start maintaining it.  I've
lost interest in contributing to the project after the last pointless
refactoring made adding anything even more effort, and it doesn't seem
that anyone else has.

Given that pkgcheck is a. faster by design, b. running checks
in parallel, c. has sane API making contributing a pleasure, I don't
really see a point in putting any more effort to support a dead repoman.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Alexis Ballier
On Thu, 2019-12-05 at 10:53 -0600, William Hubbs wrote:
> On Thu, Dec 05, 2019 at 05:36:58PM +0100, Alexis Ballier wrote:
> > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > > +
> > > 
> > > +#
> > > +# This file specifies packages that are considered deprecated
> > > (but
> > > not
> > > +# masked yet).  It will trigger pkgcheck warnings whenever other
> > > +# packages depend on them.
> > > 
> > 
> > repoman would be more useful for this
> 
> I wouldn't stop pkgcheck from supporting this, but repoman should as
> well.
> 
> 
> 

of course, that's what i meant ;)




Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread William Hubbs
On Thu, Dec 05, 2019 at 05:36:58PM +0100, Alexis Ballier wrote:
> On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> > +
> > +#
> > +# This file specifies packages that are considered deprecated (but
> > not
> > +# masked yet).  It will trigger pkgcheck warnings whenever other
> > +# packages depend on them.
> > 
> 
> 
> repoman would be more useful for this

I wouldn't stop pkgcheck from supporting this, but repoman should as
well.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Matt Turner
On Thu, Dec 5, 2019 at 11:10 AM Michał Górny  wrote:
>
> Signed-off-by: Michał Górny 
> ---
>  profiles/package.deprecated | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 profiles/package.deprecated
>
> diff --git a/profiles/package.deprecated b/profiles/package.deprecated
> new file mode 100644
> index ..b4803a4ce68f
> --- /dev/null
> +++ b/profiles/package.deprecated
> @@ -0,0 +1,17 @@
> +
> +#
> +# This file specifies packages that are considered deprecated (but not
> +# masked yet).  It will trigger pkgcheck warnings whenever other
> +# packages depend on them.
> +#
> +# When you add an entry to the top of this file, add your name, the date
> +# in the UTC timezone, and an explanation of why something is getting
> +# deprecated.
> +#
> +## Example:
> +##
> +## # Dev E. Loper  (2019-07-01)
> +## # This is no longer supported upstream, please switch to dev-foo/bar.
> +## dev-foo/foo
> +
> +#--- END OF EXAMPLES ---
> --
> 2.24.0

Yes, please!



Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Andreas K. Huettel
Am Donnerstag, 5. Dezember 2019, 17:09:57 CET schrieb Michał Górny:
[...]
> +# This file specifies packages that are considered deprecated (but not
> +# masked yet).  It will trigger pkgcheck warnings whenever other
> +# packages depend on them.

Just saying, this is an awesome functionality, and will be highly useful.

So, yes++

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)





Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Alexis Ballier
On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote:
> +
> +#
> +# This file specifies packages that are considered deprecated (but
> not
> +# masked yet).  It will trigger pkgcheck warnings whenever other
> +# packages depend on them.
> 


repoman would be more useful for this




[gentoo-dev] Last rites: net-wireless/ndiswrapper

2019-12-05 Thread Michał Górny
# Michał Górny  (2019-12-05)
# Unmaintained since 2016.  Last touched in 2018.  Pending bump since
# Feb 2019.  Does not build anymore.
# Removal in 30 days.  Bug #695580.
net-wireless/ndiswrapper

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 profiles/package.deprecated | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 profiles/package.deprecated

diff --git a/profiles/package.deprecated b/profiles/package.deprecated
new file mode 100644
index ..b4803a4ce68f
--- /dev/null
+++ b/profiles/package.deprecated
@@ -0,0 +1,17 @@
+
+#
+# This file specifies packages that are considered deprecated (but not
+# masked yet).  It will trigger pkgcheck warnings whenever other
+# packages depend on them.
+#
+# When you add an entry to the top of this file, add your name, the date
+# in the UTC timezone, and an explanation of why something is getting
+# deprecated.
+#
+## Example:
+##
+## # Dev E. Loper  (2019-07-01)
+## # This is no longer supported upstream, please switch to dev-foo/bar.
+## dev-foo/foo
+
+#--- END OF EXAMPLES ---
-- 
2.24.0




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Andreas K. Huettel
How about adding yourself as maintainer then? :)

Am Donnerstag, 5. Dezember 2019, 14:42:59 CET schrieb Jason A. Donenfeld:
> Hi,
> 
> Aaron has marked tons of important and useful Python 2.7 packages for
> removal:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fb
> b5768cc6f38ac
> 
> There are quite a few useful packages in here.
> 
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
> 
> Thanks,
> Jason


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)






Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Aaron Bauman
On Thu, Dec 05, 2019 at 09:34:16AM -0500, William Breathitt Gray wrote:
> On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:
> > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  wrote:
> > >
> > > It's quite another to mask random packages that have USE flags to
> > > optionally support whatever python 2.7 library. If you're going to
> > > last rites these, talk with the maintainer first, and only then, send
> > > emails one at a time. Doing that en masse isn't appropriate.
> > 
> > ++ - I have no idea if that happened.  For anything USE-controlled it
> > would make more sense to file a bug or mask the package-flag combo
> > itself.
> > 
> > >
> > > On another topic, I'd prefer for python 2.7 not to be removed from
> > > gentoo. Tons of code still uses it.
> > >
> > 
> > I'm sure a million people would share that preference.  I'm not sure
> > what the upstream/security status is of 2.7.  Obviously to keep it
> > around it would need to be reasonably secure, and somebody within
> > Gentoo would have to want to maintain it.  That's basically the
> > criteria for keeping anything like this around.  If somebody stepped
> > up and said "I'm maintaining 2.7 and here is why it will remain
> > secure..." I doubt they'd get a lot of resistance.
> > 
> > -- 
> > Rich
> 
> If Python 2.7 is EOL upstream then it sounds like upstream will not be
> maintaining it any longer; i.e. no more bug fixes nor support. That
> means Gentoo would have to maintain its own Python 2.7 fork if it's to
> remain in the repository. Naturally, maintaining a Python fork is not
> something the Gentoo team is ready to do, so it makes sense to remove
> Python 2.7 now that the EOL date is approaching.
> 
> Besides, the Python 2.7 EOL date has been known since 2015, so those
> python 2-only packages will have had at least 5 years to migrate to
> Python 3.
> 
> William Breathitt Gray
> 

Wonderful response, William.

For the others who are seeking a quick "why? how? when? what?" there are these
links:

https://pythonclock.org/

https://python3statement.org/ <--- This is a fun one. All the naysayers need to
go yell at the projects too!

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Aaron Bauman
On Thu, Dec 05, 2019 at 02:42:59PM +0100, Jason A. Donenfeld wrote:
> Hi,
> 
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb5768cc6f38ac
> 
> There are quite a few useful packages in here.
> 
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
> 
> Thanks,
> Jason
> 

You have obviously not read the relevant commit msg, reviewed the already
existing thread on -dev, or attempted to ask (and await a response) relevant
questions.

Jumping to conclusions does not help anyone.

<@zx2c4> that was supposed to be a || ( ... )
<@zx2c4> but for whatever reason the maintainer forgot that
<@zx2c4> so im going to correct that and remove eyeD3 from the list<@zx2c4> and 
unmask it
<@zx2c4> b-man: sound good?
<@zx2c4> slashbeast: woah look at d85e166dd999c354a5346fbb5768cc6f38ac
<@zx2c4> it's ... a lot of packages
<@zx2c4> hey removing beets too? thats not cool
<@zx2c4> and pp?
<@zx2c4> um
<@zx2c4> actually, this is ridiculous

So, clearly, you did not read the commit msg or review the thread. Magically,
you were actually going to *fix* a package and then got overwhelmed with how
many of your favorite pkgs were on the list.

Don't be lazy. Others are working to fix them and keep them around.

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread William Breathitt Gray
On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:
> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  wrote:
> >
> > It's quite another to mask random packages that have USE flags to
> > optionally support whatever python 2.7 library. If you're going to
> > last rites these, talk with the maintainer first, and only then, send
> > emails one at a time. Doing that en masse isn't appropriate.
> 
> ++ - I have no idea if that happened.  For anything USE-controlled it
> would make more sense to file a bug or mask the package-flag combo
> itself.
> 
> >
> > On another topic, I'd prefer for python 2.7 not to be removed from
> > gentoo. Tons of code still uses it.
> >
> 
> I'm sure a million people would share that preference.  I'm not sure
> what the upstream/security status is of 2.7.  Obviously to keep it
> around it would need to be reasonably secure, and somebody within
> Gentoo would have to want to maintain it.  That's basically the
> criteria for keeping anything like this around.  If somebody stepped
> up and said "I'm maintaining 2.7 and here is why it will remain
> secure..." I doubt they'd get a lot of resistance.
> 
> -- 
> Rich

If Python 2.7 is EOL upstream then it sounds like upstream will not be
maintaining it any longer; i.e. no more bug fixes nor support. That
means Gentoo would have to maintain its own Python 2.7 fork if it's to
remain in the repository. Naturally, maintaining a Python fork is not
something the Gentoo team is ready to do, so it makes sense to remove
Python 2.7 now that the EOL date is approaching.

Besides, the Python 2.7 EOL date has been known since 2015, so those
python 2-only packages will have had at least 5 years to migrate to
Python 3.

William Breathitt Gray



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  wrote:
>
> It's quite another to mask random packages that have USE flags to
> optionally support whatever python 2.7 library. If you're going to
> last rites these, talk with the maintainer first, and only then, send
> emails one at a time. Doing that en masse isn't appropriate.

++ - I have no idea if that happened.  For anything USE-controlled it
would make more sense to file a bug or mask the package-flag combo
itself.

>
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
>

I'm sure a million people would share that preference.  I'm not sure
what the upstream/security status is of 2.7.  Obviously to keep it
around it would need to be reasonably secure, and somebody within
Gentoo would have to want to maintain it.  That's basically the
criteria for keeping anything like this around.  If somebody stepped
up and said "I'm maintaining 2.7 and here is why it will remain
secure..." I doubt they'd get a lot of resistance.

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Jason A. Donenfeld
On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman  wrote:
>
> On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld  wrote:
> >
> > Hi,
> >
> > Aaron has marked tons of important and useful Python 2.7 packages for 
> > removal:
> >
> > Can we not do this prematurely? I've revered this commit until such a
> > thing an be appropriately agreed upon.
>
> Might make sense to wait to mask them at the same time as masking
> python 2.7 itself?  Maybe file a bug if not already done to make
> maintainers aware that this is coming?
>
> I assume the python team is the one deciding when python 2.7 has to go
> (after all, who else is going to maintain it?).  The fact that this is
> about a month off did come up in another recent thread but I don't
> think it was intended as a formal announcement.

It's one thing to mask python libraries in general. If gentoo isn't
going to support 2.7, then those libraries don't make sense to  keep
around.

It's quite another to mask random packages that have USE flags to
optionally support whatever python 2.7 library. If you're going to
last rites these, talk with the maintainer first, and only then, send
emails one at a time. Doing that en masse isn't appropriate.

On another topic, I'd prefer for python 2.7 not to be removed from
gentoo. Tons of code still uses it.



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld  wrote:
>
> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon.

Might make sense to wait to mask them at the same time as masking
python 2.7 itself?  Maybe file a bug if not already done to make
maintainers aware that this is coming?

I assume the python team is the one deciding when python 2.7 has to go
(after all, who else is going to maintain it?).  The fact that this is
about a month off did come up in another recent thread but I don't
think it was intended as a formal announcement.

-- 
Rich



[gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Jason A. Donenfeld
Hi,

Aaron has marked tons of important and useful Python 2.7 packages for removal:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb5768cc6f38ac

There are quite a few useful packages in here.

Can we not do this prematurely? I've revered this commit until such a
thing an be appropriately agreed upon. Many of those packages are
actively maintained upstream packages. abcde, beets, and tahoe-lafs
immediately jump out.

Thanks,
Jason



Re: [gentoo-dev] Last rites: dev-python/* leaf packages

2019-12-05 Thread Alexis Ballier
On Wed, 2019-12-04 at 19:15 -0500, Aaron Bauman wrote:
> * Removal in 30 days
> 


IMHO masking with unfixed, or much later, removal date will better help
achieve your goal: You are making your point by having them masked so
that it will make enough noise for interested people to understand py2
only is not a thing anymore.

We already see a lot of "false positives", there are probably packages
that just work but are lacking attention. If after a longer time those
packages are still not fixed, you can probably safely remove them with
the "meh, nobody cares anyway" reason and not even bother having to
check hundreds (?) of packages yourself. The 30 days is usually a
guideline for packages that have known issues but seems a bit short for
checking if someone cares about a package using a deprecated but
working python.


Also, your list is missing dev-ros/* which is py2 only. I hope I'll be
able to update them soon, last time I tried I failed miserably though
since the whole stack is really python-single style so that one broken
package with py3 causes the whole stack to be py2...


Alexis.




Re: [gentoo-dev] Last rites: dev-python/* leaf packages

2019-12-05 Thread Gerion Entrup
Am Donnerstag, 5. Dezember 2019, 01:15:48 CET schrieb Aaron Bauman:
> dev-python/pycdio

Has Python 3 support since 2.1 (released in August this year). Developed by 
libcdio itself.

> app-text/pdfshuffler

Was last rited a few day ago. As I said, pdfarranger 
(https://github.com/jeromerobert/pdfarranger) seems to be the modern follow up 
project.

Gerion




signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Last rites: dev-python/* leaf packages

2019-12-05 Thread Tobias Klausmann
Hi! 

On Wed, 04 Dec 2019, Aaron Bauman wrote:
> dev-python/eyeD3
> media-sound/abcde
> media-sound/gpodder

FWIW, eyeD3 has a Py3 (only!) version available. Since abcde is a
shell script that just calls the eyeD3 binary, the API changes
don't matter. And gpodder is Py3 only itself, so it can't have
used eyeD3 as a library. Also, this comment in
gpodder-3.10.5.ebuild:

# As in Fedora: re-enable
# >=dev-python/eyeD3-0.7[${PYTHON_USEDEP}] and
# ipod? ( media-libs/libgpod[python,${PYTHON_USEDEP}] ) once they
# support python3

I don't have an iPod, so I can't really test gpodder. But as it
is, it doesn't *actually* need eyeD3, and thus can be unmasked.

I'll see if I can bump eyeD3 to Py3 on the weekend, and clean it
up as well (it now has different deps etc). It do it now, but
properly testing abcde requires access to a CD drive and I don't
have that 'til the weekend.

Best,
Tobias



-- 
Sent from aboard the Culture ship
GOU (Abominator class) Falling Outside The Normal Moral Constraints