[gentoo-dev] Last rites: dev-lua/lua-openssl
# Michał Górny (2020-04-22) # Multiple unresolved vulnerabilities. No reverse dependencies. # Removal in 30 days. Bug #711016. dev-lua/lua-openssl -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News item v2: Python 3.7 to become the default target
On Tue, 2020-04-21 at 13:50 -0500, John Helmert III wrote: > On Tue, Apr 21, 2020 at 07:56:16AM +0200, Michał Górny wrote: > > 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" > > It might be prudent to also show this for python:3.7 in case anyone has > already rebuilt their system with these flags to let them know these > flags are the new defaults and can be removed from their configs. I suppose that makes sense. I've added it locally but won't resubmit v3 for that change ;-). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News item v2: Python 3.7 to become the default target
On Tue, Apr 21, 2020 at 07:56:16AM +0200, Michał Górny wrote: > 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" It might be prudent to also show this for python:3.7 in case anyone has already rebuilt their system with these flags to let them know these flags are the new defaults and can be removed from their configs. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development
On Tue, Apr 21, 2020 at 07:50:13AM +0200, Michał Górny wrote: > 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'. Busy work, to me at least, is work that generates a large amount of overhead compared to the gain it offers the distro and will never be accepted by upstream. > Is doing things right 'busy work' vs taking shortcuts? This depends on what you think "doing things right" or "taking shortcuts" mean. For example, I have had discussions with maintainers who are fine with writing patches to fix issues without reporting the issues upstream. Personally, I disagree with this approach. > 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? This gets into the other issue being discussed on the thread, but I have heard people say that yes you should. All we really need in portage is the base python tools -- the language, maybe pip and maybe setuptools and portage itself, then everything else should be installed via pip. > 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. In general I would say no, but I have run into tests that do not tollerate portage's sandbox, tests that take hours or days to run, or tests that require root privs. We don't force those kinds of tests to be run in src_test. > 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?). In my experience, the security team doesn't write patches to fix vulnerabilities, so what they do wouldn't be any different in this case. > 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. We can talk about theoretical issues in languages all day, but if we are going to do that we also have to talk about how terrible and permissive c is. You can google things like "security in c" and you will find that since it allows you to do exactly what you want, it is a major catastrophe in terms of security, but we accept new applications in c without any questions. Also, what about the nightmare that is php? In short, I don't see any reason to bikeshed about theoretical issues in languages. The way I see Go and Rust specifically is, more and more things are being written in these languages, and if we don't accept them, we will become irrelivent fast. William signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/django-spurl
# Michał Górny (2020-04-21) # Unmaintained. Stuck on Python 3.6. Missing tests. Bad quality # package. No revdeps. # Removal in 30 days. Bug #718744. dev-python/django-spurl -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-python/django-setuptest
# Michał Górny (2020-04-21) # Unmaintained. Last commit in 2016. Upstream bugtracker indicates it # doesn't support current dev-python/django versions. No revdeps. # Removal in 30 days. Bug #718734. dev-python/django-setuptest -- 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/21/20 6:50 AM, Michał Górny wrote: > 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. Looking into an old language (25 years old): php So many security problems... Just a few essential ebuilds exists in ::gentoo and being very well maintained by Gentoo. I think the approach to the new languages have the same requirement. Minimizing the ebuilds to the required ones would allow to minimize the effort. Then we can use an overlay to deliver all other software that would be useful. So the goal in this cases would be to define the right sieve about those libraries and tools that are required to all and that fits in package maintenance procedures, so it could be merged into ::gentoo. But don't forget the tooling available to the overlays development, where another abstraction layer takes place, since it's focused on a specific target and not all community in main ::gentoo. That's why I consider go-module as a very cleaver solution since it gives a hybrid solution connecting immutable delivery model into the mutable reality. The PR present in this subject is related to missing eclass for JVM languages, to define the common procedures to use those languages and available builders. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/django-durationfield
# Michał Górny (2020-04-21) # Django has a native DurationField since 1.8. No revdeps. # Removal in 30 days. Bug #718724. dev-python/django-durationfield -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] */*: downgrade m68k down to ~m68k
On Tue, 21 Apr 2020 08:10:15 +0100 Sergei Trofimovich wrote: > With > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dce3dc0aa1341155a31407122e079632fcd07ca > m68k does not have stable keywords in ::gentoo anymore and > thus becomes ~arch-only Gentoo target. > > """ > */*: downgrade m68k down to ~m68k > m68k and ~m68k trees are inconsistent. Let's drop keywords > down to ~m68k only. Profiles already accept both keywords: > > ACCEPT_KEYWORDS="m68k ~m68k" > """ > > Even basic packages don't have consistent ~m68k keywords. I don't > think stable keywords have any use today. > > I will pass through and un-CC/close all STABLEREQ bugs where m68k > is CCed. Thanks, I think this was inevitable really. I still hope to create a new stage3 but not with sufficient regularity to use as a basis for a stable @system. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpK6ym3Hrlf4.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] News item v2: Python 3.7 to become the default target
On Tue, 2020-04-21 at 08:58 +0200, Ulrich Mueller wrote: > > > > > > On Tue, 21 Apr 2020, Michał Górny wrote: > > 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 > > "should not" should not be duplicate. That's an important point but sure, let's keep one only one only. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] */*: downgrade m68k down to ~m68k
With https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dce3dc0aa1341155a31407122e079632fcd07ca m68k does not have stable keywords in ::gentoo anymore and thus becomes ~arch-only Gentoo target. """ */*: downgrade m68k down to ~m68k m68k and ~m68k trees are inconsistent. Let's drop keywords down to ~m68k only. Profiles already accept both keywords: ACCEPT_KEYWORDS="m68k ~m68k" """ Even basic packages don't have consistent ~m68k keywords. I don't think stable keywords have any use today. I will pass through and un-CC/close all STABLEREQ bugs where m68k is CCed. -- Sergei
Re: [gentoo-dev] News item v2: Python 3.7 to become the default target
> On Tue, 21 Apr 2020, Michał Górny wrote: > 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 "should not" should not be duplicate. signature.asc Description: PGP signature
