Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Théo Tyburn]

Hey all of you,

I'm still interested. I go by teddd on IRC. I'll write you there Ludo.

Cheers,

Théo

On Thu, Oct 6, 2022, 16:01 Ludovic Courtès  wrote:

> Hi Simon, Théo, Kaelyn,
>
> Simon Streit  skribis:
>
> > Théo Maxime Tyburn  writes:
> >> It is here https://github.com/theottm/emacs-guix-clone. There is only
> >> one branch.
> >>
> >>> if you succeed in building the new merged branch please notify me and
> >>> I'll try to upstream it to
> >>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git
> >>
> >> I just sucessfuly built it. You can probably use
> >
> > I could successfully build your branch.  Unfortunately with geiser's
> > recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side.
> >
> > Geiser has since [1] removed all references to company.  The end result
> > is, that emacs-geiser will fail to load a REPL while it tries to
> > initiate geiser-company.
> >
> > Here is my modification that fixes the REPL again: [2].
> >
> > It'd be nice to see this pushed too and merge all the branches that now
> > exist with emacs-guix.
>
> [...]
>
> > [1]
> https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272
> > [2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack
>
> I’ve now merged your ‘simons-hack’ branch on Savannah.
>
> I’m sorry for dropping the ball here.  I had told Kaelyn that they could
> get an account on Savannah and become responsible for the Emacs-Guix
> repo.  The offer still holds, and it can even be extended to you Simon
> and to Théo!
>
> As you can see I sometimes fail to follow up on issues, so I’d suggest
> that you ping me on IRC (where I go by civodul) so we can proceed.
>
> Thank you!
>
> Ludo’.
>

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ludovic Courtès]

Hi Simon, Théo, Kaelyn,

Simon Streit  skribis:

> Théo Maxime Tyburn  writes:
>> It is here https://github.com/theottm/emacs-guix-clone. There is only
>> one branch.
>>
>>> if you succeed in building the new merged branch please notify me and
>>> I'll try to upstream it to
>>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git
>>
>> I just sucessfuly built it. You can probably use
>
> I could successfully build your branch.  Unfortunately with geiser's
> recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side.
>
> Geiser has since [1] removed all references to company.  The end result
> is, that emacs-geiser will fail to load a REPL while it tries to
> initiate geiser-company.
>
> Here is my modification that fixes the REPL again: [2].
>
> It'd be nice to see this pushed too and merge all the branches that now
> exist with emacs-guix.

[...]

> [1] 
> https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272
> [2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack

I’ve now merged your ‘simons-hack’ branch on Savannah.

I’m sorry for dropping the ball here.  I had told Kaelyn that they could
get an account on Savannah and become responsible for the Emacs-Guix
repo.  The offer still holds, and it can even be extended to you Simon
and to Théo!

As you can see I sometimes fail to follow up on issues, so I’d suggest
that you ping me on IRC (where I go by civodul) so we can proceed.

Thank you!

Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Simon Streit]

Hello Théo,

Théo Maxime Tyburn  writes:
> It is here https://github.com/theottm/emacs-guix-clone. There is only
> one branch.
>
>> if you succeed in building the new merged branch please notify me and
>> I'll try to upstream it to
>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git
>
> I just sucessfuly built it. You can probably use

I could successfully build your branch.  Unfortunately with geiser's
recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side.

Geiser has since [1] removed all references to company.  The end result
is, that emacs-geiser will fail to load a REPL while it tries to
initiate geiser-company.

Here is my modification that fixes the REPL again: [2].

It'd be nice to see this pushed too and merge all the branches that now
exist with emacs-guix.


Kind Regards
Simon 


[1] 
https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272
[2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Kaelyn]

On Tuesday, June 7th, 2022 at 10:42 AM, Kaelyn  
wrote:

