Japanese Input wont't without manually adding environmental variables?

[yasu]

Hi!
After installing packages ibus and ibus-anthy , I thought I would be
able to type Japanese - but I had to follow the tip below and manually
add these variables to make it work.Would this be considered a bug?  
https://www.mail-archive.com/help-guix@gnu.org/msg08282.html
export GUIX_GTK2_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-
2.0/2.10.0/immodules-gtk2.cache" export
GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-
3.0/3.0.0/immodules-gtk3.cache" 
Cheers,Yasu

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

[Ricardo Wurmus]

Ludovic Courtès  writes:

> The simplest solution for now (I think that’s what Ricardo & co. had in
> mind) would be for you to retrieve /var/cache/guix/publish on your
> server, as is, and then run ‘guix publish’ on your sever: it will know
> where to find files.  As I wrote to Jonathan, you can/should also run
> nginx on top of that as a proxy to your local ‘guix publish’.
>
> Ricardo, can you remind us what the next steps would be?

We need to make sure that *all* the files produced by “guix publish”
have correct permissions; IIRC some of the files are not readable at all
by users other than the owner of the files.

Once that’s done we just need to start the rsync daemon again,
preferably as a shepherd service.

-- 
Ricardo

Re: RFC: subcommand to pause/resume builds

[John Soo]

Hello everyone,

Ludovic Courtès  writes:

>> After perusing info recutils some, I expected the output to be more
>> like:
>>
>> ChildProcessPID: 16923
>> ChildProcessCommand: guile --no-auto-compile -L
>> /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import
>> /gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder
>
> Yes, that would be nicer.

I sent in patch https://issues.guix.gnu.org/issue/44460 to address
it. With that I don't see any reason to consider a subcommand.


> However, note that if you fiddle with child processes, your warranty is
> void!  :-)

Definitely agreed.

> You’d be interfering with build processes, thus potentially changing
> their result in an uncontrolled way.

Like Mark said, I have seen tests potentially time out, and I have to agree.

I am done discussing a subcommand. I'll shift attention to #44460.

Thanks for listening to little old me :).

Have a nice weekend,

John

Re: RFC: subcommand to pause/resume builds

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Last, you’d need to send SIGTSTP to the whole process group of the
> build, like so (I think, haven’t tried):
>
>   sudo kill -TSTP -123
>
> where 123 is the “SessionPID” shown by ‘guix processes’.  However, doing
> so may affect build results: processes in the build environment might
> handle SIGTSTP specially, which can have side effects.  It’s an
> observable action.

What's the rationale for using SIGTSTP instead of SIGSTOP here?

FWIW, on a few occasions I've paused builds by sending SIGSTOP to the
relevant process group, and later SIGCONT, and it has worked for me.  As
I recall, I've done this while building rust, webkitgtk, and icecat.

However, I suspect that if I paused a build while running tests, the
test suite might ultimately fail due to a "timeout".

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

Agreed.

 Thanks,
   Mark

Re: “guix pack -RR r“ fails?

[zimoun]

Hi Roel,

On Thu, 05 Nov 2020 at 13:38, Roel Janssen  wrote:

>> What do I miss?
>
> Perhaps completely misguided, but is this inside an SGE or SLURM job?
> I've seen similar errors when starting R on a cluster node with too
> little memory allocated to the compute job. In my experience you need
> at least 2G of memory available.

Thank you for sharing.  I am on the master node and launched as a
regular user (not tried as root).

If I understand correctly, my issue should come from the kernel which is
too old and/or not compiled with the correct options.


All the best,
simon

Re: “guix pack -RR r“ fails?

[zimoun]

Hi,

Thank you for the help.


On Fri, 06 Nov 2020 at 11:05, Ludovic Courtès  wrote:

>> $ ./bin/R
>> : unsupported Guix execution engine; ignoring
>
> ‘GUIX_EXECUTION_ENGINE’ is set to the empty string.

Yes, sorry.  I have tried another one than the default and have been
lazy to open the manual and check which one is the default.

The result is the same with the default.


> Can you try ‘strace -f -s 500 -o log ./bin/R’ and send the tail of the
> ‘log’ file?

--8<---cut here---start->8---
$ strace -f -s 500 -o log ./bin/R
proot error: ptrace(TRACEME): Operation not permitted
proot error: 
execve("/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/bin/R"): 
Operation not permitted
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot error: can't chmod '/tmp/proot-12809-PB78qJ': No such file or directory
--8<---cut here---end--->8---

and then the tail of ’log’:

--8<---cut here---start->8---
[..]
12809 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], __WALL, NULL) = 12810
12809 ptrace(PTRACE_SYSCALL, 12810, 0, SIG_0) = -1 ESRCH (No such process)
12809 wait4(-1, 0x7ffe63a965cc, __WALL, NULL) = -1 ECHILD (No child processes)
12809 stat(".", {st_mode=S_IFDIR|0775, st_size=3864, ...}) = 0
12809 stat("/data2/tmp/foo", {st_mode=S_IFDIR|0775, st_size=3864, ...}) = 0
12809 chmod("/tmp/proot-12809-PB78qJ", 0700) = -1 ENOENT (No such file or 
directory)
12809 write(2, "proot error: ", 13) = 13
12809 write(2, "can't chmod '/tmp/proot-12809-PB78qJ'", 37) = 37
12809 write(2, ": ", 2) = 2
12809 write(2, "No such file or directory\n", 26) = 26
12809 chdir("/data2/tmp/foo")   = 0
12809 exit_group(1) = ?
--8<---cut here---end--->8---




>> The cluster machine is an old kernel:
>>
>> HEAD$ uname -a
>> Linux HEAD 2.6.32-573.8.1.el6.x86_64 #1 SMP Tue Nov 10 18:01:38 UTC 2015 
>> x86_64 x86_64 x86_64 GNU/Linux
>
> Our libc is built with ‘--enable-kernel=3.2.0’ so it’s not clear whether
> this can work at all (this ‘2.6’ kernel certainly contains stuff
> backported from 3.x though, who knows.)

Ok.  I will be annoyed if it does not work…


All the best,
simon

Talk/BoF proposal: From v1.2 to release process

[zimoun]

Dear,

Since I cannot be the judge on my own proposal, I send it here.

The proposal is:

 * Numbers of release v1.2
 * Opinionated features of v1.2
 * Propose a process to smooth releasing

The idea is to present how healthy Guix is by showing some numbers; let
release the statistician in me.  Then what are my favorite new features;
let release the user in me.  Last, propose a release process; let
release the contributor in me.

The Q&A (30min) would be about how to implement and test one release
process.  I have already my opinion and I would like to discuss it.

WDYT?

All the best,
simon

[GUIX DAY PROPOSAL] Just build it with Guix

[Efraim Flashner]

Creating custom packages is ubiquitous with Guix and packaging with Guix
is fairly straightforward. But what about working with packages where
you want to package a non-release version? Or if you're hacking on
another package which either isn't packaged in Guix or you want to test
your changes before sending off a patch set or pull request? `guix.scm`
is the unofficial filename for Guix build instructions for this case. It
provides a target for creating an environment for hacking on the
package, and it creates a build recipe to build what's currently in that
repository, meaning you can use the power of Guix for builds even while
working on other projects.
A combination of a little bit of boiler-plate for building "this here
repository" and standard package definitions allow for easy building and
rebuilding without dirtying the source tree. And also for building
multiple versions of the package in one go.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Friday, November 6, 2020 9:10 AM, Ludovic Courtès  wrote:

> Hi,
>
> Luis Felipe luis.felipe...@protonmail.com skribis:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, November 3, 2020 11:32 PM, zimoun zimon.touto...@gmail.com 
> > wrote:
> >
> > > Hi,
> > >
> > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=76ea70bd70aeb76570445c11cea2f98139192b54
> > >
> > > Clever workaround! What are now the performances on previous examples
> > > (same profiles and same packages)?
> >
> > In my case there seem to be no improvement (using Guix 
> > 5e7cf66fb35780f930ad0bc5fe21ac330df4411d).
>
> Please note that the change above addresses only one specific source of
> slowness, the ‘xdg-mime-database’ hook, and only in specific cases.
>
> It’s good to look at the overall timing of ‘guix install’, because
> that’s what matters in the end, but as we work on optimizing it, we have
> to look at specific aspects of it.
>
> > $ time guix package -i perl --max-jobs=1


