Package Details: cura-aleph-bin 21.08-1

Git Clone URL: https://aur.archlinux.org/cura-aleph-bin.git (read-only, click to copy)
Package Base: cura-aleph-bin
Description: A full 3D printing solution aimed at RepRaps and the Ultimaker. This is the Aleph Objects fork, specialized for the Lulzbot series of 3D printers.
Upstream URL: https://www.lulzbot.com/cura
Keywords: 3d aleph cura lulzbot printer slicer
Licenses: AGPL3
Conflicts: cura, cura-bin, cura-git, cura-not-so-old, cura-old
Provides: cura
Submitter: gammy
Maintainer: gammy
Last Packager: gammy
Votes: 3
Popularity: 0.000000
First Submitted: 2016-03-11 13:46 (UTC)
Last Updated: 2017-09-29 11:17 (UTC)

Latest Comments

1 2 Next › Last »

HarlemSquirrel commented on 2018-01-18 04:05 (UTC)

Update, I finally got it working! Let me know if it works for you. https://aur.archlinux.org/packages/cura2-lulzbot/

HarlemSquirrel commented on 2017-11-29 02:53 (UTC) (edited on 2017-11-29 02:54 (UTC) by HarlemSquirrel)

I built a cura 2 PKGBUILD but sadly it's not working. If anyone would like to help figure out why I'd greatly appreciate it! https://aur.archlinux.org/packages/cura2-lulzbot

gammy commented on 2017-11-27 14:51 (UTC) (edited on 2017-11-27 14:57 (UTC) by gammy)

TheZoq2 was kind enough to flag this package as out of date due to Aleph Objects releasing the Cura 2. *This* package is however unrelated to Cura 2, which is drastically different from this legacy version, which is still being developed in parallel. One major difference between these programs is that Cura2 drops i386 support entirely, and is written in python3 rather than python2. I have therefore unflagged the out-of-date flag. I have been planning on making a cura2-aleph-bin package (I want it too, after all!), but as is often the case, work and life in general keep getting in the way. Maybe you'll beat me to it?!

gammy commented on 2017-07-03 09:25 (UTC)

Updated the package to 21.06 (thanks for the flag HarlemSquirrel). It's worth noting that you will (if your system is up to date) now see two ABI compatibility warnings when starting Cura. It should not affect any functionality. In short, this is because this (arch/manjaro) package is still based on the Debian Jessie package. Debian Stretch is now available. However the i386 release is still in testing, and no Cura package is yet available for i386. This will probably amended in the next release.

gammy commented on 2017-05-23 13:40 (UTC)

Updated the package to 21.04 (thanks for the flag HarlemSquirrel). I've changed the upstream URL from download.lulzbot.com to download.alephobjects.com. When I checked, the 21.04-2228 had not yet been uploaded to the prior, although it existed on the latter.

gammy commented on 2016-12-13 11:08 (UTC)

@HardlemSquirrel marked this package as out of date some 20 days ago and I had completely missed the e-mail. I've now updated the package and apologise for the delay.

gammy commented on 2016-10-08 19:13 (UTC) (edited on 2016-10-10 16:29 (UTC) by gammy)

Thanks for that information @HarlemSquirrel. I've updated the package to 21.00-2 with your suggestion. To clarify, this will only provide a "correct icon" on a desktop or in a menu, but won't solve the problem where Cura's "launch icon" remains unset (i.e the icon displayed in your task tray or dock). This is mainly because Cura never sets an icon. It's curious that this is the case, as the WM_CLASS (which StartupWMClass refers to) is a run-time name of a specific window. The freedesktop icon specification sure can be confusing. Another thing worth noting is that, after some investigation, it turns out that the icon which Cura comes with - "c.png" - is in fact not a png at all - it's a Microsoft .ico file where each icon size is a layer in the image. It's amazing that any program (like Thunar, Refind, etc) can load it!

HarlemSquirrel commented on 2016-10-08 18:36 (UTC) (edited on 2016-10-08 18:37 (UTC) by HarlemSquirrel)

I was able to get Cura to dock to the correct icon by adding one line to /usr/share/applications/cura.desktop StartupWMClass=Cura.py

gammy commented on 2016-05-12 22:24 (UTC)

I'm on Pacman v5.0.1 - libalpm v10.0.1 on a few machines, so it doesn't sound like you're up to date! :) Has the behavior of makepkg changed recently regarding this symlink business? I'll just try to run either of the files for now - I don't see what harm it could do. As to the wxpython dependencies, "wxpython" (from extra/) is already a dependency, and it appears to be compatible; that is, wxpython 3.x is as far as I know not related to the python2/3 divide. Wxgtk depends on wxpython, so an explicit depend is not necessary there either. I lack both wxpython2.8 and wxgtk2.8 on three of my test-machines - and 'import wx' works fine from python2. That doesn't however mean that I'm right.. I've added a reasonably noisy splash notice regarding permissions - let me know what you think. Thanks for the feedback and suggestions, have a good night!

tjkopena commented on 2016-05-12 14:19 (UTC)

I had a couple problems getting the package to work and actually don't know if it does work for me now; I wound up switching to working from the lulzbot cura git repo. I had updated the whole system before trying, so I assume I'm up to date. I'm using makepkg (pacman) 4.2.1 on x86_64. Editing the diff as commented below made the build pass for me, it failed otherwise. Once built, cura would die silently on startup. The culprit turned out to be import wx, which was throwing an import error somehow not being caught and reported by the startup script (which does seem to try/catch ImportError). There seem to be dependencies missing. I had to install the following to get it to work: wxpython2.8 wxgtk2.8 The package should maybe also note that permissions need to be setup for the serial device in order to not have to run cura as root. Thanks for maintaining the package!