Re: neovim and luajit?

[HiPhish]

I just want to add my 2 cents to the discussion. Officially Neovim supports 
only 
Lua 5.1 as its extension language according to the manual (`:h lua-intro`):

> The Lua 5.1 language is builtin and always available.

Using LuaJIT allows the use of some extensions to Lua 5.1, but plugins relying 
on this functionality are strictly speaking non-portable because not all users 
might have them. I don't know if it is possible with Guix, but the ideal 
solution would be to use LuaJIT where available and fall back on Lua 5.1 
otherwise.

On Sunday, 25 April 2021 09:15:57 CEST Efraim Flashner wrote:
> On Thu, Apr 22, 2021 at 01:33:58AM -0400, Jack Hill wrote:
> > On Fri, 31 Jul 2020, Jack Hill wrote:
> > > Hi Guix,
> > > 
> > > I'm wondering why we use Lua 5.1 instead of LuaJIT for neovim? It seems
> > > that upstream prefers LuaJIT given the non-default configure flag we
> > > use[0] and their FAQ[1].
> > > 
> > > I don't have an opinion either way. I'm learning about neovim today, and
> > > am curious how we arrived at our configuration.
> > > 
> > > [0]
> > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/vim.scm?id
> > > =96a655a77bb087397a9436391e472c36ff0a2ec2#n647 [1]
> > > https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x
> > > 
> > > Best,
> > > Jack
> > 
> > I've returned to the above question. With the attached patch, neovim
> > builds
> > on x86_64 and performs basic editing functions. I did not test it with any
> > extra packages or plugins.
> > 
> > In addition to what I said before, I'm also interested in LuaJIT because
> > it
> > supports the 5.1 language and still seems to be developed upstream. Lua is
> > no longer developing the 5.1 series and the newer series have an
> > incompatible language.
> > 
> > A downside to using LuaJIT is that it doesn't support all the
> > architectures
> > that Guix supports [2]. In particular, it looks like aarch64 and ppc64el
> > are missing.
> > 
> > [2] https://luajit.org/install.html
> > 
> > Best,
> > Jack
> > 
> > P.S. Maybe its time to work on the Lua language of Guile 
> 
> Our copy of luajit supports aarch64 so I don't think that's a problem.
> (Last I checked) Debian has a patch to replace powerpc support with
> 64-bit ppc support. I'd go ahead with the change if that's the direction
> that neovim is going and let the powerpc64le people decide between using
> lua5.1 or just removing lua support on a per-architecture basis for
> ppc64le.

Re: Questions about Git and workflow

[HiPhish]

On Friday, 21 August 2020 22:59:32 CEST Ekaitz Zarraga wrote:
> Thanks for bringing the question btw. I was worried about my workflow being
> correct and it happens to be!

Yeah, I wouldn't be surprised if there are more people who would like to 
contribute, but then stumble on these minor irregularities and just give up. I 
had contributed a few patches in the past, but each time it felt like stepping 
on eggshells to me. It would be nice if one of the maintainers could have 
chimed in.

Re: Questions about Git and workflow

[HiPhish]

On Tuesday, 18 August 2020 22:33:53 CEST Leo Famulari wrote:
> I recommend not using a different local state directory. There should
> not be any negative (or even observable) effects of your experimental
> artifacts being in /gnu/store. I haven't tried managing multiple stores
> but I assume you'd need to run a separate daemon for each, configured
> for the correct directories.

OK, I'll try that. My main concern was with packages I actually want to run. 
For example, last time I wanted to update the Neovim version, so I changed the 
definition and installed Neovim in order to try it out a bit. But doing so 
replaced my previous Neovim installation. I know the old one was still in the 
store, but if I had borked the update I would have had the problem that my 
text editor, which is what I use to edit Guile scripts, was messed up.

It's not a major problem, but still an annoyance. Perhaps instead of `install` 
I should have done `environment --ad-hoc`.

Questions about Git and workflow

[HiPhish]

Hello everyone,

I am trying to get more serious about Guix, and I have a few questions about 
how to develop Guix and the associated Git workflow. The manual in chapter 14.1 
(Building from Git) explains most things pretty well.

My first question is regarding `guix git authenticate`. The first time I ran it 
after a `git clone ...` and `guix environment guix` I got an error saying that 
the `keyring` branch cannot be found. So I did a `git checkout --track origin/
keyring`, but I got a different error instead:

$ guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad "BBB0 
2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
Authenticating commits 9edb3f6 to ec32c85 (3 new commits)...
guix git: error: commit ec32c8591eb111023db514800145532a1e454125 not 
signed by an authorized key: F5DA 2032 4B87 3D0B 7A38  7672 0DB0 FF88 4F55 
6D79

Finally I did a `git pull` on both the `keyring` and the `master` branch and 
the check passed.

So my first question is: did I do it correctly? If not, what is the correct 
workflow?

My second question is regarding the `.po` files which get changed during the 
build process. Git shows me a number of language-specific files as modified, 
even 
though I never touched them by hand. Should those changes be commited? Should 
I include them when I send a patch? Why are they even version-controlled if 
they get changed automatically?

My last question is about the local state directory. The manual says the pass 
my current local state directory (by default `/var`) to `./configure`, but then 
my store gets mutated. I would prefer not to store my weird experiments where 
my day-to-day packages lie. I know I can revert at any time, but I'd rather 
not. I instead created `./var` and passed `$(pwd)/var` to `./configure`. The 
question is, is this the way to go? When I tried building a package (`/pre-
inst-env guix install go-github-com-junegunn-fzf`) Guix complained that there 
was no deamon running, so do I need a second shell running the deamon (`sudo -
E ./pre-inst-env guix-daemon --build-users-group=guixbuild`) as well?

Thank you in advance.

Re: ./configure fails when building Guix

[HiPhish]

On Tuesday, 14 May 2019 12:51:03 CEST Julien Lepiller wrote:
> Le 14 mai 2019 11:52:40 GMT+02:00, HiPhish  a écrit :
> 
> I get that too on foreign distros. Here configure finds your distso's guile
> (in /usr/bin). Try to run configure inside a pure guix environment:
> 
> guix environment guix --pure -- ./configure

Thank you, that did it.

./configure fails when building Guix

[HiPhish]

Hello everyone,

I am trying to set up Guix for proper local development, but it fails during 
the configuration step because the script cannot find the guild binary. Here is 
what I did:

- Check out the Guix repo
- Switch to a local branch
- run `guix environment guix` in order to set up all dependiencies
- run `./bootstrap`
- run `./configure`

