Repo cleanup

[xmhd]

Many more packages to be cleaned / synced with ::gentoo.

[stefson]

duktape patch is too big for posting to overlay or tree, hence it was decided to put it in distfiles xorg-server and the patch was needed at some point for arm, please ask blueness whats going on with that we had an agreement here, that there its not ok to propagate new keywords such as ~ia64 or ~m68k (seeing this with psmisc)

[xmhd]

duktape patch is too big for posting to overlay or tree, hence it was decided to put it in distfiles xorg-server and the patch was needed at some point for arm, please ask blueness whats going on with that we had an agreement here, that there its not ok to propagate new keywords such as ~ia64 or ~m68k (seeing this with psmisc)

Duktape patch can be moved back to SRC_URI on polkit-0.118-r1.

Wrt xorg-server the ebuild in the overlay doesn't even work anymore due to eselect-opengl not being in ::gentoo for some time now. The musl patch which exists there doesn't even apply cleanly to xorg-server-1.20.5 (the second change is off by some 200 lines). Sure we could forward port the first part of the patch (a one line change - change linux to GLIBC).

Wrt to keywords, those can be changed too.. However it would be nice if such agreements were written down so that contributors can follow them.

[xmhd]

I removed the xorg-server and polkit commits for now, they can be amended later.

[stefson]

I'd like to make a proposal with regards to the dev-lang/rust ebuild: I'm kinda trying to get it back to working on arm, do you want to collaborate with me on working with it in a seperate pullrequest? I might be able to contribute a neon and thumbv2 patch for it.

with regards to keywords, this is documented somewhere along the lines that only maintainer and/or ${arch} team is taking care of keywording ebuilds, as this is more demanding in terms of runtime testing.

also I believe that eapi 7 demands patches to be formated into lines like this:

a/.. b/..

seen it on elogind patch.

[xmhd]

I'd like to make a proposal with regards to the dev-lang/rust ebuild: I'm kinda trying to get it back to working on arm, do you want to collaborate with me on working with it in a seperate pullrequest? I might be able to contribute a neon and thumbv2 patch for it.

Anything dev-lang/rust related should be done at https://github.com/smaeul/portage-overlay/tree/master/dev-lang/rust , I imagine smaeul would be happy to take any patches. I won't have too much time in the coming weeks but I may be able to help after that.

with regards to keywords, this is documented somewhere along the lines that only maintainer and/or ${arch} team is taking care of keywording ebuilds, as this is more demanding in terms of runtime testing.

Is that for ::gentoo or this overlay though? again, it would help to have this formalised.

also I believe that eapi 7 demands patches to be formated into lines like this:

a/.. b/..

seen it on elogind patch.

I have amended that.

[stefson]

yeah, the problem with the dev-lang/rust ebuilds is that smaeuls style of writing them is highly idiosyncratic to me, I'm not a dev in the end. There is an open issue with the neon and thumbv7 support over at his overlay, but he is kind of non responsive. Which is fine by me, as its propably due to lack of hardware only. I'm stealing his stages for my private rust-bin in the meantime, which I shared here but no one seems willing to commit it.

thanks for testing if rsync is still needed, I had this queued up on my tasklist! :')

[mjeveritt]

yeah, the problem with the dev-lang/rust ebuilds is that smaeuls style of writing them is highly idiosyncratic to me, I'm not a dev in the end. There is an open issue with the neon and thumbv7 support over at his overlay, but he is kind of non responsive. Which is fine by me, as its propably due to lack of hardware only. I'm stealing his stages for my private rust-bin in the meantime, which I shared here but no one seems willing to commit it.

thanks for testing if rsync is still needed, I had this queued up on my tasklist! :')

@smaeul works often with ARM hardware (linux-sunxi?) so he's not immune to the cross-platform stuff. He's worked with musl on multiple arches for a number of years now (and I'm sure he's not averse to merging relevant patches to the Gentoo ebuilds in his overlay).

There is a prescribed format for ebuilds in Gentoo, governed by policy documents all over, and the ::gentoo repository maintains a fairly authoritative source for 'accepted' standards. The proxy-maintainers project has sought to make much of this more widely available, to encourage external contributions.

If you have specific queries, perhaps we can address these directly.

[stefson]

@mjeveritt the most obvious problem with the rust ebuild on arm are these double entries in the config.toml:

>>> Configuring source in /var/tmp/portage/dev-lang/rust-1.47.0-r1/work/rustc-1.47.0-src ...
 * Rust configured with the following settings:
[llvm]
optimize = true
release-debuginfo = false
assertions = false
ninja = true
targets = "ARM"
experimental-targets = ""
link-shared = false
[build]
build = "armv7a-unknown-linux-musleabihf"
host = ["armv7a-unknown-linux-musleabihf"]
target = ["armv7a-unknown-linux-musleabihf","armv7-unknown-linux-musleabihf"]
cargo = "/opt/rust-bin-1.46.0/bin/cargo"
rustc = "/opt/rust-bin-1.46.0/bin/rustc"
docs = false
compiler-docs = false
submodules = false
python = "python3.8"
locked-deps = true
vendor = true
extended = true
tools = ["cargo"]
verbose = 2
sanitizers = false
profiler = false
cargo-native-static = false
[install]
prefix = "/usr/lib/rust/1.47.0"
sysconfdir = "etc"
docdir = "share/doc/rust"
bindir = "bin"
libdir = "lib"
mandir = "share/man"
[rust]
# https://github.com/rust-lang/rust/issues/54872
codegen-units-std = 1
optimize = true
debug = false
debug-assertions = false
debuginfo-level-rustc = 0
backtrace = true
incremental = false
default-linker = "armv7a-unknown-linux-musleabihf-gcc"
parallel-compiler = false
channel = "stable"
rpath = false
verbose-tests = true
optimize-tests = true
codegen-tests = true
dist-src = false
remap-debuginfo = true
lld = false
backtrace-on-ice = true
jemalloc = false
[dist]
src-tarball = false
[target.armv7a-unknown-linux-musleabihf]
cc = "armv7a-unknown-linux-musleabihf-gcc"
cxx = "armv7a-unknown-linux-musleabihf-g++"
linker = "armv7a-unknown-linux-musleabihf-gcc"
ar = "armv7a-unknown-linux-musleabihf-ar"
crt-static = false
[target.armv7-unknown-linux-musleabihf]
cc = "armv7a-unknown-linux-musleabihf-gcc"
cxx = "armv7a-unknown-linux-musleabihf-g++"
linker = "armv7a-unknown-linux-musleabihf-gcc"
ar = "armv7a-unknown-linux-musleabihf-ar"
crt-static = false
>>> Source configured.

I have no idea where they are coming from actually.

[mjeveritt]

Yoikes...