Re: GNOME in Guix

[Danny Milosavljevic]

Hi,

I've checked guile-gi test/insanity.scm again to find "hard" evidence.

For that, I've just checked out guile-gi anew, then ran test/insanity.scm.

Steps:

(1) git clone https://github.com/spk121/guile-gi.git guile-gi
(2) cd guile-gi
(3) git checkout b454a99b65f927e947faab17d25bd3499829c1b4 # the current one
(4) guix environment --pure -l guix.scm --ad-hoc gtk+ guile
(5) ./bootstrap && ./configure && make
(6) tools/run-guile test/insanity.scm
 Starting test insanity.scm  (Writing full log to "insanity.scm.log")
/home/dannym/src/guile-gi/guile-gi/test/insanity.scm:19: FAIL GObject.Value
/home/dannym/src/guile-gi/guile-gi/test/insanity.scm:23: FAIL GObject.Closure
# of expected passes  1
# of unexpected failures  2
WARNING: (guile-user): imported module (gi) overrides core binding `quit'
(7) cat insanity.scm.log
 Starting test insanity.scm
Group begin: insanity.scm
Test begin:
  test-name: "GObject.Object"
  source-file: "/home/dannym/src/guile-gi/guile-gi/test/insanity.scm"
  source-line: 15
  source-form: (test-equal "GObject.Object"  (module-ref m (quote 
)))
Test end:
  result-kind: pass
  actual-value: #<  7f2d4e2ca180>
  expected-value: #<  7f2d4e2ca180>
Test begin:
  test-name: "GObject.Value"
  source-file: "/home/dannym/src/guile-gi/guile-gi/test/insanity.scm"
  source-line: 19
  source-form: (test-equal "GObject.Value"  (module-ref m (quote 
)))
Test end:
  result-kind: fail
  actual-value: #<  7f2d4e2ea680>
  expected-value: #<  7f2d4e2e0200>
Test begin:
  test-name: "GObject.Closure"
  source-file: "/home/dannym/src/guile-gi/guile-gi/test/insanity.scm"
  source-line: 23
  source-form: (test-equal "GObject.Closure"  (module-ref m (quote 
)))
Test end:
  result-kind: fail
  actual-value: #<  7f2d4e2ea900>
  expected-value: #<  7f2d4e2eae80>
Group end: insanity.scm
# of expected passes  1
# of unexpected failures  2

That's it.  It fails.

(8) Using attached dlopen logger (gcc -fPIC -shared -o block-open.so 
block-open.c, then edit tools/uninstalled-env bottom before the exec to export 
LD_PRELOAD=$PWD/block-open.so), I get:
dlopen libguile-gi
dlopen /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5
dlopen libguile-gi
dlopen libguile-gi
dlopen libguile-gi
dlopen libguile-gi
dlopen libguile-gi
dlopen libguile-gi
dlopen 
/gnu/store/xa1vfhfc42x655hi7vxqmbyvwldnz7r0-glib-2.62.6/lib/libgobject-2.0.so.0

There it is again.

(9) ldd /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5 |grep 
gobject
[...]
libgobject-2.0.so.0 => 
/gnu/store/4jl613j0d5y6icbxxmwij75fd0i7qpwn-profile/lib/libgobject-2.0.so.0 
(0x7fe2a0677000)

And there is the other one.

Now how do I get more info, using Guix tools?
#define _GNU_SOURCE
#include 
#include 
#include 
#include 

typedef void *(*dlopen_t)(const char *filename, int flags);

void *dlopen(const char *filename, int flags) {
	void* result;
	dlopen_t dlopen = dlsym(RTLD_NEXT, "dlopen");
	fprintf(stderr, "dlopen %s\n", filename);
	if (filename && strstr(filename, "/") == NULL && strstr(filename, "libcairo-gobject.so")) {
		fprintf(stderr, "dlopen blocked %s\n", filename);
		result = dlopen(filename, flags);
		if (result) {
			fprintf(stderr, "and would have been found! Aborting!\n");
			/*int* x = 0;
			*x = 5;
			abort();*/
		}
		//return NULL;
	}
	result = dlopen(filename, flags);
	return result;
}



pgp23zbw3XtGC.pgp
Description: OpenPGP digital signature

New Russian PO file for 'guix-manual' (version 1.2.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: GNOME in Guix

[Leo Prikler]

Hi,
Am Mittwoch, den 04.11.2020, 09:08 +0100 schrieb Danny Milosavljevic:
> Hi,
> 
> I've checked guile-gi test/insanity.scm again to find "hard"
> evidence.
> 
> For that, I've just checked out guile-gi anew, then ran
> test/insanity.scm.
> 
> Steps:
> [...]
> That's it.  It fails.
Okay, but it already states something along similar lines in the
description of the issue.
"It is pretty clear to me, that the main culprit here is a different
version of GLib being linked to Guile-GI than the one that should be
loaded through Guile-GI."

> (8) Using attached dlopen logger (gcc -fPIC -shared -o block-open.so
> block-open.c, then edit tools/uninstalled-env bottom before the exec
> to export LD_PRELOAD=$PWD/block-open.so), I get:
> dlopen libguile-gi
> dlopen /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen /gnu/store/xa1vfhfc42x655hi7vxqmbyvwldnz7r0-glib-
> 2.62.6/lib/libgobject-2.0.so.0
> 
> There it is again.
This is not meaningful at all.  Nothing here is "there again" except
for the libguile-gi, which if I understand it correctly is set up
multiple times with different init calls.  In particular, the internal
loading of libgobject by libguile-gi is obscured, hence why you need
(9) to figure out, what actually goes on.

> (9) ldd /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5
> |grep gobject
> [...]
> libgobject-2.0.so.0 =>
> /gnu/store/4jl613j0d5y6icbxxmwij75fd0i7qpwn-profile/lib/libgobject-
> 2.0.so.0 (0x7fe2a0677000)
> 
> And there is the other one.
It is not yet clear, that this is "the other one".  You would first
need to readlink it, but indeed, as is pointed out in Guile-GI#96, they
are different.  

But we already know all this from our earlier discussion.  #96 clearly
states, that those two don't line up in `guix environment`, while they
do line up in `guix environment --no-graphs` and `guix build`.  This is
certainly "evidence" and it might even be "hard" depending on how you
view it, but the questions is how to interpret it.

> Now how do I get more info, using Guix tools?
What kind of information do you even want to gather?  To be honest, you
lose me every time you end up establishing knowledge, that already
exists between this thread and the mentioned Guile-GI issue.
I suppose if you want to look at how environments are built, building
them with higher verbosity would be a start, no?
For the purpose of this, it would probably suffice to look at something
simpler than guile-gi in its totality, perhaps just gobject-
introspection + glib (note, that you'd need Scheme code to access the
latter).

Regards, Leo

Re: A public Lisp programming interface provide feature like `guix environment --container`

[Zhu Zihao]

Leo Prikler writes:

> launch-environment/container still assumes the command to be a shell
> script, which I think is not quite what you want.  You probably want to
> take a look at call-with-container from (guix build linux-container) or
> child-hurds.

I just read the source code of call-with-container. IMO, it just run
code in container, without any settings. It's quite inconvenient for my
usage. For example: I have to setup mount binding of my package closure 
manually. 

> I currently don't know of any procedure, that "directly" invokes Scheme
> code through Guix environments, so you'd have to build that on your
> own.  However, given that your stated goal is to port container entry
> scripts [I read this as "the script called by the container at entry"]
> to Guile, would it not make sense to have
>
>   (guix-environment [ENVIRONMENT OPTIONS] "--" "guile" "entry.scm")
>
> WDYT?
>
> Regards, Leo

Hmmm, maybe this is the solution, tho it's not very very elegant.


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Re: Etymology of derivation

[zimoun]

Hi Arun,

On Mon, 02 Nov 2020 at 00:57, Arun Isaac  wrote:

> I am translating Guix to the Tamil language. Tamil doesn't yet have a
> very standardized technical vocabulary, and I mostly coin terms on my
> own. Most often, I construct calques of existing English words, and it
> sounds alright. But, I'm having trouble with the word "derivation" (as
> in Guix's low-level build actions). I haven't seen the word "derivation"
> used anywhere outside of Guix. Why is a "low-level build action" called
> a "derivation"? If someone could clarify the etymology, it might really
> help with good translation.

Maybe the best is to directly ask on Nix channels from where comes from
“derivation”.  Maybe the original author would answer. :-)

BTW, as Vagrant and Timothy pointed, « derivation » means, from the
Collins dictionary:

UK
1. the act of deriving or state of being derived
2. the source, origin, or descent of something, such as a word
3. something derived; a derivative
4. 
  a. the process of deducing a mathematical theorem, formula, etc, as a
  necessary consequence of a set of accepted statements
  b. this sequence of statements
  c. the operation of finding a derivative

US
1.  a deriving or being derived
2.  descent or origination
3.  something derived; a derivative
4.  the source or origin of something
5.  the origin and development of a word; etymology
6. 
  a. Grammar
the process of forming words from bases by the addition of affixes
other than inflectional morphemes, or by internal phonetic change
the derivation of “warmth” from “warm”  
  b. Linguistics
in generative grammar, the process of forming sentences

https://www.collinsdictionary.com/dictionary/english/derivation


Therefore, to me, the word derivation makes sense for the Guix
« derivation ».

All the best,
simon

Re: RFC: subcommand to pause/resume builds

[Bengt Richter]

Hi all,

On +2020-11-03 14:53:07 +0100, Ludovic Courtès wrote:
> Hi,
> 
> John Soo  skribis:
> 
> > I was looking to pause a long build today and asked on IRC how to
> > accomplish pause/resume.  It seems this is possible already with the
> > following:
> >
> > kill --signal SIGSTOP|SIGCONT {pids-of-build-process-tree}
> >
> > There is already a command to list the processes associated to guix
> > commands: guix processes.  Perhaps pause/resume can be a subcommand or
> > set of flags to guix processes. The following is the first thing that
> > comes to mind:
> >
> > guix processes --pause package-name ... --resume package-name ...
> >
> > What do you think?
> 
> First, note that the daemon is unaware of “packages”, it only knows
> about “derivations”.
>

What if you turned the problem inside out, and made the derivation
volunteer to be paused (at sensible places in its progress)?

I.e., if you defined part of a given derivation 
"hash-prefixed-derivation-file-name-in-question.drv"
to do a check for the existence of

/var/guix/daemon-ctl/hash-prefixed-derivation-file-name-in-question.drv.sfx
(.sfx appended to signify special effects :) 

ISTM that could open the door for some easy hacks, (and probably some dangers 
to watch for :)
E.g. a proof of concept might be just to sleep 6 seconds (say) and repeat 
sleep/check
until the file disappears.

IWG this should not change anything for non-volunteering derivations other than 
the load-relief
of not running the sleeping process(es).

Then the person wanting to pause the derivation 
"hash-prefixed-derivation-file-name-in-question.drv"
could do so simply by
touch  
/var/guix/daemon-ctl/hash-prefixed-derivation-file-name-in-question.drv.sfx
and deleting it when wanting to allow it to continue.

Later, if that works, .sfx files could have content, for as yet unimagined 
purposes ;)

[...]
> 
> Conclusion: I don’t think we can implement this reliably.
>

IDK from the outside, but inside-out, WDYT?

> HTH!
> 
> Ludo’.
> 

-- 
Regards,
Bengt Richter

Re: A public Lisp programming interface provide feature like `guix environment --container`

[Leo Prikler]

Am Mittwoch, den 04.11.2020, 18:05 +0800 schrieb Zhu Zihao:
> Leo Prikler writes:
> 
> > launch-environment/container still assumes the command to be a
> > shell
> > script, which I think is not quite what you want.  You probably
> > want to
> > take a look at call-with-container from (guix build linux-
> > container) or
> > child-hurds.
> 
> I just read the source code of call-with-container. IMO, it just run
> code in container, without any settings. It's quite inconvenient for
> my
> usage. For example: I have to setup mount binding of my package
> closure manually. 
Indeed, but in my opinion it also has much of what you'd want for an
entry script, does it not?  You start with zero settings, then
configure the environment in whichever fashion you need, then call some
other function.
I think like this could be a stepping stone for some higher level
abstraction, that you would have to write on your own once, but could
then reuse more or less indefinitely.  Particularly, you would have to
copy the parts of Guix that create the environment and then just figure
out how to securely spawn a function inside it, that can't escape the
container environment, instead of running shell code.

> > I currently don't know of any procedure, that "directly" invokes
> > Scheme
> > code through Guix environments, so you'd have to build that on your
> > own.  However, given that your stated goal is to port container
> > entry
> > scripts [I read this as "the script called by the container at
> > entry"]
> > to Guile, would it not make sense to have
> > 
> >   (guix-environment [ENVIRONMENT OPTIONS] "--" "guile" "entry.scm")
> > 
> > WDYT?
> > 
> > Regards, Leo
> 
> Hmmm, maybe this is the solution, tho it's not very very elegant.
For the record, what you do want is something à la
(call-in-container-environment THUNK MANIFEST . KWARGS)
where manifest is the Guix environment manifest, THUNK is a procedure
to call with 0 arguments and KWARGS is a list of options for things you
might want to set up, e.g. just the GUIX_ENVIRONMENT variable or more
than that.

Is that about right?

Regards, Leo

Re: A public Lisp programming interface provide feature like `guix environment --container`

[Zhu Zihao]

Leo Prikler writes:

> For the record, what you do want is something à la
> (call-in-container-environment THUNK MANIFEST . KWARGS)
> where manifest is the Guix environment manifest, THUNK is a procedure
> to call with 0 arguments and KWARGS is a list of options for things you
> might want to set up, e.g. just the GUIX_ENVIRONMENT variable or more
> than that.
>
> Is that about right?
>
> Regards, Leo

Yes, that's what I want. KWARGS may accept something like user-mappings,
network?, namepsaces etc. like `launch-environment/container`. So I can
create container entry script for different executable in batch with
more confidence in code reuse. It's ugly to 
concatenate string argument (For example: `(string-append "--expose="
 "=" yyy)`) when I want to reuse some path variable.


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Release: Docker Image? DockerHub? skopeo?

[zimoun]

Hi,

Some days ago, we discussed on #guix about releasing Docker images
ready-to-use.  And you pointed your project:

  https://gitlab.com/daym/guix-on-docker/


First question for Danny: is it ready to include it to the release?
Include meaning communicate about it – with the status experimental.

Second question for Ludo: does the Guix project officially push a Docker
image to DockerHub?

Third question for all: do we add an experimental box on the “Download”
section of the website [0]?

Fourth question for Jelle: do you have time to add examples to the
Cookbook using the package ’skopeo’?  If not, who could?


This is a follow-up to the thread, started here [1] and arguments about
DockerHub and co. there [2] and Ludo’s comments [3].


0: http://guix.gnu.org/en/download/
1: https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00212.html
2: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00352.html
3: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00352.html


Feedback welcome.

All the best,
simon

Make guix-publish's URL identical to cache file name

[Peng Mei Yu]

Hi,

This proposal aims to solve an old problem.  Make it easier to setup a
mirror server for the official substitute server and prevent future
complaints from China residents about network speed.

Due to the national firewall(i.e. The GFW) deployed on every backbone
networks within China and it's aggressive rules on traffic passing
through the wall, the internet connection from inner China to outside
world is extremely unreliable and slow.  This makes it a pain for
newcomers to try and play with Guix, since guix daemon loves to spawn
thousands of HTTP requests to the substitute server and download
thousands of megabytes of packages from the substitute server.  Usually
it takes a whole day to install Guix system on a new computer.  I am
serious.  I have been a Guix user for several years and actually I am
not very much bothered by the problem.  But since V1.0 release of Guix,
Guix is frequently mentioned in tech news.  When tech savvy boys hear
the cool Guix and try to install it on their computer and still cannot
complete the installation process after half a day, they will always be
pissed off by the slow network speed and complain on internet.  I
mentioned Guix several times on some websites, this makes me the first
Chinese Guix user they can find with Google and ask for help.

I am sure maintainers here know these kind of complaints.  Do you feel
it is strange that no Chinese user make new complaints in year 2020
while the Guix project is quickly progressing and becoming more popular?
That is because I decided to setup a mirror server for Chinese Guix
users after receiving several complaints online and realizing that
lobbying academic FLOSS mirror maintainers to support Guix will be
stagnant for at least several years due to these maintainers' laziness
and cowardliness and some ridiculous strict governmental regulations.
These people only want to add mirror for a project if it is as simple as
pulling static files with a cron job (usually with rsync) and serving
static files through a simple HTTP server.  HTTP reverse proxy is not an
option.  So my mirror.guix.org.cn project was started.  It's an HTTP
cache mirror of ci.guix.gnu.org, plus a git mirror of
https://git.savannah.gnu.org/cgit/guix.git.  Yes, the connection to
Savannah is also extremely slow and it makes `guix pull` unusable.

This mirror server started as an experiment and it has been working
well.  If random new user come to me and say `guix pull` is so slow or
`guix install` is so slow, I simply tell them to use mirror.guix.org.cn.
The number of active Chinese Guix users I know has increased from two to
about ten after someone's broadcast in a news group.  It is basically:
"Look.  There is thing called Guix.  Someone has setup a mirror server
for it in China."  The traffic on the server is increasing.  Network
connections are stable.  Everything is fine in this year.  However one
thing worries me.  The bandwidth of mirror.guix.org.cn is only 5Mbps
(still far more better than ci.guix.gnu.org's 30KB/s and constant
connection reset).  This is the highest bandwidth I can afford because
internet bandwidth in China is damn too expensive.  Buying higher
bandwidth is not a financially possible approach for me.  This is not a
problem in the short term but definitely be a problem in the long term.
Persuading academic FLOSS mirror maintainers to support Guix is still
the best solution for Chinese users.  Academic organizations usually
have 100Mbps bandwidth and tens of terabytes of disk.

Now, finally, we are onto the main point.  I look into guix publish's
cache directory and think that nar and narinfo files can be directly
served through a static HTTP server if we make those files' URL
identical to their on-disk file name.  The current directory structure
is like this:

--8<---cut here---start->8---
/var/cache/guix/publish
├── gzip
│   ├── 87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.nar
│   ├── 87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.narinfo
│   ├── fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31.nar
│   └── fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31.narinfo
├── hashes
│   ├── 87kif0bpf0anwbsaw0jvg8fyciw4sz67
│   └── fa6wj5bxkj5ll1d7292a70knmyl7a0cr
├── last-expiry-cleanup
└── lzip
├── 87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.nar
├── 87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.narinfo
├── fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31.nar
└── fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31.narinfo
--8<---cut here---end--->8---

--8<---cut here---start->8---
> md5sum 
> /var/cache/guix/publish/*/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.narinfo
29cdbf041b9a304bf58f2e75ec23f18f  
/var/cache/guix/publish/gzip/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.narinfo
29cdbf041b9a304bf58f2e75ec23f18f  
/var/cache/guix/publish/lzip/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16.narinfo
--8<---cut here---end-

Re: Make guix-publish's URL identical to cache file name

[Jonathan Brielmaier]

Hi Peng Mei Yu,

first of all a big thank you for making the Guix experience in China
much nicer!

I'm running myself a smaller cuirass+publish server and I have
configured the caching on the nginx side and not with `guix publish`.

So my cache resides in:
/var/cache/nginx/nar/

For me it has a dramatic speed up on my German server reaching from
Germany. So 2-3MB/s on a cold cache hit versus a hot cache with 15MB/s
and even more.

Maybe you can give that a try. I'm not sure if it does help as you said
you are a bit limited by the bandwidth...

On 04.11.20 09:46, Peng Mei Yu wrote:
> I have to decide next year's server specs and budget for
> mirror.guix.org.cn before the Chinese shopping festival ends on November
> 11.  If the proposal above is doable, I will keep mirror.guix.org.cn
> running for half a year and help academic mirror sites add support for
> Guix in the meantime.  Otherwise I prefer to buy a prepaid three years
> VPS with a 90% discount during the shopping festival.  The discount is
> huge.  I don't want to miss it.

I think we should discuss if Guix can support your effort money wise.
AFAIK we have decent fundings available.

~Jonathan

Re: Release: Docker Image? DockerHub? skopeo?

[Jelle Licht]

Hello,

zimoun  writes:

> Some days ago, we discussed on #guix about releasing Docker images
> ready-to-use.  And you pointed your project:
>
>   https://gitlab.com/daym/guix-on-docker/

[snip]

> Fourth question for Jelle: do you have time to add examples to the
> Cookbook using the package ’skopeo’?  If not, who could?

I was actually putting that on the back burner for now, as I felt I
first needed some time to understand Danny's `guix-on-docker' better in
order for the skopeo stuff to warrant a cookbook section. The entire
workflow as I use it now can be summarized by the following three-liner:

--8<---cut here---start->8---
REGISTRY_IMAGE=registry.gitlab.com/group/project 
IMG=$(guix pack --save-provenance -f docker --entry-point=bin/hello hello)
skopeo copy --dest-creds USERNAME[:PASSWORD] \
   "docker-archive://$IMG" \
   "docker://${REGISTRY_IMAGE}:latest"
--8<---cut here---end--->8---

> This is a follow-up to the thread, started here [1] and arguments about
> DockerHub and co. there [2] and Ludo’s comments [3].

Our timing is pretty bad here, as Dockerhub updated some of their
policies only two days ago regarding usage limits for both 'anonymous'
and free tier registered users [4]. 

> 1: https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00212.html
> 2: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00352.html
> 3: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00352.html

[4]: 
https://www.docker.com/blog/what-you-need-to-know-about-upcoming-docker-hub-rate-limiting/

- Jelle

Re: GNOME in Guix

[Danny Milosavljevic]

Hi,

On Wed, 04 Nov 2020 10:45:06 +0100
Leo Prikler  wrote:

> But we already know all this from our earlier discussion.

I *know* you already know that--but "we" don't.  I want someone to actually
proceed further, because I cannot.  Hence I posted this on guix-devel
(for the first time with an easy short recipe to follow).

> > Now how do I get more info, using Guix tools?  
> What kind of information do you even want to gather?  To be honest, you
> lose me every time you end up establishing knowledge, that already
> exists between this thread and the mentioned Guile-GI issue.

I am hereby asking someone who knows how this part of guix works to find out
what happens here.

> I suppose if you want to look at how environments are built, building
> them with higher verbosity would be a start, no?

Thanks.  That is what I wanted to know.

I tried guix environment -v 99 -d 1 and it adds nothing useful, especially not
how the other libgobject got in there.

So I still want to know.

> For the purpose of this, it would probably suffice to look at something
> simpler than guile-gi in its totality, perhaps just gobject-
> introspection + glib (note, that you'd need Scheme code to access the
> latter).

Sure, sounds good.


pgpvXyQJ0YZ9v.pgp
Description: OpenPGP digital signature

Re: GNOME in Guix

[Leo Prikler]

Hi,

Am Mittwoch, den 04.11.2020, 14:43 +0100 schrieb Danny Milosavljevic:
> Hi,
> 
> On Wed, 04 Nov 2020 10:45:06 +0100
> Leo Prikler  wrote:
> 
> > But we already know all this from our earlier discussion.
> 
> I *know* you already know that--but "we" don't.  I want someone to
> actually
> proceed further, because I cannot.  Hence I posted this on guix-devel
> (for the first time with an easy short recipe to follow).
Ah, okay.  I'm still a bit confused, given how verbose that recipe was,
but I get where you're coming from.

> Thanks.  That is what I wanted to know.
> 
> I tried guix environment -v 99 -d 1 and it adds nothing useful,
> especially not
> how the other libgobject got in there.
> 
> So I still want to know.
I think some important information gets lost here, because you already
built most of the packages.  You could try garbage-collecting them and
then start anew, but then you'd be building the entire profile at full
debug info.  Interestingly, nothing shows up for the generation of
profile.drv, which might indicate, that there are not actually two
packages in there.  It's at least a bit suspicious.