Yeah, sorry I was more focused on the general issue (#44053), but I understand.


> [...]
>
> > injertando 12 paquetes en 
> > /gnu/store/anknpdyhmfirw3rz2k9zm9kiyak8yy1s-cups-filters-1.27.4.drv ...
> > construyendo la base de datos MIME XDG...
> > injertando 3 paquetes en 
> > /gnu/store/xgny7xbl635g8na8x03x4cdr7abiphiw-cups-2.3.3.drv ...
> > injertando 20 paquetes en 
> > /gnu/store/yhjl68x7kcjbv40v823x4hl8rvv8l50b-gtk+-2.24.32.drv ...
> > injertando 21 paquetes en 
> > /gnu/store/kq37fnw8335f1hqc3j4hhqqcdnhl371p-gtk+-3.24.20.drv ...
> > creando la caché de temas de iconos de GTK+...
> > construyendo los ficheros de caché para los métodos de entrada de GTK+...
> > construyendo perfil con 86 paquetes...
> > real 8m38,121s
> > user 0m2,742s
> > sys 0m0,338s
>
> Here it’s likely that grafting is what’s taking the most time on a
> spinning disk.

It does take some time, but since I can see the output change from grafting to 
grafting, I at least can tell guix is doing something, so I just let it be.

Compared to grafting, the last step "construyendo perfil con X paquetes..." 
("building profile with X packages..."), just stays there without change for 
several minutes, so it actually seems slower to me. Initially, I thought that 
guix had frozen.

Also, even though, the "building profile" step has a throbber (| / - \) to 
indicate that something is being done, it frequently stops in one of the frames 
of the sequence and stays there until the end.


> We should hack (guix status) so it can optionally prefix each event with
> a timestamp.
>
> As far as ‘xdg-mime-database’ is concerned, it should be down to 0s,
> unless your profile contains one of the packages I cited (libreoffice,
> gcr, hugin, etc.).

Yes, I have Libreoffice installed.

Fixing Zabbix db-secret-file documentation.

[Tobias Geerinckx-Rice]

Guix,

We currently claim that db-secret-file is appended to 
zabbix.conf.php.


To me that can only mean:

 $ cat db-secret-file
 $DB['PASSWORD'] = 'supersecure'
 $DB['maybe'] = 'some more sekrit stuff too'

but it's really just:

 "$DB['PASSWORD'] = '" (with-input-from-file db-secret-file
read-string) "';"

It's late into 1.2 to invalidate manual translations.  However, 
I'm sceptical of shipping a translated-but-IMO-incorrect snippet 
over a better English one just to boost coverage stats, and would 
like to push it anyway.  Thoughts?


Kind regards,

T G-R

From c6746726e4db7f674297de79ae599ca9686658a1 Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice 
Date: Fri, 6 Nov 2020 13:17:00 +0100
Subject: [PATCH 1/2] =?UTF-8?q?doc:=20Fix=20Zabbix=20?=
 =?UTF-8?q?=E2=80=98db-secret-file=E2=80=99=20documentation.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/guix.texi (Monitoring Services): Document ‘db-secret-file’'s (lack
of) structure and gexp support.
---
 doc/guix.texi | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 217ed7a8a8..1c29799d6c 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -22168,9 +22168,10 @@ Defaults to @samp{""}.
 @end deftypevr
 
 @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-secret-file
-Secret file which will be appended to @file{zabbix.conf.php} file.  This
-file contains credentials for use by Zabbix front-end.  You are expected
-to create it manually.
+Secret file containing the credentials for the Zabbix front end.  The value
+must be a local file name, not a G-expression.  You are expected to create
+this file manually.  Its contents will be copied into @file{zabbix.conf.php}
+as the value of @code{$DB['PASSWORD']}.
 
 Defaults to @samp{""}.
 
-- 
2.29.2



signature.asc
Description: PGP signature

Re: Releasing guix binary in Docker format too?

[Danny Milosavljevic]

Hi,

On Fri, 06 Nov 2020 13:47:02 +0100
zimoun  wrote:

> On Fri, 06 Nov 2020 at 10:59, Ludovic Courtès  wrote:
> 
> >  guix pack guix -f docker -S /bin=bin \
> >--entry-point="bin/guix-daemon --disable-chroot"