[snip]
> > > I just took a few minutes and checked both repos out into a single
> > > working tree, and there aren't many commits unique to each
> > > repository. The official savannah repo has 5 commits since they
> > > diverged, with the 3 oldest looking like variations of the 6 oldest in
> > > the gitlab repo. Likewise, not counting the 6 just mentioned, there
> > > are 4 unique commits in the gitlab repo. Those 4 commits are:
> > >
> > > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
> > > 'guix-package-use-name-at-point' variable (12 months ago)
> > > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 
> > > months ago)
> > > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 
> > > 3 months ago)
> > > * fbc2bbc - elisp/ui-package: Use thing at point for 
> > > 'guix-packages-by-name' command (1 year, 3 months ago)
> >
> > Awesome.
> >
> > Would you be willing to coordinate work on Emacs-Guix for some time?
> > If so, I’m in favor of granting you commit access so you can first push
> > these four commits, and eventually apply patches that are submitted or
> > fix bugs here and there.
> >
> > If Giovanni or Théo wants to do that, that’s fine too. What we need is
> > to make sure one of us/you can commit some time going forward to at
> > least protect Emacs-Guix from bitrot, and ideally help improve it, as
> > time permits.
> >
> > WDYT?
>
>
> While my time can sometimes be a little spotty short-term, I am willing to 
> coordinate work on Emacs-Guix and at least protect it from bitrot. Right now, 
> I'm still fairly new to Emacs and am still working on my setup and learning & 
> integrating things like using Emacs-Guix or M-x debbugs-gnu, but I also wish 
> to both get more involved with Guix and improve my Emacs development and 
> debugging skills. I'll also be happy to push those four commits once I work 
> out my local build and testing (i.e. getting the tests to pass locally with a 
> clean tree to see if my cherry-picking of the commits are the reason tests 
> are failing.)

I want to give a quick update: I have successfully built and run "make check" 
for my local branch with the four cherry-picked commits, plus one addition 
commit to fix the build (an emacs script used for local builds was passing an 
argument to guix-emacs-autoload-packages, which was refactored to not take 
arguments in guix commit 47b3b4c2aa from 2019). With my extra commit, I think 
the branch should be ready to push.

Cheers,
Kaelyn

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Kaelyn]

Hi Ludo'

Sorry for taking a while to send a reply!

On Monday, May 30th, 2022 at 8:33 AM, Ludovic Courtès  wrote:


> Hello Kaelyn,
>
> Kaelyn kaelyn.al...@protonmail.com skribis:
>
> > > First, we need to cherry-pick relevant commits from gitlab.com. Any
> > > takers? If you Giovanni or anyone else is willing to help, we can grant
> > > commit access so we share the work. Another way to help is by listing
> > > commits that should be applied.
> > >
> > > Volunteers?
> >
> > I'd be happy to help with the efforts!
>
>
> Yay!
>
> > I just took a few minutes and checked both repos out into a single
> > working tree, and there aren't many commits unique to each
> > repository. The official savannah repo has 5 commits since they
> > diverged, with the 3 oldest looking like variations of the 6 oldest in
> > the gitlab repo. Likewise, not counting the 6 just mentioned, there
> > are 4 unique commits in the gitlab repo. Those 4 commits are:
> >
> > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
> > 'guix-package-use-name-at-point' variable (12 months ago)
> > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
> > ago)
> > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
> > months ago)
> > * fbc2bbc - elisp/ui-package: Use thing at point for 
> > 'guix-packages-by-name' command (1 year, 3 months ago)
>
>
> Awesome.
>
> Would you be willing to coordinate work on Emacs-Guix for some time?
> If so, I’m in favor of granting you commit access so you can first push
> these four commits, and eventually apply patches that are submitted or
> fix bugs here and there.
>
> If Giovanni or Théo wants to do that, that’s fine too. What we need is
> to make sure one of us/you can commit some time going forward to at
> least protect Emacs-Guix from bitrot, and ideally help improve it, as
> time permits.
>
> WDYT?

While my time can sometimes be a little spotty short-term, I am willing to 
coordinate work on Emacs-Guix and at least protect it from bitrot. Right now, 
I'm still fairly new to Emacs and am still working on my setup and learning & 
integrating things like using Emacs-Guix or M-x debbugs-gnu, but I also wish to 
both get more involved with Guix and improve my Emacs development and debugging 
skills. I'll also be happy to push those four commits once I work out my local 
build and testing (i.e. getting the tests to pass locally with a clean tree to 
see if my cherry-picking of the commits are the reason tests are failing.)

