unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* guile-hall issues converting my project to a hall project
@ 2021-02-06 21:49 Zelphir Kaltstahl
  2021-02-07  9:14 ` tomas
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-06 21:49 UTC (permalink / raw)
  To: Guile User

Hello Guile Users!

I decided to try to use guile-hall to convert my project at
https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
For that purpose I created a separate branch
"wip-guix-package-using-guile-hall"
(branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-package-using-guile-hall
commit:
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3ebd497adcce6b683e82),
from which I am starting to run commands.

It seems, that many of guile-hall's defaults are wrong for my project
and I need to adapt a lot of its settings. It also tells me to report
unsupported file types, but I cannot do that in the guile-hall
repository, because I cannot log in on Gitlab, because Gitlab has a
"clever" "check of my browser", which simply loops forever reloading the
"browser check" website … My guess: The check requires third party
cookies to be set. So I am going to write about it here and hope someone
knows how to proceed.

The example call in the readme of
https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:

~~~~
hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute
~~~~

I am not sure what exactly the prefix is. `hall init --help` only tells
me: "Prefix of the project.", which does not help me. It basically has
zero more information for me. Does this already have to do with the
Makefile, which is created later? I leave prefix at "guile" for now.
What is "frobnigator"? I think it is the name of the project, because in
`hall init --help` it says that the syntax is:

~~~~
hall initiate [-cx] NAME
                     [-a "Alyssa P. Hacker"]
                     [-l gpl3+]
                     [-p guile]
                     [-w "https://website.mine"]
~~~~

(I like the SICP reference, btw.) `NAME` is the only thing that I cannot
translate anything else to be in the command above. I think it would be
better to not use something confusing like "frobnigator", which people
might not know what that even is, and use a generic word like
"my-project-name".

So the command I run is:

~~~~
hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib --license 'agpl3+' --execute
~~~~

What I like about it is, that everything seems to be dry-run, except
when adding `--execute`. That makes things less scary.

Then hall creates a bunch of files, but most things seem not to consider
my actual already existing project structure. hall never asks me what my
test directory is or what file my license information is in. I think it
would be good to have those things available as command line arguments,
so that I do not need to fix things afterwards, which differ from the
defaults.

I will list the things, that I need to change to correct values after
the hall command has finished and steps I am taking, from the
perspective of a first time user, because perhaps it can help improving
guile-hall:

(1) Remove my old license file, which was not `COPYING` but `LICENSE`.
Here I do not really care about in which file it is. It would be great,
if hall asked me about the `LICENSE` file though. Perhaps a list of
common names of license files could be added to hall and it could check
for those?

(2) In `guix.scm` the version is wrong. It should be `(version
"0.2.0")`, not `(version "0.1")`. The git repository already has a tag
`0.2.0`, but I think, that "0.1" is a default value, which is simply put
into `guix.scm`. Here a `--version` argument would be good to have, with
the default still being `0.1.0` or `0.1`. I think 3 parts is the better
choice, because it makes processing version numbers easier. Every
version number would have 3 parts. Always. And it could be made a list
of 3 symbols or even numbers as well. But if they are only numbers, one
could not have something like "rc" for release candidate or stuff like
that. Also not everyone might want to use version numbers like these. I
have seen projects using the date as version number.

(3) After adapting the version number, the `source` has to be adapted as
well to reflect the change in version. At this point I get insecure
about the whole thing. "Will Guix be able to find this archive? Will it
look only for a version number consisting of 2 parts? Will anything
break later in the process, because I am not following the same
versioning syntax and have 3 parts instead of 2 parts written in the
string?"

(4) In the `guix.scm` native inputs are defined. The concept of that is
very unclear in my mind. I read about that previously on the Guix pages,
but I already forgot again what native inputs are and how they differ
from inputs. Anyway, probably not so important right now. However, they
list "texinfo". My project does not make use of texinfo at all. But I am
insecure now about removing it. Perhaps hall will not be able to deal
with it, if I remove it, so I am leaving it there for now. Hopefully I
can remove it later and make my dependencies fewer (?).

(5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I
change it to the correct version.

(6) Next is the `files` section. This one creates a lot of insecurity.
It says `(directory "fslib" ())`. I have not put my source files into a
directory `fslib`, but I had no chance to tell hall, that there is no
such thing beforehand. If I have to move all my source files, then I
also need to change all my imports! My source files are in the root
directory of the project. I've had no need so far to move them into a
subdirectory. I guess with all the project managing files hall created,
a subdirectory makes sense, but then I am changing my code to conform to
what hall wants the structure to be and I am not telling hall what kind
of structure my project has instead, to make it figure out how to write
the makefiles etc. So this is one of the points, where I think it would
be good to give hall an argument `--source-location '.'` or something
like that. I will try to adapt the configuration by changing the
`directory` to "." instead of "fslib". More insecurity: "Will hall be
able to work with that? Will it understand "."? Or will everything break?"

(7) The tests directory is wrong. I have my tests in `test`, without the
plural "s". I will change the setting.

(8) I do not have additional `programs` in this project. Can I simply
remove this entry from the hall settings? I better leave it in there,
hall might break, if unexpectedly that setting is missing.

(9) I do not know what to do now, that hall has created all these files
and I have corrected some of the values in its settings. At this point I
am asking myself, whether I somehow need to generate any of the files
anew. But I find the `HACKING` file and see that in there it says I can
activate a Guix environment now, from the files hall produced:

~~~~
guix environment -l guix.scm
~~~~

And that still works, even though I changed stuff in there. Good!

(10) Next comes the important step it seems:

~~~~
hall dist --execute && autoreconf -vif && ./configure && make check
~~~~

`hall dist`. According to `hall dist --help` it will create the build
system files, which I am guessing are all the files for GNU Automake and
GNU Make and so on.

I forgot what autoreconf did again.

`./configure` checks for stuff in my system to be available or not, to
reason about whether the thing will build or not and collect locations
of required binaries etc.

`make check` probably runs my tests.

Everything runs through, there is a lot of output. It only shows `GEN
fslib.go` though, none of the other modules are shown. Probably because
I have not run `hall scan` yet.

(11) `hall scan`. This gets me to the first real error:

~~~~
$ hall scan

Your project contains a file (traces.1) of a type that is not supported by Hall yet.
(unknown-file).  Please report this at our website
~~~~

OK I cannot do that, because Gitlab does not let me in. Fine, where is
that file? `find . -name 'traces.1'` reveals:
`./autom4te.cache/traces.1`. Why does it look into the cache it created
itself? I did never create the file and the folder it is in. Is there
some ignore file for hall, like `.gitignore`, where I need to add the
cache folder to? OK, it is a cache folder, so I will simply delete it
and run `hall scan` again.

~~~~
$ rm -rf autom4te.cache
$ hall scan

Your project contains a file (pre-applypatch.sample) of a type that is not supported by Hall yet.
(unknown-file).  Please report this at our website
~~~~

Damn, another file it does not support! Where is it this time? Oh no …
It is inside `.git`! But why does it complain about that?! It is normal
to have the .git folder at the top level. I cannot remove that. Git hook
sample files are there by default. Perhaps I can remove the sample hook
files and then try again …

… Now it complains about my tag files in .git! It seems I cannot run
`hall scan` successfully.

This is it so far. This is as far as I got and I have no idea, whether I
am anywhere close to a functioning package.

Can you help me out? How do I proceed from here? Please assume no
knowledge about "things that are obvious" about any of guile-hall or
autotools, automake, make and the like.

Do I really have to move my source files into the directory hall created
and change all my import expressions in the source code? That can be
arranged. Although this seems to hint at an unfortunate coupling of
project name and directory in which source files reside. Similar to what
docker-compose is doing with container names and the folder inside which
you run it. Such a thing can be quite annoying.

How do I fix that "unsupported file type" thing?

I feel like there are so many files and stuff hall added, that if only I
understood more about what exactly GNU Guix _must_ find in the project
directory to use it as a package, I might be better off creating that
stuff manually, but perhaps to make a package I must have all this
stuff? I have no idea, whether the license must be in COPYING, or having
it inside LICENSE is fine too. I think I will ask for a complete list of
all things required by Guix on the Guix mailing list. The verdict is not
out yet though. I still hope to make everything work with guile-hall,
hoping anyone can help.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-06 21:49 guile-hall issues converting my project to a hall project Zelphir Kaltstahl
@ 2021-02-07  9:14 ` tomas
  2021-02-07 13:30 ` Tim Van den Langenbergh
       [not found] ` <11206998.46ALo4VoAQ@terra>
  2 siblings, 0 replies; 15+ messages in thread
