prusa-slicer 2.5.0

[Tom Callaway]

Hi folks,

I've done some work on getting prusa-slicer 2.5.0 into Fedora, and the good
news is that I have a set of package builds in a copr against rawhide that
seem to work:

https://copr.fedorainfracloud.org/coprs/spot/prusa-slicer-2.5.0/

There are some caveats:

* Some of the prusa-slicer tests are segfaulting. I just disabled the tests
for this build, but I know that is not ideal. At least one other upstream
(nix) which has builds of 2.5.0 has simply disabled all of the libslic3r
tests.
* I had to update tbb and opencascade
* openvdb is in the copr too, but there are no changes, it was just rebuilt
for new deps

https://spot.fedorapeople.org/prusa-2.5.0/ has the SRPMs and SPECs.

Given how intrusive this is, I would appreciate other eyes reviewing this
work.

Thanks,
~spot

[Miro Hrončok]

On 09. 01. 23 3:22, Tom Callaway wrote:
> Hi folks,
>
> I've done some work on getting prusa-slicer 2.5.0 into Fedora, and the good 
> news is that I have a set of package builds in a copr against rawhide that seem 
> to work:
>
> https://copr.fedorainfracloud.org/coprs/spot/prusa-slicer-2.5.0/ 
> https://copr.fedorainfracloud.org/coprs/spot/prusa-slicer-2.5.0/
>
> There are some caveats:
> Some of the prusa-slicer tests are segfaulting. I just disabled the tests for
>
> this build, but I know that is not ideal. At least one other upstream (nix) 
> which has builds of 2.5.0 has simply disabled all of the libslic3r tests.
> I had to update tbb and opencascade
> openvdb is in the copr too, but there are no changes, it was just rebuilt for
>
> new deps
>
> https://spot.fedorapeople.org/prusa-2.5.0/ 
> https://spot.fedorapeople.org/prusa-2.5.0/ has the SRPMs and SPECs.
>
> Given how intrusive this is, I would appreciate other eyes reviewing this work.

Thank you!

I won't be able to try this with a real printer before mid-February, but I can 
eye-ball the spec diff if you open a WIP pull request.

Is it possible to skip only the segfaulting tests instead of all of them?

[Dennis Gilmore]

I have an AArch64 desktop, so I tried to build the stack using mock-chain,
prusaslicer failed to build as the oom killer kicked in, my desktop has
64GiB ram and 64 cores. I am trying again, limiting the number of CPUs as
we do for power, I suspect we may need to limit the number of CPUs
globally, or possibly do something like Ceph does where it sets the number
of CPUs based on the ram and CPUs of the build host

Dennis

On Sun, Jan 8, 2023 at 8:22 PM Tom Callaway  wrote:
> Hi folks,
>
> I've done some work on getting prusa-slicer 2.5.0 into Fedora, and the
> good news is that I have a set of package builds in a copr against rawhide
> that seem to work:
>
> https://copr.fedorainfracloud.org/coprs/spot/prusa-slicer-2.5.0/
>
> There are some caveats:
> Some of the prusa-slicer tests are segfaulting. I just disabled the
>
> tests for this build, but I know that is not ideal. At least one other
> upstream (nix) which has builds of 2.5.0 has simply disabled all of the
> libslic3r tests.
> I had to update tbb and opencascade
> openvdb is in the copr too, but there are no changes, it was just
>
> rebuilt for new deps
>
> https://spot.fedorapeople.org/prusa-2.5.0/ has the SRPMs and SPECs.
>
> Given how intrusive this is, I would appreciate other eyes reviewing this
> work.
>
> Thanks,
> ~spot
> _______________________________________________
> 3dprinting mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Jason L Tibbitts III]

> > > > > Dennis Gilmore  writes:
> I have an AArch64 desktop, so I tried to build the stack using
> mock-chain, prusaslicer failed to build as the oom killer kicked in,
> my desktop has 64GiB ram and 64 cores. I am trying again, limiting the
> number of CPUs as we do for power, I suspect we may need to limit the
> number of CPUs globally, or possibly do something like Ceph does where
> it sets the number of CPUs based on the ram and CPUs of the build host

I know I'm late (been down with the pox for a month), but I just wanted
to note that you can use the %constrain_build macro to do something like
that.

%constrain_build -c 12
%constrain_build -m 2048

The first clamps the CPU count to 12.  The second clamps the CPU count
to the total RAM size of the system in MB divided by 2048, rounded
down.  This works in F36+.

- J<