Here is the output of `./bootstrap`:

guix$ ./bootstrap
+ find po/doc -type f -name *.po
+ sed -e s,guix-manual\.,,
+ xargs -n 1 -I{} basename {} .po
+ langs=zh_CN
de
ru
es
fr
+ [ ! -e doc/guix.zh_CN.texi ]
+ [ ! -e doc/guix.de.texi ]
+ [ ! -e doc/guix.ru.texi ]
+ [ ! -e doc/guix.es.texi ]
+ [ ! -e doc/guix.fr.texi ]
+ exec autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: running: autopoint --force
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
autoconf-2.69/bin/autoconf --force
autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
autoconf-2.69/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its 
use is discouraged.
configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro 
instead,
configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your 
Makefile.am 
files.
Makefile.am:601: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
autoreconf: Leaving directory `.'

And here is the output of `./configure`:

guix$ ./configure
checking for a BSD-compatible install... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/grep
checking for egrep... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether NLS is requested... yes
checking for msgfmt... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
msgfmt
checking for gmsgfmt... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/msgfmt
checking for xgettext... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/xgettext
checking for msgmerge... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/msgmerge
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by GCC... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-
profile/bin/ld
checking if the linker (/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for sed... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/sed
checking for the Guix system type... x86_64-linux
checking for the store directory... /gnu/store
checking the length of the installed socket file name... 40
checking for unit test root directory... /home/aleksandar/Developer/guix/test-
tmp
checking the length of the socket file name used in tests... 72
checking the length of a typical hash bang line... 73
checking the length of a hash bang line used in tests... 109
checking for pkg-config... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 2.2

Where to contribute a new package?

[HiPhish]

Hello everyone,

I would like to contribute a new package: the command line testing framework 
Roundup[1]. I think I have it all figured out so far for the most part, but I 
don't know what module to add it to. Roundup allows writing tests for command-
line applications, usually shell scripts, but it's not limited to those. I use 
it in a project of mine, so I would like to have this package.

One small caveat, building the man pages requires Ronn[2], which is a Ruby gem 
not available in Guix. Roundup will build without Ronn as well, it will just 
be missing the man pages. Is this acceptable?

What module would be best suited for a command-line testing framework?

[1] https://github.com/bmizerany/roundup/
[2] https://github.com/rtomayko/ronn

Re: Unofficial Neovim channel

[HiPhish]

> I wonder why you felt the need to have that channel?
Two points: the package in Guix is lagging behind in release, and I don't know 
enough yet about Guix to submit patches on a whim. So I made a channel to first 
try thing out for myself before submitting them to Guix. If I mess something 
up in my channel that's my problem, but if I mess up something in Guix then it 
reflects badly on all of Guix. I could have just left the channel local to my 
hard drive (as I had in the past), but making it public allows more people to 
have a look at it.

I guess most (all?) Guix package maintainers use Emacs instead of Vim or 
Neovim, but I use Neovim as my daily driver, so I'm more likely to catch if 
something is wrong. For example, I noticed that the Guix Neovim package is 
using Lua 5.2 libraries has its inputs, whereas you need Lua 5.1 libraries 
(Lua is not backwards-compatible). I had also submitted Lua 5.1 packages of 
lua-lpeg and lua-libmpack to Guix in the past.

> What's the difference between your definition and guix' definition?
Currently not much, only being three releases ahead and having the correct 
dependencies. (Lua 5.2 generally works as well, but you never know when an 
obscure edge-case might bite you in the rear)

Re: Stop it. Formerly - Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

I think you are focusing too much on the "pledge" part. Submitting a patch is 
an informal process and I doubt anyone is going to hold it up against you in a 
court. This is just an instance of using fancy words to sound important. 

People's real grievances with the CC are that it polices people outside the 
project as well (simply abiding by the rules on the mailing list and IRC is 
not enough, according to the terms of the CC), its focus on punishment, 
presumption of malice and of course the author of the CC and the surrounding 
culture. Getting hung up on details like the word "pledge" is just going to 
burn people out, but will not resolve anything.

On Tuesday, 6 November 2018 18:23:40 CET Marius Bakke wrote:
> Mark H Weaver  writes:
> > While I generally agree with the policies outlined in our CoC, and I
> > support the practice of enforcing those policies through our control
> > over our infrastructure and communications channels, I strongly oppose
> > requiring or presuming that all participants "agree" with our policies,
> > which I take to mean "declaring that they share the same opinions and
> > goals".
> > 
> > Some participants may disagree with our policies, and that's okay.
> > We don't need their agreement to enforce our policies.
> > 
> > Forcing people to declare their agreement with our policies as a
> > prerequisite for participation, or worse, _presuming_ that they agree
> > based on their having sent a patch or posted a message, is needlessly
> > alienating to those who don't share our views.
> 
> Thank you Mark for succinctly pointing out these flaws in our current
> CoC.  I agree that the language is overreaching, and think that these
> discussions will continue to crop up as long as this wording is
> included.
> 
> Our usage of the Contributor Covenant have deterred at least three
> contributors.  I hope it has attracted and retained more than that; in
> any case I think we can do better.
> 
> Also thanks to Thorsten for filing
> .
> Getting this fixed upstream will benefit much more than the Guix project.

Re: Stop it. Formerly - Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

I think "agree" in this context means to agree to follow the rules of that 
setting, not necessarily that you endorse those rules in general. For example, 
if you are a smoker in a non-smoking area you agree not to smoke while in that 
area, but you do not agree not to smoke at all. Or if you are in a vegan 
restaurant you will agree to eat vegan, but that does not make you actually a 
vegan yourself.

On Sunday, 4 November 2018 10:15:58 CET Mark H Weaver wrote:
> Hi,
> 
> I've decided to withdraw my objections to the policy of requiring that
> project participants agree to our CoC.
> 
> I read the language of the CoC again more carefully, looking to produce
> a realistic scenario of a person with legitimate but unpopular political
> views being discriminated against by this requirement.  Ultimately, I
> failed to find any realistic example that I wish to defend.
> 
> I no longer believe that agreeing to our CoC implies declaring agreement
> with it.  I think I jumped to conclusions too quickly here, partly based
> on an unusually strong interpretation of the word "agree".
> 
> I've also been worrying about possible abuses that I now suspect (hope?)
> would be unlikely to hold up in a court.  For example, I worried that if
> participation in the project is taken to imply agreement with our CoC,
> that by a natural extrapolation, someone who contributes a single fix
> but is otherwise uninvolved with the project could be legally held to be
> bound by our CoC.  That's thinking like a mathematician, where I should
> have been trying to think like a lawyer.
> 
> So, I'm withdrawing my objections.  Sorry for the stress.
> 
>Mark

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

On Wednesday, 31 October 2018 14:48:18 CET you wrote:
> Without attributing malice to your statement here, I think it is
> disingenuous to talk about "the other side". We are all part of
> communities we interact with, there is no need for any additional
> "othering" here :).
Sure, but communities can still be split on issues, like which CoC to adopt :)

> Again, while some people might be calling out for these cases to happen,
> this is not what the discussion is about; _any_ document that describes
> our norms and policies is intended to create a welcoming environment,
> where anyone can decide to become an active member of the community.
> 
> That the means through which this can happen, at its most extreme,
> involves actively removing potentially harmful elements from the
> community is in that sense a means to achieve these goals.
This is fine by me, and I don't think anyone here agrees that we would need 
someone around who just sits in the mailing list and throws around insults. 
But where do you draw the line? The CC, which is the issue at hand, allows for 
abuse by 1) being vary vague on what constitutes a break of rules, and 2) 
requiring punishment without offering any chance of clearing things up. If the 
maintainers fail to punish they themselves are open for punishment.

This is why I made that example of Alice and Bob where one party wants the 
other to be removed.

> You are correct in the sense that what you state is not really false,
> but at the same time also far removed from the actuality of any
> realistic social setting.
> 
> To me it seems that you only consider what one might call the
> "worst-case", and I'd rather state that any community pledge/policy
> document is first of all intended to prevent these situations from
> arising in the first place, and give the often-powerless some semblance
> of equal opportunity to become active participants, while still offering
> a safety net if push comes to shove.
And in my opinion the GKCG is perfectly adequate for this purpose without any 
of the potential of abuse. The GNU project was started in 1984, it's over 30 
years old, and it has produced fantastic results without the need for 
overbearing policing. The communities have been fairly good at keeping 
everyone on track, even if someone might slip from time to time. There was no 
need for the type of harsh policing that the CC mandates.

Note that the CC mandates the formation of an judicative-executive branch 
which will both judge and carry out punishments. If the maintainers are 
unwilling to do the work (which would not be surprising if they are busy 
maintaining the project) they will have to appoint people for this role. And 
my fear is that the people they put into position will be of the worst kind.

> Again, if part of this "proven track-record" includes something that
> could reasonably be seen as being in direct opposition of our norms as a
> community, it would make sense to have an honest and direct dialogue in
> order to resolve this situation. In extreme cases, it might still make
> sense to exclude harmful elements of the community, even if they are
> otherwise considered productive/effective/efficient. Nobody is above the
> rules we set ourselves as a community.
The CC does not provide room for honest and direct dialogue.

> If we are going to play an open hand here, number 3 is literally the
> goal of having this discussion in the first place: We want *anyone* to
> feel like they could fill a perceived void in our community, if they so
> choose.
Let's say I promise you that I have fifty patches in the pipeline, but person X 
makes me feel uncomfortable. So you kick out person X and I submit 50 
individual typo fixes in the manual and then never come back. Don't you think 
that is a net loss for the project? See, this is the issue I am afraid of can 
happen. I mean, if Bob starts calling Alice a "dumb bitch" over the mailing 
list, yeah that is another issue, but Alice wanting Bob removed from the 
project because he re-tweeted pictures of bikini modesl should be a no-go, 
even if the CC allows for it. Can we agree on this one?

> Number 4 seems a very weird point to make. We all have emotions, and
> some of us are more in touch with them then others, but somehow
> insinuating that having emotions influence you is a bad thing is
> confusing me. For me, most of the projects I undertake are labours of
> love.
Of course we have emotions, but we also need to learn to control them. 
Example: you are with a client and the client starts making unreasonable 
demands, you cannot just tell the client "if you know so much, then do your 
shit yourself", you have to maintain composure and explain why that demand is 
unreasonable within the technical of financial framework. Because if you have 
an outburst you will drag down the entire project. The same goes for 
contributors in a FLOSS project, you cannot just demand that everyone drops 
everything because someone upset you 

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

On Wednesday, 31 October 2018 15:14:53 CET you wrote:
> This confused me. You mean collectives of people are made up of people,
> and therefore associate with other people?
More like "I scratch your back, you scratch my back" or "oh, I know just the 
right guy for the job". You let that happen often enough and you end up with 
several groups all being "in bed with each other" so to speak. This is not 
limited to feminism, it happens in all areas of life of course.

> The problem is not only Steve making a stupid joke; the problem is the
> environment that led to Steve thinking it is okay to make statements
> like these in the first place. The only way to 'fix' this problem is to
> change the environment so that people are less likely to slip up, and to
> keep each other honest about (tiny) mistakes that everyone inevitably
> makes. To be honest, your recurring statement about people being more or
> less likely to slip up is not really coherent; I think we can all agree
> that every on slips up sometimes.
Agreed, but the punishment should also fit the crime. You can have a quick talk 
with Steve and then everyone shakes hands and is friends again. The problem is 
that there exist groups who want to exploit Steve's slip-up for their own 
gains by blowing it issue out of proportion. They cannot justify their 
existence and their bills if the issue can be sorted out with a short 
conversation, so Steve has to be punished properly.

> This seems like a question to ask the researchers, but because you have
> a concern regarding methodology does not invalidate the by now seemingly
> irrefutable clues that these issues do exist.
The issue exists, but how prevalent is it? Remember "manspreading"? Take a 
photo of a man taking up three seats in an almost empty subway, crop the photo 
so you cannot see that the subway is mostly empty, write an academic paper on 
the issue you created, sell the solution in the form of an awareness campaign, 
finance it with taxpayer money, and in the end people even get arrested because 
no matter how dumb the rules are, they have to be enforced. When my sister 
told me about manspreading she couldn't stop laughing, because even she sits 
like that when there is enough space. And why wouldn't she?

I view the catcalling issue the same way: go through the bad part of town, 
make an issue out of it, sell the solution. I am confident if you were to do 
this experiment in an area closer to Belgian standard of living none of this 
would happen.

> Your text seemingly goes from `ethnically diverse' -> `[lower] standard
> of living' -> `bad part of town' -> `ghetto'. I will assume you acted,
> and will continue acting in good faith, but I implore you to critically
> have a look at your thought processes and see how incredibly rude this
> might come across. If this was not your intention at all, then I
> apologize and hope you can still take my comments as a constructive
> critical note on parts of your writing style.
I got carried away, I was not controlling my emotions enough I guess :) My 
problem is when people like Mr Sassmannshausen take accusations at face-value 
without any shred of scepticism. People have had their lives ruined by false 
accusations and this sort of injustice is what makes my blood boil. Listening 
and believing benefits neither the innocent nor the real victims, it only 
drives a wedge between people. Who profits? Those who thrive on conflict, 
creating problems and selling solutions. (I had a much more polemic response 
to the previous mail, but I deleted it, so I guess I still had some emotional 
control)

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

Oh sure, I would have no issue working with people I disagree with, but the 
topic here is adopting the GKCG over the CC. The CC allows the maintainers to 
remove me from contributing, which is the part I and others are taking issue 
with. This can be abused to sabotage the project; even if I am not an 
important contributor right now, others are, and even I might grow over time 
to become one one day.

If people can simply put their disagreements away and take arguments out of 
the mailing list, that would be fine by me. I mean, I agree on much of what 
Stallman says, but as long as he can keep it out of GNU I am fine by that.

On Wednesday, 31 October 2018 14:48:49 CET you wrote:
> I may come as a surprise to some, but you *can* contribute to Guix
> without joining the queer or feminist movement (you can even get by
> without using singular they or zhe ;-) ).  In practice, just send
> your patches, be civil and respect all other contributors.  I can't
> remember any occasion where people were banned.  One or two people
> left when they were asked to respect people's choice of pronouns, and
> decided they'd rather leave, but nobody told them to leave...
> 
> For sure, this touches on many philosophical and political issues and
> while I respect your deep insight in these matters, and your concern
> for ethnic minorities, I don't think guix-devel is the place to
> discuss them.
> 
> Thank you for your time,
> 
> Thomas

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

If you don't want to continue the discussion then so be it, but I cannot leave 
my points misrepresented. When I say "you" I don't necessarily mean you 
personally, but rather the larger discussion. You don't have to respond if you 
don't want to, I believe we have both made our points and it's up to the 
readers to draw their conclusions.

On Wednesday, 31 October 2018 13:46:49 CET you wrote:
> After this email I'm done with the conversation.  I have tried to
> provide you with evidence.  You make it clear you have a bone to pick
> with people concerned with gender equality.  This will go around in
> circles.
I have no issue with gender equality, but this is not what feminism is doing. 
Let's do an analogy: strong nations are good, fascism promotes strong nations, 
therefore if you believe in a strong nation you are naturally a fascist. Oh, 
those death camps? Well, that's not *real* fascism, that was just Nazism. And 
now we have reached Godwin's law. You presuppose that feminism is acting for a 
good cause (gender equality), so therefore the actions of feminists must be 
good. There is your problem: never listen to what people say, always look at 
what they do (this is a rule for life in general, not just this issue). Of 
course comparing fascism and feminism is a hyperbole, the point is not to look 
at the labels of a group, but at their actions.

> The TUC is the trade union congress.  They are not a feminist
> organisation.  The Belgian government is not a feminist organization.
> The Guardian is a newspaper and the EEOC is a US government office.
You can have a strong political bias and still not be an activist group. 
Organizations cooperate, their members can be friends with one another. 
Happens all the time in all areas.

> My line of argument above was precisely that this does not only happen
> in a field with "awkward nerds".  Also I find your assertion that
> "nerds" are unable to behave decently to other people an insult to
> myself and "nerds" as a whole.
Anyone can behave, but anyone can also slip up. And some people slip up more 
often than others. Why? I don't know, I'm not a psychologist, I just know 
that's they way it is. Again, this is not limited to the issue at hand. 
Everyone knows that hitting people is wrong, but some people are more prone to 
losing their tamper then others. Why? Again, I don't know, all I know is that 
you are less likely to be slapped on the head at a university than at a trade 
job.

> I find it shocking you are basically telling people who are being
> mis-treated by others to just suck it up.
> 
> It's because of these attitudes I'm glad we have a code of conduct.
Everyone has hardships to put up with. It's about the severity of hardships. 
This is like looking at workplace accidents and putting a papercut right next 
to a cut to the bone as if they were comparable. If you have a papercut you 
suck it up, put a band aid on it so you don't bleed over the papers and get 
back to work. But if you have a cut to the bone you need the wound to get 
disinfected and stitched up. It would be absurd to say that an office job is 
more hazardous than a construction site job because people in the office suffer 
paper cuts more often. I would rather suffer a hundred paper cuts than one cut 
to the bone.

> Here's the problem with your argument.  These findings are reproduced
> over and over: women are disproportionately affected by harassment,
> especially of a gendered kind.  Even if you find an issue with a
> specific study, the consensus of virtually all these studies find the
> same thing.
> 
> You might have better results if you actually pointed to studies that
> overturned the consensus.  Good luck with that.
I am not saying these studies cannot be reproduced, I am doubting the severity 
of the issue. If we suppose that certain people tend to slip up more often 
(which I did above) then of course you will find these patterns more often. But 
again, how severe of a problem is Steve making a stupid joke at coffee break?

> Come on.  Get out of here with your manufactured concern.  Whatever the
> specific cases in this video were, the overall point, and the conclusion
> of the overall debate is that street harassment is a widespread issue,
> wherever you go.  It disproportinately affects women and is
> disproportinately carried out by men.
You just went on about reproducibility. OK, then why don't they reproduce that 
video in areas where the ethnic makeup is closer to the Belgian average? Or in 
areas with a higher standard of living? After all, this happens wherever you 
go, even though these street harassment video are always shot in the same kind 
of area for some reason. Doesn't that strike you as odd?

This is the sort of data manipulation I mean, you go through the bad part of 
town, people do bad things. But you conveniently ignore all the other bad 
things that would happen in that area. I am sure no one gets mugged in the 
ghetto after dark. No, street 

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

I am really trying to understand the other side here, so please help me out on 
this one. Let's say you have two people for the sake of simplicity, we can 
call them Alice and Bob. Alice and Bob hate each other's guts, Alice is 
unwilling to work on the team if Bob stays on the team, but Bob is willing to 
work on the team regardless of Alice. Furthermore, Bob has already worthwhile 
contributions under his belt, whereas Alice has done nothing yet, but she 
might if Bob were to be remove.

And your choice would be to remove Bob from the team. Am I correct so far? 
What sense does it make to remove someone who 1) has already a proven track-
record and 2) has shown that he is willing to control his emotions to focus on 
the task, all in the hopes that 3) the other person might perhaps fill in the 
void and 4) already has show to let emotions override work duty, and 5) has a 
track-record of wanting people remove from the project?

Please explain to me how kicking Bob out of the team is supposed to improve 
the project. I am really trying hard to wrap my head around the issue, but 
this logic is entirely alien to me. Wouldn't it make more sense to just tell 
people to keep any personal grudges out of the workplace and carry on? It is 
not that the project management is preventing Alice from joining, she refuses 
out of her own volition.

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

There is a common pattern in all the links you provided: 1) only feminists are 
seeing this supposed issue, 2) it does not go into the exact nature of the 
supposed harassment.

With regards to the first point: Feminist group have vested interests in 
furthering conflicts. Even if there is no conflict they will try to create one 
and then sell you the solution, so please excuse my scepticism. Feminists are 
proven to keep fabricating issues, like the supposed wage gap. So yes, I am 
really doubting the veracity of those claims.

You know what? When you go into a field filled with awkward nerds that's you 
occupational hazard. In other occupations you have other hazards: joint 
injuries from standing at an assembly line, getting your fingers crushed in a 
machine, falling off a construction site, contracting a disease in health 
care, having to dig through sewage in plumbing, being shot in law enforcement, 
or getting into legal problems in nursing. And don't get me started on clients 
with planet-sized egos holding back payment. I think when it comes to 
occupational hazards getting hit on by an awkward nerd is pretty harmless. 
It's certainly much less of an occupational hazard than for the people who are 
on the receiving end of an accusation and can lose their livelihood in an 
instant.

So please excuse me when I don't fall for the crocodile tears. We are talking 
about grown-up women here, not children.

> According to a TUC/Everyday Sexism study on sexual harassment, 52% of
> women have experienced sexual harassment in the workplace and 80% did
> not report it to their employer.
I am singling out this one as an example of data manipulation. Let's for the 
sake of simplicity assume that the data is 100% correct and has not been 
tampered with. Put yourself now in the shoes of an average woman: The question 
is "Have you experienced instances of sexual harassment in the workplace in 
the past?". You think a bit and remember Steve who made a dumb joke about your 
breasts during coffee break last month. So you answer with yes of course. Then 
the second question is "If so, did you report the incident to your employer?". 
Considering Steve is a shy guy, it was during coffee break, no one else joined 
in and after you gave him a stern look he got the message, you of course 
didn't consider it worth anyone's time to start office drama over pretty much 
nothing. So you answer with "no". And now your answer gets twisted into "Don't 
you see all these serious issues going unreported out of fear? You should hire 
our advocacy agency for sensibility training and diversity counseling. You 
have a nice business going here, it would be a shame is someone were to call 
it sexist".

> In 2012, in Belgium, the film Femme de la Rue directly influenced the
> passing of legislation to make street harassment
> illegal.
> [https://www.theguardian.com/world/2012/aug/03/belgium-film-street-harassme
> nt-sofie-peeters] It also helped kick-start movements in Belgium and France
> where street harassment is fairly common.  In london, UK, 4 in 10 women
> between ages of 18 and 34 experienced street harassment in 2011 alone
> [https://www.theguardian.com/lifeandstyle/2012/may/25/four-10-women-sexually
> -harassed].
Don't you consider it kind of... problematic that the video only shows people 
from a, let's call it "diverse" background? Why doesn't she show us all the 
serial catcallers in the less diverse parts of Belgium? It couldn't be that 
she intentionally picked the bad part of town, now could it? I feel deeply 
offended by the implication of this video that people of colour are the 
primary source of sexual harassment.

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

On Tuesday, 30 October 2018 00:54:54 CET you wrote:> 
> You, me, Alex and the rest of Guix share a culture. I'm assuming that is the
> culture Alex refers to, not the cultures of our distinct offline locale.
What culture am I sharing with you? I am not a hacker, I only care about code 
quality, just as only care about the plumbing of my toilet and not plumber 
culture. I also care about software Freedom because I have been bitten in the 
behind often enough by proprietary software to know that it is wrong. I care 
about Guix because functional package management is the only sane way of 
package management. What is the alternative to Guix? Flatpak and other opaque 
systems suitable for bundling proprietary software?

> Also, the burden of proof really is with HiPhish. Harassment in tech, and
> FLOSS especially has been well documented. See for example:
> http://geekfeminism.wikia.com/wiki/FLOSS
> https://lwn.net/Articles/417952/
> https://www.theregister.co.uk/2017/06/05/open_source_developer_survey_2017/
> for a start.
I asked for proof, not "she said, he said". Except this is just "she said". 
What if that "groping" as some guy brushing at her butt in a crowd by 
accident? I have a really hard time believing that there is an epidemic of 
serial gropers at tech conferences. Does that mean no one gets groped? Of 
course not, even I had my butt slapped in the past by girls, but so what?

Here is a question for you: why are you taking these reports for granted? Do 
you not consider the possibility that isolated issues are being blown out of 
proportion by malicious agents? The incidents don't even have to be fake, the 
offender might be a malicious agent as well. Free and Open Source projects are 
a problem for proprietary software companies and any means to disrupt the 
projects is acceptable. Why do you think the CC is so focused on punishment 
and not healing?

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

(I forgot to CC this message to the mailing list, sorry if you get it twice)

On Monday, 29 October 2018 19:34:47 CET you wrote:
> On Monday, 29 October 2018 13:48:24 CET Giovanni Biscuolo wrote:
> > if I was to choose a code of conduct for a project of mine I'd _never
> > ever_ choose "Contributor Covenant" since it's so vague that - in good
> > faith - I could never accept to commit to enforce it
> > 
> > please consider CC does _not_ define:
> > 
> > 1. the standards of acceptable behavior: it's up to the maintainers to
> > clarify [1]
> > 
> > 2. specific enforcement policies [2]: if needed (are the default ones
> > sufficiently defined? IMHO not) maintainers should define enforcement
> > policies
> > 
> > so it would be mine (as maintainer) responsibility to address this two
> > issues: no thanks, I do not want to "reinvent the weel" of
> > "constitutions"
> 
> This sort of thing is also why a Free license is not allowed to contain
> clauses like "the software may not be used for evil purpose". Are you really
> competent to judge what constitutes "evil"? The CC is just vague enough to
> allow any malicious person to move the goalposts as they see fit.
> 
> > > The accused is not even
> > > allowed to know what the accusation is about (confidentiality clause),
> > 
> > https://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT#n68
> > does not say so, confidentiality is about the reporter, not the
> > accusation claims (even if knowing the accusation could easily lead to
> > the accuser, if the accusation is about one single unacceptable
> > behaviour)
> > 
> > > There is no clause that allows the accused to defend their position
> > 
> > this should be part of a per-project enforcement policy, defined by
> > maintainers (point 2 above)
> 
> That's the thing, you have just found the loophole. The accused can be
> denied any right to defense under the pretense that presenting the
> accusation could compromise the identity of the accuser, thus breaking the
> rules of the CC. You as an accused are at the complete mercy of an
> arbitrary judgment.
> 
> > > If I wanted I could consider it the former and pull the trigger
> > > metaphorically. I am asking because this is not a hypothetical question,
> > > people have been loosing their jobs over these issues for real.
> > 
> > plz do you have any link to the relevant news, I mean of people being
> > fired for CC enforcement? It would be very useful for my research
> > 
> > any civilized country should have a legislation to address workers being
> > fired based on their political views (this is discrimination)
> 
> Companies don't generally disclose the reason for firing employees, but the
> two most prominent cases are that of James Damore and the incident known as
> "Donglegate".
> 
> In the case of Damore, he wrote an internal memo at Google, criticising the
> unfair treatment between the sexes. The memo got leaked, blow up by the
> media into a full-fledged "manifesto" of a cabal of women-haters and Damore
> lost his job.
> 
> "Donglegate" as about a woman overhearing a conversation of two men during
> PyCon 2013, where the talked about "dongles" and "forking repos". The
> conversation was not addressed at her, she was eavesdropping, took their
> photos without consent, uploaded them to Twitter and used the PyCon Code of
> Conduct as a justification. At least one of the men has been fired
> subsequently. The only reason why we know of this incident is because the
> woman could not contain the joy of destroying a family-man's livelihood.
> 
> Both of those incidents are well-known, so you can read up on them if you
> want to. The man from Donglegate has since found employment at an all-male
> company and he prefers it that way. Here is a question to anyone who thinks
> CoCs are a good thing: do you really think that driving such a wedge
> between men a women makes for a healthy and safe environment? How do you
> think his wife felt? Do you think she was happy that the family's income
> was now gone?
> 
> > plz do you have more examples of contributors being expelled? I need it
> > for my research purposes
> 
> Take the case of this Drupal maintainer:
> https://www.garfieldtech.com/blog/tmi-outing
> 
> He was kicked out of the project because he has a maledom fetish (BDSM where
> the man is the dominant part). That's right, he was removed from the
> project because what he did in his bedroom was not politically correct. Not
> because of abuse, rape, or anything, just because people took issues with
> what he did in private.
> 
> > > The CC's own author is one of the worst offenders of the
> > > CC's own terms, going after people's private social media accounts and
> > > quote-mining them to demand their expulsion or even extort money.
> > 
> > this is a bold accusation, made in pubblic too: plz can you give us the
> > relevant news on this so you can justify this claim?
> 
> I don't have a list of links at hand, but you already mentioned the Opal
> 

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

On Monday, 29 October 2018 12:08:56 CET you wrote:
> I think you a have burden of proof here, given that our culture at large
> has serious issues with harassment.  Why would you think FLOSS community
> is somehow different from the wider community?
No, you have a burden of proof that "our" culture (whatever this "our" is 
supposed to mean, I have no idea where you live and you have no idea where I 
live) has a serious issue with harassment.

> You can harass someone whilst believing your acting positively.  E.g. an
> ex-partner that "just wants to show how much they love the person that
> spurned them".  And ends up stalking them.
You cannot accidentally stalk someone. Stalkers who are not aware they are 
harassing have a mental disorder. Calling them harassers is against the terms 
of the CC because it is discrimination by disability. See how easy it is to 
break the terms of the CC?

> You're conflating harassment and offense here.  It is one thing to be
> offended by individuals using the wrong cutlery for the entrée; it is
> another entirely for someone to, e.g. use crass racist caricatures.
You intentionally chose the most extreme examples.

> All the more important we do everything we can to minimise the existing
> barriers to contributions from all walks of life.
By pointing a gun at the people most likely to contribute?

> This reads hyperbolic, if not somewhat conspiratorial to me.  No guns
> are being held to anyone's head, no life's endangered or violence even
> threatened.  I also disagree with the implication that harassment
> complaints might be weapons used by a nefarious competing party.
People are putting their careers on the line even by having this discussion in 
the first place. There is a reason why I am using a pseudonym. I have provided 
links to the other guy of people who had their jobs ruined under the pretense 
of a CoC. The people who made the accusations never ended up filling the void 
themselves, they only go around destroying.

> If you don't mind me asking, what are you afraid of?
See above.

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

On Sun, Oct 28, 2018, at 7:33 AM, Gábor Boskovits wrote:
> 3. GKCG seems to be inadequate in the opinion of the maintainers, as:
> a. it does not define acceptable behaviour, and
> b. it does not define processes.

To be honest, neither does the CC really. It throws out a vague list, but 
never goes into any detail. I believe this is intentional, if you never define 
what the goalposts are, then you can move them around as much as you want and 
apply punishment as you see fit.

The same goes for due process, it does not define how to apply punishment, just 
that the punishment can range from a warning to getting completely banned. 
Also the accused has no right to defense, the accusation does not need to be 
disclosed and if any maintainer disagrees they can be removed from the project 
as well. This is just a kangaroo court system.

> I proposed to try to roll our own, essentially based on GKCG,
> but have the acceptable behaviour and the processes defined.

I am not totally opposed to it, but it's like writing your own license: other 
people have already put thought into it, so just use what they have written. 
The GKCG has the added bonus that it is an official GNU guideline, so it would 
be nice to have it throughout the GNU projects. The Debian CoC seems fine, and 
KDE has a decent one as well.
https://www.kde.org/code-of-conduct/

> Do you think that this could result in a better situation overall?

Improve in regards to what exactly? Are the maintainers afraid that the 
mailing list will turn into 4chan if there is no CoC in place?

Re: Promoting the GNU Kind Communication Guidelines?

[HiPhish]

I have had two packages merged, which I guess that makes me technically a
contributor, so here is my takes on the issue.

In my opinion Codes of Conduct (or CoCs in short) are one of the worst things
that have happened in recent years to Free and Open Source projects (hold that
though, I will address it soon enough), and the Contributor Covenant (CC in
short) is the worst offender. I will explain shortly why this is, but please
allow me to elaborate first.

There is no problem of harassment in FLOSS, there is a problem of socially
awkward nerds in FLOSS. Harassment presupposes malice, i.e. that the offending
person is intentionally being abusive. If you have never said anything that
made you want to vanish into the ground the moment it came out of your mouth
you are not human. Some people will slip up more often than others, and let's
face it: the people who are more likely to slip up are also more often the 
ones
who are good at programming. Why is it this way? I don't know, I'm not a
psychologist or anthropologist, I just need to know that this is the way 
things
are.

Now here is the important part: for an offensive act to be committed it takes
two sides, the offender and the offended. Part of social competence is knowing
not to slip up, but part of it is also knowing to just let it slide when
someone else slips up. Again, I'm not talking just about online discourse, but
social interaction in general. When someone says something stupid just ignore
that person, and if it keeps happening try to correct them in a friendly
manner. This is how we grow as humans.

This leads me into why the CC is a harmful CoC. The CC presupposes malice by
default, more than half of its content is focused on punitive measures, not on
helping each other. In contrast, the GNU Kind Communications Guidelines (GKCG
in short) explicitly promotes a cooperative two-sided perspective:

> Please assume other participants are posting in good faith, even if you
> disagree with what they say. When people present code or text as their own
> work, please accept it as their work. Please do not criticize people for
> wrongs that you only speculate they may have done; stick to what they
> actually say and actually do.
>
> Please do not take a harsh tone towards other participants, and especially
> don't make personal attacks against them. Go out of your way to show that 
you
> are criticizing a statement, not a person.
>
> Please recognize that criticism of your statements is not a personal attack
> on you. If you feel that someone has attacked you, or offended your personal
> dignity, please don't “hit back” with another personal attack. That tends to
> start a vicious circle of escalating verbal aggression. A private response,
> politely stating your feelings as feelings, and asking for peace, may calm
> things down. Write it, set it aside for hours or a day, revise it to remove
> the anger, and only then send it.

There is nothing like this in the CC, but there is this:

> Instances of abusive, harassing, or otherwise unacceptable behavior may be
> reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
> complaints will be reviewed and investigated and will result in a response
> that is deemed necessary and appropriate to the circumstances. The project
> team is obligated to maintain confidentiality with regard to the reporter of
> an incident. Further details of specific enforcement policies may be posted
> separately.
>
> Project maintainers who do not follow or enforce the Code of Conduct in good
> faith may face temporary or permanent repercussions as determined by other
> members of the project’s leadership.

The CC is claiming to foster "an open and welcoming environment" while at the
same time holding a gun to every maintainer's head. The accused is not even
allowed to know what the accusation is about (confidentiality clause), so how
are they supposed to know what they did was wrong? There is no clause that
allows the accused to defend their position, only punishment is defined. This
applies even to the maintainer, so if they maintainer wants to protect an
unjustly accused person, the maintainer will be on the chopping block. To make
matters worse, the CC never defines what constitutes offensive behaviour.  
Take
a look at the following list:

> * The use of sexualized language or imagery and unwelcome sexual attention 
or
>   advances
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
>   address, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
>   professional setting

The fourth point is clear, but what exactly constitutes any of the remaining
four? Is "Wow, thank you so much, I could kiss you!" considered "unwelcome
sexual attention" or just an exaggerated expression of joy? Is overhearing
people talking about "dongles" 

Re: Removing configure flags?

[HiPhish]

I figured it out thanks to the people on IRC:

(arguments
  `(;; Roundup has no check target (It does have a `test` target, but some
;; of its tests fail intentionally, bringing the entire build process
;; down)
#:tests? #f
;; Explicitly set the shell because otherwise this value will be empty
#:make-flags
'("SHELL=bash")
#:phases
(modify-phases %standard-phases
  (add-before 'configure 'fix-configure
;; getconf will return a static path, which will not contain the
;; value adjusted by Guix
(λ _ (substitute* "configure" (("getconf PATH") "echo $PATH"
  (replace 'configure
;; Roundup is using a hand-written configure script which will 
choke
;; on the default configure flags. Therefore we invoke it with our
;; own flags.
(lambda* (#:key outputs (configure-flags '()) #:allow-other-keys)
  (let ((out (assoc-ref outputs "out")))
(apply invoke
  `("./configure"
,(string-append "--prefix=" out)
 "--sysconfdir=/etc"
,@configure-flags


Ludovic Courtès wrote:
> Indeed.  Could it be that ‘configure’ overrides PATH, setting it to,
> say, /bin:/usr/bin?  (You mentioned ‘getconf PATH’ yesterday on IRC,
> perhaps that’s related?)
> 
> HTH,
> Ludo’.

Re: Bringing the Neovim package up to date

[HiPhish]

On Monday, 2018-09-10 14:27:02 CEST Ludovic Courtès wrote:
> Sure!  While you’re trying things out, you may find that IRC will be
> better suited to get guidance and information on how to debug issues.
OK, noted.

> Yes.  In short you would define the new package to “inherit” from
> ‘lua-5.1’, and you would change its ‘inputs’ field.  There are examples
> of that in the code.  Let us know if anything’s unclear!
I'll give it a try, I just wanted to know if there is maybe something more to 
it to be aware of.

> We cannot #:select from (gnu packages …) modules due to the way Guile
> handles circular dependencies among modules.  However we could use
> select more frequently for other modules.
I didn't know about circular dependencies. I mainly wanted to know if there is 
maybe a reason or guideline against using `#:select` and whether package 
definitions like that might get rejected.

> I don’t know if there’s anything similar for (Neo)Vim, but those of us
> who use Emacs also use Geiser, which displays in the “mode line” at the
> bottom the module that provides a given variable.
That explains a lot. I know about Geiser, but Vim is the editor I have settled 
in, I feel that switching would be just as much work as porting Geiser to 
Neovim at this point. From what I understand Geiser has two parts: the Emacs 
plugin and the actual Geiser process which is written in Scheme. "Porting" 
Geiser would only require re-writing the editor interface for Neovim while the 
Scheme backend could be kept. It's just that no one has ever felt the need to 
do that, Lisp programmers who use Vim are very rare.

Is there a way to get the module from a REPL? I can run a REPL in my editor, 
that's the crutch I have been using so far. (IMO tying the readability of the 
source code to the development environment is a bad idea, that's what IDEs 
always end up doing)

Re: Removing configure flags?

[HiPhish]

Thanks to both of you I can now at least get the configure script to run, but 
it stops because it cannot find `cat`:

starting phase `configure'
building for Linux on localhost at Tue Sep 11 10:46:19 UTC 2018
looking for /bin/sh./configure: line 89: expr: command not found
 (nope)
looking for bash./configure: line 89: expr: command not found
./configure: line 89: expr: command not found
./configure: line 89: expr: command not found
 (nope)
looking for dash./configure: line 89: expr: command not found
./configure: line 89: expr: command not found
./configure: line 89: expr: command not found
 (nope)
looking for xdg-open./configure: line 89: expr: command not found
 (nope)
looking for firefox./configure: line 89: expr: command not found
 (nope)
looking for git./configure: line 89: expr: command not found
 (nope)
looking for ronn./configure: line 89: expr: command not found
./configure: line 89: expr: command not found
 (nope)
looking for shocco./configure: line 89: expr: command not found
 (nope)
warn: ronn is not installed. cannot rebuild manpages. no biggie.
warn: shocco is not installed. cannot rebuild manpages. no biggie.
okay, looks like you have everything we need. generating config files.
writing config.mk...
./configure: line 210: cat: command not found
Backtrace:
   4 (primitive-load "/gnu/store/1ilwn4mr3nb7pi6n0w4a6nkavdf…")
In ice-9/eval.scm:
   191:35  3 (_ #f)
In srfi/srfi-1.scm:
640:9  2 (for-each # …)
In /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-
build-system.scm:
   799:31  1 (_ _)
In /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/
utils.scm:
616:6  0 (invoke _ . _)

Here is my package definition (irrelevant parts omitted):

(package
  (name "roundup")
  (build-system gnu-build-system)
  (arguments
`(#:phases
  (modify-phases %standard-phases
(replace 'configure
  (lambda* (#:key inputs outputs (configure-flags '()) #:allow-other-
keys)
(let ((out (assoc-ref outputs "out")))
  (apply invoke
`("./configure"
  ,(string-append "--prefix=" out)
  ,(string-append "--sysconfdir=/etc")
  ,@configure-flags)

From my understanding, `cat` is part of coreutils, which is already an 
implicit input of the GNU build system. So the configure script should have 
it, shouldn't it?

On a related tangent: it looks like a phase is just a function which takes 
arbitrary keyword-arguments, right? Is this documented somewhere or is it 
"read the source code"? And what exactly are `outputs` and `inputs`? It looks 
like they are association lists where the keys are names and the values are 
directories.

Removing configure flags?

[HiPhish]

Hello everyone,

There is this shell scripting test framework called Roundup which I would like 
to package for Guix:
https://github.com/bmizerany/roundup
http://bmizerany.github.io/roundup/

It looks like the author has written his own configure script rather than 
using autotools to generate it, and it chokes on the default configure flags 
provided by Guix:
https://github.com/bmizerany/roundup/blob/master/configure

The culprits are the `--enable-fast-install` flag and the `--build` option. 
There is no need for either of those since it's all just shell scripts anyway, 
so is there a way to remove them? I know I can add flags, but I haven't found 
anything in the manual about removing some of the default flags.

Bringing the Neovim package up to date

[HiPhish]

Hello everyone,

I have been using the Guix package manager on Kubuntu for a while now and I'm 
relatively familiar with it, so I wanted to try my hand on updating the Neovim 
package; Neovim is my package manager of choice and at the moment I'm using an 
apt PPA. I would like to get rid of the PPA and rely on Guix instead, using 
apt only for what is necessary for the system.

Currently Neovim on Guix is at version 0.2.0, but the most recent release is 
0.3.1; I want to update the package. I would be grateful is someone could 
assist me with guidance on this endeavour.

The first thing I noticed is that the dependencies are wrong. It specifies Lua 
5.2 as an input, and the corresponding Lua 5.2 libraries like lpeg. However, 
Neovim requires Lua 5.1, and Lua minor releases are not backwards-compatible. 
So this needs to be fixed, which also means that we need to define new 
packages.

For lua5.1-lpeg and lua5.1-bitop this should be simple enough, just call the 
function that generates the package with lua-5.1 as the Lua version. The 
definition of lua5.1-libmpack would be a bit more involved, but still 
straight-forward.

Another thing is that Neovim can be built both with Lua 5.1, or LuaJIT. Using 
LuaJIT would be preferable, is there a way to define the above libraries with 
lua-5.1 as input, but then swap it out for luajit in the definition of Neovim?

On an unrelated note, the coding style always imports everything from a 
module. This makes it really hard for someone unfamiliar with Guix to know 
where the various procedures, variables and macros come from. Is there a 
reason you don't explicitly import identifiers with `#:select`? In my own code 
I always prefer that style because in a month I will have no idea where any of 
that stuff comes from.

Re: guix download and GitHub

[HiPhish]

Thank you, no idea how I missed that :(

On Mittwoch, 22. August 2018 00:02:14 CEST you wrote:
> Hello,
> 
> Looking at the manual entry for guix download [0], we can see:
> 
> guix download verifies HTTPS server certificates by loading
> the certificates of X.509 authorities from the directory
> pointed to by the SSL_CERT_DIR environment variable (see
> X.509 Certificates), unless --no-check-certificate is used.
> 
> [0]:
> https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-downloa
> d.html
> 
> You can either use your operating system's certs directory
> (usually /etc/ssl/certs), or install the nss-certs guix package,
> as shown on the man page for X.509 Certificates [1] and export
> the related environment variables to tell programs to use it:
> 
> $ guix package -i nss-certs
> $ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
> $ export
> SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" $
> export GIT_SSL_CAINFO="$SSL_CERT_FILE"
> 
> [1]:
> https://www.gnu.org/software/guix/manual/en/html_node/X_002e509-Certificate
> s.html
> 
> Hope that helps.
> 
>   -amin

guix download and GitHub

[HiPhish]

Hello Guix developers,

I wanted to try to bring the Neovim package up to date, but I am having 
trouble using `guix download`:

$ guix download  https://github.com/neovim/neovim/archive/v0.3.0.tar.gz

Starting download of /tmp/guix-file.cmWnGA
From https://github.com/neovim/neovim/archive/v0.3.0.tar.gz...
X.509 certificate of 'github.com' could not be verified:
  signer-not-found
  invalid

failed to download "/tmp/guix-file.cmWnGA" from "https://github.com/
neovim/neovim/archive/v0.3.0.tar.gz"
guix download: error: https://github.com/neovim/neovim/archive/
v0.3.0.tar.gz: download failed

This is probably something on my end that needs to be set up, but I don't know 
what. I barely know anything about certification. If someone can point me in 
the right direction I would be grateful.