From: tomas @ 2021-02-07  9:14 UTC (permalink / raw)
  To: guile-user

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

On Sat, Feb 06, 2021 at 10:49:12PM +0100, Zelphir Kaltstahl wrote:
> Hello Guile Users!

Hi, Zelphir

not that I could help you in any way wrt. your guile-hall quest, but
thanks for your long and detailed report. Way better than silently
cursing at the screen and drinking too much coffe ;-)

An example to follow.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-06 21:49 guile-hall issues converting my project to a hall project Zelphir Kaltstahl
  2021-02-07  9:14 ` tomas
@ 2021-02-07 13:30 ` Tim Van den Langenbergh
  2021-02-11 20:30   ` Zelphir Kaltstahl
  2021-02-16  0:23   ` Zelphir Kaltstahl
       [not found] ` <11206998.46ALo4VoAQ@terra>
  2 siblings, 2 replies; 15+ messages in thread
From: Tim Van den Langenbergh @ 2021-02-07 13:30 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote:
> Hello Guile Users!
> 
> I decided to try to use guile-hall to convert my project at
> https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
> For that purpose I created a separate branch
> "wip-guix-package-using-guile-hall"
> (branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-packa
> ge-using-guile-hall commit:
> https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3eb
> d497adcce6b683e82), from which I am starting to run commands.
> 
> It seems, that many of guile-hall's defaults are wrong for my project
> and I need to adapt a lot of its settings. It also tells me to report
> unsupported file types, but I cannot do that in the guile-hall
> repository, because I cannot log in on Gitlab, because Gitlab has a
> "clever" "check of my browser", which simply loops forever reloading the
> "browser check" website … My guess: The check requires third party
> cookies to be set. So I am going to write about it here and hope someone
> knows how to proceed.
> 
> The example call in the readme of
> https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:
> 
> ~~~~
> hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute
> ~~~~
> 
> I am not sure what exactly the prefix is. `hall init --help` only tells
> me: "Prefix of the project.", which does not help me. It basically has
> zero more information for me. Does this already have to do with the
> Makefile, which is created later? I leave prefix at "guile" for now.
> What is "frobnigator"? I think it is the name of the project, because in
> `hall init --help` it says that the syntax is:
> 
> ~~~~
> hall initiate [-cx] NAME
>                      [-a "Alyssa P. Hacker"]
>                      [-l gpl3+]
>                      [-p guile]
>                      [-w "https://website.mine"]
> ~~~~
> 
> (I like the SICP reference, btw.) `NAME` is the only thing that I cannot
> translate anything else to be in the command above. I think it would be
> better to not use something confusing like "frobnigator", which people
> might not know what that even is, and use a generic word like
> "my-project-name".
> 
> So the command I run is:
> 
> ~~~~
> hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib
> --license 'agpl3+' --execute ~~~~
> 
> What I like about it is, that everything seems to be dry-run, except
> when adding `--execute`. That makes things less scary.
> 
> Then hall creates a bunch of files, but most things seem not to consider
> my actual already existing project structure. hall never asks me what my
> test directory is or what file my license information is in. I think it
> would be good to have those things available as command line arguments,
> so that I do not need to fix things afterwards, which differ from the
> defaults.
> 
> I will list the things, that I need to change to correct values after
> the hall command has finished and steps I am taking, from the
> perspective of a first time user, because perhaps it can help improving
> guile-hall:
> 
> (1) Remove my old license file, which was not `COPYING` but `LICENSE`.
> Here I do not really care about in which file it is. It would be great,
> if hall asked me about the `LICENSE` file though. Perhaps a list of
> common names of license files could be added to hall and it could check
> for those?
> 
> (2) In `guix.scm` the version is wrong. It should be `(version
> "0.2.0")`, not `(version "0.1")`. The git repository already has a tag
> `0.2.0`, but I think, that "0.1" is a default value, which is simply put
> into `guix.scm`. Here a `--version` argument would be good to have, with
> the default still being `0.1.0` or `0.1`. I think 3 parts is the better
> choice, because it makes processing version numbers easier. Every
> version number would have 3 parts. Always. And it could be made a list
> of 3 symbols or even numbers as well. But if they are only numbers, one
> could not have something like "rc" for release candidate or stuff like
> that. Also not everyone might want to use version numbers like these. I
> have seen projects using the date as version number.
> 
> (3) After adapting the version number, the `source` has to be adapted as
> well to reflect the change in version. At this point I get insecure
> about the whole thing. "Will Guix be able to find this archive? Will it
> look only for a version number consisting of 2 parts? Will anything
> break later in the process, because I am not following the same
> versioning syntax and have 3 parts instead of 2 parts written in the
> string?"
> 
> (4) In the `guix.scm` native inputs are defined. The concept of that is
> very unclear in my mind. I read about that previously on the Guix pages,
> but I already forgot again what native inputs are and how they differ
> from inputs. Anyway, probably not so important right now. However, they
> list "texinfo". My project does not make use of texinfo at all. But I am
> insecure now about removing it. Perhaps hall will not be able to deal
> with it, if I remove it, so I am leaving it there for now. Hopefully I
> can remove it later and make my dependencies fewer (?).
> 
> (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I
> change it to the correct version.
> 
> (6) Next is the `files` section. This one creates a lot of insecurity.
> It says `(directory "fslib" ())`. I have not put my source files into a
> directory `fslib`, but I had no chance to tell hall, that there is no
> such thing beforehand. If I have to move all my source files, then I
> also need to change all my imports! My source files are in the root
> directory of the project. I've had no need so far to move them into a
> subdirectory. I guess with all the project managing files hall created,
> a subdirectory makes sense, but then I am changing my code to conform to
> what hall wants the structure to be and I am not telling hall what kind
> of structure my project has instead, to make it figure out how to write
> the makefiles etc. So this is one of the points, where I think it would
> be good to give hall an argument `--source-location '.'` or something
> like that. I will try to adapt the configuration by changing the
> `directory` to "." instead of "fslib". More insecurity: "Will hall be
> able to work with that? Will it understand "."? Or will everything break?"
> 
> (7) The tests directory is wrong. I have my tests in `test`, without the
> plural "s". I will change the setting.
> 
> (8) I do not have additional `programs` in this project. Can I simply
> remove this entry from the hall settings? I better leave it in there,
> hall might break, if unexpectedly that setting is missing.
> 
> (9) I do not know what to do now, that hall has created all these files
> and I have corrected some of the values in its settings. At this point I
> am asking myself, whether I somehow need to generate any of the files
> anew. But I find the `HACKING` file and see that in there it says I can
> activate a Guix environment now, from the files hall produced:
> 
> ~~~~
> guix environment -l guix.scm
> ~~~~
> 
> And that still works, even though I changed stuff in there. Good!
> 
> (10) Next comes the important step it seems:
> 
> ~~~~
> hall dist --execute && autoreconf -vif && ./configure && make check
> ~~~~
> 
> `hall dist`. According to `hall dist --help` it will create the build
> system files, which I am guessing are all the files for GNU Automake and
> GNU Make and so on.
> 
> I forgot what autoreconf did again.
> 
> `./configure` checks for stuff in my system to be available or not, to
> reason about whether the thing will build or not and collect locations
> of required binaries etc.
> 
> `make check` probably runs my tests.
> 
> Everything runs through, there is a lot of output. It only shows `GEN
> fslib.go` though, none of the other modules are shown. Probably because
> I have not run `hall scan` yet.
> 
> (11) `hall scan`. This gets me to the first real error:
> 
> ~~~~
> $ hall scan
> 
> Your project contains a file (traces.1) of a type that is not supported by
> Hall yet. (unknown-file).  Please report this at our website
> ~~~~
> 
> OK I cannot do that, because Gitlab does not let me in. Fine, where is
> that file? `find . -name 'traces.1'` reveals:
> `./autom4te.cache/traces.1`. Why does it look into the cache it created
> itself? I did never create the file and the folder it is in. Is there
> some ignore file for hall, like `.gitignore`, where I need to add the
> cache folder to? OK, it is a cache folder, so I will simply delete it
> and run `hall scan` again.
> 
> ~~~~
> $ rm -rf autom4te.cache
> $ hall scan
> 
> Your project contains a file (pre-applypatch.sample) of a type that is not
> supported by Hall yet. (unknown-file).  Please report this at our website
> ~~~~
> 
> Damn, another file it does not support! Where is it this time? Oh no …
> It is inside `.git`! But why does it complain about that?! It is normal
> to have the .git folder at the top level. I cannot remove that. Git hook
> sample files are there by default. Perhaps I can remove the sample hook
> files and then try again …
> 
> … Now it complains about my tag files in .git! It seems I cannot run
> `hall scan` successfully.
> 
> This is it so far. This is as far as I got and I have no idea, whether I
> am anywhere close to a functioning package.
> 
> Can you help me out? How do I proceed from here? Please assume no
> knowledge about "things that are obvious" about any of guile-hall or
> autotools, automake, make and the like.
> 
> Do I really have to move my source files into the directory hall created
> and change all my import expressions in the source code? That can be
> arranged. Although this seems to hint at an unfortunate coupling of
> project name and directory in which source files reside. Similar to what
> docker-compose is doing with container names and the folder inside which
> you run it. Such a thing can be quite annoying.
> 
> How do I fix that "unsupported file type" thing?
> 
> I feel like there are so many files and stuff hall added, that if only I
> understood more about what exactly GNU Guix _must_ find in the project
> directory to use it as a package, I might be better off creating that
> stuff manually, but perhaps to make a package I must have all this
> stuff? I have no idea, whether the license must be in COPYING, or having
> it inside LICENSE is fine too. I think I will ask for a complete list of
> all things required by Guix on the Guix mailing list. The verdict is not
> out yet though. I still hope to make everything work with guile-hall,
> hoping anyone can help.
> 
> Best regards,
> Zelphir

Hi Zelphir,

the prefix is a part of the project name that you do not want to include in the 
name of whichever module/library you are making, for example if I want to make 
a project called "Guile-Utils" which exports a library called "utils" I would 
use the prefix argument to add "guile" in front. Without it I could make a 
library called "utils" but hall would complain if I didn't have a library 
called "guile-utils" as well.

You also raised various good points, especially about what a pain it is to run 
hall scan after running hall dist (which we really should warn people not to 
do).

Basically the way to think of hall is like an inverse git, where instead of 
excluding certain files with a .gitignore, you keep track of files through your 
hall.scm.

If you don't want to restart the conversion of your project to a hall project 
from scratch I fear you may have to edit your hall.scm by hand.

Feel free to contact me if you have more questions.

Vale,

-Tim Van den Langenbergh





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-07 13:30 ` Tim Van den Langenbergh
@ 2021-02-11 20:30   ` Zelphir Kaltstahl
  2021-02-16  0:23   ` Zelphir Kaltstahl
  1 sibling, 0 replies; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-11 20:30 UTC (permalink / raw)
  To: Tim Van den Langenbergh; +Cc: guile-user

