+1 from me too. These directories make sense for this application.
git can write to
.gitconfig with e.g.
git config --global user.name wieczorek1990 too so I change the request from read to write.
I just tired these commands to check if it works, and it doesn’t:
snapcraft snap install --dangerous git_0.3.0_amd64.snap snap connect gitl:gitconfig gitl # acts like .gitconfig is not read # writes to ~/snap/gitl/current/.gitconfig
I don’t know how to proceed.
Seems to somehow work, but not fully, I have a strange error now:
expansion of alias 's' failed; 'status' is not a git command
.gitconfig results in an error:
error: could not lock config file home/luke/snap/gitl/x3/.gitconfig: permission denied
The new snapcraft.yaml looks like that:
Ping - I can’t tally until votes are recast for write access.
@wieczorek1990 Apologies for the delay.
+1 from me.
2 votes for, 0 against (1 discarded since it wasn’t for write). Granting use of and auto-connection for the personal-files interface.
While I have granted the snap declaration, the review-tools need a corresponding update. I have performed this update, but it is not in production yet. Newly uploaded revisions will require someone to manually approve it until this change is in production.
Apologies for the delay (due to vacation ): post-facto +1 from me with write, my only concern is granting write permissions to
.gitconfig to a third-party app but
gitl has “git” in its name so users should not be caught unaware.
Now I get this error during push:
luke ~/D/gitl $ snapcraft push gitl_2.0.0_amd64.snap Preparing to push 'gitl_2.0.0_amd64.snap'. Pushing 'gitl_2.0.0_amd64.snap' [=========================================] 100% Processing...| Error while processing... The store was unable to accept this snap. - override not found for 'plugs/gitconfig'. Use of the personal-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the 'store-requests' category (https://forum.snapcraft.io/c/store-requests), or if you would prefer to keep this private, the 'sensitive' category.
Signed up for manual revision.
Yes, that is expected and what I was trying to communicate with “While I have granted the snap declaration, the review-tools need a corresponding update. I have performed this update, but it is not in production yet. Newly uploaded revisions will require someone to manually approve it until this change is in production.” I have approved the revisions you requested. The update should be in prod soon.
Still it reads the
~/snap/gitl/current/.gitconfig instead of the user home directory.
Or am I not understanding how does it work? What directory does the $HOME variable from snapcraft.yaml refer to?
in runtime, HOME of a snap is set to that diretory, which is not the actual user’s home. This is convenient for a majority of legacy apps trying to make it into snaps, but hinders cases such as these (and I expect we’ll make opting-out of this HOME rewriting a thing at some point as things mature). Meanwhile, in
icdiff, I change the first line of
git-icdiff script to be
export HOME=$(perl -we "print((getpwuid $>))")
because as I tested things that was the most lightweight way of achieving this. Other snaps that need this do something similar using
Thanks very much.
Now I’m only waiting for review.
Finally got everything working. (Hope so)
Any info when the review tools will be updated?
@jdstrand I’m also requesting write for $HOME/.gitl_history as I’m writing history to that file.
I renamed the plug from gitconfig to git, added a gitl plug.
gitconfig was the approved interface reference name and is what was granted in the store. ‘git’ does not convey the same meaning when one does
snap [dis]connect gitl:git which is why we require ‘gitconfig’. Please adjust this back to the agreed to name and [this portion of] the snap will pass automated review.
As for ‘gitl’, this is for $HOME/.gitl_history, but there doesn’t seem to be a reason why this file needs to be in this location and not the usual $SNAP_USER_DATA (aka $HOME). History files are typical only read and written to by the tool using them, not the user.
Now I get it, thank you.
Nah, I don’t get anything why it still does not work, doing everything as instructed. There’s even a silly env GIT_DISCOVERY_ACROSS_FILESYSTEM that seems to be needed. Aliases don’t want to be read properly. Can anyone help me with debugging this, I want this finally released. Yeah, everybody probably does it with Makefile.
Maybe this line helps: https://github.com/git/git/blob/6a6c0f10a70a6eb101c213b09ae82a9cad252743/setup.c#L961
Past you not have.
Where is Linus in this thread?
Bump. Bump. Bump. Bump. Wait.