> Bug reports would still go to https://issues.guix.gnu.org, which you
>
> can access from the comfort of your Emacs with M-x debbugs-gnu. :-)

I really need to try that out! :)

Cheers,
Kaelyn

> Thanks,
> Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Théo Maxime Tyburn]

Hi all,

> Would you be willing to coordinate work on Emacs-Guix for some time?
> If so, I’m in favor of granting you commit access so you can first push
> these four commits, and eventually apply patches that are submitted or
> fix bugs here and there.
>
> If Giovanni or Théo wants to do that, that’s fine too.  What we need is
> to make sure one of us/you can commit some time going forward to at
> least protect Emacs-Guix from bitrot, and ideally help improve it, as
> time permits.
>
> WDYT?

I can definitly participate in this. I wanted to add some functionalities 
myself anyway so
I think that would make sense. I am stil a beginner guix developer
though so I might not be able to solve intricated bugs. But have
my fare share of elisp hacking so I can probably solve the easy
ones. Hacking emacs-guix also seems like a nice way to start hacking
guix to mee.

> Bug reports would still go to , which you
> can access from the comfort of your Emacs with M-x debbugs-gnu.  :-)

That would be my first time using it, but it sounds like a nice tool.

> Thanks,
> Ludo’.

Thanks,
Théo

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ludovic Courtès]

Hello Kaelyn,

Kaelyn  skribis:

>> First, we need to cherry-pick relevant commits from gitlab.com. Any
>> takers? If you Giovanni or anyone else is willing to help, we can grant
>> commit access so we share the work. Another way to help is by listing
>> commits that should be applied.
>>
>> Volunteers?
>
> I'd be happy to help with the efforts!

Yay!

> I just took a few minutes and checked both repos out into a single
> working tree, and there aren't many commits unique to each
> repository. The official savannah repo has 5 commits since they
> diverged, with the 3 oldest looking like variations of the 6 oldest in
> the gitlab repo. Likewise, not counting the 6 just mentioned, there
> are 4 unique commits in the gitlab repo. Those 4 commits are:
>
> * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
> 'guix-package-use-name-at-point' variable (12 months ago)
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
> ago)
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
> months ago)
> * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' 
> command (1 year, 3 months ago)

Awesome.

Would you be willing to coordinate work on Emacs-Guix for some time?
If so, I’m in favor of granting you commit access so you can first push
these four commits, and eventually apply patches that are submitted or
fix bugs here and there.

If Giovanni or Théo wants to do that, that’s fine too.  What we need is
to make sure one of us/you can commit some time going forward to at
least protect Emacs-Guix from bitrot, and ideally help improve it, as
time permits.

WDYT?

Bug reports would still go to , which you
can access from the comfort of your Emacs with M-x debbugs-gnu.  :-)

Thanks,
Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Théo Maxime Tyburn]

Hi,

Giovanni Biscuolo  writes:

> where do you plan to push that branch to? I mean, what git remote?

I pushed it to github for now. I tried using sr.ht but for some reason I
had troubles (fatal: error reading section header 'shallow-info'). We
can also use something else.

It is here https://github.com/theottm/emacs-guix-clone. There is only
one branch.

> if you succeed in building the new merged branch please notify me and
> I'll try to upstream it to
> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git

I just sucessfuly built it. You can probably use
--8<---cut here---start->8---
git fetch https://github.com/theottm/emacs-guix-clone.git 
merge-gitlab-remote:merge-gitlab-remote
--8<---cut here---end--->8---
to create the branch. 

Cheers,

Théo

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hi Théo

Théo Maxime Tyburn  writes:

> I would also be happy to help if I can.
>
> I could create a new branch starting at savannah’s HEAD

where do you plan to push that branch to? I mean, what git remote?

> and cherry pick everything relevant from gitlab since the
> merge-base. That would probably be everything except the duplicates,
> so the 4 commit Kaelyn mentioned, right ?

yes, that's the plan

if you succeed in building the new merged branch please notify me and
I'll try to upstream it to
https://git.savannah.gnu.org/cgit/guix/emacs-guix.git

> Probably we also need to gather the issues from gitlab. Not experienced
> with savannah issue tracker, but I could try it out.

