Unable to update due to permissions

[mcfreund]

When attempting to update within the GUI, zotero returns an error

A recommended update is available, but you do not have permission to install it. To update automatically, modify the Zotero program directly to be writeable by your user account.

In terminal, sudo snap refresh zotero-snap, returns "no updates available"

[maxsu]

@mcfreund You might want to try zotero-deb

It's trustworthy, and semi-officially endorsed by the zotero project. It also stays up to date (since it rebuilds itself every 2 hours :open_mouth: )

It provides two debian packages:

1. zotero - this is the latest 6.x version 6.0.30
2. zotero-beta - this is the latest 7.x beta 7.0.0.53+969031a37

Example: Installing Zotero Beta

curl -sL https://raw.githubusercontent.com/retorquere/zotero-deb/master/install.sh | sudo bash
sudo apt update
sudo apt install zotero-beta

Now you can update with apt:

sudo apt upgrade zotero

Note: The zotero updater will still give error messages, since it doesn't have admin powers. You can work around that with a system update.

Ps: @extraymond, if you'd like, I can develop a check_release.yml workflow to complement your publishing workflow. This workflow would check for releases, bump the snapcraft.yaml version, and trigger publish.yml. This would keep zotero-snap up to date with minimal labor.

[extraymond]

@mcfreund You might want to try zotero-deb

It's trustworthy, and semi-officially endorsed by the zotero project. It also stays up to date (since it rebuilds itself every 2 hours 😮 )

It provides two debian packages:

1. zotero - this is the latest 6.x version 6.0.30

2. zotero-beta - this is the latest 7.x beta 7.0.0.53+969031a37

Example: Installing Zotero Beta

curl -sL https://raw.githubusercontent.com/retorquere/zotero-deb/master/install.sh | sudo bash
sudo apt update
sudo apt install zotero-beta

Now you can update with apt:

sudo apt upgrade zotero

Note: The zotero updater will still give error messages, since it doesn't have admin powers. You can work around that with a system update.

Ps: @extraymond, if you'd like, I can develop a check_release.yml workflow to complement your publishing workflow. This workflow would check for releases, bump the snapcraft.yaml version, and trigger publish.yml. This would keep zotero-snap up to date with minimal labor.

This sounds wonderful!! I'd love to incorporate that into the snap.

[maxsu]

@extraymond I've built and tested the automation! It was incredibly fun to see an update commit roll into my test repository all by itself! (#43)

I've also shortened the snapcraft workflow (#42)

[maxsu]

@extraymond, I hope the new year finds you well!

I'm reaching out with two goals:

1. I would like to become a zotero-snap maintainer!
2. I want to persuade the zotero.org maintainers to mention zotero-snap in the official install instructions! (the way it mentions zotero-deb!)

This would be an exciting development! I'm eager to help enrich zotero / zotero-snap.

To support the second goal, I plan to reach out to emiliano heynes (zotero-deb maintainer) and dan stillman (zotero lead developer) next week - these are the two most packaging-oriented members of the community.

I'd like to persuade them that zotero-snap is valuable to the zotero project, because:

1. It reaches many users
2. It's incredibly easy to install!
3. It's super easy to maintain zotero-snap and ensure quality

I can well support points 3 and 2. But I need some help with point 1. So far, I can argue that zotero-snap reaches dozens of different distributions:

Knowing the download volume would make our case much stronger.

Likewise, I've love if you joined the thread to comment and field questions. That brings all the key stake holders to the conversation. I think that would be fun!

Questions:

1. Do you feel comfortable sharing the download volume information with me / with the zotero community?
2. Would you like to join me on the zotero mailing list thread?

Lets chat soon! I'm available for a video meeting or call, and you can email me at max.suica@gmail.com.

Cheers / Happy New Years! 🍔🍔🍔🥂

[bansp]

Ouch, wouldn't it be nice to see some action here... I fell into the snap trap and thought of trying to get out of it until I read the exchange between @extraymond and @maxsu and became hopeful again. But then, the current maintainer has now been silent for 2.5 months, so, I guess, it is time to pack up and leave, right? Thank you, @maxsu , for your willingness to help out, it is appreciated.

[maxsu]

@bansp I'm using and endorsing zoter-deb for the time being, see zoter-deb if you're on ubuntu/debian.

The new self updating project code is ready in my PR. If you want, you can build and install it with snapcraft - see the snapcraft.yaml build workflow for a playbook.

I propose we reach out on the Snap forum and ask them to transfer the snap's ownership to us, citing maintainer unavailability. @extraymond I'm going to assume that is okay. @bansp Would you be interested in helping me spearhead that?