Having received the path of the profile.drv, you might now want to look
at what packages it references (recursively), specifically all mentions
of glib.  (Use emacs-guix for quick navigation through .drv files.)

For the record, in case you forgot to note the .drv, my profile
containing glib-with-documentation and gobject-introspection is

/gnu/store/cl1wz5wsgjy208n330z4p9f5kljzixp2-profile.drv

Regards, Leo

Re: Releasing guix binary in Docker format too?

[Danny Milosavljevic]

Hi Ludo,

On Wed, 21 Oct 2020 17:42:36 +0200
Ludovic Courtès  wrote:

> zimoun  skribis:
> 
> > The tool is 'skopeo' and packaged in Guix.
> >
> > However, push to DockerHub requires an account (by Guix project) which
> > requires... probably non-free JS, at least once.  
> 
> Hmm OK.  Users of Docker wouldn’t have to create an account and run the
> non-free JS, so this is probably acceptable.
> 
> The next problem is: what would this image contain?  ‘guix pack guix’ is
> probably not enough because people expect the daemon to be running.
> Adding ‘--entry-point=bin/guix-daemon’ probably isn’t good either
> because ‘guix-daemon’ never exits, which I think is contrary to what
> users expect.

It really depends on how people use the images.

It's totally normal for docker containers to start services they need in
the foreground on container startup, and people then entering that
running container from the outside anyway (!) using docker tools.

