No functions working after update

I updated a (Debian) system, and it auto-updated Firefox. Now Zotero Standalone starts, but none of the files are visible, and I can't use any function in it. I can open the drop-down menus etc., but if I click on the options nothing happens.

The files are there, in the "mozilla" path, gigs of them:
https://www.zotero.org/support/kb/data_missing_after_zotero_5_upgrade

How would it be best to proceed?
  • Let's start with a Report ID.
  • Unfortunately the "Report errors to Zotero" drop-down menu item doesn't work either...
  • How did you update? Is this via debian package manager or by installing Zotero from tarball? The debian package is not maintained by Zotero.
  • As I recall installing via the package manager was not possible, and I used a tarball. Unfortunately, this also means that Zotero compatibility is not maintained by Debian.

  • I'm pretty sure I downloaded it from your site. Is there an easy way of telling whether Zotero has updated or failed to update, given that I can't get a version number or other info out of the GUI?

    I seem to have data directories in both the mozilla and zotero profile paths, though it's pretty obvious which one contains my files from size.
  • I'm not quite sure what your question is. We offer a tarball for Linux that should run on most distros, the same as Firefox. If you're not sure if you have the official one, just download it again.
  • I'm pretty sure I got the official one from your website. My question is how to get my Zotero working again, ideally without re-installing and restoring from my last flat-file backup. I'd also be interested in knowing how to avoid this in future. Finally, I'm just reporting that an update went wrong; if I can give you any useful details, please let me know.

  • I'm saying that it's a waste of time to debug anything further until you download the current tarball and try running that.
  • OK. How should I best preserve my data while doing this? Sorry if this is a stupid question.
  • Your data has nothing to do with the application files. Your data is in ~/Zotero by default. The application files are wherever you extracted the tarball.
  • OK, I've finally gotten to this. Apparently I was wrong and I did install the Debian zotero-standalone package. Sorry, this was a while ago now; I should have checked.

    So apparently the Debian package is now effectively blocked, and this has been a known problem for over a year:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864827

    Unfortunately, it is not a simple problem. Standalone 5, ironically, has a huge number of little dependencies, all of which Debian would have to package. The size and tedium of the job led the old package maintainer to resign, and some new volunteers have worked a fair bit on it and have discovered new necessary subjobs and have also given up. Progress is being made on some of the dependencies. In principle, it is a good idea to have more eyes looking at npm script snippets, but no-one really wants to do it (especially if they are obfuscated code).

    Debian's zotero-standalone package was last updated in January of 2017. Zotero did not make it into the Debian stable release which will come out later this year (2019; "Buster" release). Package databases for the many distros derived from Debian stable, such as Ubuntu, will presumably also be affected. As of March 30th, three days ago, the Zotero package has also been removed from Debian unstable.
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926033

    So as I understand it, if you want to install Zotero 5, you do it without third-party auditing, security updates, or integration from your distro. npm's security issues are also able to affect you. You need to authenticate the files you download, as the distro's package manager no longer does it for you. For these reasons, I've stopped recommending Zotero to nontechnical friends. It is, however, almost as easy as installing from a package manager. See next post.
  • Installing Zotero 5

    WARNING: Updating to Zotero 5 makes some workarounds impossible, as when you first run it it will, without asking, upgrade your database, and there is reportedly no way to downgrade it so it will work with 4.0 again.
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871502

    ...so if you try this, do as I did and backup your data directories first. I haven't
    checked if this is sufficient to allow a Firefox-downgrade workaround.

    Installing 5 manually and running it manually with ./zotero updates the database and gives access to it. See the thread below for a discussion of doing this:

    https://forums.zotero.org/discussion/73265/install-zotero-5-0-on-debian

    I don't know why this is, but the items load very slowly: about eight seconds to come up onscreen if in a collection subfolder with only one item in it, but over 25 seconds for coming up into folders with more items. Switching folders once started is fine, not slow.

    Separately, Zotero 5 updates independently on its own schedule, not on-request or on-permission, which causes delays without warning. This is common in proprietary software, but unusual in open-source.
  • I wrote most of the above two posts months ago, so an update. In practice, although I installed Zotero 5 from Zotero.org without difficulties, I have not actually added new references to it. I've been using it to access and export my old data. I'm not sure quite where the adversion comes from; the slower and more awkward access (I could integrate some menu icons, but haven't, since I haven't been using it...) and my uneasiness with some of the changes are probably part of it. The offline-unreadability and size of many snapshots (due to poor web design, not Zotero) also reduces the utility of Zotero to me. I hope to use Zotero again; it's a really useful tool.

    If a future version of Zotero can be made to stand alone from the javascript code snippets, and is thus more easily auditable, I would expect that it would be repackaged and available in the next stable Debian release in 2022-ish.
  • edited 22 days ago
    There seems to be some significant confusion here. We distribute a Linux tarball from our website, exactly like Firefox. Everything we produce is open source and unobfuscated, and we use a very small number of major, open-source, third-party libraries — I have no idea what you mean by "javascript code snippets". Like most desktop programs, open-source or otherwise, there's a built-in auto-updater — ours is built on the exact same update system Firefox uses — and you can disable auto-updating if you want to.

    Not recommending Zotero based on these things would be truly bizarre.
  • I may well be confused, and I'm afraid my tone came off as harsher than I intended; my apologies. I certainly didn't mean to imply that Zotero is closed-source or obfuscated, or that it is somehow wrong to distribute a tarball.

    I don't think that I am confused when it comes to the licensing; I know Zotero is AGPL, clearly it is open-source. My comment about automatic updates was intended to be a general one, and the comment that lot of closed-source programs have automatic updaters was not intended to imply that Zotero is closed-source, or that having an automatic updater somehow makes a package closed-source. I will look into disabling the auto-updater, thank you for the tip.

    The thread refers to some of Zotero's dependencies as "minified javascript snippets"; I should not have said "obfuscated", as that implies a different intent. I have not personally looked into the dependencies that are listed in the bug at
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871502
    There's a list of dependencies in message #139.

    I have no objection to software also being distributed as a tarball, but the package manager is convenient, especially for newbies. Firefox is available via the Debian package database, and most others. I should clarify that by "non-technical", I mean someone who can select a package from their distro's database, but would be out of their depth checking a checksum. Someone who might search the name of the program, mess up and download a program from some third-party malware merchant's site. It's easy to give such a person a script for installing packages from their distro, and tell them that if they just stick to the script and don't install programs any other way, they should be fine. Then when they need a new program, you can just tell them the name they should run through the script with.
  • I understand why people would give up on breaking out those dependencies and then having Zotero depend on them -- that's feasible for node-based programs that use npm modules, but Zotero is (as of yet) not node-based, and it would be some *major* work to get it to work this way.

    But I don't see why that should preclude Debian packages. I have working Debs (one that downloads and installs Zotero in the postinst much like the oracle java packages, one that just bundles the binaries Zotero puts out, and one built from source) and the there's only two real dependency that have been giving me issues for the latter:

    • node + npm for *only* build-time. Not used after build.

    • xulrunner (or an equivalent), which the build fetches as binary. But zotero uses a recent firefox base (52.9.0esr for Linux), so if the packaged version that's available in Debian isn't usable, that could certainly be packaged.

    WRT minification, I haven't seen code being minified (which doesn't mean it's not, just that I don't know it), but this argument strikes me as strange; you wouldn't expect to load java bytecode into vi and expect to make sense of what turns up by eyeballing it. To make sense of what it does, you go to the source. In the case of Zotero, parts of the Javascript source is put through babel, and the results are "javascript bytecode". That some of it is readable when opened in a text editor is a side-effect of the technology in use, but if you want to know what it does, much like a java (or C, Go, whatnot) program, you get the source, and the source is readily available.
  • (and my debs take care of the icons, menus, mimetype associations, etc)
  • I also see in that thread that starting Zotero blocks Firefox -- no idea what was going on on that system when that was tried, but not a single day goes by that I don't have both FF and Zotero open on my Linux (Ubuntu) system. I have *never* seen this behavior and could not think of a way to cause it.

    I'll try to get in touch with diane@caltech.edu (who was until recently working on it it appears) to see if we can work something out.
  • Thank you very much, Emilianoeheyns. I'm sure she'd know more about the details.

    As I recall Xulrunner was removed due to a discontinuation of upstream support; I've seen other packages that depended on it break. Debian has had to go to more frequent Firefox releases, they take each one with long-term support. I think some of the issues are related to meeting Debian's verification requirements; it also seems possible that people looking in the wrong places.
  • We don't use XULRunner anymore — we use Firefox, but we have to make some (scripted) modifications to it, so any package would need to download our binary or build its own and bundle that. Future versions of Zotero will use Electron.
    I have not personally looked into the dependencies that are listed in the bug at
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871502
    There's a list of dependencies in message #139.
    That's a misunderstanding. The build dependencies are very different from the actual code that's bundled. As I say, we bundle a few major JS libraries, such as React and TinyMCE. Some of those are installed into the build repo via NPM, which means all their Node dependencies show up in node_modules, but we're still just adding their stock production builds from those packages — which are the same everywhere on the web where they're used — to our actual build.
Sign In or Register to comment.