Why --disable-chroot here?  (I'm not objecting to it)

> > might work, right?
> >
> > Someone needs to try because the devil is in the details.  
> 
> I will try to give a try.  If someone does not beat me.

Please do.

Note: guix-daemon needs a usergroup in order to actually usefully build
things, with at least one member user.

If Docker actually has first-class composition operators (I don't know), then
that should not go into the same image--but that means the end user has to 
provide a /etc/group and /etc/passwd with at least the "guixbuild" group and
at least one member in that group as a composable image[maybe 1] in order
for guix-daemon to actually work.

Also, guix needs /etc/services for http and https and so on to resolve.

Or you could just add those to the main guix docker image--but I think that
would be kinda weird (even though I'm doing it for mine--but it has a kind
of narrow use case where this is fine for the time being).

Or provide the host /etc/passwd using the "-v" command line option (that
would be kinda weird, too).

Or expect the user to always create a dockerfile and use "FROM" to derive
from the offical image.

[1] https://docs.docker.com/compose/compose-file/compose-file-v2/


pgpVEgIHkrtuM.pgp
Description: OpenPGP digital signature

Re: ‘version-1.2.0’ branch created!

[Julien Lepiller]

Le 6 novembre 2020 07:51:30 GMT-05:00, zimoun  a 
écrit :
>Hi,
>
>On Fri, 06 Nov 2020 at 11:15, Ludovic Courtès  wrote:
>
>> We have a new branch now!
>
>Awesome!
>
>
>> This branch should take primarily important changes that fix the
>> installer or other key elements.  It should not change translatable
>> strings and should not change the manual either, unless a fix
>requires
>> it, because translations are being finalized.
>
>We are in string freeze.  Translators, is it fine for you?

We'll need some time to adjust the translation for the release. I've sent the 
new strings to the TP coordinator yesterday, but they're not on the TP yet.

>
>
>> It may be OK to merge “obvious” changes from ‘master’, such as the
>> addition or upgrade of leaf packages.  Changes that would lead to
>> rebuilds of key packages (everything the installer needs plus GNOME,
>> Emacs, IceCat, etc.) should be avoided I think.
>
>Agree.
>
>
>> Thoughts?  Patches?  Ideas?  :-)
>
>A lot of substitutes are still missing (for example R).  Is it possible
>to trigger the builds?
>
>
>All the best,
>simon

Flagging gexps that import (guix config) & co.

[Ludovic Courtès]

Hello Guix!

Yesterday I noticed that some of our system tests would be
non-deterministic in the sense that their .drv file name would differ
from machine to machine.  The .drv computed at ci.guix.gnu.org for a
given test was different from that I had on my machine.

This is not the first time we see it: it was due to services or tests
importing the host’s (guix config) module or (ice-9 …) modules on the
build side.  Since those modules can vary between users, importing them
leads to discrepancies like that.

(guix gexp) now emits a warning when these modules are imported:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ca465a9c8454289b7aded22719cd5d919e441780

I thought it shouldn’t be an error because it’s a matter of policy.
It looks like this:

  gnu/services/monitoring.scm:398:4: warning: importing module (ice-9 rdelim) 
from the host

where the line and column indicate the start of the gexp importing the
module(s).

Having done that, I fixed a few services and tests.  Now one can again run:

  ./pre-inst-env guix weather -m etc/system-tests.scm --display-missing

to quickly see what fraction of the system tests is successful on
ci.guix.gnu.org.

Ludo’.

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[zimoun]

Hi,

On Thu, 05 Nov 2020 at 17:59, Luis Felipe  wrote:

Therefore, it is nice improvement! :-)

> real  0m56,245s
> user  0m4,324s
> sys   0m0,218s

> real  0m43,272s
> user  0m4,214s
> sys   0m0,200s

Because, I bet that most of the time is spent in the “time-machine”
part.  I mean, compare with:

 time guix time-machine --commit=$new -- help


All the best,
simon

Re: ‘version-1.2.0’ branch created!

[zimoun]

Hi,

On Fri, 06 Nov 2020 at 11:15, Ludovic Courtès  wrote:

> We have a new branch now!

Awesome!


> This branch should take primarily important changes that fix the
> installer or other key elements.  It should not change translatable
> strings and should not change the manual either, unless a fix requires
> it, because translations are being finalized.

We are in string freeze.  Translators, is it fine for you?


> It may be OK to merge “obvious” changes from ‘master’, such as the
> addition or upgrade of leaf packages.  Changes that would lead to
> rebuilds of key packages (everything the installer needs plus GNOME,
> Emacs, IceCat, etc.) should be avoided I think.

Agree.


> Thoughts?  Patches?  Ideas?  :-)

A lot of substitutes are still missing (for example R).  Is it possible
to trigger the builds?


All the best,
simon

Re: Guide! Help! Using guix, or GNU/Linux, for secrecy, privacy.

[Aniket Patil]

Hi zimoun,

Yes, you wrote it on your blog.
http://zimoun.github.io/about/
Read first reference.

Also, unplugging from everything is not an option. I feel so. I will think
about it.

For hardware isn’t running X200 with libreboot as BIOS enough, with
trisquel on top of that or any other free distro?


Thanks for help.

Aniket.

On Fri, 6 Nov 2020 at 6:07 PM, zimoun  wrote:

> Hi,
>
> On Thu, 05 Nov 2020 at 20:14, Aniket Patil 
> wrote:
>
> > reliable either. Recently, I read zimouns vlog
> >
> > " right, Google is evil, but the storage and the search features are
> really
> > useful. So, I am thinking to switch to notmuch  >,
> > but not enough time to configure it, yet. "
>
> Is me that wrote this?  Where?  And when?
>
>
> > So, is notmuch is reliable?
> >
> > I get paranoid after reading RMS, or Snowden. I think a lot about my
> > privacy and others as well. Hence I am asking this, and participating in
> > GNU projects and Free Software Projects. So coming to the point.
> >
> > How to or which email client shall I use or email service?
> >
> > Recently I was browsing on TOR but I guess even TOR exposes my IP address
> > on internet. So shall I use it with VPN? If So which VPN? I know about
> > WireGuard but it has GPL2 license not GPL3.
> >
> > What else can I do to secure myself?
>
> Really opinionated reply; Friday’s troll! ;-)
>
>
> I am not sure to understand the question: against what you want to be
> secure.
>
> As you see, I am still using Gmail.  Most of the time, I compose emails
> using Emacs.  Sometimes, I reply using their web interface.  Most of the
> time, I read and search emails via Notmuch (+Emacs frontend), and
> sometimes via the web interface.  Whatever.
>
> I try to replace the web interface facilities.  However my emails are
> still stored on the Google infrastructure.  And somehow, 50% of all our
> emails are stored by Google.  (This one is! because of your and my gmail
> addresses.)
>
>
> https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours
>
> And even, it is a public mailing list, therefore data are on the Google
> infrastructure.  And even if it is not a public mailing list but an
> encrypted email, then it is almost sure that Google will get the
> metadata around––which are clear.  Snowden explains clearly that:
> metadata is one of the key.
>
> Replace Google by whatever is scaring.
>
> If you use another email service, you have to trust this service.  For
> example, I have a Proton email account but I have no proof that they are
> really doing what they claim to do; since all their code is not “open“.
> And even the code would be “open“, I have no proof that the binary they
> run corresponds to the code.  Well, the only way is to run your own
> service.  But even with that, you are not protected against the 2
> previous collects.
>
> About privacy, the emails are doomed.  Period.
>
> And I am not speaking about how to trust the binaries we use.  For
> example, Pandoc is not secure since the Haskell compiler GHC is not
> bootstrappable.  Another example is the Nyxt webbrowser because of the
> Common Lisp SBCL reproducibility issue.  Emacs is not reproducible
> neither.  Zillions of other example are around… I am not talking about
> how to trust the binaries running TOR or VPN or whatever service.  And
> last, how to trust the hardware?
>
> Well, the question you have to answer first is: against what you want to
> protect.
>
> If you are paranoid, then you should be unplugged.  Else, you have to
> first define what is your personal policy and what is the one of the
> people you interact with.
>
>
> Hope that helps,
> simon
>
> ps:
> As Joshua wrote, these questions are better on help-g...@gnu.org. :-)
>

Re: Releasing guix binary in Docker format too?

[zimoun]

Hi,

On Fri, 06 Nov 2020 at 10:59, Ludovic Courtès  wrote:

>  guix pack guix -f docker -S /bin=bin \
>--entry-point="bin/guix-daemon --disable-chroot"
>
> might work, right?
>
> Someone needs to try because the devil is in the details.

I will try to give a try.  If someone does not beat me.


> To me there are still important unknowns regarding an official Docker
> image (how to build it, how to upload it), so I’m not confident about
> getting that done in time for 1.2, but progress on that front is welcome
> anytime!

I am proposing to add an experimental box to:

  https://guix.gnu.org/en/download/latest/

Docker image with maybe a link to Cookbook (or elsewhere).  It is the
best way to have feedback. :-)

Yeah, you are right, it is premature to communicate via the release v1.2
without more tests.


All the best,
simon

Re: Guide! Help! Using guix, or GNU/Linux, for secrecy, privacy.

[zimoun]

Hi,

On Thu, 05 Nov 2020 at 20:14, Aniket Patil  wrote:

> reliable either. Recently, I read zimouns vlog
>
> " right, Google is evil, but the storage and the search features are really
> useful. So, I am thinking to switch to notmuch ,
> but not enough time to configure it, yet. "

Is me that wrote this?  Where?  And when?


> So, is notmuch is reliable?
>
> I get paranoid after reading RMS, or Snowden. I think a lot about my
> privacy and others as well. Hence I am asking this, and participating in
> GNU projects and Free Software Projects. So coming to the point.
>
> How to or which email client shall I use or email service?
>
> Recently I was browsing on TOR but I guess even TOR exposes my IP address
> on internet. So shall I use it with VPN? If So which VPN? I know about
> WireGuard but it has GPL2 license not GPL3.
>
> What else can I do to secure myself?

Really opinionated reply; Friday’s troll! ;-)


I am not sure to understand the question: against what you want to be
secure.

As you see, I am still using Gmail.  Most of the time, I compose emails
using Emacs.  Sometimes, I reply using their web interface.  Most of the
time, I read and search emails via Notmuch (+Emacs frontend), and
sometimes via the web interface.  Whatever.

I try to replace the web interface facilities.  However my emails are
still stored on the Google infrastructure.  And somehow, 50% of all our
emails are stored by Google.  (This one is! because of your and my gmail
addresses.)

https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours

And even, it is a public mailing list, therefore data are on the Google
infrastructure.  And even if it is not a public mailing list but an
encrypted email, then it is almost sure that Google will get the
metadata around––which are clear.  Snowden explains clearly that:
metadata is one of the key.

Replace Google by whatever is scaring.