On 2/7/21 2:30 PM, Tim Van den Langenbergh wrote:
> On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote:
>> Hello Guile Users!
>>
>> I decided to try to use guile-hall to convert my project at
>> https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
>> For that purpose I created a separate branch
>> "wip-guix-package-using-guile-hall"
>> (branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-packa
>> ge-using-guile-hall commit:
>> https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3eb
>> d497adcce6b683e82), from which I am starting to run commands.
>>
>> It seems, that many of guile-hall's defaults are wrong for my project
>> and I need to adapt a lot of its settings. It also tells me to report
>> unsupported file types, but I cannot do that in the guile-hall
>> repository, because I cannot log in on Gitlab, because Gitlab has a
>> "clever" "check of my browser", which simply loops forever reloading the
>> "browser check" website … My guess: The check requires third party
>> cookies to be set. So I am going to write about it here and hope someone
>> knows how to proceed.
>>
>> The example call in the readme of
>> https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:
>>
>> ~~~~
>> hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute
>> ~~~~
>>
>> I am not sure what exactly the prefix is. `hall init --help` only tells
>> me: "Prefix of the project.", which does not help me. It basically has
>> zero more information for me. Does this already have to do with the
>> Makefile, which is created later? I leave prefix at "guile" for now.
>> What is "frobnigator"? I think it is the name of the project, because in
>> `hall init --help` it says that the syntax is:
>>
>> ~~~~
>> hall initiate [-cx] NAME
>>                      [-a "Alyssa P. Hacker"]
>>                      [-l gpl3+]
>>                      [-p guile]
>>                      [-w "https://website.mine"]
>> ~~~~
>>
>> (I like the SICP reference, btw.) `NAME` is the only thing that I cannot
>> translate anything else to be in the command above. I think it would be
>> better to not use something confusing like "frobnigator", which people
>> might not know what that even is, and use a generic word like
>> "my-project-name".
>>
>> So the command I run is:
>>
>> ~~~~
>> hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib
>> --license 'agpl3+' --execute ~~~~
>>
>> What I like about it is, that everything seems to be dry-run, except
>> when adding `--execute`. That makes things less scary.
>>
>> Then hall creates a bunch of files, but most things seem not to consider
>> my actual already existing project structure. hall never asks me what my
>> test directory is or what file my license information is in. I think it
>> would be good to have those things available as command line arguments,
>> so that I do not need to fix things afterwards, which differ from the
>> defaults.
>>
>> I will list the things, that I need to change to correct values after
>> the hall command has finished and steps I am taking, from the
>> perspective of a first time user, because perhaps it can help improving
>> guile-hall:
>>
>> (1) Remove my old license file, which was not `COPYING` but `LICENSE`.
>> Here I do not really care about in which file it is. It would be great,
>> if hall asked me about the `LICENSE` file though. Perhaps a list of
>> common names of license files could be added to hall and it could check
>> for those?
>>
>> (2) In `guix.scm` the version is wrong. It should be `(version
>> "0.2.0")`, not `(version "0.1")`. The git repository already has a tag
>> `0.2.0`, but I think, that "0.1" is a default value, which is simply put
>> into `guix.scm`. Here a `--version` argument would be good to have, with
>> the default still being `0.1.0` or `0.1`. I think 3 parts is the better
>> choice, because it makes processing version numbers easier. Every
>> version number would have 3 parts. Always. And it could be made a list
>> of 3 symbols or even numbers as well. But if they are only numbers, one
>> could not have something like "rc" for release candidate or stuff like
>> that. Also not everyone might want to use version numbers like these. I
>> have seen projects using the date as version number.
>>
>> (3) After adapting the version number, the `source` has to be adapted as
>> well to reflect the change in version. At this point I get insecure
>> about the whole thing. "Will Guix be able to find this archive? Will it
>> look only for a version number consisting of 2 parts? Will anything
>> break later in the process, because I am not following the same
>> versioning syntax and have 3 parts instead of 2 parts written in the
>> string?"
>>
>> (4) In the `guix.scm` native inputs are defined. The concept of that is
>> very unclear in my mind. I read about that previously on the Guix pages,
>> but I already forgot again what native inputs are and how they differ
>> from inputs. Anyway, probably not so important right now. However, they
>> list "texinfo". My project does not make use of texinfo at all. But I am
>> insecure now about removing it. Perhaps hall will not be able to deal
>> with it, if I remove it, so I am leaving it there for now. Hopefully I
>> can remove it later and make my dependencies fewer (?).
>>
>> (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I
>> change it to the correct version.
>>
>> (6) Next is the `files` section. This one creates a lot of insecurity.
>> It says `(directory "fslib" ())`. I have not put my source files into a
>> directory `fslib`, but I had no chance to tell hall, that there is no
>> such thing beforehand. If I have to move all my source files, then I
>> also need to change all my imports! My source files are in the root
>> directory of the project. I've had no need so far to move them into a
>> subdirectory. I guess with all the project managing files hall created,
>> a subdirectory makes sense, but then I am changing my code to conform to
>> what hall wants the structure to be and I am not telling hall what kind
>> of structure my project has instead, to make it figure out how to write
>> the makefiles etc. So this is one of the points, where I think it would
>> be good to give hall an argument `--source-location '.'` or something
>> like that. I will try to adapt the configuration by changing the
>> `directory` to "." instead of "fslib". More insecurity: "Will hall be
>> able to work with that? Will it understand "."? Or will everything break?"
>>
>> (7) The tests directory is wrong. I have my tests in `test`, without the
>> plural "s". I will change the setting.
>>
>> (8) I do not have additional `programs` in this project. Can I simply
>> remove this entry from the hall settings? I better leave it in there,
>> hall might break, if unexpectedly that setting is missing.
>>
>> (9) I do not know what to do now, that hall has created all these files
>> and I have corrected some of the values in its settings. At this point I
>> am asking myself, whether I somehow need to generate any of the files
>> anew. But I find the `HACKING` file and see that in there it says I can
>> activate a Guix environment now, from the files hall produced:
>>
>> ~~~~
>> guix environment -l guix.scm
>> ~~~~
>>
>> And that still works, even though I changed stuff in there. Good!
>>
>> (10) Next comes the important step it seems:
>>
>> ~~~~
>> hall dist --execute && autoreconf -vif && ./configure && make check
>> ~~~~
>>
>> `hall dist`. According to `hall dist --help` it will create the build
>> system files, which I am guessing are all the files for GNU Automake and
>> GNU Make and so on.
>>
>> I forgot what autoreconf did again.
>>
>> `./configure` checks for stuff in my system to be available or not, to
>> reason about whether the thing will build or not and collect locations
>> of required binaries etc.
>>
>> `make check` probably runs my tests.
>>
>> Everything runs through, there is a lot of output. It only shows `GEN
>> fslib.go` though, none of the other modules are shown. Probably because
>> I have not run `hall scan` yet.
>>
>> (11) `hall scan`. This gets me to the first real error:
>>
>> ~~~~
>> $ hall scan
>>
>> Your project contains a file (traces.1) of a type that is not supported by
>> Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> OK I cannot do that, because Gitlab does not let me in. Fine, where is
>> that file? `find . -name 'traces.1'` reveals:
>> `./autom4te.cache/traces.1`. Why does it look into the cache it created
>> itself? I did never create the file and the folder it is in. Is there
>> some ignore file for hall, like `.gitignore`, where I need to add the
>> cache folder to? OK, it is a cache folder, so I will simply delete it
>> and run `hall scan` again.
>>
>> ~~~~
>> $ rm -rf autom4te.cache
>> $ hall scan
>>
>> Your project contains a file (pre-applypatch.sample) of a type that is not
>> supported by Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> Damn, another file it does not support! Where is it this time? Oh no …
>> It is inside `.git`! But why does it complain about that?! It is normal
>> to have the .git folder at the top level. I cannot remove that. Git hook
>> sample files are there by default. Perhaps I can remove the sample hook
>> files and then try again …
>>
>> … Now it complains about my tag files in .git! It seems I cannot run
>> `hall scan` successfully.
>>
>> This is it so far. This is as far as I got and I have no idea, whether I
>> am anywhere close to a functioning package.
>>
>> Can you help me out? How do I proceed from here? Please assume no
>> knowledge about "things that are obvious" about any of guile-hall or
>> autotools, automake, make and the like.
>>
>> Do I really have to move my source files into the directory hall created
>> and change all my import expressions in the source code? That can be
>> arranged. Although this seems to hint at an unfortunate coupling of
>> project name and directory in which source files reside. Similar to what
>> docker-compose is doing with container names and the folder inside which
>> you run it. Such a thing can be quite annoying.
>>
>> How do I fix that "unsupported file type" thing?
>>
>> I feel like there are so many files and stuff hall added, that if only I
>> understood more about what exactly GNU Guix _must_ find in the project
>> directory to use it as a package, I might be better off creating that
>> stuff manually, but perhaps to make a package I must have all this
>> stuff? I have no idea, whether the license must be in COPYING, or having
>> it inside LICENSE is fine too. I think I will ask for a complete list of
>> all things required by Guix on the Guix mailing list. The verdict is not
>> out yet though. I still hope to make everything work with guile-hall,
>> hoping anyone can help.
>>
>> Best regards,
>> Zelphir
> Hi Zelphir,
>
> the prefix is a part of the project name that you do not want to include in the 
> name of whichever module/library you are making, for example if I want to make 
> a project called "Guile-Utils" which exports a library called "utils" I would 
> use the prefix argument to add "guile" in front. Without it I could make a 
> library called "utils" but hall would complain if I didn't have a library 
> called "guile-utils" as well.
>
> You also raised various good points, especially about what a pain it is to run 
> hall scan after running hall dist (which we really should warn people not to 
> do).
>
> Basically the way to think of hall is like an inverse git, where instead of 
> excluding certain files with a .gitignore, you keep track of files through your 
> hall.scm.
>
> If you don't want to restart the conversion of your project to a hall project 
> from scratch I fear you may have to edit your hall.scm by hand.
>
> Feel free to contact me if you have more questions.
>
> Vale,
>
> -Tim Van den Langenbergh

Hello Tim,

Thank you for explaining the prefix thing. I think that makes sense in
combination with GNU Guix, as GNU Guix has the convention of prefixing
package names with the programming language. Also thanks for mentioning,
that one is not supposed to run hall scan after hall dist. I do not mind
editing guix.scm or hall.scm, as long as the do-s and do-not-s are clear
and I can understand it. I hope to look into making a new hall project
and then incrementally adding my existing library to it. I'll keep you
in mind, if questions arise.

Thanks,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-07 13:30 ` Tim Van den Langenbergh
  2021-02-11 20:30   ` Zelphir Kaltstahl
@ 2021-02-16  0:23   ` Zelphir Kaltstahl
  2021-02-17 22:47     ` Vladimir Zhbanov
  1 sibling, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-16  0:23 UTC (permalink / raw)
  To: Tim Van den Langenbergh; +Cc: guile-user

On 07.02.21 14:30, Tim Van den Langenbergh wrote:
> On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote:
>> Hello Guile Users!
>>
>> I decided to try to use guile-hall to convert my project at
>> https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
>> For that purpose I created a separate branch
>> "wip-guix-package-using-guile-hall"
>> (branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-packa
>> ge-using-guile-hall commit:
>> https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3eb
>> d497adcce6b683e82), from which I am starting to run commands.
>>
>> It seems, that many of guile-hall's defaults are wrong for my project
>> and I need to adapt a lot of its settings. It also tells me to report
>> unsupported file types, but I cannot do that in the guile-hall
>> repository, because I cannot log in on Gitlab, because Gitlab has a
>> "clever" "check of my browser", which simply loops forever reloading the
>> "browser check" website … My guess: The check requires third party
>> cookies to be set. So I am going to write about it here and hope someone
>> knows how to proceed.
>>
>> The example call in the readme of
>> https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:
>>
>> ~~~~
>> hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute
>> ~~~~
>>
>> I am not sure what exactly the prefix is. `hall init --help` only tells
>> me: "Prefix of the project.", which does not help me. It basically has
>> zero more information for me. Does this already have to do with the
>> Makefile, which is created later? I leave prefix at "guile" for now.
>> What is "frobnigator"? I think it is the name of the project, because in
>> `hall init --help` it says that the syntax is:
>>
>> ~~~~
>> hall initiate [-cx] NAME
>>                      [-a "Alyssa P. Hacker"]
>>                      [-l gpl3+]
>>                      [-p guile]
>>                      [-w "https://website.mine"]
>> ~~~~
>>
>> (I like the SICP reference, btw.) `NAME` is the only thing that I cannot
>> translate anything else to be in the command above. I think it would be
>> better to not use something confusing like "frobnigator", which people
>> might not know what that even is, and use a generic word like
>> "my-project-name".
>>
>> So the command I run is:
>>
>> ~~~~
>> hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib
>> --license 'agpl3+' --execute ~~~~
>>
>> What I like about it is, that everything seems to be dry-run, except
>> when adding `--execute`. That makes things less scary.
>>
>> Then hall creates a bunch of files, but most things seem not to consider
>> my actual already existing project structure. hall never asks me what my
>> test directory is or what file my license information is in. I think it
>> would be good to have those things available as command line arguments,
>> so that I do not need to fix things afterwards, which differ from the
>> defaults.
>>
>> I will list the things, that I need to change to correct values after
>> the hall command has finished and steps I am taking, from the
>> perspective of a first time user, because perhaps it can help improving
>> guile-hall:
>>
>> (1) Remove my old license file, which was not `COPYING` but `LICENSE`.
>> Here I do not really care about in which file it is. It would be great,
>> if hall asked me about the `LICENSE` file though. Perhaps a list of
>> common names of license files could be added to hall and it could check
>> for those?
>>
>> (2) In `guix.scm` the version is wrong. It should be `(version
>> "0.2.0")`, not `(version "0.1")`. The git repository already has a tag
>> `0.2.0`, but I think, that "0.1" is a default value, which is simply put
>> into `guix.scm`. Here a `--version` argument would be good to have, with
>> the default still being `0.1.0` or `0.1`. I think 3 parts is the better
>> choice, because it makes processing version numbers easier. Every
>> version number would have 3 parts. Always. And it could be made a list
>> of 3 symbols or even numbers as well. But if they are only numbers, one
>> could not have something like "rc" for release candidate or stuff like
>> that. Also not everyone might want to use version numbers like these. I
>> have seen projects using the date as version number.
>>
>> (3) After adapting the version number, the `source` has to be adapted as
>> well to reflect the change in version. At this point I get insecure
>> about the whole thing. "Will Guix be able to find this archive? Will it
>> look only for a version number consisting of 2 parts? Will anything
>> break later in the process, because I am not following the same
>> versioning syntax and have 3 parts instead of 2 parts written in the
>> string?"
>>
>> (4) In the `guix.scm` native inputs are defined. The concept of that is
>> very unclear in my mind. I read about that previously on the Guix pages,
>> but I already forgot again what native inputs are and how they differ
>> from inputs. Anyway, probably not so important right now. However, they
>> list "texinfo". My project does not make use of texinfo at all. But I am
>> insecure now about removing it. Perhaps hall will not be able to deal
>> with it, if I remove it, so I am leaving it there for now. Hopefully I
>> can remove it later and make my dependencies fewer (?).
>>
>> (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I
>> change it to the correct version.
>>
>> (6) Next is the `files` section. This one creates a lot of insecurity.
>> It says `(directory "fslib" ())`. I have not put my source files into a
>> directory `fslib`, but I had no chance to tell hall, that there is no
>> such thing beforehand. If I have to move all my source files, then I
>> also need to change all my imports! My source files are in the root
>> directory of the project. I've had no need so far to move them into a
>> subdirectory. I guess with all the project managing files hall created,
>> a subdirectory makes sense, but then I am changing my code to conform to
>> what hall wants the structure to be and I am not telling hall what kind
>> of structure my project has instead, to make it figure out how to write
>> the makefiles etc. So this is one of the points, where I think it would
>> be good to give hall an argument `--source-location '.'` or something
>> like that. I will try to adapt the configuration by changing the
>> `directory` to "." instead of "fslib". More insecurity: "Will hall be
>> able to work with that? Will it understand "."? Or will everything break?"
>>
>> (7) The tests directory is wrong. I have my tests in `test`, without the
>> plural "s". I will change the setting.
>>
>> (8) I do not have additional `programs` in this project. Can I simply
>> remove this entry from the hall settings? I better leave it in there,
>> hall might break, if unexpectedly that setting is missing.
>>
>> (9) I do not know what to do now, that hall has created all these files
>> and I have corrected some of the values in its settings. At this point I
>> am asking myself, whether I somehow need to generate any of the files
>> anew. But I find the `HACKING` file and see that in there it says I can
>> activate a Guix environment now, from the files hall produced:
>>
>> ~~~~
>> guix environment -l guix.scm
>> ~~~~
>>
>> And that still works, even though I changed stuff in there. Good!
>>
>> (10) Next comes the important step it seems:
>>
>> ~~~~
>> hall dist --execute && autoreconf -vif && ./configure && make check
>> ~~~~
>>
>> `hall dist`. According to `hall dist --help` it will create the build
>> system files, which I am guessing are all the files for GNU Automake and
>> GNU Make and so on.
>>
>> I forgot what autoreconf did again.
>>
>> `./configure` checks for stuff in my system to be available or not, to
>> reason about whether the thing will build or not and collect locations
>> of required binaries etc.
>>
>> `make check` probably runs my tests.
>>
>> Everything runs through, there is a lot of output. It only shows `GEN
>> fslib.go` though, none of the other modules are shown. Probably because
>> I have not run `hall scan` yet.
>>
>> (11) `hall scan`. This gets me to the first real error:
>>
>> ~~~~
>> $ hall scan
>>
>> Your project contains a file (traces.1) of a type that is not supported by
>> Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> OK I cannot do that, because Gitlab does not let me in. Fine, where is
>> that file? `find . -name 'traces.1'` reveals:
>> `./autom4te.cache/traces.1`. Why does it look into the cache it created
>> itself? I did never create the file and the folder it is in. Is there
>> some ignore file for hall, like `.gitignore`, where I need to add the
>> cache folder to? OK, it is a cache folder, so I will simply delete it
>> and run `hall scan` again.
>>
>> ~~~~
>> $ rm -rf autom4te.cache
>> $ hall scan
>>
>> Your project contains a file (pre-applypatch.sample) of a type that is not
>> supported by Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> Damn, another file it does not support! Where is it this time? Oh no …
>> It is inside `.git`! But why does it complain about that?! It is normal
>> to have the .git folder at the top level. I cannot remove that. Git hook
>> sample files are there by default. Perhaps I can remove the sample hook
>> files and then try again …
>>
>> … Now it complains about my tag files in .git! It seems I cannot run
>> `hall scan` successfully.
>>
>> This is it so far. This is as far as I got and I have no idea, whether I
>> am anywhere close to a functioning package.
>>
>> Can you help me out? How do I proceed from here? Please assume no
>> knowledge about "things that are obvious" about any of guile-hall or
>> autotools, automake, make and the like.
>>
>> Do I really have to move my source files into the directory hall created
>> and change all my import expressions in the source code? That can be
>> arranged. Although this seems to hint at an unfortunate coupling of
>> project name and directory in which source files reside. Similar to what
>> docker-compose is doing with container names and the folder inside which
>> you run it. Such a thing can be quite annoying.
>>
>> How do I fix that "unsupported file type" thing?
>>
>> I feel like there are so many files and stuff hall added, that if only I
>> understood more about what exactly GNU Guix _must_ find in the project
>> directory to use it as a package, I might be better off creating that
>> stuff manually, but perhaps to make a package I must have all this
>> stuff? I have no idea, whether the license must be in COPYING, or having
>> it inside LICENSE is fine too. I think I will ask for a complete list of
>> all things required by Guix on the Guix mailing list. The verdict is not
>> out yet though. I still hope to make everything work with guile-hall,
>> hoping anyone can help.
>>
>> Best regards,
>> Zelphir
> Hi Zelphir,
>
> the prefix is a part of the project name that you do not want to include in the 
> name of whichever module/library you are making, for example if I want to make 
> a project called "Guile-Utils" which exports a library called "utils" I would 
> use the prefix argument to add "guile" in front. Without it I could make a 
> library called "utils" but hall would complain if I didn't have a library 
> called "guile-utils" as well.
>
> You also raised various good points, especially about what a pain it is to run 
> hall scan after running hall dist (which we really should warn people not to 
> do).
>
> Basically the way to think of hall is like an inverse git, where instead of 
> excluding certain files with a .gitignore, you keep track of files through your 
> hall.scm.
>
> If you don't want to restart the conversion of your project to a hall project 
> from scratch I fear you may have to edit your hall.scm by hand.
>
> Feel free to contact me if you have more questions.
>
> Vale,
>
> -Tim Van den Langenbergh

Hello Tim and hello Guile users!

I finally got around to reproducing your patch step-by-step. I have
tried to make the commits as "atomic" as possible, so that one can see
each step I took in a separate commit. The result is here:
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/65d40a0f1dd4bb2005d3f369928ebf5b2247eacc.
Now however, I am hitting an issue. When I run:

~~~~
hall dist --execute && autoreconf -vif && ./configure && make check
~~~~

as indicated in the autogenerated HACKING file, I get an error deep in
the generated `configure` file:

~~~~
$ hall dist --execute && autoreconf -vif && ./configure && make check
Making file: /home/user/dev/Guile/guile-fslib/NEWS
Making file: /home/user/dev/Guile/guile-fslib/AUTHORS
Making file: /home/user/dev/Guile/guile-fslib/ChangeLog
Making dir: /home/user/dev/Guile/guile-fslib/build-aux
  Making file: /home/user/dev/Guile/guile-fslib/build-aux/test-driver.scm
Making file: /home/user/dev/Guile/guile-fslib/configure.ac
Making file: /home/user/dev/Guile/guile-fslib/Makefile.am
Making file: /home/user/dev/Guile/guile-fslib/pre-inst-env.in
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:11: installing 'build-aux/install-sh'
configure.ac:11: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am:     Consider adding the COPYING file to the version control system
Makefile.am:     for your code, to avoid questions about which license your project uses
Makefile.am:62: installing 'build-aux/mdate-sh'
Makefile.am:62: installing 'build-aux/texinfo.tex'
Makefile.am:63: warning: user target 'dvi' defined here ...
automake: ... overrides Automake target 'dvi' defined here
Makefile.am:63: consider using dvi-local instead of dvi
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
./configure: line 2385: syntax error near unexpected token `3.0'
./configure: line 2385: `GUILE_PKG(3.0 2.2 2.0)'
~~~~

The line in the generated `configure` file looks quite simple. It is only:

~~~~
GUILE_PKG(3.0 2.2 2.0)
~~~~

It looks like there could be a simple fix, but I do not know what to do
about this error and how that error could happen in the first place.

To be sure I also tried the same with your patch applied to the commit,
where I had not yet done any steps with guile-hall, but the result and
error remains the same.

How can I fix this error?

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
       [not found]   ` <02902ff9-1585-a453-4e36-c9a731eee6fe@posteo.de>
@ 2021-02-16 16:48     ` Tim Van den Langenbergh
  2021-02-16 18:12       ` Zelphir Kaltstahl
  0 siblings, 1 reply; 15+ messages in thread
From: Tim Van den Langenbergh @ 2021-02-16 16:48 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

Err, looking at your hall.scm file, you have the fslib file added to your
libraries twice.

Guix environment is not needed if you have all the requirements for building
the package installed locally, but if you want to distribute your package it's
good practise to ensure it builds in a clean environment (see also https://
guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
information about Guix environments).

The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html

Hope this helps,

Vale

-Tim





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-16 16:48     ` Tim Van den Langenbergh
@ 2021-02-16 18:12       ` Zelphir Kaltstahl
  2021-02-17 21:17         ` Alex Sassmannshausen
  0 siblings, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-16 18:12 UTC (permalink / raw)
  To: Tim Van den Langenbergh; +Cc: guile-user

Hello Tim!

Thank you, it works now!

Removing the duplicate entry of `fslib` in hall.scm fixed it.

Regarding the license: OK, I have no problem moving my license to
`COPYING`. However, I still think, that it should not put GPL there,
when I specified AGPL in `hall.scm`. This looks like a hardcoded
fallback, which does not take the license specification into account.
Something like: "If there is no `COPYING` file just put GPL into a file
`COPYING`." instead of "If there is no `COPYING` file just put
<user-specified-license-in-hall.scm> into a file `COPYING`.". I could be
wrong though, as I do not know anything about guile-hall's internals.

Follow up question would be, how to bring the package into the guix
repository, but I am guessing, that it will be answered at
https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html,
which I have not read yet.

Another question is, whether I should put you into the authors file and
write something like "help with packaging" there. What is the common
practice?

Best regards,
Zelphir

On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote:
> Err, looking at your hall.scm file, you have the fslib file added to your
> libraries twice.
>
> Guix environment is not needed if you have all the requirements for building
> the package installed locally, but if you want to distribute your package it's
> good practise to ensure it builds in a clean environment (see also https://
> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
> information about Guix environments).
>
> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html
>
> Hope this helps,
>
> Vale
>
> -Tim
>
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-16 18:12       ` Zelphir Kaltstahl
@ 2021-02-17 21:17         ` Alex Sassmannshausen
  2021-02-18 19:16           ` Zelphir Kaltstahl
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Sassmannshausen @ 2021-02-17 21:17 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

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

Hi Zelphir and Tim,

I am the author of guile hall — apologies for only now getting into this
thread. I'm afraid I have been somewhat distracted with other things.

First of all I want to echo what others have said — thank you very much
for your detailed descriptions of what exactly happened when you tried
to migrate the project to guile hall.

The aim of the project is to massively reduce the barrier of entry to
creating new, portable, high quality guile projects — and to contribute
them to Guix. Your descriptions suggest it's not there yet!

In any case, some comments inline:

Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:

> Hello Tim!
>
> Thank you, it works now!
>
> Removing the duplicate entry of `fslib` in hall.scm fixed it.

Fwiw, since commit ac76541a this issue can be automatically resolved by
running scan once more: it should remove duplicate entries in hall.scm.

> Regarding the license: OK, I have no problem moving my license to
> `COPYING`. However, I still think, that it should not put GPL there,
> when I specified AGPL in `hall.scm`. This looks like a hardcoded
> fallback, which does not take the license specification into account.
> Something like: "If there is no `COPYING` file just put GPL into a file
> `COPYING`." instead of "If there is no `COPYING` file just put
> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be
> wrong though, as I do not know anything about guile-hall's internals.

This is odd — Hall should respect your license choice. It should, for
(A)GPL licenses automatically download those from the internet and
install them in COPYING. There was an issue with those licenses hiding
behind a 302 status code, which resulted in fallback text being loaded
in COPYING. But even that fallback text should respect your license.

I just tried changing my license to AGPLv3+ in one of my projects,
running hall from Master (the most recent commit fixes the 302 license
issue), and it's fetching the license correctly.

I'd be interested in seeing what your experience is if you are willing
to try?

In any case, Hall is undergoing active development, and I'm hoping to
have a fresh release end of this month, with a whole bunch of
improvements and bug fixes. Definitely feel free to drop issues to me
directly by email or on gitlab (though some of the ones you raised have
been fixed, like the unknown filetype issue).

Best wishes,

Alex

> Follow up question would be, how to bring the package into the guix
> repository, but I am guessing, that it will be answered at
> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html,
> which I have not read yet.
>
> Another question is, whether I should put you into the authors file and
> write something like "help with packaging" there. What is the common
> practice?
>
> Best regards,
> Zelphir
>
> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote:
>> Err, looking at your hall.scm file, you have the fslib file added to your
>> libraries twice.
>>
>> Guix environment is not needed if you have all the requirements for building
>> the package installed locally, but if you want to distribute your package it's
>> good practise to ensure it builds in a clean environment (see also https://
>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
>> information about Guix environments).
>>
>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html
>>
>> Hope this helps,
>>
>> Vale
>>
>> -Tim
>>
>>


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-16  0:23   ` Zelphir Kaltstahl
@ 2021-02-17 22:47     ` Vladimir Zhbanov
  2021-02-18 12:18       ` alex sassmannshausen
  0 siblings, 1 reply; 15+ messages in thread
From: Vladimir Zhbanov @ 2021-02-17 22:47 UTC (permalink / raw)
  To: guile-user


Hi Zelphir,

On Tue, Feb 16, 2021 at 01:23:34AM +0100, Zelphir Kaltstahl wrote:
...

> The line in the generated `configure` file looks quite simple. It is only:
> 
> ~~~~
> GUILE_PKG(3.0 2.2 2.0)
> ~~~~

> It looks like there could be a simple fix, but I do not know what to do
> about this error and how that error could happen in the first place.

IIUC, the macro args should be in square brackets:

GUILE_PKG([3.0 2.2 2.0])

-- 
  Vladimir



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-17 22:47     ` Vladimir Zhbanov
@ 2021-02-18 12:18       ` alex sassmannshausen
  0 siblings, 0 replies; 15+ messages in thread
From: alex sassmannshausen @ 2021-02-18 12:18 UTC (permalink / raw)
  To: Guile User

Yes, I forgot to mention this in my wall of text. Vladimir's solution is
correct.

Hall does this in master too.

Alex

On Wed, 17 Feb 2021, 23:47 Vladimir Zhbanov, <vzhbanov@gmail.com> wrote:

>
> Hi Zelphir,
>
> On Tue, Feb 16, 2021 at 01:23:34AM +0100, Zelphir Kaltstahl wrote:
> ...
>
> > The line in the generated `configure` file looks quite simple. It is
> only:
> >
> > ~~~~
> > GUILE_PKG(3.0 2.2 2.0)
> > ~~~~
>
> > It looks like there could be a simple fix, but I do not know what to do
> > about this error and how that error could happen in the first place.
>
> IIUC, the macro args should be in square brackets:
>
> GUILE_PKG([3.0 2.2 2.0])
>
> --
>   Vladimir
>
>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-17 21:17         ` Alex Sassmannshausen
@ 2021-02-18 19:16           ` Zelphir Kaltstahl
  2021-02-21 13:42             ` Alex Sassmannshausen
  0 siblings, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-18 19:16 UTC (permalink / raw)
  To: alex.sassmannshausen; +Cc: guile-user

Hi Alex!

I am willing to test/try some more.

When you say "since commit xyz", do you mean commit of guile-hall
itself, or a commit of Guix, where an updated version of guile-hall is
available?

How would I test the master branch version? I would guess install it in
a guix environment and then use that environment to try and convert a
project.

What would you suggest testing?

It was quite OK to edit hall.scm in an editor. Perhaps, if a project is
significantly bigger than my project, it would become cumbersome, but
for me personally it is fine, now that I know what goes in there and how
it needs to look.

I have not yet begun writing a guide for converting a project. Hopefully
I'll be able to do so soon.

Best regards,
Zelphir

On 2/17/21 10:17 PM, Alex Sassmannshausen wrote:
> Hi Zelphir and Tim,
>
> I am the author of guile hall — apologies for only now getting into this
> thread. I'm afraid I have been somewhat distracted with other things.
>
> First of all I want to echo what others have said — thank you very much
> for your detailed descriptions of what exactly happened when you tried
> to migrate the project to guile hall.
>
> The aim of the project is to massively reduce the barrier of entry to
> creating new, portable, high quality guile projects — and to contribute
> them to Guix. Your descriptions suggest it's not there yet!
>
> In any case, some comments inline:
>
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>
>> Hello Tim!
>>
>> Thank you, it works now!
>>
>> Removing the duplicate entry of `fslib` in hall.scm fixed it.
> Fwiw, since commit ac76541a this issue can be automatically resolved by
> running scan once more: it should remove duplicate entries in hall.scm.
>
>> Regarding the license: OK, I have no problem moving my license to
>> `COPYING`. However, I still think, that it should not put GPL there,
>> when I specified AGPL in `hall.scm`. This looks like a hardcoded
>> fallback, which does not take the license specification into account.
>> Something like: "If there is no `COPYING` file just put GPL into a file
>> `COPYING`." instead of "If there is no `COPYING` file just put
>> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be
>> wrong though, as I do not know anything about guile-hall's internals.
> This is odd — Hall should respect your license choice. It should, for
> (A)GPL licenses automatically download those from the internet and
> install them in COPYING. There was an issue with those licenses hiding
> behind a 302 status code, which resulted in fallback text being loaded
> in COPYING. But even that fallback text should respect your license.
>
> I just tried changing my license to AGPLv3+ in one of my projects,
> running hall from Master (the most recent commit fixes the 302 license
> issue), and it's fetching the license correctly.
>
> I'd be interested in seeing what your experience is if you are willing
> to try?
>
> In any case, Hall is undergoing active development, and I'm hoping to
> have a fresh release end of this month, with a whole bunch of
> improvements and bug fixes. Definitely feel free to drop issues to me
> directly by email or on gitlab (though some of the ones you raised have
> been fixed, like the unknown filetype issue).
>
> Best wishes,
>
> Alex
>
>> Follow up question would be, how to bring the package into the guix
>> repository, but I am guessing, that it will be answered at
>> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html,
>> which I have not read yet.
>>
>> Another question is, whether I should put you into the authors file and
>> write something like "help with packaging" there. What is the common
>> practice?
>>
>> Best regards,
>> Zelphir
>>
>> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote:
>>> Err, looking at your hall.scm file, you have the fslib file added to your
>>> libraries twice.
>>>
>>> Guix environment is not needed if you have all the requirements for building
>>> the package installed locally, but if you want to distribute your package it's
>>> good practise to ensure it builds in a clean environment (see also https://
>>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
>>> information about Guix environments).
>>>
>>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
>>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html
>>>
>>> Hope this helps,
>>>
>>> Vale
>>>
>>> -Tim
>>>
>>>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall issues converting my project to a hall project
  2021-02-18 19:16           ` Zelphir Kaltstahl
@ 2021-02-21 13:42             ` Alex Sassmannshausen
  2021-02-22 11:34               ` guile-hall packaging guide Zelphir Kaltstahl
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Sassmannshausen @ 2021-02-21 13:42 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

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

Hi Zelphir,

Some notes inline:

Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:

> I am willing to test/try some more.

Great, that's really good to hear!

> When you say "since commit xyz", do you mean commit of guile-hall
> itself, or a commit of Guix, where an updated version of guile-hall is
> available?

I mean in the guile-hall repository. But you should be able to do:
guix install guile-hall --with-commit="guile-hall=HASH"
to get the right version.

I *think* it should just build and work.

> How would I test the master branch version? I would guess install it in
> a guix environment and then use that environment to try and convert a
> project.

Yeah, that would work too.

You should even be able to combine the two and go with:
guix environment --ad-hoc guile guile-hall --with-commit="guile-hall=HASH"

> What would you suggest testing?

I think it would be best if you tried using the convert command and see
whether it gets you better results this time around.  Outside of that,
probably playing with the new --skip option and `scan' arguments might
be useful and interesting for you.

> It was quite OK to edit hall.scm in an editor. Perhaps, if a project is
> significantly bigger than my project, it would become cumbersome, but
> for me personally it is fine, now that I know what goes in there and how
> it needs to look.

Good to hear. The spec was always meant to be human readable. Still, the
new scan options might make it easier to add additional files
gradually.

> I have not yet begun writing a guide for converting a project. Hopefully
> I'll be able to do so soon.

That would be very interesting to see!

Best wishes,

Alex

>
> Best regards,
> Zelphir
>
> On 2/17/21 10:17 PM, Alex Sassmannshausen wrote:
>> Hi Zelphir and Tim,
>>
>> I am the author of guile hall — apologies for only now getting into this
>> thread. I'm afraid I have been somewhat distracted with other things.
>>
>> First of all I want to echo what others have said — thank you very much
>> for your detailed descriptions of what exactly happened when you tried
>> to migrate the project to guile hall.
>>
>> The aim of the project is to massively reduce the barrier of entry to
>> creating new, portable, high quality guile projects — and to contribute
>> them to Guix. Your descriptions suggest it's not there yet!
>>
>> In any case, some comments inline:
>>
>> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>>
>>> Hello Tim!
>>>
>>> Thank you, it works now!
>>>
>>> Removing the duplicate entry of `fslib` in hall.scm fixed it.
>> Fwiw, since commit ac76541a this issue can be automatically resolved by
>> running scan once more: it should remove duplicate entries in hall.scm.
>>
>>> Regarding the license: OK, I have no problem moving my license to
>>> `COPYING`. However, I still think, that it should not put GPL there,
>>> when I specified AGPL in `hall.scm`. This looks like a hardcoded
>>> fallback, which does not take the license specification into account.
>>> Something like: "If there is no `COPYING` file just put GPL into a file
>>> `COPYING`." instead of "If there is no `COPYING` file just put
>>> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be
>>> wrong though, as I do not know anything about guile-hall's internals.
>> This is odd — Hall should respect your license choice. It should, for
>> (A)GPL licenses automatically download those from the internet and
>> install them in COPYING. There was an issue with those licenses hiding
>> behind a 302 status code, which resulted in fallback text being loaded
>> in COPYING. But even that fallback text should respect your license.
>>
>> I just tried changing my license to AGPLv3+ in one of my projects,
>> running hall from Master (the most recent commit fixes the 302 license
>> issue), and it's fetching the license correctly.
>>
>> I'd be interested in seeing what your experience is if you are willing
>> to try?
>>
>> In any case, Hall is undergoing active development, and I'm hoping to
>> have a fresh release end of this month, with a whole bunch of
>> improvements and bug fixes. Definitely feel free to drop issues to me
>> directly by email or on gitlab (though some of the ones you raised have
>> been fixed, like the unknown filetype issue).
>>
>> Best wishes,
>>
>> Alex
>>
>>> Follow up question would be, how to bring the package into the guix
>>> repository, but I am guessing, that it will be answered at
>>> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html,
>>> which I have not read yet.
>>>
>>> Another question is, whether I should put you into the authors file and
>>> write something like "help with packaging" there. What is the common
>>> practice?
>>>
>>> Best regards,
>>> Zelphir
>>>
>>> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote:
>>>> Err, looking at your hall.scm file, you have the fslib file added to your
>>>> libraries twice.
>>>>
>>>> Guix environment is not needed if you have all the requirements for building
>>>> the package installed locally, but if you want to distribute your package it's
>>>> good practise to ensure it builds in a clean environment (see also https://
>>>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
>>>> information about Guix environments).
>>>>
>>>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
>>>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html
>>>>
>>>> Hope this helps,
>>>>
>>>> Vale
>>>>
>>>> -Tim
>>>>
>>>>


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* guile-hall packaging guide
  2021-02-21 13:42             ` Alex Sassmannshausen
@ 2021-02-22 11:34               ` Zelphir Kaltstahl
  2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
  0 siblings, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-22 11:34 UTC (permalink / raw)
  To: alex.sassmannshausen; +Cc: guile-user

Hi Alex!

I've begun writing the guide for using guile-hall to package GNU Guile
libraries/programs:

https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide

If you would like to take a look and if you see any mistakes, imprecise
terminology, missing explanations or anything, please let me know and I
will try to improve it.

Still have to get to the tests with the master branch and all that. I
guess I will first get a first version of that guide done and then use
it to go through the steps testing the up-to-date version of guile-hall.

Best regards,
Zelphir

On 2/21/21 2:42 PM, Alex Sassmannshausen wrote:
> Hi Zelphir,
>
> Some notes inline:
>
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>
>> I am willing to test/try some more.
> Great, that's really good to hear!
>
>> When you say "since commit xyz", do you mean commit of guile-hall
>> itself, or a commit of Guix, where an updated version of guile-hall is
>> available?
> I mean in the guile-hall repository. But you should be able to do:
> guix install guile-hall --with-commit="guile-hall=HASH"
> to get the right version.
>
> I *think* it should just build and work.
>
>> How would I test the master branch version? I would guess install it in
>> a guix environment and then use that environment to try and convert a
>> project.
> Yeah, that would work too.
>
> You should even be able to combine the two and go with:
> guix environment --ad-hoc guile guile-hall --with-commit="guile-hall=HASH"
>
>> What would you suggest testing?
> I think it would be best if you tried using the convert command and see
> whether it gets you better results this time around.  Outside of that,
> probably playing with the new --skip option and `scan' arguments might
> be useful and interesting for you.
>
>> It was quite OK to edit hall.scm in an editor. Perhaps, if a project is
>> significantly bigger than my project, it would become cumbersome, but
>> for me personally it is fine, now that I know what goes in there and how
>> it needs to look.
> Good to hear. The spec was always meant to be human readable. Still, the
> new scan options might make it easier to add additional files
> gradually.
>
>> I have not yet begun writing a guide for converting a project. Hopefully
>> I'll be able to do so soon.
> That would be very interesting to see!
>
> Best wishes,
>
> Alex
>
>> Best regards,
>> Zelphir
>>
>> On 2/17/21 10:17 PM, Alex Sassmannshausen wrote:
>>> Hi Zelphir and Tim,
>>>
>>> I am the author of guile hall — apologies for only now getting into this
>>> thread. I'm afraid I have been somewhat distracted with other things.
>>>
>>> First of all I want to echo what others have said — thank you very much
>>> for your detailed descriptions of what exactly happened when you tried
>>> to migrate the project to guile hall.
>>>
>>> The aim of the project is to massively reduce the barrier of entry to
>>> creating new, portable, high quality guile projects — and to contribute
>>> them to Guix. Your descriptions suggest it's not there yet!
>>>
>>> In any case, some comments inline:
>>>
>>> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>>>
>>>> Hello Tim!
>>>>
>>>> Thank you, it works now!
>>>>
>>>> Removing the duplicate entry of `fslib` in hall.scm fixed it.
>>> Fwiw, since commit ac76541a this issue can be automatically resolved by
>>> running scan once more: it should remove duplicate entries in hall.scm.
>>>
>>>> Regarding the license: OK, I have no problem moving my license to
>>>> `COPYING`. However, I still think, that it should not put GPL there,
>>>> when I specified AGPL in `hall.scm`. This looks like a hardcoded
>>>> fallback, which does not take the license specification into account.
>>>> Something like: "If there is no `COPYING` file just put GPL into a file
>>>> `COPYING`." instead of "If there is no `COPYING` file just put
>>>> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be
>>>> wrong though, as I do not know anything about guile-hall's internals.
>>> This is odd — Hall should respect your license choice. It should, for
>>> (A)GPL licenses automatically download those from the internet and
>>> install them in COPYING. There was an issue with those licenses hiding
>>> behind a 302 status code, which resulted in fallback text being loaded
>>> in COPYING. But even that fallback text should respect your license.
>>>
>>> I just tried changing my license to AGPLv3+ in one of my projects,
>>> running hall from Master (the most recent commit fixes the 302 license
>>> issue), and it's fetching the license correctly.
>>>
>>> I'd be interested in seeing what your experience is if you are willing
>>> to try?
>>>
>>> In any case, Hall is undergoing active development, and I'm hoping to
>>> have a fresh release end of this month, with a whole bunch of
>>> improvements and bug fixes. Definitely feel free to drop issues to me
>>> directly by email or on gitlab (though some of the ones you raised have
>>> been fixed, like the unknown filetype issue).
>>>
>>> Best wishes,
>>>
>>> Alex
>>>
>>>> Follow up question would be, how to bring the package into the guix
>>>> repository, but I am guessing, that it will be answered at
>>>> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html,
>>>> which I have not read yet.
>>>>
>>>> Another question is, whether I should put you into the authors file and
>>>> write something like "help with packaging" there. What is the common
>>>> practice?
>>>>
>>>> Best regards,
>>>> Zelphir
>>>>
>>>> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote:
>>>>> Err, looking at your hall.scm file, you have the fslib file added to your
>>>>> libraries twice.
>>>>>
>>>>> Guix environment is not needed if you have all the requirements for building
>>>>> the package installed locally, but if you want to distribute your package it's
>>>>> good practise to ensure it builds in a clean environment (see also https://
>>>>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more
>>>>> information about Guix environments).
>>>>>
>>>>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility
>>>>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Vale
>>>>>
>>>>> -Tim
>>>>>
>>>>>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall packaging guide
  2021-02-22 11:34               ` guile-hall packaging guide Zelphir Kaltstahl
@ 2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
  2021-02-23 16:32                   ` Alex Sassmannshausen
  0 siblings, 1 reply; 15+ messages in thread
From: Jérémy Korwin-Zmijowski @ 2021-02-22 20:52 UTC (permalink / raw)
  To: Zelphir Kaltstahl, alex.sassmannshausen; +Cc: guile-user

Le lundi 22 février 2021 à 12:34 +0100, Zelphir Kaltstahl a écrit :
> I've begun writing the guide for using guile-hall to package GNU
> Guile
> libraries/programs:
> 
> https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide

Wow, I have to read that ! Nice work ;-)

Jérémy




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: guile-hall packaging guide
  2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
@ 2021-02-23 16:32                   ` Alex Sassmannshausen
  0 siblings, 0 replies; 15+ messages in thread
From: Alex Sassmannshausen @ 2021-02-23 16:32 UTC (permalink / raw)
  To: Jérémy Korwin-Zmijowski; +Cc: guile-user

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

seconded! Thanks for writing this, Zelphir!

Alex


Jérémy Korwin-Zmijowski <jeremy@korwin-zmijowski.fr> writes:

> Le lundi 22 février 2021 à 12:34 +0100, Zelphir Kaltstahl a écrit :
>> I've begun writing the guide for using guile-hall to package GNU
>> Guile
>> libraries/programs:
>> 
>> https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide
>
> Wow, I have to read that ! Nice work ;-)
>
> Jérémy


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-02-23 16:32 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-06 21:49 guile-hall issues converting my project to a hall project Zelphir Kaltstahl
2021-02-07  9:14 ` tomas
2021-02-07 13:30 ` Tim Van den Langenbergh
2021-02-11 20:30   ` Zelphir Kaltstahl
2021-02-16  0:23   ` Zelphir Kaltstahl
2021-02-17 22:47     ` Vladimir Zhbanov
2021-02-18 12:18       ` alex sassmannshausen
     [not found] ` <11206998.46ALo4VoAQ@terra>
     [not found]   ` <02902ff9-1585-a453-4e36-c9a731eee6fe@posteo.de>
2021-02-16 16:48     ` Tim Van den Langenbergh
2021-02-16 18:12       ` Zelphir Kaltstahl
2021-02-17 21:17         ` Alex Sassmannshausen
2021-02-18 19:16           ` Zelphir Kaltstahl
2021-02-21 13:42             ` Alex Sassmannshausen
2021-02-22 11:34               ` guile-hall packaging guide Zelphir Kaltstahl
2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
2021-02-23 16:32                   ` Alex Sassmannshausen

unofficial mirror of guile-user@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-user/0 guile-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-user guile-user/ https://yhetil.org/guile-user \
		guile-user@gnu.org
	public-inbox-index guile-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.user
	nntp://news.gmane.io/gmane.lisp.guile.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git