On 12/25/19 9:48 PM, Norbert Preining wrote: > Hi Eli, > > thanks for the report.
[...] >> - Disable-update-check-by-default.patch >> >> While I'm on the topic of Debian-specific patches... this patch seems to >> cause calibre to start up with the update checker disabled, but that >> will disable both the application version check and the plugins version >> check, and I don't believe the latter is appropriate to disable. Please >> check if this is overreaching, and find a more targeted patch if so. > > Indeed, but I think this was the original idea. Programs should not > start up and contact outside entities by default - at least this is what > I learned back then, maybe this is not a requirement anymore. Could be. The patch doesn't clearly explain the rationale, so without insider information I cannot be sure whether the intention was to prevent contacting a server, or just to prevent confusing messages about an update that isn't applicable to a stable release. For what it's worth, this is linked to: https://calibre-ebook.com/dynamic/calibre-usage "Usage statistics are collected whenever a user starts calibre. Every calibre installation has a unique ID, this ID remains unchanged by upgrades and even an uninstall/re-install. This ID is used to collect usage statistics. Only this ID is stored, no other identifying information is collected." So per the developer's promise, nothing is logged other than a UUID, operating system, version, and icon theme (if any). That last bit of information will be used in Preferences -> Look & Feel -> Change icon theme, in order to sort by popularity. I don't know if that commitment is sufficient for Debian. > I will check back with debian-devel. I would change the patch to make > it only check for updated plugins. We don't want users to try to mess up > the dpkg version with some hand-updates as root, that will not work out. That's a reasonable concern. My distro provides updates usually within a day (well, we are rolling), so I don't bother to disable this as generally no one is going to sudo install anything. Fedora has a patch which completely prevents the application from checking for application updates, but leaves the plugin updater check running. Perhaps you would find this interesting? https://src.fedoraproject.org/rpms/calibre/blob/master/f/calibre-no-update.patch > The patches that will be used (atm) for the package I am preparing are > - Disable-update-check-by-default.patch > see above > - Fix-desktop-integration-installation.patch > I am surprised that on Arch nothing like this is necessary ... > When I do this on Debian, the calibre installer tries to > actually install into system directories Well, it cannot because it doesn't run as root... I used to use XDG_DATA_DIRS in my recipe, until I eventually submitted https://github.com/kovidgoyal/calibre/commit/2a63948440fe2d60a5573b829f27000d5c0389e2 upstream to do this automatically when staging an install into a packaging root. I haven't run across any cases of it attempting to install to system directories when using this. xdg-desktop-menu does have some strange interactions with /usr/share/gnome/apps, but AFAICT it manages to disable those bits if the directory is not writable by the invoking user. > - no-detach-in-desktop-files > also something reasonable I think > - Hardening-Qt-code.patch > same with that > So I really think that Debian packages do **not** degress from upstream > as far as it is always assumed. The only *functional* change is the > update check, which, as I wrote, is a requirement AFAIR of Debian. To be fair, the package is a lot better now that it's using the upstream-approved mathjax bundle, and now that both Debian and calibre agree on whether markdown is a system module. Also several fixes that resulted from the forum thread at https://www.mobileread.com/forums/showthread.php?t=288093 Way back in the day, when cherrypy was still in use by the calibre codebase, that was broken on Debian too... there were a whole bunch of local modifications in the calibre fork. I actually submitted a rather snarky bug report to Arch Linux about that, since it was broken there too, although that was before I joined the packaging team. Taking a look at the current packaging you have, I'm happy to say that nothing jumps out at me as problematic anymore. Thanks for your work improving calibre on Debian. :) -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