If you use another email service, you have to trust this service.  For
example, I have a Proton email account but I have no proof that they are
really doing what they claim to do; since all their code is not “open“.
And even the code would be “open“, I have no proof that the binary they
run corresponds to the code.  Well, the only way is to run your own
service.  But even with that, you are not protected against the 2
previous collects.

About privacy, the emails are doomed.  Period.

And I am not speaking about how to trust the binaries we use.  For
example, Pandoc is not secure since the Haskell compiler GHC is not
bootstrappable.  Another example is the Nyxt webbrowser because of the
Common Lisp SBCL reproducibility issue.  Emacs is not reproducible
neither.  Zillions of other example are around… I am not talking about
how to trust the binaries running TOR or VPN or whatever service.  And
last, how to trust the hardware?

Well, the question you have to answer first is: against what you want to
protect.

If you are paranoid, then you should be unplugged.  Else, you have to
first define what is your personal policy and what is the one of the
people you interact with.


Hope that helps,
simon

ps:
As Joshua wrote, these questions are better on help-g...@gnu.org. :-)

[Outreachy] Thank you & decision in progress

[zimoun]

Dear,

Thank you for your application to the project: « Add a subcommand
showing GNU Guix history of all packages ».  During this period, we hope
the community have been welcoming enough to make you want to contribute
again to Free Software, here with Guix or elsewhere.

You are 3 applicants and we are happy about your contributions.
However, we have only one funding and we are sad because we have to
choose one of you.  And it is hard.

It is not a personal judgment on you.  A refusal should rather be
interpreted as “let’s try to work together later with the next round”.

Currently, we ––Gábor, Ludo, Ricardo and me–– have internal discussions
and are trying to make a grounded decision on the interaction we had
with you.  Not only technical skill matters.

I speak for myself and as future mentor, my criteria are: What am *I*
able to bring to you based on your current skills?  How could *I* help
you to progress?

As I said, the decision is hard.

All the best,
simon

‘version-1.2.0’ branch created!

[Ludovic Courtès]

Hi Guix!

We have a new branch now!

This branch should take primarily important changes that fix the
installer or other key elements.  It should not change translatable
strings and should not change the manual either, unless a fix requires
it, because translations are being finalized.

It may be OK to merge “obvious” changes from ‘master’, such as the
addition or upgrade of leaf packages.  Changes that would lead to
rebuilds of key packages (everything the installer needs plus GNOME,
Emacs, IceCat, etc.) should be avoided I think.

Changes to core Guix should be limited to bug fixes as well.

Thoughts?  Patches?  Ideas?  :-)

Ludo’.

Re: “guix pack -RR r“ fails?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> The usual ‘./bin/R’ fails with:
>
> $ ./bin/R
> : unsupported Guix execution engine; ignoring

‘GUIX_EXECUTION_ENGINE’ is set to the empty string.

> ./bin/R
> R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
>
> [...]
>
>  *** caught segfault ***
> address 0x7f44f4b11008, cause 'memory not mapped'

[...]

> 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':

Can you try ‘strace -f -s 500 -o log ./bin/R’ and send the tail of the
‘log’ file?

> The cluster machine is an old kernel:
>
> HEAD$ uname -a
> Linux HEAD 2.6.32-573.8.1.el6.x86_64 #1 SMP Tue Nov 10 18:01:38 UTC 2015 
> x86_64 x86_64 x86_64 GNU/Linux

Our libc is built with ‘--enable-kernel=3.2.0’ so it’s not clear whether
this can work at all (this ‘2.6’ kernel certainly contains stuff
backported from 3.x though, who knows.)

HTH,
Ludo’.

Re: Releasing guix binary in Docker format too?

[Ludovic Courtès]

Hi!

Danny Milosavljevic  skribis:

> 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.

OK so this:

 guix pack guix -f docker -S /bin=bin \
   --entry-point="bin/guix-daemon --disable-chroot"

might work, right?

Someone needs to try because the devil is in the details.

To me there are still important unknowns regarding an official Docker
image (how to build it, how to upload it), so I’m not confident about
getting that done in time for 1.2, but progress on that front is welcome
anytime!

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hello!

Peng Mei Yu  skribis:

> 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.

Just so you know: we’re aware of this problem and agree that it needs
solving.  Ricardo (Cc’d) has helped in the past set up rsync on
ci.guix.gnu.org so that someone could rsync /var/cache/guix/publish to a
server in China.  I think we have most of the pieces more or less in
place.

> Then a mirror site can simply pull the directory
> /var/cache/guix/publish/nar from the Berlin server and serve this
> directory through a static HTTP server.  There will be cache misses.
> But guix-daemon will safely fallback to the next server in
> substitute-urls.

The simplest solution for now (I think that’s what Ricardo & co. had in
mind) would be for you to retrieve /var/cache/guix/publish on your
server, as is, and then run ‘guix publish’ on your sever: it will know
where to find files.  As I wrote to Jonathan, you can/should also run
nginx on top of that as a proxy to your local ‘guix publish’.