Savannah does not have an issue tracker, I think bug-guix
(http://lists.gnu.org/mailman/listinfo/bug-guix) it's the official
emacs-guix bug tracking system

But "issues merging" is another step, let's finish the code merge :-D

Thank! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hello,

I've removed "GNU Guix maintainers "

Kaelyn  writes:

[...]

>> how is your cherry-picking going?
>>
>> is there anything I can do to help?

[...]

> However, I keep getting elisp errors about something having the wrong
> number of arguments,

I think it depends from the Emacs upgrade to 28.1 since I saw other
emacs packages had to adjust the build due to wrong number of arguments

emacs-guix as distributed now (taken from
https://gitlab.com/emacs-guix/emacs-guix.git) compiles well on 28.1

[...]

> I wanted to at least make sure the package built with the included
> guix.scm before figuring out how to send a pull request (or patch
> series) to a savannah-hosted project, but that error has me stumped.

OK, I'll try this week-end and I'll report back my findings

Thank! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Kaelyn]

Hello Gio'

On Thursday, May 26th, 2022 at 8:01 AM, Giovanni Biscuolo  
wrote:


> Hello Kaelyn and Ludo'
>
> thank you for your help!
>
> Kaelyn kaelyn.al...@protonmail.com writes:
>
>
> [...]
>
> > > First, we need to cherry-pick relevant commits from gitlab.com. Any
> > > takers? If you Giovanni or anyone else is willing to help,
>
>
> I'd be really happy to help, I just saw Kaelyn was already working on
> this
>
> unfortunately I'm not the right person to maintain emacs-guix since my
> *-lisp foo is still Panda-style
>
> > > we can grant commit access so we share the work. Another way to help
> > > is by listing commits that should be applied.
> > >
> > > Volunteers?
> >
> > I'd be happy to help with the efforts! I just took a few minutes and
> > checked both repos out into a single working tree, and there aren't
> > many commits unique to each repository. The official savannah repo has
> > 5 commits since they diverged, with the 3 oldest looking like
> > variations of the 6 oldest in the gitlab repo. Likewise, not counting
> > the 6 just mentioned, there are 4 unique commits in the gitlab repo.
>
>
> how is your cherry-picking going?
>
> is there anything I can do to help?

I've attempted to cherry-pick the four gitlab commits (by interactively 
rebasing the gitlab HEAD on the savannah HEAD and dropping the overlapping 
commits) but haven't made progress beyond that. The rebase/cherry-pick was 
pretty simple as there didn't seem to be conflicts. However, I keep getting 
elisp errors about something having the wrong number of arguments, and I'm 
still new enough to emacs that I don't know how to debug it or to get a useful 
backtrace of where the error is coming from.

Basically it seems like the same error compiling any of the elisp files (at 
least with emacs 27), but the errors are ignored by default and so installation 
fails because all of the .elc files to be installed are missing. A sample of 
the repeated error:

  ELC  elisp/guix-hash.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan 
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f 
load noerror] 3]] 3 
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
 . 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-hash.elc] Error 255 (ignored)
  ELC  elisp/guix-derivation.elc
Wrong number of arguments: #[nil "ÁÂÃ \"Ä\")" [autoloads mapcan 
guix-emacs-find-autoloads guix-emacs--non-core-load-path mapc #[(f) "Â\"" [f 
load noerror] 3]] 3 
("/gnu/store/wl48zzhf6gvvi7vml7w0yzg14ks4b0ls-profile/share/emacs/site-lisp/guix-emacs.elc"
 . 1084) nil], 1
make[1]: [Makefile:1285: elisp/guix-derivation.elc] Error 255 (ignored)

I wanted to at least make sure the package built with the included guix.scm 
before figuring out how to send a pull request (or patch series) to a 
savannah-hosted project, but that error has me stumped.

Cheers,
Kaelyn

>
> Thanks, Gio'
>
> [...]
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Théo Maxime Tyburn]

Hi,

I would also be happy to help if I can.

I could create a new branch starting at savannah’s HEAD and
cherry pick everything relevant from gitlab since the merge-base. That
would probably be everything except the duplicates, so the 4 commit
Kaelyn mentioned, right ?

Probably we also need to gather the issues from gitlab. Not experienced
with savannah issue tracker, but I could try it out. 

Cheers,

