Upgrade StorageNo 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?
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?
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.
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.
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.
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.
Not recommending Zotero based on these things would be truly bizarre.
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.
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 intoviand 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.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.
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.