[bansp]

Thanks for the suggestion, @maxsu , but packaging infrastructure is far from my turf, I wouldn't be of use. The more so that, after I'd posted, I removed the snap and switched to the working solution. And I'm very happy about that. Good luck and thanks for your willingness to get things rolling.

[extraymond]

@bansp I'm using and endorsing zoter-deb for the time being, see zoter-deb if you're on ubuntu/debian.

The new self updating project code is ready in my PR. If you want, you can build and install it with snapcraft - see the snapcraft.yaml build workflow for a playbook.

I propose we reach out on the Snap forum and ask them to transfer the snap's ownership to us, citing maintainer unavailability. @extraymond I'm going to assume that is okay. @bansp Would you be interested in helping me spearhead that?

Apologize for the silence, it's been a pretty tight season for me. First of all thanks for the effort for the PR and the discussion, I pretty much agree on all of it, and would like to share some thoughts from my end:

Just to let you know that, this snap was originally targeted to be used as an PR in the upstream zotero project. The snapcraft.yaml I use was actually forked from Alan Pope, who was a Canonical employee who advocates snap. At that time, it seems that the original maintainer does not have the intent or have the bandwidth to incorporate it into their build process. Thus, it became a stand-alone snap, which I was using heavily back then.

Since I rarely use or need this wonderful tool in my work environment any more, it's been sometimes ignored or just plain forgotten by me to update the snap.

---

Some possible action I think we can collaborate on:

1. propose to get the snapcraft yaml and your PR on the CI incorporated into upstream, this seems to be the best case we could get, so that zotero get it's official update from it's original author, no confusion for its user.
2. I can transfer the snap to you, or a intermediate group like zotero-snap-community, if you are more than likely to maintain it than I could. I'm not entirely sure how that works, but I assume we need to ask for transferring the ownership on the snapcraft forum.
3. The most simple solution, I can allow you for merge rights on this repo so that you can push and made changes to the CI and tag a release.

What do you think @maxsu

[extraymond]

@maxsu BTW I merged all your PR's, thanks for all the house keeping, the update and publish to different channels with a single job is pretty neat.

[franklegolasyoung]

Hi @extraymond, really appreciate your works. I noticed that the update is not frequent anymore. I just commited an update of stable version. Pls merge it for updates, thanks.

[franklegolasyoung]

Also, @extraymond, I have checked the workflow about why it is not updated.

remote: error: GH006: Protected branch update failed for refs/heads/master.        
remote: error: Changes must be made through a pull request.

It shows the master branch is not changeable according to repository protections. If possible, u may change the master branch protection rules in the project settings. Or maybe we could alter the work flow to create a pull request after detected updates. Thanks.

[maxsu]

Proposed resolution plan - (/w optimistic assumptions):

• [ ] Step one: Confirm root cause. Is branch protection enabled on main?
• [ ] Step two: Assuming yes, decide if branch protection is controlling risks.
• [ ] Step three: Assuming the repo has only one member, what significant risks do branch protections control?
• [ ] Step four: Assuming branch protection controls no significant risks, disable it.
• [ ] Step five: Manually trigger the workflow to confirm automated upgrade.
• [ ] Step six: Monitor updates for the next few Zotero releases until we achieve the Victory KPI

Victory KPI: 🧈🧈🧈Buttery Smooth Updates🧈🧈🧈 The time to update drops to under 24 hours for 5 consecutive updates, without human intervention.

[extraymond]

@franklegolasyoung

I've updated to the new version, thanks for the PR.

Also appreciate your suggestion, I quite like the create PR approach and thus changed the bit submitted by @maxsu to create PR instead, hopefully this will trigger correctly when the next update arrive.

@maxsu Ideally I still want the main protection because it would avoid bot or other malicious actors from uploading arbitrary stuff without me noticing it(cough cough on the recent crypto scam snap).
So manual review is still something I would like to have.

I think a pattern I saw on other open source projects is that:

1. use gh-action to trigger a release pr
2. automatically tag user with privilege to merge in the pr, maybe as collaborators
3. upon pr accepted, release the snap via gh-action
4. optionally create a push to stable action which can only be triggered manually, most likely triggered by someone checking candidate channel works

We currently have 1 and 3, point 2 should be semi-working via my new commit. Would you mind I invite you and others as collaborator and help me approve release prs? If all that works as planned than we might be able to:

1. only get notified when new version is up
2. approve pr to push to candidate
3. manually push to stable if a test run is success