Théo

Kaelyn  writes:

> Hi,
>
> --- Original Message ---
> On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès  wrote:
>
>
>> Hi,
>>
>> Ludovic Courtès l...@gnu.org skribis:
>>
>> > Anyway, the situation is confusing; there’s no point in having two
>> > slightly different variants. I suggest we check with Alex off-list to
>> > get a better understanding of what they want. Worst case, we can
>> > cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
>> > in discussions around Emacs-Guix or Guix development.
>>
>>
>> Emailed Alex off-list and didn’t get a reply.
>>
>> So we’re on our own like grownups, but that’s fine, I’m sure we’ll
>> manage. :-)
>>
>> First, we need to cherry-pick relevant commits from gitlab.com. Any
>> takers? If you Giovanni or anyone else is willing to help, we can grant
>> commit access so we share the work. Another way to help is by listing
>> commits that should be applied.
>>
>> Volunteers?
>
> I'd be happy to help with the efforts! I just took a few minutes and
> checked both repos out into a single working tree, and there aren't
> many commits unique to each repository. The official savannah repo has
> 5 commits since they diverged, with the 3 oldest looking like
> variations of the 6 oldest in the gitlab repo. Likewise, not counting
> the 6 just mentioned, there are 4 unique commits in the gitlab
> repo. Those 4 commits are:
>
> * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add
> 'guix-package-use-name-at-point' variable (12 months ago)
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
> ago)
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
> months ago)
> * fbc2bbc - elisp/ui-package: Use thing at point for
> 'guix-packages-by-name' command (1 year, 3 months ago)
>
> Cheers,
> Kaelyn
>
> P.S For full reference, the remotes are:
> gitlabhttps://gitlab.com/emacs-guix/emacs-guix.git
> official  git://git.savannah.gnu.org/guix/emacs-guix.git
>
> `git merge-base gitlab/master official/master` returns the hash:
> 41fba4eec845e050be92bfe76c0f7980bbe821bd
>
> The commits since the merge-base in the savannah repo:
> * c9c5cb0 - (HEAD -> master, official/master) elisp/profiles: Support Home 
> profiles. (3 months ago)
> * 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months 
> ago)
> * 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months 
> ago)
> * a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago)
> * d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months 
> ago)
>
> And the commits in the gitlab repo since the merge-base:
> * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add
> 'guix-package-use-name-at-point' variable (12 months ago)
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
> ago)
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
> months ago)
> * fbc2bbc - elisp/ui-package: Use thing at point for
> 'guix-packages-by-name' command (1 year, 3 months ago)
> * 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months 
> ago)
> * bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago)
> * 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago) Soo>
> * 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months 
> ago)
> * 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 
> months ago)
> * 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 
> year, 5 months ago)
>
>>
>> Thanks,
>> Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hello Kaelyn and Ludo'

thank you for your help!

Kaelyn  writes:

[...]

>> First, we need to cherry-pick relevant commits from gitlab.com. Any
>> takers? If you Giovanni or anyone else is willing to help,

I'd be really happy to help, I just saw Kaelyn was already working on
this

unfortunately I'm not the right person to maintain emacs-guix since my
*-lisp foo is still Panda-style

>> we can grant commit access so we share the work. Another way to help
>> is by listing commits that should be applied.
>>
>> Volunteers?
>
> I'd be happy to help with the efforts! I just took a few minutes and
> checked both repos out into a single working tree, and there aren't
> many commits unique to each repository. The official savannah repo has
> 5 commits since they diverged, with the 3 oldest looking like
> variations of the 6 oldest in the gitlab repo. Likewise, not counting
> the 6 just mentioned, there are 4 unique commits in the gitlab repo.

how is your cherry-picking going?

is there anything I can do to help?

Thanks, Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Kaelyn]

Hi,

--- Original Message ---
On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès  wrote:


> Hi,
>
> Ludovic Courtès l...@gnu.org skribis:
>
> > Anyway, the situation is confusing; there’s no point in having two
> > slightly different variants. I suggest we check with Alex off-list to
> > get a better understanding of what they want. Worst case, we can
> > cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> > in discussions around Emacs-Guix or Guix development.
>
>
> Emailed Alex off-list and didn’t get a reply.
>
> So we’re on our own like grownups, but that’s fine, I’m sure we’ll
> manage. :-)
>
> First, we need to cherry-pick relevant commits from gitlab.com. Any
> takers? If you Giovanni or anyone else is willing to help, we can grant
> commit access so we share the work. Another way to help is by listing
> commits that should be applied.
>
> Volunteers?