The guix I packaged on https://gitlab.com/daym/guix-on-docker/ is
specifically used as a test runner, which is why I background
guix-daemon there.  Otherwise, the gitlab test runners would hang waiting
for guix-daemon to finish (which never happens).

If I wouldn't need that, I'd totally not background stuff.

> For the same reason, an image produced by ‘guix system docker-image’ may
> not be OK because ‘shepherd’ never returns.
> 
> Should we change ‘guix system docker-image’ such that ‘shepherd’ is
> started in the background?

Why?  Docker tools are perfectly capable of entering a docker container
where a foreground process is running.

Also, one has to be careful that the container doesn't get stopped since
the last process finished.


pgp74SOIIR5Yr.pgp
Description: OpenPGP digital signature

Re: Release: Docker Image? DockerHub? skopeo?

[Danny Milosavljevic]

Hi zimoun,

On Wed, 04 Nov 2020 12:05:28 +0100
zimoun  wrote:

> Some days ago, we discussed on #guix about releasing Docker images
> ready-to-use.  And you pointed your project:
> 
>   https://gitlab.com/daym/guix-on-docker/
> 
> First question for Danny: is it ready to include it to the release?
> Include meaning communicate about it – with the status experimental.

Yes.  It's done.

For the use case I'm using it for, guix-on-docker is final now.
I doubt that I'll change anything in it, and certainly nothing major.

