Testers/contributors welcome.
Here’s the first problem.
* Detected file collision(s):
*
* /var/lib/urbackup/version.txt
* /usr/share/urbackup/urbackup_ecdsa409k1.pub
What are the consequences of moving those files?
Client auto-update and download stops working.
Thanks, but actually I just meant the duplicates, not both sets.
However, since the purpose of these files is upstream auto-updates, and that conflicts with downstream package management anyway, then for the purpose of distro packaging these files should not be installed at all, since at best the result would be unmanaged files, and at worst we’d end up with broken dependencies.
Simply omitting those files will prevent that, however that leaves a non-functioning option in the UI, which in itself isn’t a serious issue, except that it might cause confusion and needless bug reports. The cleanest solution would be a build-time configure option to remove the auto-updates option in the UI, but in the meantime I can simply apply a patch for downstream use.
Sure, thanks. Tell me if it is ready to be added to the download page 
Idk what the Gentoo policy is but would changing the defaults of the “download_client” client setting to false and removing the server update notifications be enough?
If that changes the default behaviour to not auto-update, then yes.
I believe Gentoo’s packaging policy is not remarkably different from any other distro, except that it has a far more liberal view of such things as copyrights and patents. This is a luxury it can afford because, as a source-based meta-distro, it doesn’t actually host any software, and thus can “package” pretty much anything it wants. Gentoo could literally package Windows 10, since the package (ebuild) is just a text file containing a URL to the upstream sources (and build/install instructions).
Mostly we only care that packages are not broken by default. In that context, “broken” can mean that either the package doesn’t work, or that it causes something else on the system not to work. File collisions (as above) would be one example. Another would be an inconsistent record of installed files resulting from an out-of-tree update.
I think it’s generally true that distros expect to control the software installed on the system, via one form or another of package manager, and that anything that “auto-updates” itself is considered a violation of the package management system, since it causes the database of installed files to be inconsistent, and introduces unmanaged files into the system that will probably have broken dependencies.
Theoretically it could even result in binaries unsupported by that system architecture. Not all “x86” systems are created equal, even beyond questions of address space. I discovered this years ago when my not-really-i686 AMD K62 CPU turned out to really be an i686 minus CMOV, and therefore only really usable when rebased to i586.
In the Windows world none of that matters, since everyone gets the same unoptimised binaries without choice, and anything too old, too new, or too niche is simply unsupported.
In the Linux world there are as many permutations as there are distros.
In the Gentoo world there are as many permutations as there are Gentoo users. 
The server can only display that a new version is available, that overlaps with the distribution mechanisms, but doesn’t really hurt in any case (and can be disabled).
The client update only works with Linux clients which have been compiled with -DURB_WITH_CLIENTUPDATE, which hopefully only people do who want to build the distribution-independent binary installer themselves.
So there isn’t any danger of that happening.
1 Like
May I ask, why is urbackupsrv being installed into both bin and sbin?
sbin_PROGRAMS = urbackupsrv$(EXEEXT)
bin_PROGRAMS = urbackupsrv$(EXEEXT) urbackup_snapshot_helper$(EXEEXT)Hmm idk, I guess it does not break anything if I remove the sbin one? $(EXEEXT) is for Windows?
Well, the FHS says that “non-essential binaries used exclusively by the system administrator” should go into /usr/sbin, and I’d say that the server component of a backup program qualifies (unprivileged users will not be running this independently), so really it should be the /usr/bin copy that’s removed. This is true even if the program drops privileges.
That then raises the question of where urbackup_snapshot_helper should live. Presumably it’s being called by urbackupsrv after it drops privileges, in which case it needs to stay in bin.
On the other hand, Gentoo “does not consider the Filesystem Hierarchy Standard to be an authoritative standard”, so I don’t suppose it matters either way, as long as there is only one copy of the file … somewhere.
The server ebuild is now stable and ready to be added to the download page.
Gentoo users will know what to do.
The client ebuild will be ready soon.
Changes:
- All upstream autoupdate code, files and UI elements have been removed, to avoid package management conflicts and any subsequent confusion
- gcc “warning: _FORTIFY_SOURCE redefined” corrected by first undefining then redefining
- Fixed bad perms on www files (executable bit is not necessary, and breaks both FHS and POSIX)
- Updated and Gentoo-fied “FILES” section of man page, and corrected formatting
- Installed compressed man page in FHS compliant directory
- Provided Gentoo-fied init script for OpenRC
- Removed redundant second copy of urbackupsrv binary from /usr/bin
- Use Gentoo-fied (and FHS compliant) ${localstatedir}, /var/lib rather than /var, for package database files
- Set owner and group to urbackup for ${localstatedir}/urbackup and ${datadir}/urbackup/www
- Honoured configure options for crypt, mail, fuse, zlib and gcc-fortify in USE flags
Built and tested OK.
1 Like
I’d prefer linking to a stable URL. Could you tag a release please, so that I can link to e.g. https://github.com/HomerSlated/urbackup-server-gentoo/releases
The client ebuild is also now ready.
Changes:
- Upstream autoupdate disabled via configure option, as per the server build
- Gettext files installed into FHS compliant directory /usr/share/locale/${LINGUAS}/LC_MESSAGES
- Ebuild honours LINGUAS USE flags, so only requested gettext languages are installed
- Installed compressed man page in FHS compliant directory
- gcc “warning: _FORTIFY_SOURCE redefined” corrected by first undefining then redefining
- Logrotate config borrowed from server version
- Provided Gentoo-fied init script for OpenRC
- Honoured configure options for gcc-fortify and headless in USE flags
Built and tested urbackupclientbackend, urbackupclientctl and urbackupclientgui OK.
I’ve just added the 2.1.7 beta client and server ebuilds to the repo.
For reference, see this bug report on gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=596870
1 Like
Snapshot helper scripts added to ebuild.
Thank you, Homer, for providing an ebuild!
I had problems with the line
inherit user systemd
So I removed it and rebuilt the package.
It started to compile but failed in the end…I’ll do a World-Update and report back if the issue persists!
Hi @SowaNMS and thanks.
Please be advised that systemd support was added by @jonesmz, and unfortunately I don’t use systemd or know anything about it.
I’m afraid I’ve not updated my repo in very a long time, and the current build is very outdated.
I advise grabbing the source from the urbackup download section and building that instead.
I may revisit this at a later date and update the ebuild, but for now I’m working on other projects.
If you post the build log errors here (as attachments), someone else may be able to assist.
Thanks again.