I'd be happy to help with the efforts! I just took a few minutes and checked 
both repos out into a single working tree, and there aren't many commits unique 
to each repository. The official savannah repo has 5 commits since they 
diverged, with the 3 oldest looking like variations of the 6 oldest in the 
gitlab repo. Likewise, not counting the 6 just mentioned, there are 4 unique 
commits in the gitlab repo. Those 4 commits are:

* c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
'guix-package-use-name-at-point' variable (12 months ago)
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
ago)
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
months ago)
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' 
command (1 year, 3 months ago)

Cheers,
Kaelyn

P.S For full reference, the remotes are:
gitlab  https://gitlab.com/emacs-guix/emacs-guix.git
officialgit://git.savannah.gnu.org/guix/emacs-guix.git

`git merge-base gitlab/master official/master` returns the hash:
41fba4eec845e050be92bfe76c0f7980bbe821bd

The commits since the merge-base in the savannah repo:
* c9c5cb0 - (HEAD -> master, official/master) elisp/profiles: Support Home 
profiles. (3 months ago)
* 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months 
ago)
* 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months 
ago)
* a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago)
* d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months 
ago)

And the commits in the gitlab repo since the merge-base:
* c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
'guix-package-use-name-at-point' variable (12 months ago)
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
ago)
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
months ago)
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' 
command (1 year, 3 months ago)
* 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months 
ago)
* bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago)
* 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago)
* 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months ago)
* 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 
months ago)
* 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 
year, 5 months ago)

>
> Thanks,
> Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Anyway, the situation is confusing; there’s no point in having two
> slightly different variants.  I suggest we check with Alex off-list to
> get a better understanding of what they want.  Worst case, we can
> cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> in discussions around Emacs-Guix or Guix development.

Emailed Alex off-list and didn’t get a reply.

So we’re on our own like grownups, but that’s fine, I’m sure we’ll
manage.  :-)

First, we need to cherry-pick relevant commits from gitlab.com.  Any
takers?  If you Giovanni or anyone else is willing to help, we can grant
commit access so we share the work.  Another way to help is by listing
commits that should be applied.

Volunteers?

Thanks,
Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[zimoun]

Hi,

On Thu, 28 Apr 2022 at 10:08, Ludovic Courtès  wrote:

> I’m not sure what “personal” means in this case.

Quoting [1]:

From: Alex Kost 
To: John Soo 
Cc: Guix-Devel 
Subject: Re: New emacs-guix location
Date: Tue, 22 Dec 2020 13:20:59 +0300

John Soo (2020-11-24 11:23 -0800) wrote:

> Hello Alex and Guix,
> Hope you are well.

Hello, I am fine, thanks!

> I volunteered to maintain some version of
> emacs-guix recently. How do you feel about a fork moving to Savannah?

You (and all the Guix people) are free to do whatever you think is
appropriate.  Emacs-Guix is a free software after all.

So if you will maintain the "official" (used by Guix) version of
Emacs-Guix at Savannah, I will only be happy that I don't have this
burden anymore.

As for me, I will continue to use my version of Emacs-Guix and to adjust
it for my needs.

And thank you for your latest commits that fixed Emacs-Guix for the
current versions of Guix and Geiser!

1: 


> Anyway, the situation is confusing; there’s no point in having two
> slightly different variants.  I suggest we check with Alex off-list to
> get a better understanding of what they want.  Worst case, we can
> cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> in discussions around Emacs-Guix or Guix development.

To add to the confusion, note that this Gitlab repo [2] also contains
some issues.  But both Gitlab and Github repos are sync by Alex, I
guess.

BTW, note this message [3] by Alex on April 2020:

