Download from Printables fails on every model

[kozross]

Description of the bug

Prior to using the release of PrusaSlicer 2.6, I had no problems using the Printables integration. However, now, every time I attempt this, the download fails, always getting a 0KiB file, which the slicer fails to open (obviously).

Project file & How to reproduce

Zip of project

How to reproduce:

1. Open PrusaSlicer
2. Go to Printables.
3. Try to open any model in PrusaSlicer (I used this one here: prusaslicer://open?file=https%3A%2F%2Ffiles.printables.com%2Fmedia%2Fprints%2F230356%2Fstls%2F2096125_9cfc404b-0edb-4c30-a332-5ae014742d16%2Fmodular__004___x1x2.stl).
4. Watch things not work.

Checklist of files included above

• [X] Project file
• [X] Screenshot

Version of PrusaSlicer

Version 2.6.0

Operating system

Arch Linux

Printer model

Prusa MINI+

[lukasmatena]

I assume you are running some build from Arch repository. Can you reproduce the problem with the AppImage downloaded directly from our github (here)? Thanks.

[kozross]

@lukasmatena - I just tried using a release from Github, and those indeed work. Closing this and reporting the issue to the Arch maintainers.

[lukasmatena]

Thanks for the update.

[lukasmatena]

@kozross Just out of curiosity. Was it the AUR package, or the official one?

[kozross]

@lukasmatena - it was the one in extra, which I guess is as official as it gets. Bug report is here.

[svenstaro]

I'm the downstream maintainer and I have no idea what's wrong and how to get debug output on this. Could you give me some pointers?

[lukasmatena]

@svenstaro Hi. To be honest, I have no idea what could the problem be. In general, Linux PrusaSlicer packages usually get broken because the packagers link PrusaSlicer dynamically against whatever libraries are currently bundled with the distribution. And because every library version has its own set of bugs, we have our workarounds in place, the compatibility is not exactly what semver numbers would indicate and so on, using a different version changes the behavior of the application and effectively invalidates our testing. And because the maintainers are capable of releasing the package without at least trying to run the binary, the results are sometimes sad: https://github.com/prusa3d/PrusaSlicer/issues/8299#issuecomment-1186748653. The problem most frequently happens with wxWidgets, which we heavily rely upon. Our in-house builds of PrusaSlicer 2.6.0 use patched version of wxWidgets 3.2 from prusa3d repository, as you can see in deps/wxWidgets/wxWidgets.cmake.

As a result of this all, we usually recommend our AppImages to our users, and advice them to stay away from distribution packages, which from our experience are very often broken, outdated or both.

If you want to debug the issue, you can try to link PrusaSlicer statically against exactly the same libraries that we do (described here). If the problem disappears, it is the case I described above, and in that case we cannot provide any more support. If it does not disappear, you may try to run with --loglevel=5 and check stdout for clues, in which case we would be interested to know what the problem is.

[svenstaro]

This is how we build PrusaSlicer in Arch Linux. As you can see, we use the patched version of wxWidgets from you guys and statically link it. However, vendoring deps is usually frowned upon in distros for reasons you are probably aware of and so we try to use as many system deps as we can. If dependencies have bugs, they should be fixed upstream so that all downstreams can benefit from the fixes and not just a single vendor. I'm a bit saddened that you try to work around distros as opposed to embracing them and working with them. We want to ship your app as we ship many thousands of apps and the overwhelming majority of them run just fine on system deps and it's considered a bug if that's not possible. I'd very much appreciate if our relationship could be like that. Distro maintainers are your friends but sometimes that's sadly not always mutual.

Anyway, I digress. I was able to get a full log of a failure when opening a link directly from Printables: slicer.log. In contrast, this is the log from a statically vendored version: slicer-working.log. The static version works.

As we can see, downloading works in both cases. I'd also like to note that downloading profile updates works fine. I therefore conclude that system curl is working fine. However, the resulting file is 0 bytes in size and there are no obvious errors in the log as far as I can tell. The obvious difference is the progress which looks entirely different with some questionable float action going on in our version. Any ideas about that?

[svenstaro]

@lukasmatena any thoughts or pointers? I could try to debug this in-depth if it would help.

[svenstaro]

Alright, we basically threw the towel and now just use upstream deps. At least this will now mean that any bugs reported from our users should also be present in your builds.

[lukasmatena]

@svenstaro Sorry for the late reply, I was not working for the past week.

any thoughts or pointers?

Sadly, no. @kocikdav might have an idea, he knows more about what happens during the download.

Alright, we basically threw the towel and now just use upstream deps. At least this will now mean that any bugs reported from our users should also be present in your builds.

Thanks. We will gladly process any issue reproducible in our static builds.

OFF TOPIC FOLLOWS:

I'm a bit saddened that you try to work around distros

After 5+ years working on PrusaSlicer (and using Linux most of that time btw), I noticed that the theories of package management do not align well with practice. There are many different Linux distributions, each having its own set of currently "stable" libraries, and the list is constantly being changed. We simply cannot allocate our time to solving the never ending stream of issues of the "I linked against this and that, it does not work, you should consider it a bug and fix it" type. We did this in the past, but had to stop because we would not do anything else. Our current stance is "If it works in our builds, it is not our problem." By using different libraries than we do, the package effectively becomes a different binary application, so...

If dependencies have bugs, they should be fixed upstream so that all downstreams can benefit from the fixes and not just a single vendor.

It is easy to say what others "should" do and what good it would make. In reality, wxWidgets took 9 years to get from 3.0.0 to 3.2.0. The 3.1.x series was not shipped with the distros and 3.0.x only contained some of the improvements. We can hardly wait that long, not to mention that some of the features we added in our wxWidgets branch did not get to 3.2 at all. The upstream maintainer decides what gets merged - which is the way it has to be. And there are many good reasons for not merging something.

Distro maintainers are your friends

That is warming, but we also have many other friends - our customers. We are a multiplatform application and about 95 % of them do not even use Linux. We have our statistics about how many use Arch and how many use the packages and I estimate that the problem may affect 1 user in 500. We have to prioritize and "the needs of the many outweigh the needs of the few". Or the one - especially given that the one can always use our AppImage.

I know that my words are blunt, but I think that showing the things from this perspective might help in understanding our stance.

[svenstaro]

It's important to note that there will still definitely be differences between our builds and your builds. We use different compiler versions and flags. I hope that despite these differences, you will still accept bug reports from our users now that we use your dependencies directly.

And thank you for the off-topic answer. I do absolutely understand the needs of upstreams, being one myself in many cases. I think this is also why we're seeing lockfiles so commonly now with other ecosystems. Rust stuff and such is usually a lot easier to package, for instance. :)