Arch Linux User Repository

(follow-up) - yeah, currently it's a bit of a mess :

• I found permalinks, like https://ltspice.analog.com/download/24.1.0/LTspice64.msi
• the above is the same file as what you currently (2025/01/25) get from https://ltspice.analog.com/software/LTspice64.msi
• the version string in the .json file is not 24.1.0 as expected, but '24.0.12' ....
• if you download https://ltspice.analog.com/download/24.0.12/LTspice64.msi, the .json says 24.0.11...

I'm going to try using a permalink, just so the build doesn't break on their next update, but I may not notice for a while to update the PKGBUILD. We can revisit this if analog gets their versioning straightened out.

@Mighty_Pig

Make sure your PKGBUILD is up to date (and matches https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ltspice ), it should be fixed since jan 23

It is still failing to download the file.

 -> Downloading LTspice64.msi...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
==> ERROR: Failure while downloading https://ltspice.analog.com/download//LTspice64.msi
    Aborting...
 -> error making: ltspice-exit status 1
 -> Failed to install the following packages. Manual intervention is required:
ltspice - exit status 1

Seems like the version is not added correctly to the url?

Edit: For some reason the source inside the PKGBUILD is as following:

source=("${pkgname}.sh"
        "${pkgname}-help.sh"
    "conv.sh"
    "https://ltspice.analog.com/download/${_filever}/LTspice64.msi"
    )

It seems to be using the _filever variable instead of the pkgver it should be using? Even removing cache and redownloading everything still results into having the _filever variable inside the PKGBUILD?

It looks like _filever=24.1.0 is missing?

oops, leftover from a test, and when I re-tried 'makepkg', of course I already had the .msi file downloaded and didn't notice. Should work now.

I'll pin my other comment just to draw attention to the versioning situation.

@fenugrec It looks like _filever=24.1.0 is missing? That aside, thank you for taking over this package and providing such prompt maintenance.

P.S. By 'adding a note,' I actually meant a pinned comment, but your solution is even better!

(follow-up) - yeah, currently it's a bit of a mess :

• I found permalinks, like https://ltspice.analog.com/download/24.1.0/LTspice64.msi
• the above is the same file as what you currently (2025/01/25) get from https://ltspice.analog.com/software/LTspice64.msi
• the version string in the .json file is not 24.1.0 as expected, but '24.0.12' ....
• if you download https://ltspice.analog.com/download/24.0.12/LTspice64.msi, the .json says 24.0.11...

I'm going to try using a permalink, just so the build doesn't break on their next update, but I may not notice for a while to update the PKGBUILD. We can revisit this if analog gets their versioning straightened out.

@yaoyun thanks. Yes, I thought of this when I adopted the package; I'm not sure if analog has permalinks to previous versions. In this case I think it takes a manual intervention anyway; IIRC they changed some of the help hierarchy and some scripts need tweaking. Agreed some form of warning would be nice. I don't think it's possible to output anything before makepkg validates the sums however...

The sha256sum for LTspice64.msi needs an update after the Jan 21 upstream change.

~/.cache/paru/clone/ltspice master 
❯ wget https://ltspice.analog.com/software/LTspice64.msi
2025-01-23 02:14:45 (28.2 MB/s) - ‘LTspice64.msi’ saved [135219200]

~/.cache/paru/clone/ltspice master ?1  
❯ sha256sum LTspice64.msi
404f065708fadb95d73ba8135ef8ac2e851b8cd1d57db9cd77dae64047e84815  LTspice64.msi

Keeping this updated could get annoying. Maybe add a note for users to update the checksum manually or find the correct .msi version themselves (e.g., via Wayback Machine)?

Ok. Bumped pkgrel to -2, help docs should work, I think I haven't broken anything else.

I noticed some weird effects though when rotating some symbols, is anyone else seeing this : https://ez.analog.com/design-tools-and-calculators/ltspice/f/q-a/591072/voltage--and-current-controlled-switch-symbols-do-not-rotate-properly/553447

@c0d3z3r0

the helpfiles are annoying enough that I'm cooking a script to adjust the filenames : (WIP)

#!/bin/bash

# ensure there are no htm(l) files with external src=... resources
if  grep -P 'src=\"h.*?[A-Z][^\>]+\>' ` find -type f -name '*.htm*'`; then
    echo Can't fix docs : 
fi

# get 'src=' refs containing uppercase chars, trim 'src="' prefix, sort, list unique
# grep -ohP 'src="[^"]+[A-Z][^"]+' ` find -type f -name '*.htm*'` | sed 's/.*\"//' | sort | uniq

# this is actually slower and not much clearer
# find -type f -name '*.htm*' -exec grep -ohP 'src="[^"]+[A-Z][^"]+' '{}' \; | sed 's/.*\"//' | sort | uniq


flist=$(grep -ohP 'src="[^"]+[A-Z][^"]+' $(find -type f -name '*.htm*') | sed 's/.*\"//' | sort | uniq)

for file in $flist; do
    if [ ! -e "$file" ]; then
        # file with wrong case; check if lowercase exists and rename

        all_exist=false
        break
    fi
done

@fenugrec Nice, thanks!

"$HOME/.ltspice" was required for the env, right. Can be dropped.

Oh, no idea how to fix the help :/ Wine should do case-insensitive lookups, but I remember having such problem earlier... no idea how I had fixed that