Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
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
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
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
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
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)
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
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
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
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
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
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
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.
[gentoo-dev] Last rites: app-laptop/nvidiabl
# 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
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)
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
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
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
+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
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
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
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
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
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
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
# 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
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
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
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
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
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
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
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
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
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
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
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
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
