[gentoo-dev] Last rites: dev-util/webstorm
# Michał Górny (2019-09-13) # Unmaintained. Last bumped in 2017. Unresolved license issues. # Removal in 30 days. Bug #694274. dev-util/webstorm -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-util/idea-ultimate
# Michał Górny (2019-09-13) # Last bumped in 2017. Newer version fails to fetch. Pending bump. # Unresolved license issues. # Removal in 30 days. Bug #694264. dev-util/idea-ultimate -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules
On Thu, 12 Sep 2019 23:12:52 +0200 Michał Górny wrote: > Since when it is a bug that when you strip debug info, you don't have > debug info? I thought that's precisely what stripping debug info means > but maybe in the special Go world it is different, and debug info is > expected to remain after stripping it. I think the distinction may be because typically, people use external tools to consume debug info, thus, people without said tools aren't disadvantaged by stripping. But when the program itself uses its own debug info as part of its behaviour, it seems more reasonable that you might want to keep those. For instance, if you build a rust binary "without debugging" and "with optimization", you still actually get *some* debugging symbols, just not all of them, and you still get useful backtraces that are vaguely related when a panic happens. But if you point strip at it, panic-backtraces become much less useful. And given the nature of Rust and Go, where tripping a panic is pretty much a "file a bug immediately" situation, it seems silly to have programs having the capacity to print their own backtraces, but also being useless for reporting bugs. ( I need to look into if rust does the right thing if you do split-debugs, but I doubt it, I was under the impression bringing the split debug info back into context is gdb magic ) pgpujAS9Gjbpb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Thu, 12 Sep 2019 17:58:08 -0400 Michael Orlitzky wrote: > What kind of math would convince you that an idea with all "cons" and no > "pros" is bad? Is "upstream tooling doesn't work without static compilation" or "built packages tend to need exact version matching at runtime to work" ( which necessitates massive-scale multi-slotting, where every version of every packaged "thing" has a co-existing slot ) a problem for you? Having the same problem as static-linking in terms of disk use ( all those different parallel versions ), but adding dependency hell to it , and adding compile time overhead (even if those assets were no-op virtuals, portage overhead is still pretty steep) isn't fun. Not to mention reduced opportunities for whole-program optimization. Yes, In general I'm against static linking, and I really dislike this trend. But when upstreams ecosystem is built around it as a core concept, its really hard to buck that trend. pgpBeUWLViaub.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On 9/12/19 11:13 PM, Mike Gilbert wrote: > > I'm really objecting to your suggestion that we abuse an existing > Portage/PMS feature to do something beyond its design. Adding > fictitious runtime dependencies is wrong, and seems like a very lazy > solution. Ok, you're right. > If you want to propose an extension to PMS to handle this situation, > that's something I can support. Portage and the PMS are fine. This junk belongs in an overlay.
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On 9/13/19 5:19 AM, Kent Fredric wrote: > On Thu, 12 Sep 2019 17:58:08 -0400 > Michael Orlitzky wrote: > >> What kind of math would convince you that an idea with all "cons" and no >> "pros" is bad? > > Is "upstream tooling doesn't work without static compilation" or > "built packages tend to need exact version matching at runtime to work" > ( which necessitates massive-scale multi-slotting, where every version > of every packaged "thing" has a co-existing slot ) a problem for you? > I see it as a problem, but not one that has to be my problem. I don't see it as a foregone conclusion that we have to package every piece of software -- no matter how bad -- and distribute it with the OS that I use to do my banking. These languages are badly implemented, and very little of value is written in them. If their developers ever hit 2+ users, I'm sure they'll realize that everyone else was right back in the 1970s, and fix the design. But in the meantime, this stuff belongs in an overlay. Lowering our standards until they match upstream's is antithetical to how a distribution is supposed to improve my life.
[gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
friendly ping for patch review.
On Thu, Sep 12, 2019 at 4:32 AM Manoj Gupta wrote:
>
> LLD is a new linker for LLVM project.
> Add tc-ld-is-lld helper to be able to detect it.
>
> Signed-off-by: Manoj Gupta
> ---
> eclass/toolchain-funcs.eclass | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 7bd90bb4e4a..e358d484417 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -453,6 +453,36 @@ tc-ld-is-gold() {
> return 1
> }
>
> +# @FUNCTION: tc-ld-is-lld
> +# @USAGE: [toolchain prefix]
> +# @DESCRIPTION:
> +# Return true if the current linker is set to lld.
> +tc-ld-is-lld() {
> + local out
> +
> + # First check the linker directly.
> + out=$($(tc-getLD "$@") --version 2>&1)
> + if [[ ${out} == *"LLD"* ]] ; then
> + return 0
> + fi
> +
> + # Then see if they're selecting lld via compiler flags.
> + # Note: We're assuming they're using LDFLAGS to hold the
> + # options and not CFLAGS/CXXFLAGS.
> + local base="${T}/test-tc-lld"
> + cat <<-EOF > "${base}.c"
> + int main() { return 0; }
> + EOF
> + out=$($(tc-getCC "$@") ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} -Wl,--version
> "${base}.c" -o "${base}" 2>&1)
> + rm -f "${base}"*
> + if [[ ${out} == *"LLD"* ]] ; then
> + return 0
> + fi
> +
> + # No lld here!
> + return 1
> +}
> +
> # @FUNCTION: tc-ld-disable-gold
> # @USAGE: [toolchain prefix]
> # @DESCRIPTION:
> --
> 2.23.0.162.g0b9fbb3734-goog
>
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
> On Fri, 13 Sep 2019, Manoj Gupta wrote:
>> LLD is a new linker for LLVM project.
>> Add tc-ld-is-lld helper to be able to detect it.
>>
>> Signed-off-by: Manoj Gupta
>> ---
>> eclass/toolchain-funcs.eclass | 30 ++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
>> index 7bd90bb4e4a..e358d484417 100644
>> --- a/eclass/toolchain-funcs.eclass
>> +++ b/eclass/toolchain-funcs.eclass
>> @@ -453,6 +453,36 @@ tc-ld-is-gold() {
>> return 1
>> }
>>
>> +# @FUNCTION: tc-ld-is-lld
>> +# @USAGE: [toolchain prefix]
>> +# @DESCRIPTION:
>> +# Return true if the current linker is set to lld.
>> +tc-ld-is-lld() {
>> + local out
>> +
>> + # First check the linker directly.
>> + out=$($(tc-getLD "$@") --version 2>&1)
Why 2>&1 here, and not 2>/dev/null?
>> + if [[ ${out} == *"LLD"* ]] ; then
>> + return 0
>> + fi
>> +
>> + # Then see if they're selecting lld via compiler flags.
>> + # Note: We're assuming they're using LDFLAGS to hold the
>> + # options and not CFLAGS/CXXFLAGS.
>> + local base="${T}/test-tc-lld"
>> + cat <<-EOF > "${base}.c"
>> + int main() { return 0; }
>> + EOF
>> + out=$($(tc-getCC "$@") ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
>> -Wl,--version "${base}.c" -o "${base}" 2>&1)
Ditto.
>> + rm -f "${base}"*
>> + if [[ ${out} == *"LLD"* ]] ; then
>> + return 0
>> + fi
>> +
>> + # No lld here!
>> + return 1
The previous 6 lines could be shortened to one:
[[ ${out} == *"LLD"* ]]
>> +}
>> +
>> # @FUNCTION: tc-ld-disable-gold
>> # @USAGE: [toolchain prefix]
>> # @DESCRIPTION:
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
On Fri, Sep 13, 2019 at 7:32 AM Ulrich Mueller wrote:
>
> > On Fri, 13 Sep 2019, Manoj Gupta wrote:
>
> >> LLD is a new linker for LLVM project.
> >> Add tc-ld-is-lld helper to be able to detect it.
> >>
> >> Signed-off-by: Manoj Gupta
> >> ---
> >> eclass/toolchain-funcs.eclass | 30 ++
> >> 1 file changed, 30 insertions(+)
> >>
> >> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> >> index 7bd90bb4e4a..e358d484417 100644
> >> --- a/eclass/toolchain-funcs.eclass
> >> +++ b/eclass/toolchain-funcs.eclass
> >> @@ -453,6 +453,36 @@ tc-ld-is-gold() {
> >> return 1
> >> }
> >>
> >> +# @FUNCTION: tc-ld-is-lld
> >> +# @USAGE: [toolchain prefix]
> >> +# @DESCRIPTION:
> >> +# Return true if the current linker is set to lld.
> >> +tc-ld-is-lld() {
> >> + local out
> >> +
> >> + # First check the linker directly.
> >> + out=$($(tc-getLD "$@") --version 2>&1)
>
> Why 2>&1 here, and not 2>/dev/null?
>
> >> + if [[ ${out} == *"LLD"* ]] ; then
> >> + return 0
> >> + fi
> >> +
> >> + # Then see if they're selecting lld via compiler flags.
> >> + # Note: We're assuming they're using LDFLAGS to hold the
> >> + # options and not CFLAGS/CXXFLAGS.
> >> + local base="${T}/test-tc-lld"
> >> + cat <<-EOF > "${base}.c"
> >> + int main() { return 0; }
> >> + EOF
> >> + out=$($(tc-getCC "$@") ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
> >> -Wl,--version "${base}.c" -o "${base}" 2>&1)
>
> Ditto.
>
> >> + rm -f "${base}"*
> >> + if [[ ${out} == *"LLD"* ]] ; then
> >> + return 0
> >> + fi
> >> +
> >> + # No lld here!
> >> + return 1
>
> The previous 6 lines could be shortened to one:
> [[ ${out} == *"LLD"* ]]
Thanks for the review. I did it this way to make this an exact copy of
tc-ld-is-gold function above it except the LLD checks.
Should I also change the tc-ld-is-gold function?
>
> >> +}
> >> +
> >> # @FUNCTION: tc-ld-disable-gold
> >> # @USAGE: [toolchain prefix]
> >> # @DESCRIPTION:
[gentoo-dev] Packages up for grabs due to cardoe being MIA
Hello, The following packages are now up for grabs since Undertakers have not received any reply nor seen any activity from cardoe: dev-util/crash [b,v] media-libs/libhdhomerun [v] media-tv/ivtv-utils net-misc/dhcpd-pools [b] net-misc/x11-ssh-askpass sys-auth/sakcl [b] sys-firmware/ivtv-firmware x11-misc/vdpauinfo [v] x11-themes/echo-icon-theme The packages marked [v] have version bump requests open. The packages marked [b] have other bugs reported. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
> On Fri, 13 Sep 2019, Manoj Gupta wrote: > Thanks for the review. I did it this way to make this an exact copy of > tc-ld-is-gold function above it except the LLD checks. > Should I also change the tc-ld-is-gold function? Good question. Presumably the eclass maintainers should have the last word on this. Ulrich signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs: dev-libs/tntnet, media-tv/w_scan, www-misc/xxv
Hi, The following packages are up for grabs due to hd_brummy being close to inactivity retirement: dev-libs/tntnet media-tv/w_scan www-misc/xxv tntnet seems to have 3 different build failures reported, while xxv has a QA issue reported. They all need an EAPI bump. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Package up for grabs: dev-db/clickhouse
Hi, The following package is up for grabs due to civil being close to inactivity retirement: dev-db/clickhouse This seems to be a monster of a package with multiple bugs reported. There's also a pull request open for it. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due to dolsen's inactivity (mostly dev-python/*, buildbot)
Hi, The following packages are in need of a new maintainer due to dolsen's prolonged absence: app-metrics/buildbot-prometheus dev-python/automat [t] dev-python/constantly dev-python/m2r dev-python/pyjade dev-python/pytest-fixture-config [t] dev-python/pytest-shutil [b] dev-python/pytest-virtualenv dev-python/sdnotify [b] dev-python/setuptools_trial dev-python/shutilwhich dev-python/sphinx-jinja dev-python/treq dev-python/txtorcon dev-util/buildbot [t] dev-util/buildbot-console-view dev-util/buildbot-grid-view dev-util/buildbot-pkg dev-util/buildbot-waterfall-view dev-util/buildbot-worker [t] dev-util/buildbot-wsgi-dashboards dev-util/buildbot-www net-misc/crossbar [t] Packages marked [t] have test failures reported. Packages marked [b] have other bugs reported. At least buildbot needs a version bump, and has a stablereq open (but not started). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due to cardoe being MIA
On 9/13/19 9:44 AM, Michał Górny wrote: Hello, The following packages are now up for grabs since Undertakers have not received any reply nor seen any activity from cardoe: dev-util/crash [b,v] media-libs/libhdhomerun [v] I use media-libs/libhdhomerun with mythtv. I can update and test this device so i'll grab it. I submitted a PR to version bump media-tv/mythtv recently. it is still pending... media-tv/ivtv-utils Mythtv can use this too, but I do not have one to test on. net-misc/dhcpd-pools [b] net-misc/x11-ssh-askpass sys-auth/sakcl [b] sys-firmware/ivtv-firmware This looks like part of media-tv/ivtv-utils x11-misc/vdpauinfo [v] I use this with mythtv and can test it. x11-themes/echo-icon-theme The packages marked [v] have version bump requests open. The packages marked [b] have other bugs reported.
[gentoo-dev] Packages up for grabs: app-misc/ddcutil, media-libs/opencollada, media-sound/tuxguitar, sys-apps/qdirstat
Hi, The following packages are up for grabs due to prolonged inactivity of dracwyrm: app-misc/ddcutil media-libs/opencollada media-sound/tuxguitar sys-apps/qdirstat All of the listed packages have open bugs. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 0/1] Introduce new eclass to handle go modules (round 2)
This version shows both methods of handling vendor tarballs mentioned on the previous thread. The first method, while it removes the src_prepare function, forces a maintainer to re-pack a new vendor tarball for every release. The second method allows a maintainer to decide when a new vendor tarball is needed. An ebuild using this would look the same as in the previous round, so I'm not including any examples. William Hubbs (1): go-module.eclass: introduce new eclass to handle go modules eclass/go-module.eclass | 100 1 file changed, 100 insertions(+) create mode 100644 eclass/go-module.eclass -- 2.21.0
[gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 100
1 file changed, 100 insertions(+)
create mode 100644 eclass/go-module.eclass
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
new file mode 100644
index 000..501e334b23f
--- /dev/null
+++ b/eclass/go-module.eclass
@@ -0,0 +1,100 @@
+# Copyright 2019 gentoo authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-module.eclass
+# @MAINTAINER:
+# William Hubbs
+# @SUPPORTED_EAPIS: 7
+# @BLURB: basic eclass for building software written in the go
+# programming language that uses go modules.
+# @DESCRIPTION:
+# This eclass provides some basic things needed by all software
+# written in the go programming language that uses go modules.
+#
+# You will know the software you are packaging uses modules because
+# it will have files named go.sum and go.mod in its top-level source
+# directory. If it does not have these files, use the golang-* eclasses.
+#
+# If the software you are packaging uses modules, the next question is
+# whether it has a directory named "vendor" at the top-level of the source
tree.
+#
+# If it doesn't, you need to create a tarball of what would be in the
+# vendor directory and mirror it locally.
+# If foo-1.0 is the name of your project and you have the tarball for it
+# in your current directory, this is done with the following commands:
+#
+# @CODE:
+#
+# tar -xf foo-1.0.tar.gz
+# cd foo-1.0
+# go mod vendor
+# cd ..
+# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
+#
+# @CODE:
+
+# If we uncomment src_prepare below, the last two lines in the above
+# code block are reduced to one:
+#
+# @CODE:
+#
+# tar -acf foo-1.0-vendor.tar.gz vendor
+#
+# @CODE:
+
+case ${EAPI:-0} in
+ 7) ;;
+ *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
+esac
+
+if [[ -z ${_GO_MODULE} ]]; then
+
+_GO_MODULE=1
+
+BDEPEND=">=dev-lang/go-1.12"
+
+# The following go flags should be used for all go builds.
+# -mod=vendor stopps downloading of dependencies from the internet.
+# -v prints the names of packages as they are compiled
+# -x prints commands as they are executed
+export GOFLAGS="-mod=vendor -v -x"
+
+# Do not complain about CFLAGS etc since go projects do not use them.
+QA_FLAGS_IGNORED='.*'
+
+# Go packages should not be stripped with strip(1).
+RESTRICT="strip"
+
+# EXPORT_FUNCTIONS src_prepare
+#
+# @FUNCTION: go-module_src_prepare
+# @DESCRIPTION:
+# Run a default src_prepare then move our provided vendor directory to
+# the appropriate spot if upstream doesn't provide a vendor directory.
+#
+# This is commented out because I want to see where the discussion on
+# the ml leads.
+# Commenting it out and following the above instructions means that you
+# are forced to manually re-tar the vendored dependencies for every
+# version bump.
+# Using the previous method, it would be possible to decide if you need
+# to do this by comparing the contents of go.mod in the previous and new
+# version.
+# go-module_src_prepare() {
+# default
+# # If upstream vendors the dependencies and we provide a vendor
+# # tarball, generate a qa warning.
+# [[ -d vendor ]] && [[ -d ../vendor ]] &&
+# eqawarn "This package's upstream source includes a vendor
+# eqawarn "directory and the maintainer provides a vendor
tarball."
+# eqawarn "Please report this on https://bugs.gentoo.org";
+# # Use the upstream provided vendor directory if it exists.
+# [[ -d vendor ]] && return
+# # If we are not providing a mirror of a vendor directory we created
+# # manually, return since there may be nothing to vendor.
+# [[ ! -d ../vendor ]] && return
+# # At this point, we know we are providing a vendor mirror.
+# mv ../vendor . || die "Unable to move ../vendor directory"
+# }
+
+fi
--
2.21.0
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
I know about the typos on the eqawarns, they need to be a block if, so I'll take care of that before I commit. Wililam signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On 9/12/19 1:45 PM, Alec Warner wrote: > > Er, I'm fairly sure computer *science* has not conclusively proven that > dynamic binaries are somehow superior to static binaries. > Please don't make me work this hard ever again. The principal of modularity in software design goes back to at least 1970. In Parnas's famous 1971 paper[0], he cites "Designing Systems Programs" by Gauthier and Pont from 1970, and suggests that the idea goes back even further, to at least 1967 (Balzer & Mealy). On the very first page of Parnas' paper, he says The major advancement in the area of modular programming has been the development of coding techniques and assemblers which (1) allow one module to be written with little knowledge of the code in another module, and (2) allow modules to be reassembled and replaced without reassembly of the whole system. The second item has a clear interpretation in terms of static/dynamic linking. Parnas concludes that ...one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. If you statically link to a library, then none of its implementation details are hidden from you -- you need to "reassemble" your program whenever the library changes. If we jump way forward to 1979, the SICP[1] is basically a thousand-page treatise on abstraction. But not only at one level of computation: Well-designed computational systems, like well-designed automobiles or nuclear reactors, are designed in a modular manner, so that the parts can be constructed, replaced, and debugged separately. "Replaced" here is of course what I want to draw your attention to. But also on the fact that abstraction and modularity don't just apply at one level of software design and engineering -- it's a fractal. At the lowest levels, we abstract machine code to assembler, assembler to low-level languages, low-level languages to high-level languages, high-level languages to functions and procedures, functions and procedures to libraries, libraries to services, and services to distributed APIs. The same principles that apply to a collection of functions (a program) also apply to a collection of programs (an operating system). The rule "don't copy and paste code" applies to your linker just as much as it applies to the first program you wrote in CS101, and for the same reasons. As you commented on IRC, the cost in terms of man-power is that someone's workload jumps from O(n) to O(m*n), because you have to duplicate everything you do for every statically-linked dependency. And you can find as much theory as you like on software modularity in papers from the 1970s and 1980s, but the benefits are not only theoretical. There's a mountain of empirical data that supports the theory. Some choice quotes [2][3]: Poorly placed dependencies, especially those that link otherwise independent modules, may result in a cascade of unwanted and hard-to- detect indirect interactions. Our results suggest that purposeful actions to reduce such "rogue dependencies" can be effective (the redesign of Mozilla reduced propagation cost by over 80%). Our results confirm the existence of a relationship between component modularity and design evolution that is both statistically significant and large in magnitude... Tightly-coupled components are... less adaptable via the processes of exclusion or substitution; they are more likely to experience "surprise" dependency additions unrelated to new functionality, implying that they demand greater maintenance efforts; and they are harder to augment, in that the mix of new components is more modular than the legacy design. The only difference between static linking and copy/pasting chunks of code around is in who pays the price. If the programmer copies & pastes code into his own program, he will eventually have to deal with the mess. On the other hand, it he forces his program to be statically linked, then it is the end user who is harmed by his decision. In any case, the theory says that modularity is superior, and the empirical data confirm it. The fact that you won't find a paper saying "dynamic linking is better than static linking" is somewhat beside the point, and only muddies the water. Linking is just one specific instance of a problem that was solved 40 years ago. [0] https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf [1] https://web.mit.edu/alexmv/6.037/sicp.pdf [2] https://pubsonline.informs.org/doi/10.1287/mnsc.1060.0552 [3] http://www.hbs.edu/research/pdf/08-038.pdf
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
On Fri, 13 Sep 2019 07:11:03 -0700 Manoj Gupta wrote: > friendly ping for patch review. Pushed your patch as-is as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=463ec5b25ac36933127e726c553ad83994017aa1 Thank you! -- Sergei
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
On Fri, 13 Sep 2019 16:53:34 +0200 Ulrich Mueller wrote: > > On Fri, 13 Sep 2019, Manoj Gupta wrote: > > > Thanks for the review. I did it this way to make this an exact copy of > > tc-ld-is-gold function above it except the LLD checks. > > Should I also change the tc-ld-is-gold function? > > Good question. Presumably the eclass maintainers should have the last > word on this. I've pushed the change as-is. You can send follow-up patch. Or I'll get to to it later. -- Sergei
Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Add tc-ld-is-lld helper.
On Fri, Sep 13, 2019 at 11:45 AM Sergei Trofimovich wrote: > > On Fri, 13 Sep 2019 07:11:03 -0700 > Manoj Gupta wrote: > > > friendly ping for patch review. > > Pushed your patch as-is as: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=463ec5b25ac36933127e726c553ad83994017aa1 Thanks a lot > > Thank you! > > -- > > Sergei
Re: [gentoo-dev] [PATCH] ada.eclass: New eclass for dev-ada packages
I'm sorry for not finding time to review this earlier.
On Thu, 2019-09-05 at 20:25 +0200, Tupone Alfredo wrote:
> Signed-off-by: Alfredo Tupone
> ---
> eclass/ada.eclass | 435 ++
> 1 file changed, 435 insertions(+)
> create mode 100644 eclass/ada.eclass
>
> diff --git a/eclass/ada.eclass b/eclass/ada.eclass
> new file mode 100644
> index ..338b73bab86b
> --- /dev/null
> +++ b/eclass/ada.eclass
> @@ -0,0 +1,435 @@
> +# Copyright 2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: ada.eclass
> +# @MAINTAINER:
> +# Ada team
> +# @AUTHOR:
> +# Tupone Alfredo
> +# @BLURB: An eclass for Ada packages
> +# @DESCRIPTION:
> +# This eclass set the IUSE and REQUIRED_USE to request the ADA_TARGET
> +# when the inheriting ebuild can be supported by more than one Ada
> +# implementation. It also set ADA_USEDEP and ADA_DEPS with a suitable form.
> +# A common eclass providing helper functions to build and install
> +# packages supporting Ada implementations.
> +#
> +# This eclass sets correct IUSE. Modification of REQUIRED_USE has to
> +# be done by the author of the ebuild (but ADA_REQUIRED_USE is
> +# provided for convenience, see below). ada exports ADA_DEPS
> +# and ADA_USEDEP so you can create correct dependencies for your
> +# package easily.
> +#
> +# Mostly copied from python-single-r1.eclass
> +
> +case "${EAPI:-0}" in
> + 0|1|2|3|4)
> + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> + ;;
> + 5|6|7)
> + # EAPI=5 is required for sane USE_EXPAND dependencies
> + ;;
Given that EAPI 5 is deprecated already, you shouldn't be adding any new
ebuilds with it. Therefore, adding support for it is a bit pointless.
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac
> +
> +EXPORT_FUNCTIONS pkg_setup
> +
> +# @ECLASS-VARIABLE: ADA_DEPS
> +# @DESCRIPTION:
> +# This is an eclass-generated Ada dependency string for all
> +# implementations listed in ADA_COMPAT.
> +#
> +# The dependency string is conditional on ADA_TARGET.
> +#
> +# Example use:
> +# @CODE
> +# RDEPEND="${ADA_DEPS}
> +# dev-foo/mydep"
> +# DEPEND="${RDEPEND}"
> +# @CODE
> +#
> +
> +# @ECLASS-VARIABLE: _ADA_ALL_IMPLS
> +# @INTERNAL
> +# @DESCRIPTION:
> +# All supported Ada implementations, most preferred last.
> +_ADA_ALL_IMPLS=(
> + gnat_2016 gnat_2017 gnat_2018 gnat_2019
> +)
> +readonly _ADA_ALL_IMPLS
> +
> +
> +# @FUNCTION: _ada_impl_supported
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check whether the implementation (ADA_COMPAT-form)
> +# is still supported.
> +#
> +# Returns 0 if the implementation is valid and supported. If it is
> +# unsupported, returns 1 -- and the caller should ignore the entry.
> +# If it is invalid, dies with an appopriate error messages.
> +_ada_impl_supported() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + [[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
> +
> + local impl=${1}
> +
> + # keep in sync with _ADA_ALL_IMPLS!
> + # (not using that list because inline patterns shall be faster)
> + case "${impl}" in
> + gnat_201[6789])
> + return 0
> + ;;
> + *)
> + [[ ${ADA_COMPAT_NO_STRICT} ]] && return 1
> + die "Invalid implementation in ADA_COMPAT: ${impl}"
> + esac
> +}
> +
> +# @FUNCTION: _ada_set_impls
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check ADA_COMPAT for well-formedness and validity, then set
> +# two global variables:
> +#
> +# - _ADA_SUPPORTED_IMPLS containing valid implementations supported
> +# by the ebuild (ADA_COMPAT - dead implementations),
> +#
> +# - and _ADA_UNSUPPORTED_IMPLS containing valid implementations that
> +# are not supported by the ebuild.
> +#
> +# Implementations in both variables are ordered using the pre-defined
> +# eclass implementation ordering.
> +#
> +# This function must be called once in global scope by an eclass
> +# utilizing ADA_COMPAT.
> +_ada_set_impls() {
> + local i
> +
> + if ! declare -p ADA_COMPAT &>/dev/null; then
> + die 'ADA_COMPAT not declared.'
> + fi
> + if [[ $(declare -p ADA_COMPAT) != "declare -a"* ]]; then
> + die 'ADA_COMPAT must be an array.'
> + fi
> + for i in "${ADA_COMPAT[@]}"; do
> + # trigger validity checks
> + _ada_impl_supported "${i}"
> + done
> +
> + local supp=() unsupp=()
> +
> + for i in "${_ADA_ALL_IMPLS[@]}"; do
> + if has "${i}" "${ADA_COMPAT[@]}"; then
> + supp+=( "${i}" )
> + else
> + unsupp+=( "${i}" )
> + fi
> + done
> + if [[ ! ${supp[@]} ]]; then
> + die "No supported implementation in ADA_COMPAT."
> + fi
> +
> + if [[ ${_ADA_SUPPORTED_IM
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Fri, 13 Sep 2019 08:29:20 -0400 Michael Orlitzky wrote: > On 9/13/19 5:19 AM, Kent Fredric wrote: > > On Thu, 12 Sep 2019 17:58:08 -0400 > > Michael Orlitzky wrote: > > > >> What kind of math would convince you that an idea with all "cons" > >> and no "pros" is bad? > > > > Is "upstream tooling doesn't work without static compilation" or > > "built packages tend to need exact version matching at runtime to > > work" ( which necessitates massive-scale multi-slotting, where > > every version of every packaged "thing" has a co-existing slot ) a > > problem for you? > > I see it as a problem, but not one that has to be my problem. I don't > see it as a foregone conclusion that we have to package every piece of > software -- no matter how bad -- and distribute it with the OS that I > use to do my banking. > I don't think anyone here has suggested that any go packages are installed in the stage3 tarballs, or included in profiles. Something's presence in the tree does not mean that you are required to install it. A package's presence in the tree really has little to zero effect on any user that does not use the package. If you do not install the package, it will have zero effect on your banking. I also want to point out that the Gentoo packages for Firefox, Chromium, and Webkit all have a _lot_ of bundled dependencies and absolutely do static linking internally. If you are using a browser to do your banking, you are almost certainly using static linking, even without the presence of code written in golang. > These languages are badly implemented, and very little of value is > written in them. If their developers ever hit 2+ users, I'm sure > they'll realize that everyone else was right back in the 1970s, and > fix the design. But in the meantime, this stuff belongs in an > overlay. Lowering our standards until they match upstream's is > antithetical to how a distribution is supposed to improve my life. Despite your (and my) objections to it's approach to linking, golang is a very popular language these days with some very popular packages written in it. Docker and Kubernetes immediately come to mind, but there are many others. The argument "I don't use, and I dislike the implementation language, so no one should use it" is not a very compelling argument. These are very popular packages, that users and developers absolutely want to be available in Gentoo. Given this fact, and the fact that there are Gentoo developers who want these packages enough that they will maintain the packages, they absolutely do belong in the tree.
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Fri, 13 Sep 2019 12:50:48 -0400 Michael Orlitzky wrote: > On 9/12/19 1:45 PM, Alec Warner wrote: > > > > Er, I'm fairly sure computer *science* has not conclusively proven > > that dynamic binaries are somehow superior to static binaries. > > > > > If you statically link to a library, then none of its implementation > details are hidden from you -- you need to "reassemble" your program > whenever the library changes. > > If we jump way forward to 1979, the SICP[1] is basically a > thousand-page treatise on abstraction. But not only at one level of > computation: While I personally have opinions about static linking (I basically completely agree with you that it's a dumb idea). That said, this has nothing to do with this particular discussion, I suggest you take it up with the golang upstream. I don't think anyone here is arguing that static linking is a great idea and everyone should do it. We are arguing that the golang community believes strongly in static linking, and the entire ecosystem is designed around this idea, as such trying to bodge dynamic linking on to the existing ecosystem is probably more work than it is worth. In general, developers Gentoo tries to stay close to upstream as much as possible, as this reduces the maintenance burden. The entire point of this thread is to try to find a sane way to support the golang community's standards. I think the merits of static linking are out of scope here. > Well-designed computational systems, like well-designed automobiles > or nuclear reactors, are designed in a modular manner, so that the > parts can be constructed, replaced, and debugged separately. > > "Replaced" here is of course what I want to draw your attention to. > But also on the fact that abstraction and modularity don't just apply > at one level of software design and engineering -- it's a fractal. At > the lowest levels, we abstract machine code to assembler, assembler to > low-level languages, low-level languages to high-level languages, > high-level languages to functions and procedures, functions and > procedures to libraries, libraries to services, and services to > distributed APIs. The same principles that apply to a collection of > functions (a program) also apply to a collection of programs (an > operating system). The rule "don't copy and paste code" applies to > your linker just as much as it applies to the first program you wrote > in CS101, and for the same reasons. > > As you commented on IRC, the cost in terms of man-power is that > someone's workload jumps from O(n) to O(m*n), because you have to > duplicate everything you do for every statically-linked dependency. > And you can find as much theory as you like on software modularity in > papers from the 1970s and 1980s, but the benefits are not only > theoretical. There's a mountain of empirical data that supports the > theory. Some choice quotes [2][3]: > > Poorly placed dependencies, especially those that link otherwise > independent modules, may result in a cascade of unwanted and > hard-to- detect indirect interactions. Our results suggest that > purposeful actions to reduce such "rogue dependencies" can be > effective (the redesign of Mozilla reduced propagation cost by over > 80%). > > Our results confirm the existence of a relationship between > component modularity and design evolution that is both statistically > significant and large in magnitude... Tightly-coupled components > are... less adaptable via the processes of exclusion or > substitution; they are more likely to experience "surprise" > dependency additions unrelated to new functionality, implying that > they demand greater maintenance efforts; and they are harder to > augment, in that the mix of new components is more modular than the > legacy design. > > The only difference between static linking and copy/pasting chunks of > code around is in who pays the price. If the programmer copies & > pastes code into his own program, he will eventually have to deal > with the mess. On the other hand, it he forces his program to be > statically linked, then it is the end user who is harmed by his > decision. > > In any case, the theory says that modularity is superior, and the > empirical data confirm it. The fact that you won't find a paper saying > "dynamic linking is better than static linking" is somewhat beside the > point, and only muddies the water. Linking is just one specific > instance of a problem that was solved 40 years ago. > > > [0] > https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf > > [1] https://web.mit.edu/alexmv/6.037/sicp.pdf > > [2] https://pubsonline.informs.org/doi/10.1287/mnsc.1060.0552 > > [3] http://www.hbs.edu/research/pdf/08-038.pdf >
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
(Replying to both messages at once.) On 9/13/19 4:17 PM, Patrick McLean wrote: >> > I don't think anyone here has suggested that any go packages are > installed in the stage3 tarballs, or included in profiles. Something's > presence in the tree does not mean that you are required to install it. > A package's presence in the tree really has little to zero effect on > any user that does not use the package. If you do not install the > package, it will have zero effect on your banking. This is true only so far as they never become dependencies of anything else. Do all new developers know that dev-go is an insecure ghetto? Do our users? Or might someone accidentally install or depend upon something in dev-go before learning that crucial bit of information? > I also want to point out that the Gentoo packages for Firefox, > Chromium, and Webkit all have a _lot_ of bundled dependencies and > absolutely do static linking internally. If you are using a browser to > do your banking, you are almost certainly using static linking, even > without the presence of code written in golang. Is this is a "two wrongs make a right" argument? I'm telling mom =P > Despite your (and my) objections to it's approach to linking, golang is > a very popular language these days with some very popular packages > written in it. No it's not. It's below Delphi and Object Pascal on TIOBE this month. It's a trend that a tiny percentage of people jumped on because they heard the name "Google" back when Google was cool. The "people want this in Gentoo" argument I understand, but people don't really have it "in Gentoo." They have a thin wrapper around the "go" command. They don't get the Gentoo security guarantees, they don't get the Gentoo license handling, they don't get the ease of management that comes with a Gentoo @world update. They silently get something less than they're expecting. We would be better off telling people to run "go whatever" themselves, or by putting this stuff in an overlay where expectations are clearly defined. > While I personally have opinions about static linking (I basically > completely agree with you that it's a dumb idea). That said, this has > nothing to do with this particular discussion, I suggest you take it up > with the golang upstream. I don't think anyone here is arguing that > static linking is a great idea and everyone should do it. We just have a philosophical difference here. I don't think we should commit admittedly-dumb ideas to ::gentoo. These packages would work fine in an overlay until such a time as someone is interested in doing things correctly. They also work "fine" if you install them with "go" yourself: Portage isn't doing much for you when everything is bundled, statically linked, and has LICENSE set incorrectly. I don't want to keep replying to these threads -- I've said everything that I've got to say, and I'm boring myself, so I can only imagine how you all feel. This will get pushed through anyway, because it always does. It's just demoralizing constantly begging people not to make things worse and being ignored.
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Fri, 13 Sep 2019 19:44:55 -0400 Michael Orlitzky wrote: > (Replying to both messages at once.) > > > On 9/13/19 4:17 PM, Patrick McLean wrote: > >> > > I don't think anyone here has suggested that any go packages are > > installed in the stage3 tarballs, or included in profiles. > > Something's presence in the tree does not mean that you are > > required to install it. A package's presence in the tree really has > > little to zero effect on any user that does not use the package. If > > you do not install the package, it will have zero effect on your > > banking. > > This is true only so far as they never become dependencies of anything > else. Do all new developers know that dev-go is an insecure ghetto? Do > our users? Or might someone accidentally install or depend upon > something in dev-go before learning that crucial bit of information? A suggestion was made on IRC to have a pkg_postinst in the eclass that warn about golang package dependencies not having the same level of Gentoo security coverage that other packages in the tree have due to static linking. I think this is a reasonable approach, and users and developers will know. There is precedent for this, see sys-kernel/vanilla-sources > > I also want to point out that the Gentoo packages for Firefox, > > Chromium, and Webkit all have a _lot_ of bundled dependencies and > > absolutely do static linking internally. If you are using a browser > > to do your banking, you are almost certainly using static linking, > > even without the presence of code written in golang. > > Is this is a "two wrongs make a right" argument? I'm telling mom =P I am pointing out that we can't ban all static linking in the tree, many upstream packages won't work without it (or significant effort that no one has the time or motivation for). > > Despite your (and my) objections to it's approach to linking, > > golang is a very popular language these days with some very popular > > packages written in it. > > No it's not. It's below Delphi and Object Pascal on TIOBE this month. > It's a trend that a tiny percentage of people jumped on because they > heard the name "Google" back when Google was cool. Random stats from a website are not really an indication of how much a language is being used. There are plenty of very popular packages that are written in golang. > The "people want this in Gentoo" argument I understand, but people > don't really have it "in Gentoo." They have a thin wrapper around the > "go" command. They don't get the Gentoo security guarantees, they > don't get the Gentoo license handling, they don't get the ease of > management that comes with a Gentoo @world update. They silently get > something less than they're expecting. We would be better off telling > people to run "go whatever" themselves, or by putting this stuff in > an overlay where expectations are clearly defined. Users and Gentoo developers want Docker and Kubernetes (to name a couple) in the main tree. These are written in golang. I don't think we should ban packages because of the language they are written in. Especially if there are developers who want to maintain them. They do get the ease of management of @world in that if the upstream package releases a new version, it will be pulled in via an @world update. That is quite a large advantage to users, and is worth doing if there are developers willing to maintain the packages in the tree. > > > While I personally have opinions about static linking (I basically > > completely agree with you that it's a dumb idea). That said, this > > has nothing to do with this particular discussion, I suggest you > > take it up with the golang upstream. I don't think anyone here is > > arguing that static linking is a great idea and everyone should do > > it. > > We just have a philosophical difference here. I don't think we should > commit admittedly-dumb ideas to ::gentoo. These packages would work > fine in an overlay until such a time as someone is interested in > doing things correctly. They also work "fine" if you install them > with "go" yourself: Portage isn't doing much for you when everything > is bundled, statically linked, and has LICENSE set incorrectly. When "doing things correctly" means basically forking the entire ecosystem and maintaining all the forks internally, that is not something that is ever going to happen. There is demand from users and developers for golang packages. It's the same reason why we don't unbundle everything in Firefox and Chromium, it's simply too much work. It basically means maintaining our own fork of the package. That also means security updates will take significantly longer, as the fork will need to be rebased on the new upstream version. > I don't want to keep replying to these threads -- I've said everything > that I've got to say, and I'm boring myself, so I can only imagine how > you all feel. This will get pushed through anyway, because it always > does. It's just demoraliz
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
> On Fri, 13 Sep 2019, Patrick McLean wrote: > Something's presence in the tree does not mean that you are required > to install it. A package's presence in the tree really has little to > zero effect on any user that does not use the package. I wonder if that's always true. Distros adopting a package will make it more likely that other software will gain a dependency on it. Ulrich signature.asc Description: PGP signature
