Issue CAL-62 was opened many months ago thru me. However Teo already fixed it in git. For Manjaro we released Calamares 1.1.1-2 to our unstable branch today, which includes that fix.
Netrunner is using their own package. As Manjaro was the flag-ship distro most of the modules came from me anyway or were adopted from Thus installer. We are currently using only 3 custom modules. The grub module is maintained upstream, as we wanted to have most available modules used by Manjaro.
For Manjaro 0.8.13 we used an updated version of Thus as many needed features were not available in Calamares. On almost daily bases I’m building development builds of our installer medias with latest Calamares code. I personally think with Calamares 1.1.2 out, most of the known issues should have been fixed.
Regarding intel-ucode: this package is optional. Removing that package from your package list will not create a boot/intel-ucode.img file and therefor your install media will act as any other distribution not having intel-ucode in a separate image. You simply don’t ship it then.
Beside theming I see no bigger issues as those already reported in current Calamares releases. If there are still questions related to Manjaro, please feel free to ask me directly.
I’m working closely with Teo on the netrunner implementation of calamares, and via his recommendation I’ve been using the stable releases of Calamares instead of the unreleased git code. I have also been including some of the Manjaro modules as well, like hardware detection, etc…
Wouldn’t I not need use of these modules in our spin being based on Manjaro or would it be better to use Calamares without them?
What would you recommend on the intel-ucode implementation?
Are there any advantages and/or disadvantages to leaving this in my package list?
As Netrunner-Rolling is based on Manjaro you have to relate on our custom modules. Without them you won’t be able to finish your installation. I managed to get most of my modules upstream. Now we have those three modules left. You can take a look at all of them, to see why we need them.
Shipping intel-ucode is up to you. You simply will have some issues with newer Intel CPUs when you not ship it. See the Arch-Wiki for more information regarding that matter: https://wiki.archlinux.org/index.php/Microcode
I also recommend to use the git-code within Manjaro/Netrunner, as most fixes are related on that distro. You can always check when I update my Calamares build at our github repo under [packages-extra]. All updates are personally tested within my test builds for the upcoming 0.9-series of Manjaro as I’m also working closly with Teo on that installer. You can check the git history for which modules Teo adopted from Manjaro sources.
I tried modifying your pkgbuild at first “as is” using the netrunner branding, but it wouldn’t build properly. Teo is the one who recommended that I use the release tarballs instead.
What was the issue? If the release tarballs work for you it is also fine. I checkout always tarballs of latest git-snapshot. I’ve no issues with that. If you post me your log with error message I might be able to help you out. Else you can use a simple patch to get latest changes into your tarball. Example:
Things seem to be moving on this and from what I can make out, it looks as though the option has now been implemented and might be included in the next Calamares release(1.1.2). However, I’m sure @teo will correct me if I’m wrong
I would rather stick with officially released code whenever possible, I only consider using the AUR, patched and/or git versions of packages whenever they are not available in any other way.
Also, If Teo thinks it’s a better option to use the released tarballs than who am I to do otherwise, after all he is the main developer.
However, thanks for the suggestions, as I said earlier they are always welcome.
There’s nothing wrong with checking out a tag from git, I just find it’s potentially more work and less reliable than using our tarballs which don’t require messing around with submodules and have been tested to build for sure before being published. It’s really your choice how you prefer to package and deploy
Edit: to clarify, checking out a tag of a release from git is fine, but I do not recommend shipping a package based on Calamares git master to end users. The master branch might be broken at any time because that’s how master works. As a consequence, triaging bug reports filed against master and providing support is much more time consuming and error prone, and the end result is productivity loss for the user, for the packager and for the developer. If at any point you (or any other distribution maintainer in your situation) need a newer release than the currently most recent one, ask me and we can surely figure out a good time for releasing an official tarball in the near future.
All packages I release to the public are personally tested by me or one of our staff members. As I’m also a developer of Calamares I can read the code and clarify if there are no issues expected doing so. From Manjaros end it is always clear which git-tag was used. Using ‘master’ in general is not wise to do so. Another approach would be to use git-cherrypick cmds to just add specific patches. But you have to use a git repo for this. To get specific fixes into a final tarball I always recommend to use patches:
I didn’t mean to turn this into a debate, I do apologize for doing so.
I always appreciate input from all developers, maintainers and end users, but in the end I must be held accountable for what gets shipped to our end users even in beta and release candidates, so I think it wise to ship only officially released and supported code whenever and wherever possible.
