New French 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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/fr.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: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Danny Milosavljevic]

Hello everyone,

On Thu, 29 Oct 2020 21:55:10 +0530
Aniket Patil  wrote:

>If we build a GUI frontend then we can attract more
> people who don't identify themselves with CLI users. As such there are many
> people like writers, Graphic Designers, General users, etc. who don't
> bother about CLI, will love to see such a package manager.  And considering
> the fact GUIX lets rollback to the previous version of the package it will
> be very helpful in the scientific community, to maintain and work with
> different versions of packages.

I've got one at https://gitlab.com/daym/guix-gui/ .

As of commit 978f7d92b4486829fd4f5030baf2d42c001b0890 (current master),
guix-gui works well enough that you can see the current profile, you have
(slow) tooltips, you can type to search, you can view the previous generation,
and you can get a list of all installable packages in Guix.

Not much more works yet because I've hit this (design) bug in Guix and/or GNOME:

* https://github.com/spk121/guile-gi/issues/96

I hadn't noticed before just how bad a match Guix's private dependencies (which
I think are a good thing) and GNOME's object system is (see link above).

> P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
> doesn't. If I am mistaken please enlighten me on this topic.

It does kinda exist--but working on GUIs in Guile is like pulling teeth.

I'm used to seamless integration like PyGTK is in Python--PyGTK feels
EXACTLY like a native Python library.  You can't tell that it's implemented
in C at all.

The way it is in Guile is not seamless.  Furthermore, there are fundamental
problems in how the package "gobject-introspection" is designed (see link
above)--so I can't see how this can be resilient or consistent at all.

(Also, I've used Delphi before--that's basically the holy grail of GUI
development.  That doesn't help making me less grumpy using this contraption
string-and-duct-tape barely-holding-together contraption instead)

In any case, with all the involuntary yak-shaving I have to do it's gonna
take a while.

Or I could just use Gtk in C and use popen("guix ...").


pgpSoL0oVDO2w.pgp
Description: OpenPGP digital signature

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[zimoun]

Hi,

On Thu, 29 Oct 2020 at 21:55, Aniket Patil  wrote:

> P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
> doesn't. If I am mistaken please enlighten me on this topic.

For sure, a GUI front-end will be nice.  Today, the most GUI-like is
provided by the package ’emacs-guix’, and as the name indicates, it
uses… Emacs.  Well for the worst and the better. :-)

Recently, we discussed with Pierre and Mathieu about this.  And even if
some GTK front-end would be nice to have, from my point of view, the
good direction would be a “web-app frontend”, similarly to
git-annex-assistant [1].  This design is more flexible because it could
be used locally *and* could also be the front-end of some servers (e.g.,
build farms).

For example, let imagine that one user is running Guix on their own
machine and they locally generates a Docker image (guix pack -f docker)
via the front-end.  Another user who does not run Guix on their own
machine (but instead some Apple product), they could go to the front-end
served by one shared machine and so click, generates the Docker image
and get back one link usable by “docker pull“ or whatever.

The same code could run the 2 use cases.  Well, command by command,
these are sharable between the 2 use cases: describe, search, show,
time-machine, weather, part of system and package and pack; at least for
a start.

1: 


Just my opinion if I would be starting a GUI front-end. :-)

All the best,
simon

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[jbranso]

Can you link us to any code?  Or is it a bit too premature?

October 29, 2020 2:38 PM, "Pierre Neidhardt"  wrote:

> Hi!
> 
> As part of the NLNet grant, I am planning on working on a (probably GTK
> based) GUI for Guix.
> 
> The bad news: I had to put the grant on the side for the better part of
> the year due to lack of time.
> 
> The good news: I recently got the opportunity to work on the internals
> of the GUI. Most of the work that remains to be done is to plug it to a
> GTK interface in Guile, possibly using guile-gi or g-golf.
> 
> Stay tuned, more is coming, hopefully soon :)
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Pierre Neidhardt]

Hi!

As part of the NLNet grant, I am planning on working on a (probably GTK
based) GUI for Guix.

The bad news: I had to put the grant on the side for the better part of
the year due to lack of time.

The good news: I recently got the opportunity to work on the internals
of the GUI.  Most of the work that remains to be done is to plug it to a
GTK interface in Guile, possibly using guile-gi or g-golf.

Stay tuned, more is coming, hopefully soon :)

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


signature.asc
Description: PGP signature

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[jbranso]

There is an Emacs interface in install Guix packages, but at present there is 
not a working GUI for installing packages with guix. :(

I think there may have been a web interface to install packages at some point? 
maybe?

For those interested in creating such a GUI, they might like to look at 
guile-gi, which will eventually let you build GUIs from guile code.

Thanks,

Joshua
https://gnucode.me

October 29, 2020 12:44 PM, "Aniket Patil" mailto:aniket112.pa...@gmail.com?to=%22Aniket%20Patil%22%20)>
 wrote:
Hi all,
I am a researcher in the field of AI. Many of the people in the field of AI are 
inclining towards GNU/Linux operating systems. Particularly I would say they 
use Ubuntu. In general, they can also use LinuxMint or any other GNU/Linux 
distro of their choice. What I noticed in these people (researchers) they tend 
to be more focused on mathematical aspects and scientific programming. If we 
build a GUI frontend then we can attract more people who don't identify 
themselves with CLI users. As such there are many people like writers, Graphic 
Designers, General users, etc. who don't bother about CLI, will love to see 
such a package manager. And considering the fact GUIX lets rollback to the 
previous version of the package it will be very helpful in the scientific 
community, to maintain and work with different versions of packages. 
For example, the LAMBDA ( consist of TensorFlow, PyTorch, Keras, NVIDIA Cuda, 
Ubuntu) stack is very popular in the field of AI. Now if a person with a fresh 
install of GNU/Linux wants to install the stack and work immediately, through 
GUI he can search for the recipe of LAMBDA and install it. Not only that if it 
doesn't exist, but they can also create and share their own recipe with other 
guix users or to the main server/repo. E.g Linus Torvalds shares the recipe of 
building a Linux kernel environment. User finds it, installs it, and start 
working on the development of the Linux kernel immediately. 
P.S: I don't know whether GUI for Guix exists or not, to my knowledge it 
doesn't. If I am mistaken please enlighten me on this topic. 
Regards, 
Aniket.

Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Aniket Patil]

Hi all,

I am a researcher in the field of AI. Many of the people in the field of AI
are inclining towards GNU/Linux operating systems. Particularly I would say
they use Ubuntu. In general, they can also use LinuxMint or any other
GNU/Linux distro of their choice. What I noticed in these people
(researchers) they tend to be more focused on mathematical aspects and
scientific programming. If we build a GUI frontend then we can attract more
people who don't identify themselves with CLI users. As such there are many
people like writers, Graphic Designers, General users, etc. who don't
bother about CLI, will love to see such a package manager.  And considering
the fact GUIX lets rollback to the previous version of the package it will
be very helpful in the scientific community, to maintain and work with
different versions of packages.

For example, the LAMBDA ( consist of TensorFlow, PyTorch, Keras, NVIDIA
Cuda, Ubuntu) stack is very popular in the field of AI. Now if a person
with a fresh install of GNU/Linux wants to install the stack and work
immediately, through GUI he can search for the recipe of LAMBDA and install
it. Not only that if it doesn't exist, but they can also create and share
their own recipe with other guix users or to the main server/repo. E.g
Linus Torvalds shares the recipe of building a Linux kernel environment.
User finds it, installs it, and start working on the development of the
Linux kernel immediately.

P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
doesn't. If I am mistaken please enlighten me on this topic.

Regards,
Aniket.

Re: Outreachy contribution & guidance with guile.

[Aniket Patil]

Yes, Arun will let you know.

Also, I was wondering how shall I write Indic languages, heard of ibus, I
was wondering is there anything else which I can use to type in Indian
languages?

Aniket.

On Thu, 29 Oct 2020 at 10:03, Arun Isaac  wrote:

>
> >> I am thinking about translating guix or gnu docs in Indian languages,
> >> which I know.
> >
> > Several people on this list are involved in translation, and Arun Isaac
> > took care of the Tamil translation of the Shepherd, so surely you can
> > get guidance on this from people here.
>
> Yes, I'd be happy to help. I am proficient only in Tamil, but feel free
> to CC me on anything concerning translation to Indian languages.
>
> Cheers!
>

Re: Linux-Libre-LTS

[Leo Famulari]

On Thu, Oct 29, 2020 at 09:24:08AM +0100, Tobias Geerinckx-Rice wrote:
> Raghav!
> 
> Raghav Gururajan 写道：
> > I think it is good to have a package-variable "linux-libre-lts", as
> > mentioned in the table at https://jxself.org/linux-libre/
> 
> It is!  Would you like to try your hand at a patch?  It should be easy if
> unexciting work.  (If you want excitment you can suggest making it the
> default.)

Go for it!

> We should use upstream[0] release names, though, not roll our own (+less
> clear) ones.  So ‘-longterm’ instead of ‘-lts’.

+1


signature.asc
Description: PGP signature

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

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Wednesday, October 28, 2020 10:38 PM, zimoun  
wrote:

[...]

> Does it make sense?

It makes more sense now, thank you zimoun :)


> Well from my POV, the information is #44053 is enough for now. :-)

Ok.

New French 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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/fr.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: Linux-Libre-LTS

[Tobias Geerinckx-Rice]

Raghav!

Raghav Gururajan 写道：
I think it is good to have a package-variable "linux-libre-lts", 
as

mentioned in the table at https://jxself.org/linux-libre/


It is!  Would you like to try your hand at a patch?  It should be 
easy if unexciting work.  (If you want excitment you can suggest 
making it the default.)


We should use upstream[0] release names, though, not roll our own 
(+less clear) ones.  So ‘-longterm’ instead of ‘-lts’.


Kind regards,

T G-R

[0]: https://www.kernel.org/category/releases.html


signature.asc
Description: PGP signature

Re: Linux-Libre-LTS

[Efraim Flashner]

On Wed, Oct 28, 2020 at 11:32:08PM -0400, Raghav Gururajan wrote:
> Hello Guix!
> 
> I think it is good to have a package-variable "linux-libre-lts", as
> mentioned in the table at https://jxself.org/linux-libre/
> 
> This way, users don't have to remember and change the version numbers in
> their operating-system-configuration or package-manifest, whenever there is
> new LTS release.
> 
> Thoughts?
> 

I was waiting for the kernel code reorganization before adding it as a
variable. The trick is to add also linux-libre-lts-source and all the
others, and in a useful location. Now it's just taking the time to add
it in somewhere.

Do you want to take a stab at it? I'm not sure when I'll get around to
it.





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

Linux-Libre-LTS

[Raghav Gururajan]

Hello Guix!

I think it is good to have a package-variable "linux-libre-lts", as 
mentioned in the table at https://jxself.org/linux-libre/


This way, users don't have to remember and change the version numbers in 
their operating-system-configuration or package-manifest, whenever there 
is new LTS release.


Thoughts?

Regards,
RG.


OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature