Manage your dotfiles across multiple machines, securely. website: https://github.com/twpayne/chezmoi overlay: https://github.com/pdemonaco/overlay
This package is great. Is there anything else that a non developer could help with with this bug review? I'm not familiar with the process here. Is this stalled waiting for a package group to allow the inclusion?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=14b3b3ceccdddd7bfad79f7e6d6ff1d62a3b1ab9 commit 14b3b3ceccdddd7bfad79f7e6d6ff1d62a3b1ab9 Author: Philip DeMonaco <phil@demona.co> AuthorDate: 2020-06-16 23:00:28 +0000 Commit: Phil DeMonaco <phil@demona.co> CommitDate: 2020-06-16 23:06:26 +0000 app-admin/chezmoi-bin: new package Manage your dotfiles across multiple machines, securely. Note that this is a port of an existing pull request made against the primary portage tree. Bug: https://bugs.gentoo.org/688190 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Philip DeMonaco <phil@demona.co> app-admin/chezmoi-bin/Manifest | 2 ++ app-admin/chezmoi-bin/chezmoi-bin-1.8.2.ebuild | 50 ++++++++++++++++++++++++++ app-admin/chezmoi-bin/metadata.xml | 22 ++++++++++++ 3 files changed, 74 insertions(+)
I suggest you might want to investigate how this should be installed "the Gentoo way", from sources, by means of the appropriate Go eclasses. Many Gentoo developers and users wouldn't necessarily trust an unknown binary from an unknown vendor. That said, I have personally used stow, and it's a very useful system.
I had a "from source" build working for an old version of chezmoi (v1.4.0), however, due to the dependencies on numerous google modules it's actually not possible to do this at the current moment. Getting the list of dependencies is relatively straightforward now via: I've found a good way to list dependencies via the following: cd $(mktemp -d) git clone --depth=1 https://github.com/twpayne/chezmoi.git cd chezmoi go list -m all Unfortunately, golang-vcs-snapshot.eclass can't currently handle the "cloud.google.com/go" modules due to the way Google decided to manage their release on github. For whatever reason, they have a bunch of different sub-modules within the same repository: cloud.google.com/go cloud.google.com/go/bigquery cloud.google.com/go/datastore cloud.google.com/go/firestore cloud.google.com/go/pubsub cloud.google.com/go/storage These are all part of https://github.com/googleapis/google-cloud-go and are released against this repo with minor sub-versions. For example, the bigquery 1.0.1 can be found here: https://github.com/googleapis/google-cloud-go/releases/tag/bigquery%2Fv1.0.1 https://github.com/googleapis/google-cloud-go/archive/bigquery/v1.0.1.tar.gz There are other issues including * Sources referenced outside of github by commit version. * Extrapolating the full commit checksum for github releases so the "version" can be downloaded All in all dealing with go is very annoying.
(In reply to Phil DeMonaco from comment #4) I think if you use -modonly=vendor and such, with the Go eclasses and EGO_SUM, you can use vendored modules fine.
Oh wow. go-module is much easier to work with than golang-vcs-snapshot. I've got a working build from source now. Should I modify this bug report to reference the new package or make a new submission?
(In reply to Phil DeMonaco from comment #6) > Oh wow. go-module is much easier to work with than golang-vcs-snapshot. > > I've got a working build from source now. Should I modify this bug report to > reference the new package or make a new submission? I think you could leave existing, if it works, and create a new ebuild to work alongside. It's not like we don't have -bin packages for a number of other online services. If you don't mind keeping both up-to-date, I'm sure that would be appreciated. I look forward to the ebuilds joining the main package repository soon! :) Thanks for your work!
Oh, sure I wouldn't mind maintaining both. The -bin version is about as hard as `git mv chemzoi-bin-${PV}.ebuild chezmoi-bin-${PV_NEW}.ebuild` Should I create a separate pull request for the other version or can they be combined into one?
(In reply to Phil DeMonaco from comment #8) > Oh, sure I wouldn't mind maintaining both. The -bin version is about as hard > as `git mv chemzoi-bin-${PV}.ebuild chezmoi-bin-${PV_NEW}.ebuild` > > Should I create a separate pull request for the other version or can they be > combined into one? You should be able to add commits to your branch, and the PR will be updated :) I can't see any reason why this would be a problem, but proxy-maint@ team might be able to clarify.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=f7bdef0c7763968151b091647ff758d2b22d9cfa commit f7bdef0c7763968151b091647ff758d2b22d9cfa Author: Philip DeMonaco <phil@demona.co> AuthorDate: 2020-06-20 19:10:15 +0000 Commit: Philip DeMonaco <phil@demona.co> CommitDate: 2020-06-20 19:10:15 +0000 app-admin/chezmoi: new package Manage your dotfiles across multiple machines, securely. Note This is a conversion of my original submission from a binary package to one which is compiled from source. The go-module eclass makes this much easier that the technique I originally tried back in 2018/2019. Bug: https://bugs.gentoo.org/688190 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Philip DeMonaco <phil@demona.co> app-admin/chezmoi/Manifest | 564 ++++++++++++++++++++++++++++++ app-admin/chezmoi/chezmoi-1.8.2.ebuild | 609 +++++++++++++++++++++++++++++++++ app-admin/chezmoi/metadata.xml | 18 + 3 files changed, 1191 insertions(+)
Oh, I meant that question more from the procedural standpoint instead of the technical - i.e. should two "distinct" packages (bin and non bin) each get their own separate bug report and pull request or can they be combined. For the moment, I've put them both in my PR and updated both to the latest release.
One PR is fine, and bug is not really required.
I believe this bug was closed on GitHub, and can be closed here; as this is already available on The Guru Overlay.
