[gentoo-dev] News item v2: Python 3.7 to become the default target
Hi, Here's v2 following IRC feedback and some rereading. Changes: - pushed the date forward (it will be 2 weeks after publishing the news item) and indicated that it may happen later. - did some more grammar improvements. - switched snippets to use package.use as make.conf breaks IUSE defaults. Also added a little explanation about that to the end but without getting into technical details. - indicated that not all packages support py3.7. - indicated that ~arch users may prefer py3.8. Please review. --- Title: Python 3.7 to become the default target Author: Michał Górny Posted: 2020-04-21 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: dev-lang/python:3.6 On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one of the default Python targets for Gentoo systems. The new default values will be: PYTHON_TARGETS="python2_7 python3_7" PYTHON_SINGLE_TARGET="python3_7" If you have not overriden these variables on your system, then your package manager will switch to the new targets immediately. In order to avoid dependency conflicts, please clean stray packages up and rebuild/upgrade all packages with USE flag changes after the change, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean Please note that during the system upgrade some of the package dependencies may temporarily become missing. While this should not should not affect programs that are already fully loaded, it may cause ImportErrors while starting Python scripts or loading additional modules (only scripts running Python 3.6 are affected). In order to improve stability of the upgrade, you may choose to temporarily enable both targets, i.e. set in /etc/portage/package.use or its equivalent: PYTHON_TARGETS: python3_6 python3_7 PYTHON_SINGLE_TARGET: -* python3_6 This will cause the dependencies to include both Python 3.6 and 3.7 support whenever possible, throughout the next system upgrade. Once all packages are updated, you can restart your scripts, remove the setting and start another upgrade in order to cleanly remove Python 3.6. There are still some Gentoo packages that do not support Python 3.7. We will be pushing updates to these packages as time permits. However, some of them will probably be removed instead. If you would like to postpone the switch to Python 3.7, you can copy the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET to /etc/portage/package.use or its equivalent: PYTHON_TARGETS: -python3_7 python3_6 PYTHON_SINGLE_TARGET: -* python3_6 If you would like to migrate your systems earlier, you can do the opposite. Note that if you are running ~arch, you may want to go straight for Python 3.8 at this point. Please note that this switch is long overdue. Python 3.6 is no longer receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will probably remove it earlier than that. [1] All above snippets assume using package.use to control USE flags. If you still have make.conf entries for these targets, you need to remove them. While using make.conf is possible, it is strongly discouraged as it does not respect package defaults. The latter can help you keep some of Python 3.6 packages without the need to explicitly toggle flags per-package. [1] https://devguide.python.org/#status-of-python-branches -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, 2020-04-20 at 16:04 -0500, William Hubbs wrote: > Your proposal seems to completely go against how the go ecosystem operates, > but if you can come up with a proof-of-concept for how it would work > without forcing a lot of busy work on us that would never get accepted > upstream, I'll take a look. > Define 'busy work'. Is doing things right 'busy work' vs taking shortcuts? Is it 'busy work' that I'm putting a lot of effort into fixing Python packages? Should I just last rite them all and tell people to use virtualenv? Is testing packages 'busy work'? I suppose it's all easier when you just silently include 240 dependencies without testing a single one of them and call it a day. Sure, you run some tests on the final package. Leaves 240 untested, some of them likely failing tests and requiring 'busy work' to fix them. Is security support 'busy work'? I suppose it's all easier when you ignore them problem and let security team deal with it (except they won't). Sure, you can assume that when vulnerability is discovered, all upstreams will eventually learn of it, update their bundled dependencies and *maybe* inform people that their code might have been indirectly vulnerable (but would they do the 'busy work' of discovering whether it affected them or not?). I realize Go is not isolated here. It's just brought as one major example. Rust is no better. All these shiny 'write and forget' languages share the same problem. Pay for some work hours, get a working product, deploy it and forget unless customers want more features. Today these languages are still young and the problems can be considered largely theoretical. But some day -- well, unless all the cool kids manage to move on to next shiny new language before then -- this will be a major catastrophe. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 5:48 PM, Georg Rudoy wrote: > >> I've learned the hard way that it discourages you from doing all the >> things that I just said high-quality software should do. > > Again, ranging from one-off pseudo-scripts that I had to come back to > after a couple of years, to quite complicated pieces of software > running in prod and actually serving customers I had to update up to > the latest LTS after 3-4 years of inactivity, I tend to disagree. Even > the latter was a surprisingly smooth process boiling down to about an > hour or two of very effortless, mechanical and thus boring code > changes (mostly about Semigroup/Monoid hierarchy, if you wonder). > > This is surely offtopic, but I just don't want to silently participate > in spreading things that aren't objectively true (even if they are > subjectively true in your/mine/etc experience). Fair enough, I was speaking only from personal experience. But if you do an experiment I bet you'll agree with me. Updating your code to work with the latest GHC is pretty easy. But if you wanted to write an ebuild for that program, it would have a dependency on that specific version of GHC, leading to these same problems that we're talking about when other programs require other specific versions. I can compile my C programs with any GCC going back to the 4.x days -- or even clang. In the past three years, we've collected ghc-8.0 though ghc-8.10 in ::gentoo. Try to make your code work with all of those GHC releases at once; if you come back and tell me it was easy, I'll be impressed (and may start asking you to update my Haskell code). Working around something like gcc-10's -fno-common breakage, on the other hand, is relatively easy. We write a patch, send it upstream, add it to ::gentoo in the meantime, and everything keeps working. But that's only backwards-compatible because the C standard says how it should work, and the C standard doesn't change every six months to be "whatever this version of GCC does." To refer back to something on-topic: some projects are willing to make the extra effort, and some aren't. The ones that are, are easy to package and definitely belong in ::gentoo. The others... should be dealt with case-by-case. But lowering the standards of the main tree should not be how we get them over the bar.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 5:25 PM, Patrick McLean wrote: > > Please explain how we are actively making things worse for you? We > are contributing useful packages to the tree, we are doing the work > and we are doing it in the way that makes the most effective use of > our time. We simply do not have time to be trying to convince > upstreams to make changes to their build systems to support a single, > somewhat niche, distribution. We certainly don't have time to be > patching build systems with every version bump. > You're introducing unfixable security vulnerabilities into a distribution that I recommend to people, that my name implicitly endorses, and that I use to professionally to handle peoples' sensitive personal data. Likewise with the license issues that can't be fixed. It's a waste of time having to explain to every new contributor that Go ebuilds in ::gentoo are "special" and aren't something they should be using as an example. You're setting an example that our QA and security standards (that we beat to death in the quizzes) can be ignored whenever you feel like it. This indirectly creates technical debt as other developers follow your example. You're directly creating technical debt that someone else is going to have to clean up when you move on to the next shiny and the treecleaners have to waste six months last-riting everything. And you're blocking a golang implementation that doesn't have these problems.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
пн, 20 апр. 2020 г. в 17:38, Michael Orlitzky : > Diamond dependencies manifest mainly in delayed version > bumps, while slyfox does all the work to make sure that the things > already in the tree will work with the new version. This requires lots > of careful updates to neighboring packages, and unfortunately a lot of > cabal file hacking. This is precisely what I meant by "doesn't scale well". Wonder if this can be automated. > > Dunno much about Go and I don't have a single Go package locally to > > check. Do they do static or dynamic linking with the deps, for > > instance? What's the language model wrt API and linking? > > FORGET I MENTIONED IT Lol, happy to! > >> and C. > > > > More stable API (and ABI). > > > > Definitely. The "Haskell" language changes entirely every few years. Some say the same about C++ (and ABI does change even within a standard), so... > I've learned the hard way that it discourages you from doing all the > things that I just said high-quality software should do. Again, ranging from one-off pseudo-scripts that I had to come back to after a couple of years, to quite complicated pieces of software running in prod and actually serving customers I had to update up to the latest LTS after 3-4 years of inactivity, I tend to disagree. Even the latter was a surprisingly smooth process boiling down to about an hour or two of very effortless, mechanical and thus boring code changes (mostly about Semigroup/Monoid hierarchy, if you wonder). This is surely offtopic, but I just don't want to silently participate in spreading things that aren't objectively true (even if they are subjectively true in your/mine/etc experience). > There's a core of mature Haskell that's pretty easy to develop against. > (I think you just have to wait about five years with any project before > the authors realize that changing everything every month isn't fun.) Out > in the woods you can still get into a lot of trouble though. We now have > the mature core stuff in ::gentoo, and the crazies out in the ::haskell > overlay. That feels like the right mix. I've seen transifex-client last-rited the other day and was thinking of throwing up something in haskell (plus I have a couple of other projects that might be useful). Let's see what it'd take to get that into ::gentoo once I'm done. BTW having things like servant in ::haskell as opposed to ::gentoo is like having boost in some C++ overlay as opposed to ::gentoo. -- Georg Rudoy
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 5:05 PM, Georg Rudoy wrote: > >> If upstream absolutely insists on minor-version dependencies, then you >> either tolerate it conflicting with everything else, or leave it out of >> the tree. You probably shouldn't even be packaging a library whose API >> is distinguishable across minor releases. > > That's not a matter of just the API per se. Even the library file name > encodes its deps in its name (if I understand correctly, that's the > hash in libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so > for example). Personally I just find it hard to reason about this sort > of dependencies management. But, again, I should probably avoid trying > that and just jump head first to packaging. Haskell already requires transitive rebuilds of dependencies due to a (serious) implementation constraint. Subslots help with that, but it will take a new EAPI to truly tell an ebuild how to do what we need to do. In any case, all Haskell ebuilds depend on separate packages for their dependencies, and with haskell-updater, subslots, and @preserved-rebuild it all more or less works. I think that's largely separate from the "diamond dependency problem" you posed. Diamond dependencies manifest mainly in delayed version bumps, while slyfox does all the work to make sure that the things already in the tree will work with the new version. This requires lots of careful updates to neighboring packages, and unfortunately a lot of cabal file hacking. > Dunno much about Go and I don't have a single Go package locally to > check. Do they do static or dynamic linking with the deps, for > instance? What's the language model wrt API and linking? FORGET I MENTIONED IT >> and C. > > More stable API (and ABI). > Definitely. The "Haskell" language changes entirely every few years. I've learned the hard way that it discourages you from doing all the things that I just said high-quality software should do. There's a core of mature Haskell that's pretty easy to develop against. (I think you just have to wait about five years with any project before the authors realize that changing everything every month isn't fun.) Out in the woods you can still get into a lot of trouble though. We now have the mature core stuff in ::gentoo, and the crazies out in the ::haskell overlay. That feels like the right mix.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, 20 Apr 2020 17:03:50 -0400 Michael Orlitzky wrote: > On 4/20/20 4:19 PM, Patrick McLean wrote: > > > > My co-workers are not the only ones adding/maintaining go packages in the > > tree, please do not single out any groups, and let's all work to make > > Gentoo the best it can be. > > > > Everyone else is just using the eclass that your coworkers defended and > committed the last time we did this. We're not in this together and you > sound like a COVID commercial from a billionaire that wants me to go > back to work. You're in this for you, and everything you do for you > makes things worse for me. > We are under no obligation to contribute anything to ::gentoo, we could do all our go packaging work in a private overlay, and never push anything upstream. It is a considerable amount of extra work to push our packages upstream. We do this to contribute to the wider Gentoo community. I resent your statement that we are not doing this to contribute to the community. Please explain how we are actively making things worse for you? We are contributing useful packages to the tree, we are doing the work and we are doing it in the way that makes the most effective use of our time. We simply do not have time to be trying to convince upstreams to make changes to their build systems to support a single, somewhat niche, distribution. We certainly don't have time to be patching build systems with every version bump.
Re: [gentoo-portage-dev] [PATCH] Import portage.util.netlink.RtNetlink in global scope
On 4/20/20 1:50 PM, Mike Gilbert wrote: > Bug: https://bugs.gentoo.org/718578 > Signed-off-by: Mike Gilbert > --- > lib/portage/process.py | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/lib/portage/process.py b/lib/portage/process.py > index 590116890..79052b608 100644 > --- a/lib/portage/process.py > +++ b/lib/portage/process.py > @@ -27,6 +27,13 @@ from portage.const import BASH_BINARY, SANDBOX_BINARY, > FAKEROOT_BINARY > from portage.exception import CommandNotFound > from portage.util._ctypes import find_library, LoadLibrary, ctypes > > +try: > + from portage.util.netlink import RtNetlink > +except ImportError: > + if platform.system() == "Linux": > + raise > + RtNetlink = None > + > try: > import resource > max_fd_limit = resource.getrlimit(resource.RLIMIT_NOFILE)[0] > @@ -504,8 +511,8 @@ def _configure_loopback_interface(): > # Bug: https://bugs.gentoo.org/690758 > # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13 > > - # Avoid importing this module on systems that may not support netlink > sockets. > - from portage.util.netlink import RtNetlink > + if RtNetlink is None: > + return > > try: > with RtNetlink() as rtnl: > Looks good. Please merge. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
пн, 20 апр. 2020 г. в 16:51, Michael Orlitzky : > Except that Haskell as a research language tends to inspire more "fire and > forget" software. I'd say this is not the case for the last few years, but that's maybe just my own impression from interacting with > (And Haskell works better in Gentoo than anywhere else, in my opinion.) Totally agreed here. That's one of the main reasons I run Gentoo (especially before dev-haskell/stack emerged upstream a few years ago). > You package each dependency as a separate package. If there's a conflict > between two packages, then... you can't have those two packages > installed together. When that happens, you alert upstream, and try to > convince them to be more lenient with their dependencies (again, nothing > Haskell-specific here). Sometimes that involves code changes, but often > it's just an edit to the cabal file. Many people follow either semver or > the PVP (https://pvp.haskell.org/) which keeps things from getting too > far out of control. I'd say the Haskell-specific thing is the presence of stackage LTS releases that people tend to stick to. For instance, beam-postgres disappeared in recent LTSes, so some projects of mine are stuck on older LTSes (adding that to extra-deps was a pain for reasons I don't remember at the moment), while the others can happily use the new ones. Libraries incompatibilities are just a matter of time in this case. Sure, hacking on .cabal/package.yaml is one way to solve this, but I wasn't sure it's reasonably robust in the long run. Anyway, thanks for your feedback. This probably means I should stop thinking about the general case and maybe start playing around with packaging stuff, and then seeing where it breaks. > If upstream absolutely insists on minor-version dependencies, then you > either tolerate it conflicting with everything else, or leave it out of > the tree. You probably shouldn't even be packaging a library whose API > is distinguishable across minor releases. That's not a matter of just the API per se. Even the library file name encodes its deps in its name (if I understand correctly, that's the hash in libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so for example). Personally I just find it hard to reason about this sort of dependencies management. But, again, I should probably avoid trying that and just jump head first to packaging. > I don't see anything fundamentally different here > between Haskell (or Go, or...) Dunno much about Go and I don't have a single Go package locally to check. Do they do static or dynamic linking with the deps, for instance? What's the language model wrt API and linking? > and C. More stable API (and ABI). -- Georg Rudoy
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, Apr 20, 2020 at 03:23:15PM -0400, Michael Orlitzky wrote: > > Are you volunteering to do the work to package go packages? The people > > doing the work generally get to decide how that work gets done, and which > > approach they would like to take. The upstream situation makes it very > > labour-intensive to do the work in a the way you are proposing (many > > packages would end up with hundreds to thousands of packages in the tree). > > Separating everything out in to separate packages will just increase the > > maintenance load exponentially, with no gains as go upstreams version lock > > all their dependencies. > > > > I'm volunteering to work on one or two small Go packages. Can I convert > the eclass to use dynamic linking? Can I start replacing your packages > with my own if I need them as dependencies? I suspect not, and that's > one of many reasons why "having things in ::gentoo does not affect > anyone who does not use them" is bullshit. As one of the maintainers of the go-module eclass, I'm all ears, but keep a couple of things in mind. First, I have yet to see an upstream go-based build system that uses dynamic linking for go libraries. No one does it. they all statically link everything. This alone probably means you'll have to patch every upstream build system you find. Another issue is the sheer number of dependencies that a single go package would pull into the tree. For example, dev-vcs/cli-0.6.3, which looks like a small enough package, has 65 dependencies. sys-apps/kubernetes-1.18.2, a bigger package for sure, has 246. So, the worst case you are looking at here is over 300 dependencies, and this is just for two packages. The only way this number would come down is if these packages happened to share exact dependencies since you can't really unlock the versions. and, yes, gccgo is out there, but no one writes for it. I have yet to see an upstream that supports using it. So, if you go that route, you are looking at patching build systems. Your proposal seems to completely go against how the go ecosystem operates, but if you can come up with a proof-of-concept for how it would work without forcing a lot of busy work on us that would never get accepted upstream, I'll take a look. William
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 4:19 PM, Patrick McLean wrote: > > My co-workers are not the only ones adding/maintaining go packages in the > tree, please do not single out any groups, and let's all work to make Gentoo > the best it can be. > Everyone else is just using the eclass that your coworkers defended and committed the last time we did this. We're not in this together and you sound like a COVID commercial from a billionaire that wants me to go back to work. You're in this for you, and everything you do for you makes things worse for me. [0] Sony Interactive Entertainment
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 8:27 PM, Rich Freeman wrote: > IMO it isn't really worth worrying about, because right now the main > limitation seems to be a lack of people working on projects, not 25 > devs who each want to re-implement go their own way... This is another reason I think is so important the overlays in Gentoo. ::gentoo overlay can be the most stricter one. It is a fact that is more feasible to deliver software in overlays as already happen (for example gitlab, science stuff, ...). But should ::gentoo be confined to GNU, Linux and other OS base stuff? Lets look into a specific case for a distro where everything should be packaged and placed in an universal repository (crazy debian): https://packages.debian.org/buster/snapd There are very radical package pattern people there and looking into snapd we can see that upstream just regarded the package integration, bundling all necessary dependencies into it. So, even there, we can't find all the required go dependencies packaged... Actually, the dependencies are only those that undoubtedly could appear on ::gentoo. IMHO, there are many software that doesn't need to be in a ebuild, but the base pieces such as go, snapd, docker-ce, docker engine, are some examples of go tools that we need to have available in ::gentoo. The same happens for other platforms such as those mentioned in the subject of this email. In conclusion, I think that all the trouble about licenses and security will be always a growing challenge and a distro should adapt their tools to allow software being available in a better way than upstream provided. I think that the point here is about: - how to bring the software to an OS - how to manage the software in a better way - share knowledge and magnetize the community so Gentoo can grow and show how is so useful helping to deliver better software I'm very pleased for Gentoo! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 4:21 PM, Georg Rudoy wrote: > вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky : >> But please quit looking to Go as an example of anything >> anyone should be doing. > > On a somewhat related note, I'd like to take this chance to ask about > packaging haskell software, which has somewhat similar issues: > > ... > 3. What is major is the following. Let's say two executables A and B > depend on libfoo:1 and libfoo:2 respectively, and depend on the same > version of libbar. libbar itself depends on libfoo (and supports both > versions), but libbar built with libfoo:1 is incompatible with libbar > built with libfoo:2. Loosely speaking, the slot of a library is > defined by all its dependencies' _versions_. > > Of all these, (3) is quite major, as it leads to exponential explosion > of the slots count. Otherwise, one might choose to carefully curate > the library versions, ensuring that no such situation arises, but this > approach is neither feasible nor possible at all for sufficiently > large packages base. There's nothing Haskell-specific here, is there? Except that Haskell as a research language tends to inspire more "fire and forget" software. (And Haskell works better in Gentoo than anywhere else, in my opinion.) You package each dependency as a separate package. If there's a conflict between two packages, then... you can't have those two packages installed together. When that happens, you alert upstream, and try to convince them to be more lenient with their dependencies (again, nothing Haskell-specific here). Sometimes that involves code changes, but often it's just an edit to the cabal file. Many people follow either semver or the PVP (https://pvp.haskell.org/) which keeps things from getting too far out of control. If upstream absolutely insists on minor-version dependencies, then you either tolerate it conflicting with everything else, or leave it out of the tree. You probably shouldn't even be packaging a library whose API is distinguishable across minor releases. Software engineering is a fractal. Curating APIs and dependencies is as much a part of it as what sorting algorithms you choose. These are all old problems with known solutions (sonames, semver, etc.) and software isn't magically high-quality because it's written in a language that came our last week. So aside from the "What's Gentoo?" that's going to be more common among Haskell upstreams, I don't see anything fundamentally different here between Haskell (or Go, or...) and C. We should be helping to make upstream software more good, and then packaging it. (It's OK to hack the cabal file while the bug report is open.)
[gentoo-portage-dev] [PATCH] Import portage.util.netlink.RtNetlink in global scope
Bug: https://bugs.gentoo.org/718578 Signed-off-by: Mike Gilbert --- lib/portage/process.py | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/portage/process.py b/lib/portage/process.py index 590116890..79052b608 100644 --- a/lib/portage/process.py +++ b/lib/portage/process.py @@ -27,6 +27,13 @@ from portage.const import BASH_BINARY, SANDBOX_BINARY, FAKEROOT_BINARY from portage.exception import CommandNotFound from portage.util._ctypes import find_library, LoadLibrary, ctypes +try: + from portage.util.netlink import RtNetlink +except ImportError: + if platform.system() == "Linux": + raise + RtNetlink = None + try: import resource max_fd_limit = resource.getrlimit(resource.RLIMIT_NOFILE)[0] @@ -504,8 +511,8 @@ def _configure_loopback_interface(): # Bug: https://bugs.gentoo.org/690758 # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13 - # Avoid importing this module on systems that may not support netlink sockets. - from portage.util.netlink import RtNetlink + if RtNetlink is None: + return try: with RtNetlink() as rtnl: -- 2.26.1
Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
On Mon, Apr 20, 2020 at 5:14 AM Marek Szuba wrote: > > On 2020-04-20 06:13, Joonas Niilola wrote: > > > He has been on devaway for a while. > > > > I would've much rather seen the differences between -r0 -r1 ebuilds to > > focus on what is actually done there. Not that I have any say what will > > be done in the end, but it's easier for the eyes... > > Indeed, that is a bit of a problem with revbumps. That said, jer did > update the ebuilds today (jer: thank you!) so no list review will be > required after all... > > OpenCL status update: looks like we are good to go, I'll run some tests > to confirm that there are no obvious issues with the deptree and > assuming there aren't, will unleash the whole thing (by which I mean > "post the news item and unmask the updated loader packages") on the > unsuspecting public this weekend. Great! Thank you so much for your work on this.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky : > But please quit looking to Go as an example of anything > anyone should be doing. On a somewhat related note, I'd like to take this chance to ask about packaging haskell software, which has somewhat similar issues: 1. Two different executables might depend on different versions of a library. This is, of course, solvable via slots, so this is minor (but, looking at a random sample of `dev-haskell/`, most of libs there aren't slotted). 2. The dependency trees are pretty big and wide. A simple project of mine depends on a hundred or two of dependencies on average, and the union of all deps of all the projects I do is probably closer to a thousand. Again, this is minor, just bear in mind the corresponding ebuilds tree size increase. 3. What is major is the following. Let's say two executables A and B depend on libfoo:1 and libfoo:2 respectively, and depend on the same version of libbar. libbar itself depends on libfoo (and supports both versions), but libbar built with libfoo:1 is incompatible with libbar built with libfoo:2. Loosely speaking, the slot of a library is defined by all its dependencies' _versions_. Of all these, (3) is quite major, as it leads to exponential explosion of the slots count. Otherwise, one might choose to carefully curate the library versions, ensuring that no such situation arises, but this approach is neither feasible nor possible at all for sufficiently large packages base. In practice, outside of Gentoo/system PM issues, this does not pose a problem since each executable is built in an isolated sandbox and links statically to its dependencies, so different executables can happily be deployed alongside each other even if they have incompatible dependencies. But looks like Gentoo's approach to haskell is to use dynamic linking and expose the dependencies to the package manager (which I sure agree is the right thing to do), so what should be right the solution here? -- Georg Rudoy
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, 20 Apr 2020 15:23:15 -0400 Michael Orlitzky wrote: > On 4/20/20 2:58 PM, Patrick McLean wrote: > >> > >> You keep saying that, but the fact that dev-go/* is filled with trash > >> that has your name on it prevents anyone else from doing a better job. > >> > > Ad-hominen attacks are unwarranted, please refrain from them. I challenge > > you to find *anything* in dev-go/* with my name on it. > > You quoted me one sentence prior saying that it's the Go ebuilds that > are trash and not anyone personally. But OK, I should have said "Sony > Interactive Entertainment" there instead of "you." My co-workers are not the only ones adding/maintaining go packages in the tree, please do not single out any groups, and let's all work to make Gentoo the best it can be. > > > Are you volunteering to do the work to package go packages? The people > > doing the work generally get to decide how that work gets done, and which > > approach they would like to take. The upstream situation makes it very > > labour-intensive to do the work in a the way you are proposing (many > > packages would end up with hundreds to thousands of packages in the tree). > > Separating everything out in to separate packages will just increase the > > maintenance load exponentially, with no gains as go upstreams version lock > > all their dependencies. > > > > I'm volunteering to work on one or two small Go packages. Can I convert > the eclass to use dynamic linking? Can I start replacing your packages > with my own if I need them as dependencies? I suspect not, and that's > one of many reasons why "having things in ::gentoo does not affect > anyone who does not use them" is bullshit. > Please do not make backward-incompatible changes to existing eclasses. If you would like to make a new go eclasss (say go-dynamic.eclass) then go ahead, I am certainly not going to stop you. As was said elsewhere in the thread, there is no policy against having a second version of a package in the tree. If the second version is truly better, then the other packages can be moved over to depending on it instead, and the original package can be moved or last-rited. The current method of packaging go packages tries to strike a balance between maintainability, following upstream, and something that is compatible with ebuilds. If you have a better way to do things, we are not going to block you from trying, but we are also not going to necessarily adopt it if working with it would be orders of magnitude more work. We all have limited time to work on Gentoo stuff.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, Apr 20, 2020 at 2:07 PM Michael Orlitzky wrote: > > On 4/20/20 1:31 PM, Patrick McLean wrote: > >> Simply having things in ::gentoo does not affect anyone who does not > use them. > > > > You keep saying that, but the fact that dev-go/* is filled with trash > that has your name on it prevents anyone else from doing a better job. > As far as I'm aware Gentoo policy does not prevent somebody from re-implementing a package that is already in Gentoo. Obviously it could get pretty confusing if that happened. IMO it isn't really worth worrying about, because right now the main limitation seems to be a lack of people working on projects, not 25 devs who each want to re-implement go their own way... -- Rich
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 2:58 PM, Patrick McLean wrote: >> >> You keep saying that, but the fact that dev-go/* is filled with trash >> that has your name on it prevents anyone else from doing a better job. >> > Ad-hominen attacks are unwarranted, please refrain from them. I challenge you > to find *anything* in dev-go/* with my name on it. You quoted me one sentence prior saying that it's the Go ebuilds that are trash and not anyone personally. But OK, I should have said "Sony Interactive Entertainment" there instead of "you." > Are you volunteering to do the work to package go packages? The people doing > the work generally get to decide how that work gets done, and which approach > they would like to take. The upstream situation makes it very > labour-intensive to do the work in a the way you are proposing (many packages > would end up with hundreds to thousands of packages in the tree). Separating > everything out in to separate packages will just increase the maintenance > load exponentially, with no gains as go upstreams version lock all their > dependencies. > I'm volunteering to work on one or two small Go packages. Can I convert the eclass to use dynamic linking? Can I start replacing your packages with my own if I need them as dependencies? I suspect not, and that's one of many reasons why "having things in ::gentoo does not affect anyone who does not use them" is bullshit.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Mon, 20 Apr 2020 14:07:01 -0400 Michael Orlitzky wrote: > On 4/20/20 1:31 PM, Patrick McLean wrote: > >> Simply having things in ::gentoo does not affect anyone who does not > use them. > > > > You keep saying that, but the fact that dev-go/* is filled with trash > that has your name on it prevents anyone else from doing a better job. > Ad-hominen attacks are unwarranted, please refrain from them. I challenge you to find *anything* in dev-go/* with my name on it. Are you volunteering to do the work to package go packages? The people doing the work generally get to decide how that work gets done, and which approach they would like to take. The upstream situation makes it very labour-intensive to do the work in a the way you are proposing (many packages would end up with hundreds to thousands of packages in the tree). Separating everything out in to separate packages will just increase the maintenance load exponentially, with no gains as go upstreams version lock all their dependencies.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On 4/20/20 1:31 PM, Patrick McLean wrote: >> Simply having things in ::gentoo does not affect anyone who does not use them. > You keep saying that, but the fact that dev-go/* is filled with trash that has your name on it prevents anyone else from doing a better job.
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Sun, 19 Apr 2020 11:37:15 -0400 Michael Orlitzky wrote: > On 4/19/20 10:55 AM, Samuel Bernardo wrote: > > > > Taking into account the network sandbox requirement, sbt.eclass needs to > > download all dependencies with some approach like EGO_SUM implementation > > in go-module.eclass[1]. > > > > EGO_SUM is not a legitimate approach to packaging. You have to create > packages for each package. I know, it sounds crazy when you say it. > A lot of upstreams are doing things that are not very friendly to packagers. Sometimes we have to take different approaches to packaging to make it feasible to package these very popular programs. Having 300+ packages in the tree with a single version that are only used as a dependency by a single package is not the way to a well-maintained tree. Sometimes things like EGO_SUM are the only feasible way to do things given we all have limited time to work on Gentoo, and we want these packages in the tree because many people find them useful. If you object to the way these are handled, you are free to mask dev-lang/go on your system to endure that you do not get anything written in go installed. Simply having things in ::gentoo does not affect anyone who does not use them. --
[gentoo-dev] Re: [PATCH] meson.eclass: export NM and READELF variables
Nice. Thanks!
[gentoo-dev] Last rites: dev-python/dexml
# Michał Górny (2020-04-20) # Stuck on Python 3.6. Last release in 2012. No revdeps. # Removal in 30 days. Bug #718646. dev-python/dexml -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-python/demjson
# Michał Górny (2020-04-20) # Stuck on Python 3.6. Relies on 2to3. Last release in 2015. # No revdeps. # Removal in 30 days. Bug #718638. dev-python/demjson -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] meson.eclass: export NM and READELF variables
On Mon, 2020-04-20 at 11:18 -0400, Mike Gilbert wrote:
> These are used by the symbolextractor.py script in meson.
>
> Closes: https://bugs.gentoo.org/717720
> Signed-off-by: Mike Gilbert
> ---
> eclass/meson.eclass | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2bd1dc017609..81cfa7c38fc6 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -261,6 +261,11 @@ meson_src_configure() {
> "${BUILD_DIR}"
> )
>
> + # Used by symbolextractor.py
> + # https://bugs.gentoo.org/717720
> + tc-export NM
> + tc-getPROG READELF readelf >/dev/null
> +
> # https://bugs.gentoo.org/625396
> python_export_utf8_locale
>
+1
Thanks for adding this, LGTM.
[gentoo-dev] [PATCH] meson.eclass: export NM and READELF variables
These are used by the symbolextractor.py script in meson.
Closes: https://bugs.gentoo.org/717720
Signed-off-by: Mike Gilbert
---
eclass/meson.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2bd1dc017609..81cfa7c38fc6 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -261,6 +261,11 @@ meson_src_configure() {
"${BUILD_DIR}"
)
+ # Used by symbolextractor.py
+ # https://bugs.gentoo.org/717720
+ tc-export NM
+ tc-getPROG READELF readelf >/dev/null
+
# https://bugs.gentoo.org/625396
python_export_utf8_locale
--
2.26.1
[gentoo-dev] Last rites: dev-python/flask-bootstrap
# Louis Sautier (2020-04-20) # No revdeps, no release in 3 years, doesn't support Bootstrap 4. # Removal in 30 days. dev-python/flask-bootstrap signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] rpm.eclass: use BDEPEND for EAPI 7
Hi, merged, thanks: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=606c745e611c216df15568bc8655e2781dc11095 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] rpm.eclass: use BDEPEND for EAPI 7
On Sat, Apr 18, 2020 at 11:15 AM David Michael wrote:
> The build system's rpm2tar command is executed during unpack, so it
> must be install in /.
>
> Signed-off-by: David Michael
> ---
>
> This patch fixes failures like this:
> >>> Unpacking source...
> >>> Unpacking urw-fonts-2.4-9.fc13.src.rpm to
> /var/tmp/portage/media-fonts/urw-fonts-2.4.9/work
> /var/tmp/portage/media-fonts/urw-fonts-2.4.9/temp/environment: line 850:
> rpm2tar: command not found
>
> eclass/rpm.eclass | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/rpm.eclass b/eclass/rpm.eclass
> index 3a29c7e9f76..d27f0a386c7 100644
> --- a/eclass/rpm.eclass
> +++ b/eclass/rpm.eclass
> @@ -8,7 +8,10 @@
>
> inherit estack eutils
>
> -DEPEND=">=app-arch/rpm2targz-9.0.0.3g"
> +case "${EAPI:-0}" in
> + [0-6]) DEPEND=">=app-arch/rpm2targz-9.0.0.3g" ;;
> + *) BDEPEND=">=app-arch/rpm2targz-9.0.0.3g" ;;
> +esac
>
> # @FUNCTION: rpm_unpack
> # @USAGE:
> --
> 2.21.1
Can someone apply this?
Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
On 2020-04-20 06:13, Joonas Niilola wrote: > He has been on devaway for a while. > > I would've much rather seen the differences between -r0 -r1 ebuilds to > focus on what is actually done there. Not that I have any say what will > be done in the end, but it's easier for the eyes... Indeed, that is a bit of a problem with revbumps. That said, jer did update the ebuilds today (jer: thank you!) so no list review will be required after all... OpenCL status update: looks like we are good to go, I'll run some tests to confirm that there are no obvious issues with the deptree and assuming there aren't, will unleash the whole thing (by which I mean "post the news item and unmask the updated loader packages") on the unsuspecting public this weekend. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-python/rst2pdf, media-gfx/svg2rlg
No, not there. I have a branch ready and tested (just literally need to create the PR), but I get your point :) On Mon, 20 Apr 2020 at 19:32, Michał Górny wrote: > On Mon, 2020-04-20 at 19:11 +1000, Andrea Cerisara wrote: > > Hello, > > > > I have a PR ready to go for rst2pdf v0.96 (Bug #716964). > > > > I don't see a PR there, and attachments on that bug can not be used, > as stated in the disclaimer above file attachment form that nobody > reads. > > -- > Best regards, > Michał Górny > > -- ** Think about the environment before printing
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-proxy/mitmproxy
Sam, Let me know if you are experiencing any issues or need assistance. I also want to save this package and can help. Thanks, Viktar On Sun, Apr 19, 2020 at 10:34 PM Sam James wrote: > I’ll try look at this. > > > > On 19 Apr 2020, at 21:05, Michał Górny wrote: > > > > # Michał Górny (2020-04-19) > > # Unmaintained. Stuck on Python 3.6. Needs version bump. > > # Removal in 30 days. Bug #718458. > > net-proxy/mitmproxy > > > > -- > > Best regards, > > Michał Górny > > > > >
Re: [gentoo-dev] Last rites: dev-python/rst2pdf, media-gfx/svg2rlg
On Mon, 2020-04-20 at 19:11 +1000, Andrea Cerisara wrote: > Hello, > > I have a PR ready to go for rst2pdf v0.96 (Bug #716964). > I don't see a PR there, and attachments on that bug can not be used, as stated in the disclaimer above file attachment form that nobody reads. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: dev-python/rst2pdf, media-gfx/svg2rlg
Hello, I have a PR ready to go for rst2pdf v0.96 (Bug #716964). On Mon, 20 Apr 2020 at 17:54, Michał Górny wrote: > # Michał Górny (2020-04-20) > # Unmaintained. Stuck on Python 2. rst2pdf depends on dev-python/pdfrw > # that is dead and broken with py3.7+. svg2rlg is only used by pdfrw. > # Removal in 30 days. Bug #718572. > dev-python/rst2pdf > media-gfx/svg2rlg > > -- > Best regards, > Michał Górny > > -- ** Think about the environment before printing
Re: [gentoo-dev] Last rites: app-admin/ngxtop
On Sun, Apr 19, 2020 at 2:04 PM Michał Górny wrote: > # Michał Górny (2020-04-19) > # Unmaintained. Stuck on Python 3.6. Last upstream activity in 2015. > # Removal in 30 days. Bug #718184. > app-admin/ngxtop > > -- > Best regards, > Michał Górny > > I know it's old, but it works with python 3.8 (thanks to patches by jlec): https://github.com/gentoo/gentoo/pull/15440 Seems like goaccess may be a good alternative too. Tomas
[gentoo-dev] Last rites: media-video/griffith
# Michał Górny (2020-04-20) # Effectively unmaintained. Stuck on Python 2 and pygtk. Last bumped # in 2014. # Removal in 30 days. Bug #708168. media-video/griffith -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-python/rst2pdf, media-gfx/svg2rlg
# Michał Górny (2020-04-20) # Unmaintained. Stuck on Python 2. rst2pdf depends on dev-python/pdfrw # that is dead and broken with py3.7+. svg2rlg is only used by pdfrw. # Removal in 30 days. Bug #718572. dev-python/rst2pdf media-gfx/svg2rlg -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