I am very sorry but I rarely use Guix and Emacs-Guix these days and I
don't have any wish to maintain it. I mean, if it is some small
easy-to-fix problem or a proposed patch, then I will look at it, but
investigating a problem like this is too much for me currently. Sorry 
:-(

Hopefully, someone else who has this problem will look at it.

3: 

and I sent them an email off-list asking them the status on 29 May 2020,
15:33.  And I am not able to find an answer back.


Cheers,
simon

2: 

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hi John

John Soo  writes:

> Hi Gio!
>
> I am very sorry I have let it slip.

Nothing to apologise for, you are doing your best: I did not mean to put
pressure on you!

> If there are patches I need to get to, I can put them in to
> emacs-guix. I believe we should get the savannah version up to snuff
> and use that as the one in guix.

IMHO it's not "just" the two repos, but also the web page, MELPA and the
issue tracking systems that we need to keep togheter

[...]

Thank you and Happy Hacking!

Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hi Ludovic:

Ludovic Courtès  writes:

> Hi Giovanni,
>
> Giovanni Biscuolo  skribis:
>
>> AFAIU since 2021-01-11 [1] the new official home of emacs-guix is on
>> Savannah as a Guix sub-project [2]; Alex Kost agreed [3] and told us
>> that:
>>
>>
>>  As for me, I will continue to use my version of Emacs-Guix and to adjust
>>  it for my needs.
>>
>>
>> and that's what he is doing (see below), so now "officially" we have
>> /two/ packages named emacs-guix: the official one at Savannah and the
>> "personal" one maintained by Alex.
>
> I’m not sure what “personal” means in this case.

Just my personal interpretation of the words "my version" and "for my
needs" from Alex :-D... after all Alex's version is now the Guix
"official" one (the one we are packaging)

> Anyway, the situation is confusing; there’s no point in having two
> slightly different variants.  I suggest we check with Alex off-list to
> get a better understanding of what they want.

I agree, thank you for your off-list message, let's wait Alex reply.

> Worst case, we can cherry-pick commits from Alex’s copy if Alex
> doesn’t want to be involved in discussions around Emacs-Guix or Guix
> development.

In this worst case, we'll have two different emacs-guix packages,
documentation, issue tracking: the situation will continue to be
confusing, one of the two emacs-guix "ecosystems" (repo, web page, issue
tracking) should be discontinued (or renamed?), IMHO, hopefully with
both Alex and John as co-maintainers in one emacs-guix.

> Thanks for the heads-up!

Thank you all for your work!

Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ludovic Courtès]

Hi Giovanni,

Giovanni Biscuolo  skribis:

> AFAIU since 2021-01-11 [1] the new official home of emacs-guix is on
> Savannah as a Guix sub-project [2]; Alex Kost agreed [3] and told us
> that:
>
>
>  As for me, I will continue to use my version of Emacs-Guix and to adjust
>  it for my needs.
>
>
> and that's what he is doing (see below), so now "officially" we have
> /two/ packages named emacs-guix: the official one at Savannah and the
> "personal" one maintained by Alex.

I’m not sure what “personal” means in this case.

Anyway, the situation is confusing; there’s no point in having two
slightly different variants.  I suggest we check with Alex off-list to
get a better understanding of what they want.  Worst case, we can
cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
in discussions around Emacs-Guix or Guix development.

Thanks for the heads-up!

Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ryan Prior]

On Wednesday, April 27th, 2022 at 2:01 PM, John Soo  wrote:

> Hi Gio!
>
> I am very sorry I have let it slip.

No worries! I am planning this weekend to try out the fixes in 55013 (and try 
building from upstream savannah; I didn't realize that was different from what 
we have in guix) and this weekend to see if we can get something working "out 
of the box."

We appreciate your work on getting emacs-guix back into shape!

Cheers,
Ryan

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[John Soo]

Hi Gio!

I am very sorry I have let it slip. If there are patches I need to get to, I 
can put them in to emacs-guix. I believe we should get the savannah version up 
to snuff and use that as the one in guix.

My apologies again. I may be able to look into it this weekend if that's 
alright.

Kindly,

John

emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Giovanni Biscuolo]

Hi all!

Executive summary: we should agree with Alex Kost to continue
development on the one and only one official package repo, web page
/and/ bug report (and dismiss the old ones, converting them read-only of
necessary, with a note on the old pages) system because we now have two
/diverging/ packages with the very same name and two (three?) different
bug reporting platforms... and that's very confusing.