Right now, my gitlab project automatically tracks guix from git master on
savannah and rebuilds that and pushes the result to gitlab's docker
registry (every time someone commits to guix master).

If we wanted the gitlab project to track a release tag, we'd have to
configure it to do building from a tag, too.  If so, please tell me.


pgp5110WCvptK.pgp
Description: OpenPGP digital signature

“guix pack -RR r“ fails?

[zimoun]

Dear,

Using Guix fd0ef0e, I run:

--8<---cut here---start->8---
rsync -av --progress\
  $(guix pack -RR --save-provenance \
  -S /bin=bin   \
  -S /etc=etc   \
  -S /include=include   \
  -S /lib=lib   \
  -S /share=share   \
  -S /site-library=site-library \
  r)\
  cluster:/path/to/my/stuff
--8<---cut here---end--->8---

then log via SSH to cluster and untar the pack.

--8<---cut here---start->8---
$ ls -ahl
total 422M
drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:05 .
drwxrwxrwx. 15 root   root   3.8K Nov  4 19:02 ..
-r--r--r--   1 sitour sitour 421M Jan  1  1970 
5n55mgjcj33s700g91x0zzf3ngflnba7-tarball-pack.tar.gz
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 bin -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/bin
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 etc -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/etc
drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:03 gnu
lrwxrwxrwx   1 sitour sitour   58 Nov  4 19:05 include -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/include
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 lib -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/lib
lrwxrwxrwx   1 sitour sitour   56 Nov  4 19:05 share -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/share
lrwxrwxrwx   1 sitour sitour   63 Nov  4 19:05 site-library -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/site-library
--8<---cut here---end--->8---

The usual ‘./bin/R’ fails with:

--8<---cut here---start->8---
$ ./bin/R
: unsupported Guix execution engine; ignoring
./bin/R
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"

[...]

 *** caught segfault ***
address 0x7f44f4b11008, cause 'memory not mapped'
--8<---cut here---end--->8---

and then has to be killed.  Last,

--8<---cut here---start->8---
$ gdb ./bin/R
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/R...(no
 debugging symbols found)...done.
(gdb) run
Starting program: 
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/R
 
: unsupported Guix execution engine; ignoring
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/Rprocess
 36927 is executing new program: 
