[gentoo-dev] Last rites: sys-fs/wpflash
# Michał Górny (2019-09-17) # Last touched in 2005. EAPI 0. No clearly defined license. # Removal in 30 days. Bug #694598. sys-fs/wpflash -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [PATCH] bzr.eclass: Restrict supported EAPIs to 5 and 7
> On Sun, 15 Sep 2019, Michał Górny wrote: > The eclass is currently used by exactly one ebuild which is at EAPI 5. > Let's restrict allowed EAPIs just to 5 and 7, to cover a reasonable > upgrade path for that ebuild while blocking proliferation of old > EAPIs. This is a pointless change, because it doesn't go along with any simplification of code. In addition, it will break ebuilds in overlays for no good reason. Ulrich signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-db/cppdb, dev-db/odbtp, dev-db/soci, dev-db/xbase, dev-db/xbsql
# Michał Górny (2019-09-17) # Unmaintained libraries with no reverse dependencies. # Removal in 30 days. Bug #694602. dev-db/cppdb dev-db/odbtp dev-db/soci dev-db/xbase dev-db/xbsql -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: www-apache/*, unmaintained, EAPI 0
# Michał Górny (2019-09-17) # Unmaintained EAPI 0 Apache modules. # Removal in 30 days. www-apache/mod_authn_sasl www-apache/mod_depends www-apache/mod_dnsbl_lookup www-apache/mod_flvx www-apache/mod_geoip2 www-apache/mod_macro www-apache/mod_umask -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: www-apache/*, unmaintained, EAPI 0
On Tue, 2019-09-17 at 11:19 +0200, Michał Górny wrote: > # Michał Górny (2019-09-17) > # Unmaintained EAPI 0 Apache modules. > # Removal in 30 days. > www-apache/mod_authn_sasl > www-apache/mod_depends > www-apache/mod_dnsbl_lookup + www-apache/mod_access_dnsbl as a revdep > www-apache/mod_flvx > www-apache/mod_geoip2 > www-apache/mod_macro > www-apache/mod_umask > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs: app-editors/kakoune, app-text/scdoc, app-vim/rust-vim, media-gfx/imv, media-sound/pms, media-video/syncplay, www-plugins/pdfjs
Hello, Due to retirement of a proxied maintainer, the following packages are now looking for new maintainers: app-editors/kakoune app-text/scdoc app-vim/rust-vim media-gfx/imv media-sound/pms media-video/syncplay www-plugins/pdfjs All of those packages are outdated and in need of a version bump. There are no other bugs reported for them, though. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Tue, Sep 17, 2019 at 07:36:07AM +0200, Michał Górny wrote: > On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote: > > On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > > > On 9/16/19 11:35 AM, William Hubbs wrote: > > > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > > > > > For packages that I maintain, I'd prefer to continue using EGO_VENDOR > > > > > to > > > > > even with packages using go.mod. I hope that this go-module.class will > > > > > not preclude this sort of usage. For example, the latest go-tools > > > > > ebuild > > > > > uses EGO_VENDOR together with GOFLAGS="-mod=vendor": > > > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f > > > > > > > > Can you elaborate on why you want to keep EGO_VENDOR? > > > > > > > > The "go mod vendor" command above downloads all the correct versions > > > > of the dependencies and puts them in the vendor directory, so I'm not > > > > sure why you would need the EGO_VENDOR variable. > > > > > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > > > containing vendored dependencies. It's more space-efficient in the sense > > > that each vendored dependency is stored in a separate tarball, so > > > multiple ebuilds can share the same tarball if the version of a > > > particular vendored dependency has not changed. > > > > I see what you are saying, but I haven't yet found a way to generate > > these separate tarballs that I'm comfortable with. Also, thinking about > > this, there will be many more tarballs on our mirrors if we store one > > dependency in each tarball than if we generate vendor tarballs that > > contain all dependencies for a package. > > > > I would consider this an enhancement to the eclass if you still feel > > that we need it, but let me get the eclass into the tree first then we > > can work on that. > > > > That sounds like a bad idea. If there are any potential enhancements > that can happen, I'd rather see them happen before there's a bunch of > ebuilds using the eclass in the wild, and potentially limiting possible > changes. Like I just said on IRC, it would have been better if you responded in terms of discussing the enhancement itself. The main blocker for me is that EGO_VENDOR is basically the same information as go.mod, but it isn't quite the same format. You can get close with "go list -m all", but EGO_VENDOR doesn't automatically handle imports that start with things like golang.org/x or gopkg.in; you have to manually fix those, and you would have to do that every time. That seems to be a lot of work for little gain. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On 9/17/19 7:10 AM, William Hubbs wrote:
> On Tue, Sep 17, 2019 at 07:36:07AM +0200, Michał Górny wrote:
>> On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote:
>>> On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote:
On 9/16/19 11:35 AM, William Hubbs wrote:
> On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote:
>> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to
>> even with packages using go.mod. I hope that this go-module.class will
>> not preclude this sort of usage. For example, the latest go-tools ebuild
>> uses EGO_VENDOR together with GOFLAGS="-mod=vendor":
>>
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f
>
> Can you elaborate on why you want to keep EGO_VENDOR?
>
> The "go mod vendor" command above downloads all the correct versions
> of the dependencies and puts them in the vendor directory, so I'm not
> sure why you would need the EGO_VENDOR variable.
EGO_VENDOR eliminates to need to generate and host monolithic tarballs
containing vendored dependencies. It's more space-efficient in the sense
that each vendored dependency is stored in a separate tarball, so
multiple ebuilds can share the same tarball if the version of a
particular vendored dependency has not changed.
>>>
>>> I see what you are saying, but I haven't yet found a way to generate
>>> these separate tarballs that I'm comfortable with. Also, thinking about
>>> this, there will be many more tarballs on our mirrors if we store one
>>> dependency in each tarball than if we generate vendor tarballs that
>>> contain all dependencies for a package.
>>>
>>> I would consider this an enhancement to the eclass if you still feel
>>> that we need it, but let me get the eclass into the tree first then we
>>> can work on that.
>>>
>>
>> That sounds like a bad idea. If there are any potential enhancements
>> that can happen, I'd rather see them happen before there's a bunch of
>> ebuilds using the eclass in the wild, and potentially limiting possible
>> changes.
>
> Like I just said on IRC, it would have been better if you responded in
> terms of discussing the enhancement itself.
>
> The main blocker for me is that EGO_VENDOR is basically the same
> information as go.mod, but it isn't quite the same format.
> You can get close with "go list -m all", but EGO_VENDOR doesn't
> automatically handle imports that start with things like golang.org/x or
> gopkg.in; you have to manually fix those, and you would have to do that
> every time. That seems to be a lot of work for little gain.
It looks like it should not be too difficult to create a script that
will convert from go.mod to EGO_VENDOR format. For example, take this
go.mod file:
https://github.com/golang/tools/blob/master/go.mod
It contains a line like this:
golang.org/x/net v0.0.0-20190620200207-3b0461eec859
The part after the last hyphen corresponds to the commit hash which can
be used directly or expanded like this:
$ curl -sS https://api.github.com/repos/golang/net/commits/3b0461eec859 |
jq -r .sha
3b0461eec859c4b73bb64fdc8285971fd33e3938
The github owner and repo names can resolved like this:
$ curl -sS https://golang.org/x/net | grep go-source
https://github.com/golang/net/ https://github.com/golang/net/tree/master{/dir}
https://github.com/golang/net/blob/master{/dir}/{file}#L{line}";>
I've found that `go get` parses a similar meta element named "go-import"
here:
https://github.com/golang/go/blob/master/src/cmd/go/internal/get/discovery.go
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] eclass update for php-ext-source-r3
This diff is required to get proper support for PHP 7.4 and newer.
Upstream has discontinued acinclude.m4 and this has been breaking our
call to eautoreconf. Instead, we are now simulating their ./buildconf
script with our own toolchain functions to ensure cross-build compatibility.
diff --git a/eclass/php-ext-source-r3.eclass
b/eclass/php-ext-source-r3.eclass
index 5ef879a2be2..385bdb9dae0 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -15,7 +15,8 @@ inherit autotools
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
case ${EAPI:-0} in
- 6|7) ;;
+ 6) inherit eapi7-ver ;;
+ 7) ;;
*)
die "${ECLASS} is not compatible with EAPI=${EAPI}"
esac
@@ -183,10 +184,18 @@ php-ext-source-r3_phpize() {
# WANT_AUTOMAKE (see bugs #329071 and #549268).
autotools_run_tool "${PHPIZE}"
- # Force libtoolize to run and regenerate autotools files (bug
- # #220519).
- rm aclocal.m4 || die "failed to remove aclocal.m4"
- eautoreconf
+ # PHP >=7.4 no longer works with eautoreconf
+ if ver_test $PHP_CURRENTSLOT -ge 7.4 ; then
+ rm -fr aclocal.m4 autom4te.cache config.cache \
+ configure main/php_config.h.in || die
+ eautoconf --force
+ eautoheader
+ else
+ # Force libtoolize to run and regenerate autotools
files (bug
+ # #220519).
+ rm aclocal.m4 || die "failed to remove aclocal.m4"
+ eautoreconf
+ fi
fi
}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags
On Tue, 2019-09-10 at 22:44 +0200, Michał Górny wrote: > Hi, everyone. > > I've recently (finally!) started adding tests to cpuid2cpuflags. Tests > are based on mocked syscalls that return arch-specific data read from > text files. So far I've got x86 and ppc covered, and now I'd like to > add tests for various arm hardware. Since ARM covers a pretty broad > range of hardware, I'd use as much data as possible, especially from > different ARM generations. > > If you have an ARM board and would like to help, please: > > wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2 > tar -xf cpuid2cpuflags-7-dev.tar.bz2 > cd cpuid2cpuflags-7-dev > ./configure > make hwcap-dump > ./hwcap-dump > > and send me the output along with 'uname -m'. TIA! > Thanks for all the data so far. I've released v8 with the lot of ARM tests just now. If someone's got older hardware ( signature.asc Description: This is a digitally signed message part