AFAIU since 2021-01-11 [1] the new official home of emacs-guix is on
Savannah as a Guix sub-project [2]; Alex Kost agreed [3] and told us
that:

--8<---cut here---start->8---

 As for me, I will continue to use my version of Emacs-Guix and to adjust
 it for my needs.

--8<---cut here---end--->8---

and that's what he is doing (see below), so now "officially" we have
/two/ packages named emacs-guix: the official one at Savannah and the
"personal" one maintained by Alex.

The official version is hosted here:

  https://git.savannah.gnu.org/cgit/guix/emacs-guix.git

but this is /not/ what is packaged in Guix now: we are packaging the
"personal" Alex version since 2021-05-01 (commit 57681f1640) since I've
done my little research (grepping for emacs-guix in commit message) and
found this changes in the URL of the origin (list in reverse timeline
order):

* 399e3ee7b7 (gnu: emacs-guix: Update to 0.5.2.5-c9aef52.) dated Thu Aug
  26 21:52:49 2021 (current) contains this diff:

--8<---cut here---start->8---

 (uri (git-reference
-  ;; TODO: Use the official version when it has a new home
-  (url "https://github.com/alezost/guix.el;)
+  (url "https://gitlab.com/emacs-guix/emacs-guix.git;)

--8<---cut here---end--->8---

* 57681f1640 (gnu: emacs-guix: Update to 0.5.2-4.8ce6d21.) dated Sat May
  1 15:56:41 2021 contains this diff:

--8<---cut here---start->8---

   ;; TODO: Use the official version when it has a new home
-  (url "https://github.com/jsoo1/guix.el;)
+  (url "https://github.com/alezost/guix.el;)

--8<---cut here---end--->8---

* f98e3adcd5 (gnu: emacs-guix: Update to 0.5.2.3-a694fdb.) dated Sat Dec
  12 20:56:46 2020 contains this diff:

--8<---cut here---start->8---

-  (url "https://gitlab.com/emacs-guix/emacs-guix;)
+  ;; TODO: Use the official version when it has a new home
+  (url "https://github.com/jsoo1/guix.el;)

--8<---cut here---end--->8---

Looking at the commit log summary on the web, the officlal and Alex
repositories have diverged meanwhile, with different commits on both;
the official one have two new commits from you Ludo' (that's why I'm
directly messaging you Ludo'... you (and others) are probably using the
official version /not/ installed from Guix upstream ;-) ).

Also, the official (personal ?) web site for emacs-guix is
https://emacs-guix.gitlab.io/website/; in the home page we read: «Source
code of Emacs-Guix: https://gitlab.com/emacs-guix/emacs-guix»

Also, the "official" (personal ?) home page references to MELPA as one
of the install method, and on MELPA we have https://melpa.org/#/guix
referencing

  
https://github.com/alezost/guix.el/tree/c9aef52121b458297e70bb50f49f7276b4a8d759

for the source code.  Fortunately the GitLab and GitHub remotes are kept
in sync (by Alex I guess) so we non not have a third repo :-)

Also, "official" web page contains a manual
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html
that is /not/ obtained using the official repo (AFAIU the manual still
have the same content, anyway)

Also, the "personal" issues (/and/ merge requests) are here:
https://gitlab.com/emacs-guix/emacs-guix/-/issues /and/ here:
https://github.com/alezost/guix.el/issues and...

...they are not (obviously) in sync, so users now have to search on tho
different platforms (three considering guix-devel) for past _upstream_
bug reports; AFAIK we don't even have an official bug reporting mailing
list on gnu.org (is it supposed to be guix-bugs?)

So now we have an official emacs-guix on Savannah (lacking an official
web page and a bug-report mailing list) and the "personal" version of
emacs-guix on a different "personal" reporitory hosted on two remotes:
one on GitLab, referenced in the home page, and one on GitHub,
referenced in the MELPA project page.

IMHO we should definitely fix this situation.

Thanks!  Gio'


[1] Message id:871rer5xxv@asu.edu

[2] Message id:87bldu43ta@asu.edu (same thread of the above message)

[3] Message id:87v9cum99w@gmail.com

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature