Native Fedora install script: iTunes 12.13.11.1 + patched AMDS in a plain Wine prefix #10

New issue

Closed

opened 2026-10-28 13:25:28 +01:00 by The_Void · 0 comments

The_Void commented

2026-10-28 13:25:28 +01:00

Owner

iTunes now runs on the user's Fedora desktop under plain Wine, not on the headless box (operator decision 2026-10-28; KNOWLEDGE.md → Scope). The containers stay as the test rig only.

Everything that made iTunes work was a Wine fix, not a container fix (KNOWLEDGE.md → Build grid, Library and playback, Device service). So the script repeats it in a normal Wine prefix:

Check for Wine and the other tools (msitools, socat) and print the dnf install line if any is missing. Use Fedora's own Wine; nothing so far was run on it. Record its version.
Create a 64-bit prefix (default ~/.local/share/itunes-wine, overridable) and install iTunes64Setup.exe 12.13.11.1 (/qn /norestart). Take the installer path as an argument, or download it from Apple and check its sha1 (HANDOFF.md).
Extract AppleMobileDeviceSupport64.msi, set SetAppleMobileDeviceServicePermissions64's condition to 0 with msibuild, and install it with msiexec /qn.
Disable the AMDS service (Start=4) so 127.0.0.1:27015 is free for the bridge (the bridge issue).
Add a .desktop launcher.

Test it here in a fedora:44 container, with Xvfb and PulseAudio as the test harness only. Run the script there, then the existing checks with wine/library.js: iTunes 12.13.11.1 starts, an MP3 imports with its tags and plays to the sink, and the AMDS files are present with the service disabled. Record any difference from the Debian/WineHQ results in KNOWLEDGE.md.

Done when the script runs unattended on a clean fedora:44 container and those checks pass, and AGENTS.md → Commands gives the one line the user runs on the desktop.

iTunes now runs on the user's Fedora desktop under plain Wine, not on the headless box (operator decision 2026-10-28; KNOWLEDGE.md → *Scope*). The containers stay as the test rig only. Everything that made iTunes work was a Wine fix, not a container fix (KNOWLEDGE.md → *Build grid*, *Library and playback*, *Device service*). So the script repeats it in a normal Wine prefix: 1. Check for Wine and the other tools (`msitools`, `socat`) and print the `dnf install` line if any is missing. Use **Fedora's own Wine**; nothing so far was run on it. Record its version. 2. Create a 64-bit prefix (default `~/.local/share/itunes-wine`, overridable) and install `iTunes64Setup.exe` 12.13.11.1 (`/qn /norestart`). Take the installer path as an argument, or download it from Apple and check its sha1 (`HANDOFF.md`). 3. Extract `AppleMobileDeviceSupport64.msi`, set `SetAppleMobileDeviceServicePermissions64`'s condition to `0` with `msibuild`, and install it with `msiexec /qn`. 4. Disable the AMDS service (`Start`=4) so 127.0.0.1:27015 is free for the bridge (the bridge issue). 5. Add a `.desktop` launcher. **Test it here in a `fedora:44` container**, with Xvfb and PulseAudio as the test harness only. Run the script there, then the existing checks with `wine/library.js`: iTunes 12.13.11.1 starts, an MP3 imports with its tags and plays to the sink, and the AMDS files are present with the service disabled. Record any difference from the Debian/WineHQ results in KNOWLEDGE.md. Done when the script runs unattended on a clean `fedora:44` container and those checks pass, and AGENTS.md → Commands gives the one line the user runs on the desktop.

The_Void added the

Claude

implementation

priority/high

labels

2026-10-28 13:25:28 +01:00

The_Void added a new dependency

2026-10-28 13:25:29 +01:00

#8 Local bridge: socat 127.0.0.1:27015 to the desktop's usbmuxd, as a systemd user unit

The_Void added this to the Ready to work milestone

2026-10-28 13:25:31 +01:00

The_Void referenced this issue from a commit