Package Details: luxcorerender 2:2.7.beta1-2

Git Clone URL: https://aur.archlinux.org/luxcorerender.git (read-only, click to copy)
Package Base: luxcorerender
Description: Physically correct, unbiased rendering engine.
Upstream URL: https://www.luxcorerender.org/
Licenses: Apache
Provides: luxrays
Submitter: bartus
Maintainer: bartus (howetuft)
Last Packager: bartus
Votes: 14
Popularity: 0.000004
First Submitted: 2018-05-11 21:03 (UTC)
Last Updated: 2025-04-28 09:06 (UTC)

Dependencies (21)

Sources (15)

Pinned Comments

bartus commented on 2020-06-11 15:32 (UTC) (edited on 2020-08-22 09:39 (UTC) by bartus)

This package is also hosted on GitHub.
Use env vars to control build process:
  • DISABLE_OPENCL=1 to skip opencl kernel build (yields DISABLE_CUDA=1)
  • DISABLE_CUDA=1 to skip cuda kernel build.
Usage cases:
  • export DISABLE_CUDA=1 before build
  • DISABLE_CUDA=1 ~your-aur-helper~
  • makepkg DISABLE_CUDA=1
  • yay -S blender-2.8-git --mflags "DISABLE_CUDA=1"

bartus commented on 2019-04-10 11:42 (UTC)

Please report issues and patches to luxcorerender@github.com

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 9 Next › Last »

howetuft commented on 2024-01-28 09:59 (UTC)

@DarkShadow

Hello, Can you please provide some more information (log, error message...)? Is it the same issue as in your previous post or did something evolve? Thank you

DarkShadow44 commented on 2024-01-26 18:27 (UTC)

Still doesn't build for me

howetuft commented on 2023-08-21 17:55 (UTC)

@MarsSeed Done (sorry, I thought it had to be reset when incrementing pkgrel...)

MarsSeed commented on 2023-08-21 11:40 (UTC)

Epoch was decreased from 2 to 1. Please set it back to 2. You should never decrease the epoch.

howetuft commented on 2023-08-21 05:16 (UTC)

You see me absolutely confused. I've just relaunched a makepkg -fis against the package, after having cleaned build dirs: everything worked fine for me. Again, my previous build in a clean chroot with devtools (extra-x86_64-build -- -I fmt9-9.1.0-5-x86_64.pkg.tar.xz -I pyside6-tools-wrappers-20230711-1-any.pkg.tar.xz) was also successful. So I cannot reproduce the issue (not denying it did not happen on your system, obviously). I would propose: let other users report the same anomaly if they encounter it - and, if someone is in this case, please pastebin build log.

DarkShadow44 commented on 2023-08-20 22:41 (UTC) (edited on 2023-08-20 22:41 (UTC) by DarkShadow44)

The first time I run makepkg is a fresh git clone from the AUR. That breaks.

But running makepkg again works for some weird reason.

Btw, command is "makepkg -fis" in both cases

howetuft commented on 2023-08-20 17:58 (UTC)

The first time you run makepkg, do you clean beforehand? I mean, do you clean/erase the previous build directory? Otherwise, there can be remnants from the previous build, especially in CMake files, that interfere with the new build...

DarkShadow44 commented on 2023-08-20 17:19 (UTC)

So, I just retried, and the results are weird. When I run makepkg, I get the same fmt error in spdlog. But when I run makepkg again without cleaning, it suddenly works...

Not sure why that is, but it's very reproducible.

howetuft commented on 2023-08-19 14:59 (UTC)

@DarkShadow44 I fixed fmt9 dependency, so this should not be an issue any more. I also slightly modified the last patch, to reinforce fmt9 include paths over fmt10 ones.

I rebuilt the package in a clean chroot (with devtools) and everything worked fine for me.

Could you please retry to build on your side?

howetuft commented on 2023-08-19 10:47 (UTC)

@DarkShadow44 OK, thank you. At least, it points out one thing: I forgot to add fmt9 in depends, in lieu of fmt :-( I shall quickly fix that. For the second issue, once fmt9 is installed, I'm a bit disconcerted: that is exactly what fmt9 should fix. I still have to investigate...

« First ‹ Previous 1 2 3 4 5 6 7 .. 9 Next › Last »