Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hello, On Fri, 05 Aug 2016, Mike Gilbert wrote: >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz wrote: >> I know that. But the patch should be applied *only* for versions of kernels >> 4.7+. So, I'm asking how is the policy for that. > >If you're asking for policy: The Gentoo packaging policy is not to do >conditional patching. Instead, modify the patch so that the resulting >code works for both cases. This can generally be accomplished via >pre-processor macros. My patch does it like that. See https://archives.gentoo.org/gentoo-user/message/baa36d14d8cdbf58404267ee2ffd34ea Just dumping the attached patch into /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/ (and making it readable for the portage user) is sufficient. HTH, -dnh -- Every feature is a bug, unless it can be turned off. -- Karl Heuerdiff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c b/kernel/nvidia-drm/nvidia-drm-fb.c --- a/kernel/nvidia-drm/nvidia-drm-fb.c 2016-07-12 06:53:45.0 +0200 +++ b/kernel/nvidia-drm/nvidia-drm-fb.c 2016-07-28 09:43:11.494515158 +0200 @@ -32,6 +32,8 @@ #include +#include + static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb) { struct nvidia_drm_device *nv_dev = fb->dev->dev_private; @@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_ * We don't support any planar format, pick up first buffer only. */ +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0) +gem = drm_gem_object_lookup(file, cmd->handles[0]); +#else gem = drm_gem_object_lookup(dev, file, cmd->handles[0]); +#endif if (gem == NULL) { diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c b/kernel/nvidia-drm/nvidia-drm-gem.c --- a/kernel/nvidia-drm/nvidia-drm-gem.c 2016-07-12 06:53:45.0 +0200 +++ b/kernel/nvidia-drm/nvidia-drm-gem.c 2016-07-28 09:27:24.610637573 +0200 @@ -28,6 +28,8 @@ #include "nvidia-drm-ioctl.h" #include "nvidia-drm-gem.h" +#include + static struct nvidia_drm_gem_object *nvidia_drm_gem_new ( struct drm_file *file_priv, @@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset mutex_lock(&dev->struct_mutex); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0) +gem = drm_gem_object_lookup(file, handle); +#else gem = drm_gem_object_lookup(dev, file, handle); +#endif if (gem == NULL) { diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h --- a/kernel/nvidia-uvm/uvm_linux.h 2016-07-12 06:52:17.0 +0200 +++ b/kernel/nvidia-uvm/uvm_linux.h 2016-07-28 09:29:21.096322608 +0200 @@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada INIT_RADIX_TREE(tree, GFP_NOWAIT); } +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0) static bool radix_tree_empty(struct radix_tree_root *tree) { void *dummy; return radix_tree_gang_lookup(tree, &dummy, 0, 1) == 0; } +#endif #if !defined(NV_USLEEP_RANGE_PRESENT)
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hello, On Sat, 06 Aug 2016, Natanael Olaiz wrote: >Thank you for your patch. It was a good example to answer my question. > >But about the patch itself, I see that you are commented the code for >radix_tree_empty(...). In my patch I renamed it and it only usage instead, >so I'm sure it's calling the same code. I don't know the expected >compatibility with the kernel function implementation... But without >knowing the specific code for neither the nvidia driver nor the kernel, I >think the rename is safer... If you're in doubt or hit any trouble, yes, definitely change/adapt the patch to only rename that function and use the renamed function in the nvidia-driver as in your original patch. Keep/adapt the stuff about kernel-versions though. That's the "safe" approach. That "just put it in /etc/portage/patches/..." should work tough :) I've looked quite sharp at the code, i.e. in the nvidia code static bool radix_tree_empty(struct radix_tree_root *tree) { void *dummy; return radix_tree_gang_lookup(tree, &dummy, 0, 1) == 0; } vs. the kernel function static inline bool radix_tree_empty(struct radix_tree_root *root) { return root->rnode == NULL; } *oik* I miss a check for root != NULL there ;) Anyway, it was quite clear, that the driver calls kernel-stuff at this point anyway, radix_tree_gang_lookup() is a kernel function. (I love to use mc for digging for stuff like this!) So, digging into the kernel-source I came to the conclusion that calling the _kernel code_(!) radix_tree_gang_lookup(tree, &dummy, 0, 1); actually _is_ (or SHOULD BE) equivalent to the kernel code for the new radix_tree_empty(tree); and the latter should be faster (unless the compiler optimizes the 'radix_tree_gang_lookup(root, &dummy, 0, 1)' call away). All this applies if and only if the last two arguments of radix_tree_gang_lookup() are 0 and 1! And yes, I did go through the code of radix_tree_gang_lookup() step by step (repeatedly) until I was sure enough that the code is equivalent). But I'm not a C guru. I might have missed something even important. So, if more guys firm in C can check this ... As I'm a guy generally trusting the kernel guys _a lot_ and that nvidia assumedly got it right implementing 'radix_tree_empty(tree)' via 'radix_tree_gang_lookup(tree, &dummy, 0, 1);' and I think those two equivalent (with 0, 1 being the 3rd and 4th parameters!), I tried it, and it worked. And Meino has not yet complained. AFAIR he's around long enough to have complained by now (and circumvented problems with the patch). I'll ping him on the -user ML though in a parallel mail. Recap: calling the kernel function in this way (via the nvidia function) radix_tree_gang_lookup(tree, &dummy, 0, 1); is IMHO equivalent to calling the kernel function radix_tree_empty(tree); and on this I based my patch on. I'm rather sure from looking at the code. It worked in a short test. Meino has not complained yet. If you want a "sure"/"safe" approach, go with renaming the function in the nvidia-code, or wait a bit if Meino pipes up, he should've been running the driver with my patch for a week by now. Or until an official patch crops up. Or, take precautions, some other way to boot+chroot, and keep the "old" driver handy or to disable it, build a binary package of the previous driver, have an older kernel ready etc. pp., you know the drill, don't you? -dnh -- MCSE: "Microsoft Certified Stupidity enclosed"-- A. Spengler
Re: [gentoo-dev] bash-4.4 - call for testers
Hello, On Tue, 20 Sep 2016, Lars Wendler wrote: >This is a call for testers. If you feel brave enough, please give >bash-4.4 a shot and report all problems you might have with it. > >Add the following to you package.unmask file/directory: > > =app-shells/bash-4.4* > =sys-libs/readline-7.0* with basically no testing so far: builds ok. >in order to get all readline reverse deps being built against new >readline. Reporting those packages in our bug tracker [1] would be >helpful. Creating a new bug or what? [2] seems inappropriate. >[2] https://bugs.gentoo.org/594496 I've found this that I guess has to do with the new readline: >From the build.log of emerge -1 dev-lisp/clisp [..] * Package:dev-lisp/clisp-2.49-r8 * Repository: gentoo * Maintainer: common-l...@gentoo.org * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk kernel_linux pcre postgres readline threads unicode userland_GNU zlib * FEATURES: ccache compressdebug nostrip preserve-libs sandbox splitdebug userpriv usersandbox [..] ;; Loading file /var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas ... *** - FFI::FIND-FOREIGN-VARIABLE: foreign variable # does not have the required size or alignment ./clisp-link: failed in /var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir Makefile:2621: recipe for target 'base' failed make: *** [base] Error 1 [..] # equery uses -i =dev-lisp/clisp-2.49-r8 | xargs echo +X +berkdb -dbus -fastcgi +gdbm +gtk -hyperspec -pari +pcre +postgres +readline +threads +unicode +zlib So, something with 'rl_readline_state' and how clisp uses that has changed that I won't dig into right now. Clisp maintainers? That seems to be the only problem with readline-7.0/bash-4.4 on this install (so far). -dnh -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger Wybe Dijkstra
Re: [gentoo-dev] bash-4.4 - call for testers
Hello, On Thu, 22 Sep 2016, David Haller wrote: [..] >I've found this that I guess has to do with the new readline: > >>From the build.log of >emerge -1 dev-lisp/clisp > > >[..] > * Package:dev-lisp/clisp-2.49-r8 > * Repository: gentoo > * Maintainer: common-l...@gentoo.org > * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk > kernel_linux pcre postgres readline threads unicode userland_GNU > zlib > * FEATURES: ccache compressdebug nostrip preserve-libs sandbox > splitdebug userpriv usersandbox >[..] >;; Loading file >/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas > ... >*** - FFI::FIND-FOREIGN-VARIABLE: foreign variable #"rl_readline_state" #x0088B460> does not have the > required size or alignment > >./clisp-link: failed in >/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir >Makefile:2621: recipe for target 'base' failed >make: *** [base] Error 1 >[..] > [..] Got a patch for that: https://bugs.gentoo.org/show_bug.cgi?id=594552 https://bugs.gentoo.org/attachment.cgi?id=447492 -dnh -- Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. -- RFC 1391
USE=doc gnustep-make broken (was: Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority)
Hello, On Wed, 11 Jan 2017, Bernard Cafarelli wrote: >Le 11/01/2017 8:30, Ulrich Mueller a écrit : [..] >> Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve >> it. >Indeed, I tested (and committed) this yesterday and repoman was happy again gnustep-base/gnustep-make-2.6.8.ebuild is broken when built with USE=doc, as it tries to install into the system, not the image. Easy fix: diff -U7 -r a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild --- a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild 2017-01-14 19:55:10.658259392 +0100 +++ b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild 2017-01-14 19:55:17.158259179 +0100 @@ -97,15 +97,15 @@ src_compile() { emake # Prepare doc here (needed when no gnustep-make is already installed) if use doc ; then # If a gnustep-1 environment is set unset GNUSTEP_MAKEFILES pushd Documentation &> /dev/null - emake -j1 all install + emake -j1 all install DESTDIR="${D}" popd &> /dev/null fi } src_install() { # Get GNUSTEP_* variables . ./GNUstep.conf HTH, -dnh -- What once was muesli is now of a colour and (from the looks) consistency unheard of in dairy produce. At a second guess, it might be running for political office by the time flattie's back. -- The Bastard Flatmate From Hell
Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc
Hello, On Fri, 24 Aug 2018, Mart Raudsepp wrote: [..] >Suggested description for global gtk-doc USE: >Build and install gtk-doc based developer documentation Mentioning gtk-doc, what about: https://bugs.gentoo.org/646850 Ready-made patch since 2018-02-07, and then what? -dnh -- If you don't see why, please stay the fuck away from my code. -- Paul "Rusty" Russel, in /usr/src/linux/Documentation/DocBook/kernel-locking.tmpl
Re: [gentoo-dev] Last rites: dev-lang/solidity
Hello, On Thu, 13 Sep 2018, Michal Górny wrote: ># Michal Górny (13 Sep 2018) ># Depends on old version of dev-libs/jsoncpp, blocking its pruning. ># Downstream maintainer is inactive to bump it. Removal in 30 days. >dev-lang/solidity As per the "no -Werror" policy, the following patch to the ebuild, or something to the same effect should be done anyway, and it compiles without '-Werror'. --- a/solidity-0.4.18.ebuild 2017-12-20 21:09:16.0 +0100 +++ b/solidity-0.4.18.ebuild 2018-09-13 15:59:06.584892127 +0200 @@ -28,6 +28,11 @@ "${FILESDIR}"/${P}-fix-cmake-external-jsoncpp.diff ) +src_prepare() { + sed -i '/add_compile_options(-Werror)/d' cmake/EthCompilerSettings.cmake + cmake-utils_src_prepare +} + src_configure() { local mycmakeargs=( "-DBoost_USE_STATIC_LIBS=off" HTH, -dnh -- | Ceci n'est pas une pipe
Re: [gentoo-dev] Last rites: dev-python/epydoc
Michal, ... On Wed, 29 Jan 2020, Michal Górny wrote: ># Michal Górny (2020-01-29) ># Abandoned in 2009. Python 2 only. No blockers left. ># Removal in 30 days. Bug #706218. >dev-python/epydoc ... I think you're getting a liiittle bit trigger happy there ... # equery d dev-python/epydoc * These packages depend on dev-python/epydoc: sys-apps/portage-2.3.86 (python_targets_python2_7 ? >=dev-python/epydoc-2.0[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]) $ cd /usr/portage/sys-apps/portage $ grep epydoc portage-2.3.86.ebuild IUSE="build doc epydoc gentoo-dev +ipc +native-extensions +rsync-verify selinux xattr" epydoc? ( >=dev-python/epydoc-2.0[${PYTHON_USEDEP}] REQUIRED_USE="epydoc? ( $(python_gen_useflags 'python2*') )" use epydoc && DISTUTILS_ALL_SUBPHASE_IMPLS=( python2.7 ) use epydoc && targets+=( epydoc ) use epydoc && targets+=( install_epydoc ... and thats the fricking bleeding edge unstable portage, mind! Stable 2.3.84-r1 looks almost identical when grepped ... BTW: has it been taken note of that (at least ESR) Mozillen like firefox still use python2.7 for quite a bit in the build process? -dnh -- 3rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped -- from a post by Simon Cozens
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hello, On Mon, 28 Dec 2020, Michal Górny wrote: >The only problem that I can think of are packages that depend >on libressl specifically and do not support openssl. I don't think we >have anything like that but I'll double check. A naive check finds these: Depends unconditionally on dev-libs/libressl: app-crypt/acme-client Depends conditionally on only dev-libs/libressl (no openssl alternative): net-misc/s6-networking net-misc/openntpd HTH, -dnh -- New, from IKEA: DARCKENSE, the chair. Available in white only. All-natural materials! -- Niklas Karlsson