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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 5047 bytes --]

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.fsf@asu.edu

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

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

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[John Soo]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 821 bytes --]

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

[Ryan Prior]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Wednesday, April 27th, 2022 at 2:01 PM, John Soo <jsoo1@asu.edu> 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

[-- Attachment #2: Type: text/html, Size: 920 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Hi John

John Soo <jsoo1@asu.edu> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Ludovic Courtès]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> 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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Hi Ludovic:

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Giovanni,
>
> Giovanni Biscuolo <g@xelera.eu> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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 <ludo@gnu.org> wrote:

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

Quoting [1]:

        From: Alex Kost <alezost@gmail.com>
        To: John Soo <jsoo1@asu.edu>
        Cc: Guix-Devel <guix-devel@gnu.org>
        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: <https://yhetil.org/guix/87v9cum99w.fsf@gmail.com>


> 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: <https://github.com/alezost/guix.el/issues/38#issuecomment-617718043>

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: <https://gitlab.com/emacs-guix/emacs-guix>

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

[Ludovic Courtès]

Hi,

Ludovic Courtès <ludo@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?

Thanks,
Ludo’.

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 <ludo@gnu.org> wrote:


> Hi,
>
> Ludovic Courtès ludo@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)<Alex Kost>
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>

Cheers,
Kaelyn

P.S For full reference, the remotes are:
gitlab	https://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)<Ludovic Courtès>
* 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months ago)<Ludovic Courtès>
* 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months ago)<Tobias Geerinckx-Rice>
* a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago)<John Soo>
* d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months ago)<John Soo>

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)<Alex Kost>
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>
* 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months ago)<Tobias Geerinckx-Rice>
* bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago)<John Soo>
* 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago)<John Soo>
* 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months ago)<John Soo>
* 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 months ago)<John Soo>
* 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 year, 5 months ago)<John Soo>

>
> Thanks,
> Ludo’.

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Hello Kaelyn and Ludo'

thank you for your help!

Kaelyn <kaelyn.alexi@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?

Thanks, Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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 <g@xelera.eu> wrote:


> Hello Kaelyn and Ludo'
>
> thank you for your help!
>
> Kaelyn kaelyn.alexi@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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

Hello,

I've removed "GNU Guix maintainers <guix-maintainers@gnu.org>"

Kaelyn <kaelyn.alexi@protonmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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 <kaelyn.alexi@protonmail.com> writes:

> Hi,
>
> ------- Original Message -------
> On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>
>> Hi,
>>
>> Ludovic Courtès ludo@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)<Alex Kost>
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
> * fbc2bbc - elisp/ui-package: Use thing at point for
> 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>
>
> Cheers,
> Kaelyn
>
> P.S For full reference, the remotes are:
> gitlab	https://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)<Ludovic Courtès>
> * 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months ago)<Ludovic Courtès>
> * 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months ago)<Tobias Geerinckx-Rice>
> * a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago)<John Soo>
> * d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months ago)<John Soo>
>
> 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)<Alex Kost>
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
> * fbc2bbc - elisp/ui-package: Use thing at point for
> 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>
> * 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months ago)<Tobias Geerinckx-Rice>
> * bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago)<John Soo>
> * 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago)<John Soo>
> * 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months ago)<John Soo>
> * 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 months ago)<John Soo>
> * 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 year, 5 months ago)<John Soo>
>
>>
>> Thanks,
>> Ludo’.

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi Théo

Théo Maxime Tyburn <theo.tyburn@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Théo Maxime Tyburn]

Hi,

Giovanni Biscuolo <g@xelera.eu> 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

[Simon Streit]

Hello Théo,

Théo Maxime Tyburn <theo.tyburn@gmail.com> 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

[Ludovic Courtès]

Hi Simon, Théo, Kaelyn,

Simon Streit <simon@netpanic.org> skribis:

> Théo Maxime Tyburn <theo.tyburn@gmail.com> 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

[Théo Tyburn]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

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 <ludo@gnu.org> wrote:

> Hi Simon, Théo, Kaelyn,
>
> Simon Streit <simon@netpanic.org> skribis:
>
> > Théo Maxime Tyburn <theo.tyburn@gmail.com> 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’.
>

[-- Attachment #2: Type: text/html, Size: 3093 bytes --]

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

[Ludovic Courtès]

Hello Kaelyn,

Kaelyn <kaelyn.alexi@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)<Alex Kost>
> * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
> * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
> * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>

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 <https://issues.guix.gnu.org>, 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 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 <https://issues.guix.gnu.org>, 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

[Kaelyn]

Hi Ludo'

Sorry for taking a while to send a reply!

On Monday, May 30th, 2022 at 8:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:


> Hello Kaelyn,
>
> Kaelyn kaelyn.alexi@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)<Alex Kost>
> > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
> > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
> > * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>
>
>
> 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

[Kaelyn]

On Tuesday, June 7th, 2022 at 10:42 AM, Kaelyn <kaelyn.alexi@protonmail.com> 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)<Alex Kost>
> > > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months ago)<Alex Kost>
> > > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 months ago)<Alex Kost>
> > > * fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' command (1 year, 3 months ago)<Alex Kost>
> >
> > 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