Cannot install Server in Ubuntu

NO_PUBKEY 60EE7A4D9B483075

Problem here is a snipet:
404 Not Found [IP: 2620:2d:4000:1::81 443]

The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 60EE7A4D9B483075
Reading package lists… Done
E: The repository ‘Index of /uroni/urbackup/ubuntu noble Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: /repositories/home:/uroni/xUbuntu_24.04 - openSUSE Download InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 60EE7A4D9B483075

N: See apt-secure(8) manpage for repository creation and user configuration details.
carlos@carlos-frankenstein:~$ sudo apt update
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.

I used wget to get the file urbackup-server_2.5.33_amd64.deb but now get the following error:

The following packages have unmet dependencies:
urbackup-server : Depends: libcurl3-nss (>= 7.23.1) but it is not installable
E: Unable to correct problems, you have held broken packages.

The UrBackup server packages were built on a platform with curl sources below v8.3.0. curl 8.3.0 removed support for the NSS TLS library, hence the libcurl3-nss package is not available anymore on APT repositories of recent Debian/Ubuntu versions: Debian 13 Trixie and Ubuntu 24.04 Noble: https://github.com/curl/curl/pull/11459

Best solution would be to rebuild packages against libcurl with OpenSSL backend, i.e. libcurl4-openssl-dev headers package, since on both platforms, the that backend is used by the curl build itself as well, and hence almost assured to be preinstalled. It would be possible with GnuTLS as well, like done with ARM builds already, but the related libcurl3-gnutls dependency package (“libcurl3” vs “libcurl4” is no typo here, don’t ask me why the names differ, but they are correct) is often not pre-installed, making the install slightly heavier.

But there is another issue: Both distros switched to 64-bit time_t time64 syscalls, and those packages which make use of them got a t64 suffix. Hence they are called libcurl4t64 (OpenSSL flavour) and libcurl3t64-gnutls respectively. The new syscalls are required on 32-bit only, hence the packages do not differ on 64-bit builds, hence the packages “provide” the old name as well. But on 32-bit i386 and armhf builds this is a breaking change, hence attempting to install e.g. libcurl4 on such a systems will fail just the same way. This can be solved by allowing both to satisfy the dependency of the UrBackup server package, e.g.:

Depends: libcurl4 (>= 7.23.1) | libcurl4t64 (>= 7.23.1)
1 Like

Following. Does anyone have any ideas on if there are any updates to this issue coming down the pipe?

It does not even require any source code change, just consequently having OpenSSL flavor of libcurl headers installed, that’s all. If anyone knows whether the build workflows are public, I would open a PR to do the change. But I could only find a test workflow (which also uses the obsolete NSS flavor): https://github.com/uroni/urbackup_backend/blob/dev/.github/workflows/c-cpp.yml

Otherwise, keep an eye on new releases, which are hopefully compiled correctly (regarding modern libcurl support): https://hndl.urbackup.org/Server/

You could fork Show home:uroni / urbackup-server - openSUSE Build Service fix it, then create a PR/point me at the changes.

Same for the ppa.

Or fork the github repo, add a deb-pkg CD pipeline and then add a PR to add that. Would not say no if that runs on each tag or something.

1 Like

Nice, I wasn’t aware that there are official packages distributed via opensuse.org repository, which can be used with APT on Debian and even Raspbian as well: https://download.opensuse.org/repositories/home:/uroni/

Much better than looping through https://hndl.urbackup.org/Server/ to find the latest package via CLI tools.
Is there a particular reason this method is not documented at https://www.urbackup.org/download.html#server_debian or https://www.urbackup.org/debianserverinstall.html? I can write down the steps.

I will try it tomorrow, and add explicit Debian 13 Trixie builds in the same turn. Always confused when I see something which should be a Git repository (?) but without any source code tree. I guess workflows are in some meta dir that becomes visible after (creating an account and) forking it? Will find it out tomorrow.

@uroni
Learned that the OpenSUSE Build Service is not Git-based and no source code repository at all, but uses the build control/meta files. I skipped dealing with its own CLI tools (osc), just downloaded, altered and uploaded/replaced the Debian/debhelper control/meta files:

  • https://build.opensuse.org/package/show/home:MichaIng:branches:home:uroni/urbackup-server
  • Version build suffix incremented: 2.5.33.0-1 => 2.5.33.0-2
  • Build-Depends: libcurl3-dev => libcurl4-openssl-dev, which is the recent OpenSSL flavor libcurl on each Debian and Ubuntu version. debhelper should derive the correct runtime library package automatically:
    • https://packages.debian.org/libcurl4-openssl-dev
    • https://packages.ubuntu.com/libcurl4-openssl-dev
  • Added a changelog entry for 2.5.33.0-2
  • Replaced sizes and hashes in the .dsc and _source.changes files, though the latter lists a .buildinfo file I do not have. AFAIK this is generated by debhelper, but not sure which particular build is expected there, so I changed the filename only to what it would be and skipped altering size and hashes.

I checked how to add builds for other Debian versions and especially other architectures, but it looks like this would need to be done your end. I am suggesting, to make the repository fully usable:

  • Adding Debian_13 repository
  • Adding armv7l and aarch64 builds for Debian_11/12/13/Testing/Unstable
  • Adding riscv64 builds for Debian_13/Testing/Unstable
  • The “Add from a Distribution” does not list Raspbian_13, while it is in fact available: http://raspbian.raspberrypi.org/raspbian/dists/trixie/
    Not sure whether it can be added somehow manually, or where these distribution repos can be added. Raspbian (not to be confused with Raspberry Pi OS) is maintained by moreless one person, which explains that, while builds based on recently merged Debian sources are automatically done on a regular basis, keeping things elsewhere updated lags behind, if no one else is reminding or helping with it.
  • Something else that might need to be changed: Raspbian builds are currently done for armv7l, while it is an armv6l (+hardfloat) clone of Debian. The only reason it exists is that Debian does not support this arm(v6)hf architecture needed for the earliest Raspberry Pi models, but only either armel with softfloat or arm(v7)hf, which is incompatible. I am not sure about the practical effect of the format architecture selection in the OpenSUSE Build Service, but for Raspbian I would expect armv6l, which is the correct kernel architecture. … though comparing with the functional packages from the myMPD project, it uses armv7l as well, so it looks like it does not make a difference (in most cases), as the toolchain from the Raspbian repository assures no ARMv7-only instructions: https://build.opensuse.org/repositories/home:jcorporation

Now I wanted to open a pull request, or whatever it is called, but don’t know how :sweat_smile:. I can “Submit Package”, but that does not sound correct, does it?

If you are generally interested to make the download.opensuse.org repository usable for all Debian/Raspbian versions, including ARM and RISC-V packages, we do have automated tests for such user-side installations on all those Debian/architecture combinations, and I do own actual hardware for real tests as well.

v2.5.34 builds for amd64 do now depend on the libcurl4, which works on all Debian and Ubuntu versions. The Trixie-only builds from the Debian subdir and the OBS repository depend on libcurl4t64 with the dependency change suggested above merged. I tested these and can confirm they install and startup successfully for us on Debian Trixie and Forky/testing.

However, the OBS repo is configured to do amd64 builds only, which is likely the reason why armhf build still depend on libcurl3-gnutls, which does not exist on Trixie. For distro version-agnostic 32-bit packages to install on all Debian versions, there would be no way around declaring the dependency manually like libcurl4t64 (>= 7.23.1) | libcurl4 (>= 7.23.1) as I mentioned further above, since the t64 packages from Trixie do not “provide” the non-t64 ones. This is only the case for 64-bit. But even when doing so, I guess it would not work. The related 64-bit time_t transition on recent Debian and Ubuntu mans that for (only) 32-bit, new time64 syscalls are used, return 64-bit long time_t values. This is likely a breaking change compared to the classic syscalls returning 32-bit long time_t values on 32-bit systems. Only on 64-bit systems, this does not make any difference, since their time_t values were always 64-bit anyway. Hence distro version-agnostic 32-bit packages are likely not possible.

@uroni
Is enabling armv7l and aarch64 builds on OBS and riscv64 from Debian 13 Trixie (and other modern distros) on anything more than just adding them on https://build.opensuse.org/repositories/home:uroni, and letting OBS do everything for you? That would solve everything now, and would allow to use the OBS repository as primary install source, not only for Debian, making the launchpad repo and manual package downloads obsolete. Or are there limits regarding the amounts of builds/packages you can host on OBS? If so, I suggest to remove/disable Debian 8/9/10 and Ubuntu 16/18 and similarly long EOL distro version builds, in favor of better/wider support for recent distro versions.

I’ve added those

1 Like

I guess the riscv64 might not be working/available

1 Like

Many thanks, that was fast. Will implement, test, and report back, with instructions how to add the repo on dpkg-based distros.

Yeah, it seems the riscv64 builds have failed, but I cannot find logs. Maybe you have more access to see logs somewhere. Not uncommon that some flags or so need to be adjusted for riscv64, depending on build system stack. Was worth a try :slightly_smiling_face:.

Works great. Here instructions for Debian, Raspbian, and Ubuntu:

echo 'Obtaining distro ID and version from /etc/os-release'
. /etc/os-release
echo "ID=${ID}, VERSION_ID=${VERSION_ID}"

echo 'Obtaining repo URL based on distro ID and version'
case ${ID} in
'debian') distro='Debian';;
'raspbian') distro='Raspbian';;
'ubuntu') distro='xUbuntu';;
*) echo "ERROR: Unknown distro '$ID'" >&2; return 1;;
esac
REPO_URL="https://download.opensuse.org/repositories/home:/uroni/${distro}_${VERSION_ID}"
echo "REPO_URL=${REPO_URL}"

echo 'Downloading repo key to /etc/apt/keyrings/urbackup.asc'
sudo mkdir -p /etc/apt/keyrings
sudo curl -sSfLo /etc/apt/keyrings/urbackup.asc "${REPO_URL}/Release.key"

echo 'Creating repo sources list at /etc/apt/sources.list.d/urbackup.list'
echo "deb [signed-by=/etc/apt/keyrings/urbackup.asc] ${REPO_URL} /" | sudo tee /etc/apt/sources.list.d/urbackup.list

echo 'Updating local repo lists'
sudo apt update

echo 'Installing urbackup-server package'
sudo apt install urbackup-server

Works, at time of writing, on

  • all Debian versions up to 13 Trixie with armhf, arm64, and x86_64
  • all Ubuntu versions up to 25.04 Plucky with x86_64, and aarch64 on 23.10 + 24.04 + 24.10 (build failed on 25.04 for some reason)
  • all Raspbian versions up to 12 Bookworm

@uroni
On the right side build status list, it shows slightly more details about why the riscv64 build failed: “nothing provides base-passwd”. That is strange, since Debian 13 Trixie has that package for riscv64 architectures: https://packages.debian.org/trixie/base-passwd. I guess something is wired falsely internally or so.

For Debian 12 Bookworm btw it cannot for: riscv64 has been added with Trixie, i.e. can generally work with Debian_13 and Debian_Testing only. Related to that, would you mind to add all architectures to Debian_Testing as well? We started testing and providing Debian 14/Forky/testing images already :wink:.

Raspbian 13 Trixie and testing projects do exist in the meantime, after I emailed Adrian, the maintainer of those projects on OBS, who seems to be the OBS repository admin:

  • https://build.opensuse.org/project/show/Raspbian:13
  • https://build.opensuse.org/project/show/Raspbian:Next

However, when I tried to add them on my account via “Add from a Distribution”, they did not show up yet. I can add them via “Add from a Project” searching for “Raspbian”, but not sure whether things are internally wired correctly in this case. Also the meta info is wrong, being a copy&paste from Raspbian 12 Bookworm at time of writing.

EDIT: Dammit, 3 links in 1 post triggered all my other posts with links to be hidden by the system :sweat_smile:. Too many links to the same host, I guess, interpreted as spam. I can unhide them in 10 minutes.

EDIT2: Okay, I code-wrapped all URLs, but posts did not get unhidden automatically as system PM says. Probably because 5 posts were auto-hidden + the topic unlisted as a whole. Sorry for the inconvenience, gotta be careful until reaching a trust level :roll_eyes:.