/data2/tmp/foo/gnu/store/jwdvnklncaqw15376vbbr1vgpfr17j18-proot-static-5.1.0/bin/proot
Detaching after fork from child process 36930.

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Error: package or namespace load failed for 'grDevices' in dyn.load(file, 
DLLpath = DLLpath, ...):
 unable to load shared object 
'/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
  
/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
 cannot open shared object file: Bad address
Error: package or namespace load failed for 'graphics' in dyn.load(file, 
DLLpath = DLLpath, ...):
 unable to load shared object 
'/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
  
/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
 cannot open shared object file: Bad address
Error: package or namespace load failed for 'stats' in dyn.load(file, DLLpath = 
DLLpath, ...):
 unable to load shared object 
'/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
  
/gnu/store/nqqh

New Tamil PO file for 'guix' (version 1.2.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the Tamil team of translators.  The file is available at:

https://translationproject.org/latest/guix/ta.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Hunspell dictionaries

[paul]

Hi Jonathan,

On 11/1/20 10:41 AM, Jonathan Brielmaier wrote:

On 31.10.20 21:03, paul wrote:> Dear Guixers,


I was packaging an Italian dictionary for Hunspell, when I found this
link listing all the Hunspell dictionaries supported by Libreoffice [0].

This lead me to think about a function for defining dictionary packages
(very much based on aspell-dictionary from (gnu packages aspell)).


Hi Paul, that is nice. I think it's absolutly worth it making support of
more languages easier :)

I worked back then on the hunspell-dict-de and we discussed that we
should move the hunspell dicts out of libreoffice.scm as they are used
by other programs as well.

So when you make a patch you could save that stuff in
gnu/packages/hunspell.scm...

Thank you for the infos :D, I'll proceed ASAP to send a patch with the 
new file and the function.


Cheers,

Giacomo

Re: Make guix-publish's URL identical to cache file name

[Peng Mei Yu]

Hi Jonathan,

Jonathan Brielmaier writes:

> I'm running myself a smaller cuirass+publish server and I have
> configured the caching on the nginx side and not with `guix publish`.
>
> So my cache resides in:
> /var/cache/nginx/nar/
>
> For me it has a dramatic speed up on my German server reaching from
> Germany. So 2-3MB/s on a cold cache hit versus a hot cache with 15MB/s
> and even more.
>
> Maybe you can give that a try. I'm not sure if it does help as you said
> you are a bit limited by the bandwidth...

I am perfectly fine with any method to setup a mirror site.  But the
academic mirror sites I am talking about only want a simple approach.
They want to pull files with rsync, rclone, or FTP and serve files with
static HTTP server.  If we make Guix's mirror as simple as that, I am
confident I can persuade more mirror sites to support Guix.


> On 04.11.20 09:46, Peng Mei Yu wrote:
>> I have to decide next year's server specs and budget for
>> mirror.guix.org.cn before the Chinese shopping festival ends on November
>> 11.  If the proposal above is doable, I will keep mirror.guix.org.cn
>> running for half a year and help academic mirror sites add support for
>> Guix in the meantime.  Otherwise I prefer to buy a prepaid three years
>> VPS with a 90% discount during the shopping festival.  The discount is
>> huge.  I don't want to miss it.
>
> I think we should discuss if Guix can support your effort money wise.
> AFAIK we have decent fundings available.

That would be great.  Although I still think letting academic mirror
sites do the job and saving the money would be better.  As I said, the
ISP cost in China is expensive and academic mirror sites have plenty of
bandwidth and storage resources available.


--
Peng Mei Yu

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Maxim Cournoyer writes:

> Hello Guix!
>
> I've been experimenting with the following modification to the
> .dir-locals file shipped with Guix, that allows setting per-buffer
> variables within Emacs when visiting a file in the same directory (or in
> one of its sub-directories).
>
> This makes life a bit easier, by ensuring that a Geiser REPL started
> with C-c C-a in a file of either the main 'guix' checkout, a
> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
> `geiser-guile-load-path' Elisp variable).
>
> The only requirement for it to work reliably is that any Guix checkout
> or worktree name should start with "guix".
>
> It doesn't require Geiser to be installed (it will just set the above
> variable uselessly if it isn't used -- not a big deal).
>
> What do you think?  Is it useful?  Should we include this as part of the
> default .dir-locals of Guix?
>
> Patch to follow!
>
> Thanks,
>
> Maxim

I'm a bit unsure what the implications fully are with this change, but
here was my user experience:

 - Did a pull using magit to guix
 - Suddenly every file I open in Guix is prompting me if I want to
   enable these dir-locals, I notice some have "eval" and I don't know
   what it's doing so I say no
 - But it's asking me every file
 - And oh no, it's asking me about ten times for every magit operation!
   (Presumably due to the reload operation.)  Fine okay fine, YES, okay
   cool it's quiet now... I hope that was safe.

Later...

 - I'm hacking on another file in another repo
 - C-x v = (check to see a diff of the work-in-progress changes of the
   file I'm working on)
 - Error in the minibuffer!  "Wrong type argument: stringp, nil"
 - wtf, okay M-x toggle-debug-on-error

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  (let* ((root-dir (expand-file-name (locate-dominating-file default-directory 
".dir-locals.el"))) (root-dir* (directory-file-name root-dir))) (unless (boundp 
'geiser-guile-load-path) (defvar geiser-guile-load-path 'nil)) 
(make-local-variable 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew 
root-dir* geiser-guile-load-path :test #'string-equal))
  eval((let* ((root-dir (expand-file-name (locate-dominating-file 
default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
(require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
#'string-equal)))
  hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
(locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
(directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
(defvar geiser-guile-load-path 'nil)) (make-local-variable 
'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
geiser-guile-load-path :test #'string-equal)))
  hack-local-variables-apply()
  hack-dir-local-variables-non-file-buffer()
  diff-mode()
  vc-diff-internal(t (Git 
("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
  vc-diff(nil t)
  funcall-interactively(vc-diff nil t)
  call-interactively(vc-diff nil nil)
  command-execute(vc-diff)
 
 - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
   now my vc-diff is broken outside of there... :\

I'm presuming that if I understood whatever this is doing, it's probably
something that gives me a better user experience if I accept it while
working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
written in such a way that it antagonizes me for not accepting it and I
didn't know what it eval was (maybe this is a lack of understanding in
how to "say no and get it to listen to me"... I didn't resist for too
long) and b) it seems like this change isn't scoped to Guix's checkout
itself somehow...

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Also, I hope this email isn't interpreted as being dismissive or negative
about what looks like it's probably a real usability improvement for
hacking on Guix!  I just thought my experience indicated maybe there are
additional considerations to address.

Christopher Lemmer Webber writes:

> Maxim Cournoyer writes:
>
>> Hello Guix!
>>
>> I've been experimenting with the following modification to the
>> .dir-locals file shipped with Guix, that allows setting per-buffer
>> variables within Emacs when visiting a file in the same directory (or in
>> one of its sub-directories).
>>
>> This makes life a bit easier, by ensuring that a Geiser REPL started
>> with C-c C-a in a file of either the main 'guix' checkout, a
>> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
>> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
>> `geiser-guile-load-path' Elisp variable).
>>
>> The only requirement for it to work reliably is that any Guix checkout
>> or worktree name should start with "guix".
>>
>> It doesn't require Geiser to be installed (it will just set the above
>> variable uselessly if it isn't used -- not a big deal).
>>
>> What do you think?  Is it useful?  Should we include this as part of the
>> default .dir-locals of Guix?
>>
>> Patch to follow!
>>
>> Thanks,
>>
>> Maxim
>
> I'm a bit unsure what the implications fully are with this change, but
> here was my user experience:
>
>  - Did a pull using magit to guix
>  - Suddenly every file I open in Guix is prompting me if I want to
>enable these dir-locals, I notice some have "eval" and I don't know
>what it's doing so I say no
>  - But it's asking me every file
>  - And oh no, it's asking me about ten times for every magit operation!
>(Presumably due to the reload operation.)  Fine okay fine, YES, okay
>cool it's quiet now... I hope that was safe.
>
> Later...
>
>  - I'm hacking on another file in another repo
>  - C-x v = (check to see a diff of the work-in-progress changes of the
>file I'm working on)
>  - Error in the minibuffer!  "Wrong type argument: stringp, nil"
>  - wtf, okay M-x toggle-debug-on-error
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil)
>   (let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal))
>   eval((let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal)))
>   hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
> (locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
> (directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
> (defvar geiser-guile-load-path 'nil)) (make-local-variable 
> 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
> geiser-guile-load-path :test #'string-equal)))
>   hack-local-variables-apply()
>   hack-dir-local-variables-non-file-buffer()
>   diff-mode()
>   vc-diff-internal(t (Git 
> ("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
>   vc-diff(nil t)
>   funcall-interactively(vc-diff nil t)
>   call-interactively(vc-diff nil nil)
>   command-execute(vc-diff)
>  
>  - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
>now my vc-diff is broken outside of there... :\
>
> I'm presuming that if I understood whatever this is doing, it's probably
> something that gives me a better user experience if I accept it while
> working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
> written in such a way that it antagonizes me for not accepting it and I
> didn't know what it eval was (maybe this is a lack of understanding in
> how to "say no and get it to listen to me"... I didn't resist for too
> long) and b) it seems like this change isn't scoped to Guix's checkout
> itself somehow...

RFC: subcommand to pause/resume builds

[John Soo]

 
 

 
 
 
Hello Guix, 

 
I just sent a patch to normalize the output of processes with bug number 44460. 
The allows me to compose recutils with kill to get the desired effect of 
pausing all process trees for the things I want without any convoluted 
implementation.I think I would be satisfied with such a patch and nothing 
else.
 

 
Thanks again!
 

 
John