Ricardo, can you remind us what the next steps would be?

Does that make sense?

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hi,

Jonathan Brielmaier  skribis:

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

This is suboptimal because then your /nar responses lack the
‘Content-Length’ header (‘guix publish’ cannot provide that header when
running without ‘--cache’), which in turn means no progress bar, no
estimate of the amount of data downloaded, etc.

> 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.

‘guix publish --cache’ should bring you the same benefits.  I’d still
recommend having nginx in front of it (for HTTPS, etc.), but caching can
be disabled in nginx in that case.  That’s what we do on
ci.guix.gnu.org.

Ludo’.

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

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> "guix environment --container" is a very useful feature for me to
> isolate the untrusted software. But sadly it lacks a interface for user
> to use it in Lisp programming.

The interface to containers is in (gnu build linux-container), though
it’s a bit lower-level compared to what ‘guix environment’ does.

See also the example at
,
which is precisely about your use case.

Thanks,
Ludo’.

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Ludovic Courtès]

Hello,

zimoun  skribis:

>> So it would seem we cannot simply used the pre-built database from
>> ‘shared-mime-info’ and merge it with that of the other packages, at
>> least not without changing ‘update-mime-database’ or re-implementing
>> parts of it on our side.
>
> ’shared-mime-info’ is simply a package, right?  So what does it means:
> «Find a way to avoid reprocessing 'shared-mime-info'» in:
>
>  ;; the database.  TODO: Find a way to avoid reprocessing
>  ;; 'shared-mime-info', which is the most expensive one.
> [...]
>  (invoke #+(file-append shared-mime-info
> "/bin/update-mime-database")
>  destdir)))

‘shared-mime-info’ contains ‘share/mime/freedesktop.org.xml’, which is
by far where ‘update-mime-database’ spends most of its time.

But it’s wasteful because ‘shared-mime-info’ already contains the result
of running ‘update-mime-database’ on itself.

HTH!

Ludo’.

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Ludovic Courtès]

Hi,

Luis Felipe  skribis:

> ‐‐‐ Original Message ‐‐‐
> On Tuesday, November 3, 2020 11:32 PM, zimoun  
> wrote:
>
>> Hi,
>>
>> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=76ea70bd70aeb76570445c11cea2f98139192b54
>>
>> Clever workaround! What are now the performances on previous examples
>> (same profiles and same packages)?
>
> In my case there seem to be no improvement (using Guix 
> 5e7cf66fb35780f930ad0bc5fe21ac330df4411d).

Please note that the change above addresses only one specific source of
slowness, the ‘xdg-mime-database’ hook, and only in specific cases.

It’s good to look at the overall timing of ‘guix install’, because
that’s what matters in the end, but as we work on optimizing it, we have
to look at specific aspects of it.

> $ time guix package -i perl --max-jobs=1

[...]

> injertando 12 paquetes en 
> /gnu/store/anknpdyhmfirw3rz2k9zm9kiyak8yy1s-cups-filters-1.27.4.drv ...
> construyendo la base de datos MIME XDG...
> injertando 3 paquetes en 
> /gnu/store/xgny7xbl635g8na8x03x4cdr7abiphiw-cups-2.3.3.drv ...
> injertando 20 paquetes en 
> /gnu/store/yhjl68x7kcjbv40v823x4hl8rvv8l50b-gtk+-2.24.32.drv ...
> injertando 21 paquetes en 
> /gnu/store/kq37fnw8335f1hqc3j4hhqqcdnhl371p-gtk+-3.24.20.drv ...
> creando la caché de temas de iconos de GTK+...
> construyendo los ficheros de caché para los métodos de entrada de GTK+...
> construyendo perfil con 86 paquetes...
>
>
> real  8m38,121s
> user  0m2,742s
> sys   0m0,338s

Here it’s likely that grafting is what’s taking the most time on a
spinning disk.

We should hack (guix status) so it can optionally prefix each event with
a timestamp.

As far as ‘xdg-mime-database’ is concerned, it should be down to 0s,
unless your profile contains one of the packages I cited (libreoffice,
gcr, hugin, etc.).

Thanks,
Ludo’.

Re: RFC: subcommand to pause/resume builds

[Ludovic Courtès]

Hi,

John Soo  skribis:

> After even further investigation,
>
> Does guix processes output the desired rec format? It seems hard to
> select the child process pid:
>
> ChildProcess: 16923: guile --no-auto-compile -L 
> /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import 
> /gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder
> ChildProcess: 31859: 
> /gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
> /gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
>  substitute --query
> ChildProcess: 31869: 
> /gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
> /gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
>  offload x86_64-linux 0 1 0
>
> After perusing info recutils some, I expected the output to be more
> like:
>
> ChildProcessPID: 16923
> ChildProcessCommand: guile --no-auto-compile -L 
> /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import 
> /gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder

