[gentoo-dev] Last rites: old, ruby23-only, slots of various ruby packages
# Hans de Graaff (7 May 2018) # Old slots that are ruby23-only and no longer maintained # upstream, and that do not have packages depend on them. # Migrate to newer slot of the same package. dev-ruby/askismet:0 dev-ruby/arel:5.0 dev-ruby/autoprefixer-rails:6 dev-ruby/blankslate:2 dev-ruby/http:0.6 dev-ruby/jquery-ui-rails:4 dev-ruby/net-ssh:3 dev-ruby/sanitize:0 dev-ruby/twitter:5 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Monthly x11@ project status for May 2018
Firstly, I'd like to welcome Nick Sarnie to the X11 team. He's been very helpful in improving the state of media-libs/vulkan-loader for a while now, so it's nice to make it official! == Fix x11-base/xorg-server suid/systemd situation == https://bugs.gentoo.org/635102 Frustratingly, not sure if this is sorted out. In 1.19.99.904 [1] I modified things so that Xorg is installed setuid when USE=-systemd. Only got one test report (unsuccessful) but it could be a separate problem. Please test 1.19.99.905 (RC5). The next version will be 1.20. I would appreciate an ebuild patch from any elogind user for elogind support. == Update packages to depend on x11-base/xorg-proto == https://bugs.gentoo.org/651286 All architectures have stabilized x11-base/xorg-proto! Non-empty x11-proto/* packages have been removed. I was finally able to close out 15+ bugs about missing (transitive) dependencies on x11-proto/*. That felt good. About 20% of the way there since April 1st: Packages depending on x11-proto/* down from 530 -> 432 [2] ebuilds depending on x11-proto/* down from 1908 -> 1503 [3] Big thanks to Arfrever for handling whole categories at a time! If there's a way to have repoman alert developers to deprecated dependencies in the same way we handle deprecated eclasses, I'd like to know about it. == media-libs/vulkan-loader updates and features == https://bugs.gentoo.org/619124 Sarnex worked hard to get vulkan-loader updated. He added USE=layers and USE=demos. The "layers" are an important feature of Vulkan: validation layers that can be enabled to help you fix your application. == Xorg stabilization for May 2018 == https://bugs.gentoo.org/649316 Stabilization of 27 packages appears to be going rather smoothly. The new xorg-server version being stabilized contains a fix Sarnex found that will be necessary for Mesa 18.0. == Remove x11-proto/printproto and x11-libs/libXp == https://bugs.gentoo.org/649076 All blockers handled. Packages given last rites. Will be removed May 21st or soon thereafter. == Remove x11-libs/xpyb == https://bugs.gentoo.org/651300 Given last rites. Will be removed May 22nd or soon thereafter == Remove media-libs/libtxc_dxtn == https://bugs.gentoo.org/654464 I merged the S3TC texture compression code in libtxc_dxtn into Mesa for 17.3 (the patent expired! yay!). A couple of packages actually depend directly on libtxc_dxtn. Once those are fixed, we'll be able to tree clean it. == Remove x11-libs/libXfont == https://bugs.gentoo.org/655102 libXfont has been replaced by libXfont2. With a few packages fixed, we'll be able to tree clean the old slot. == Convert media-libs/mesa ebuild to build with Meson == https://bugs.gentoo.org/652762 Ebuild posted. Blocked on problems surrounding LLVM (this is the story of maintaining media-libs/mesa). The problem is that Meson has no way of specifying a different llvm-config binary without a cross file, which our meson.eclass does not generate for 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't seen any progress towards a solution. == Convert media-libs/xorg-server ebuild to build with Meson == No progress. == Add and require glvnd == https://bugs.gentoo.org/606924 https://github.com/NVIDIA/libglvnd No progress. == Drop app-eselect/eselect-mesa == https://bugs.gentoo.org/576334 No progress. == Fix/Remove OpenCL == https://bugs.gentoo.org/546320 https://bugs.gentoo.org/647330 No progress, but an upstream Mesa developer interested in OpenCL and Gentoo user is interested in contributing in order to get rid of eselect-opencl and to use the ICD interface instead. == Clean out x11 overlay == https://gitweb.gentoo.org/proj/x11.git/ No progress. [1] https://bugs.gentoo.org/635102#c31 [2] git grep x11-proto | cut -d '/' -f -2 | grep -v metadata | sort -u | wc -l [3] git grep x11-proto | wc -l [4] https://github.com/mesonbuild/meson/issues/3327 signature.asc Description: Digital signature
[gentoo-dev] Re: Monthly x11@ project status for May 2018
On Mon, May 7, 2018 at 1:38 PM, Matt Turner wrote: > == Convert media-libs/mesa ebuild to build with Meson == > https://bugs.gentoo.org/652762 > > Ebuild posted. Blocked on problems surrounding LLVM (this is the story of > maintaining media-libs/mesa). > > The problem is that Meson has no way of specifying a different llvm-config > binary without a cross file, which our meson.eclass does not generate for > 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't > seen > any progress towards a solution. Just wanted to highlight this section for the Meson maintainers specifically. Why do we not generate cross files for 32-bit builds on 64-bit? As far as I understand that would be sufficient for us. Do you have any suggestions?
[gentoo-dev] [PATCH] java-utils-2.eclass: port to EAPI 7
---
eclass/java-utils-2.eclass | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 25e35c33dd2..47bbb64ffd4 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -15,7 +15,7 @@
# you should inherit java-pkg-2 for Java packages or java-pkg-opt-2 for
packages
# that have optional Java support. In addition you can inherit java-ant-2 for
# Ant-based packages.
-inherit eutils versionator multilib
+has "${EAPI:-0}" 0 1 2 3 4 5 6 && inherit eutils versionator multilib
IUSE="elibc_FreeBSD"
@@ -1526,8 +1526,16 @@ java-pkg_is-vm-version-eq() {
local vm_version="$(java-pkg_get-vm-version)"
- vm_version="$(get_version_component_range 1-2 "${vm_version}")"
- needed_version="$(get_version_component_range 1-2 "${needed_version}")"
+ case ${EAPI} in
+ 0|1|2|3|4|5|6)
+ vm_version="$(get_version_component_range 1-2 "${vm_version}")"
+ needed_version="$(get_version_component_range 1-2
"${needed_version}")"
+ ;;
+ 7)
+ vm_version="$(ver_cut 1-2 "${vm_version}")"
+ needed_version="$(ver_cut 1-2 "${needed_version}")"
+ ;;
+ esac
if [[ -z "${vm_version}" ]]; then
debug-print "Could not get JDK version from DEPEND"
--
2.17.0
Re: [gentoo-dev] Monthly x11@ project status for May 2018
On Mon, 7 May 2018 13:38:47 -0700 Matt Turner wrote: > > If there's a way to have repoman alert developers to deprecated > dependencies in the same way we handle deprecated eclasses, I'd like > to know about it. > > Currently there is not. Thinking out loud... It would mean parsing package.mask to generate the list filtering out those with "masked for removal", from other general mask reasons, but even that is not consistent. from another email in today's batch... (not to pick on this one, was just a lucky coincidence) eg: Subject: [gentoo-dev] Last rites: old, ruby23-only, slots of various ruby packages # Hans de Graaff (7 May 2018) # Old slots that are ruby23-only and no longer maintained # upstream, and that do not have packages depend on them. # Migrate to newer slot of the same package. Perhaps we would need to add a separate last-rites.mask list that the package manager merges internally as part of the .mask stack. That would make just one file to load without a need for filtering. A separate list might also be beneficial for the undertakers and any tooling for its automation. (I am not familiar with any of that tooling) I would then suggest the dependency depth check to default to one (or two) so as to not slow things down drastically. Perhaps a Q/A check report to scan the whole tree on a weekly basis. But that would also require PMS to be updated for the new file, which means a council vote... -- Brian Dolbec pgpDUQqsEMJ4M.pgp Description: OpenPGP digital signature