Yes, that would be nicer.

However, note that if you fiddle with child processes, your warranty is
void!  :-)

You’d be interfering with build processes, thus potentially changing
their result in an uncontrolled way.

Ludo’.

Re: RFC: subcommand to pause/resume builds

[Ludovic Courtès]

Hi,

John Soo  skribis:

> This feels close to little sed/awk pipelines.  Which is not to be
> entirely dismissive. I like the compositionality of these tools.  In
> fact I mentioned earlier that it might be good to send arbitrary
> signals. But why not let kill (shell or scheme) do that?  All we would
> need is to filter and format pids in a composable way (on the scheme
> side and the shell side). That has the benefits of remaining agnostic on
> side effects in builds (let the user decide what they are comfortable
> with) and being more composable.
>
> Maybe flags like this would be enough:
>
> guix processes --session= ...
>
> to get something like
>
> 
> 1212
> 343434
> ...

You can filter by piping ‘guix processes’ output through ‘recsel’:

--8<---cut here---start->8---
$ sudo guix processes | recsel -p SessionPID,LockHeld -e 'LockHeld ~ "chromium"'
SessionPID: 31410
LockHeld: 
/gnu/store/kdsp1pjj6znaxzs3d0vfwdcddc436g7f-ungoogled-chromium-86.0.4240.183-0.b68e17f.lock

SessionPID: 3455
LockHeld: 
/gnu/store/bhy3c5damrpzx7hdp8bam1lk2rk7789r-ungoogled-chromium-86.0.4240.183-0.b68e17f.lock
--8<---cut here---end--->8---

HTH,
Ludo’.

Re: wip-node-14 branch

[Ludovic Courtès]

Hi!

Jelle Licht  skribis:

> First things first: most of the hard work has been done by others. I'd
> like to specifically thank Timothy Sample for their
> `other-node-build-system' and Ryan Prior for getting `esbuild' packaged
> and telling me about it. A shout out goes to Giacomo Leidi for making me
> grumpy enough with the existing node-build-system to finally sit down
> and fix this. I added Timothy as a Co-author on the first commit, so I
> hope that is Good Enough for the copyright situation.

Woow, well done!

> As a small extra, I have also worked on getting Timothy Sample's
> 'binary' npm importer to work with the contemporary guix import and
> guile-json APIs; I'd like some insight into whether this binary importer
> could still hold some value for inclusion in guix proper[3]. I could
> still add this code to the branch as well if there is interest.

I think it would make sense to include this importer.  The manual should
warn about the fact that it does not yield built-from-source packages
and perhaps give pointers on how to address that, but it can still be
useful, and probably even more useful if it’s in Guix proper.

Thoughts?

> I won't be able to commit significant chunks of time on my end in the
> upcoming month, but I've learned that it makes sense to share once you
> have something worth sharing, instead of when you think it's
> done. Reviews, tests and improvements very much welcome! I don't think
> it makes sense to still target the upcoming release for all of this fun
> stuff to be merged into master, but if somebody want to pick up the
> slack and champion that cause; go right ahead!

I think the key is to avoid bitrot: I suggest working to make sure you
can have that branch merged within, say, one or two months at most, even
if that means regularly pinging people.  :-)

Thanks!

Ludo’.

Re: Guide! Help! Using guix, or GNU/Linux, for secrecy, privacy.

[Pierre Neidhardt]

Hi!

I don't understand why using a VPN would help with regard to privacy.
Tor should be doing the job here.  A VPN, as I understand it, only
forwards the privacy issue to a third-party (usually untrustworthy)
entity, the VPN service.

> You'll browsing speed probably won't support playing internet videos
> though.

Here you could use youtube-dl over Tor.  

~/.config/youtube-dl/config:

--8<---cut here---start->8---
--proxy socks5://127.0.0.1:9050
--8<---cut here---end--->8---

It takes time but then you can watch most videos offline afterwards.
Beside saving bandwidth and increasing your independance, that's a cool
feature on its own!

Emails leak metadata (like the people you talk to), regardless of
encryption.

We really need a replacement for emails... Anyone? :p

About Notmuch: to clarify, it's just the interface, not the hosting.
It's super cool, maybe the "easiest" to setup among Emacs clients (it's
still a bit involved), and I have my setup outlined here:

https://gitlab.com/ambrevar/dotfiles

> How to or which email client shall I use or email service?

Beside Protonmail, Riseup and dismail.de, I've also heard of Fastmail
and Mailo.  Pick the option that fits you best!

Another option is to buy a domain name at a service like Gandi:
https://www.gandi.net/.  They offer free mail hosting for their
subscribers.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature