Re: ‘version-1.2.0’ branch created!

[Oleg Pykhalov]

Hi,

Ludovic Courtès  writes:

[…]

> Changes to core Guix should be limited to bug fixes as well.
>
> Thoughts?  Patches?  Ideas?  :-)

Could we have a shepherd with 5082354a included (service: Add
#:supplementary-groups.)?  I could live with an overrided shepherd
package [1] which contains 5082354a as a patch, but still. ;-)

Also, I remember people ask for this change be merged recently.


[1]: (module-set! (resolve-module '(gnu packages admin)) 'shepherd 
shepherd-patched)

Thanks,
Oleg.


signature.asc
Description: PGP signature

Re: Fixing Zabbix db-secret-file documentation.

[Miguel Ángel Arruga Vivas]

Hi!

Tobias Geerinckx-Rice  writes:
> I've changed it to front-end just for consistency... for now ;-) and
> pushed to master as 83dee0e5b29dee75cffd5aa2a7748697eb73b036. If
> nobody objects I'll cherry-pick it to version-1.2.0 before the
> release.  That'll be the on-line manual for some time to come.

I have to raise my hand here, as TP.org hasn't updated their page yet,
or at least I haven't received the email yet, but the tarball was
already sent.  Perhaps we're lucky and the first mail may end in
/dev/null with no fuss if we send the update soon  Julien, WDYT?

Just for the record, I'm glad to translate that change or whatever comes
next, but it makes me a bit sad when that effort is reduced to a number,
because that "number" means making accessible the documentation to
people who don't speak English.  I understand what you meant, and I
agree about the change too; I just wanted to clarify that it isn't a
matter of boosting stats but working together.

Happy hacking!
Miguel


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Marius Bakke  writes:

> This is a friendly reminder to please list all changes to inputs,
> arguments etc in the commit message.  It makes resolving merge conflicts
> *much* easier.
>
> Due to SBCL changes on the 'staging' branch, there have been a few
> changes to the 'nyxt' inputs; and because the changes from 'master' are
> not mentioned in the commit messages, I need to manually look at each
> commit and note what has changed in order to resolve the conflict.
>
> (feel free to try merging c2396ceb onto 052939c2 to get an idea of what
> I'm talking about :-)

If you happen to be around right now, can you confirm that there were no
changes to nyxt inputs in 573489fbcd68e3a89cc5c9c66693d3689b1b88bf?


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Hello Pierre,

guix-comm...@gnu.org writes:

> commit 21e79225352a5e78aa329b6cd213eb553862c363
> Author: Pierre Neidhardt 
> AuthorDate: Tue Oct 20 15:06:59 2020 +0200
>
> gnu: nyxt: Update to 2-pre-release-3.
> 
> * gnu/packages/web-browsers.scm (nyxt): Update to 2-pre-release-3.
> ---
>  gnu/packages/web-browsers.scm | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

[...]

> @@ -482,7 +482,8 @@ driven and does not detract you from your daily work.")
> #:strip-binaries? #f ; Stripping breaks SBCL binaries.
> #:phases
> (modify-phases %standard-phases
> - (add-after 'unpack 'patch-version ; Version is guessed from .git 
> which Guix does not have.
> + ;; Version is guessed from .git which Guix does not have.
> + (add-after 'unpack 'patch-version
> (lambda* (#:key inputs #:allow-other-keys)
>   (let ((version (format #f "~a" ,version))
> (file "source/global.lisp"))
> @@ -515,7 +516,8 @@ driven and does not detract you from your daily work.")
> ":"))
>  (gi-path (string-join
>(map (lambda (lib)
> - (string-append (assoc-ref inputs lib) 
> "/lib/girepository-1.0"))
> + (string-append (assoc-ref inputs lib)
> +"/lib/girepository-1.0"))
> libs)
>":"))
>  (xdg-path (string-join
> @@ -540,6 +542,7 @@ driven and does not detract you from your daily work.")
>   ;; See https://github.com/atlas-engineer/nyxt/issues/680.
>   `(("alexandria" ,cl-alexandria)
> ("bordeaux-threads" ,cl-bordeaux-threads)
> +   ("cl-chanl" ,cl-chanl)
> ("cl-containers" ,cl-containers)
> ("cl-css" ,cl-css)
> ("cl-json" ,cl-json)
> @@ -555,7 +558,6 @@ driven and does not detract you from your daily work.")
> ("iolib" ,cl-iolib)
> ("local-time" ,cl-local-time)
> ("log4cl" ,cl-log4cl)
> -   ("lparallel" ,cl-lparallel)
> ("mk-string-metrics" ,cl-mk-string-metrics)
> ("moptilities" ,cl-moptilities)
> ("osicat" ,sbcl-osicat) ; SBCL version needed for 
> libosicat.so.
> @@ -571,6 +573,7 @@ driven and does not detract you from your daily work.")
> ("trivial-package-local-nicknames" 
> ,cl-trivial-package-local-nicknames)
> ("trivial-types" ,cl-trivial-types)
> ("unix-opts" ,cl-unix-opts)
> +   ("usocket" ,cl-usocket)
> ;; WebKitGTK deps
> ("cl-cffi-gtk" ,cl-cffi-gtk)
> ("cl-webkit" ,cl-webkit)

This is a friendly reminder to please list all changes to inputs,
arguments etc in the commit message.  It makes resolving merge conflicts
*much* easier.

Due to SBCL changes on the 'staging' branch, there have been a few
changes to the 'nyxt' inputs; and because the changes from 'master' are
not mentioned in the commit messages, I need to manually look at each
commit and note what has changed in order to resolve the conflict.

(feel free to try merging c2396ceb onto 052939c2 to get an idea of what
I'm talking about :-)


signature.asc
Description: PGP signature

Re: Anybody please help improving rust crates importer

[John Soo]

 Hello Hartmut, 

 
There is a patch set that has slightly bit rotted that does what you want.
It could use a little polish but any work on it would be appreciated:   
http://issues.guix.gnu.org/38408
 

 
Thanks for thinking about the rust ecosystem in guix!
 

 
- John
 

Anybody please help improving rust crates importer

[Hartmut Goebel]

Hi,

can anybody please help improving the crates importer? My guile skills
are far to poor and my time is to limited. Help is appreciated!

Why the crates importer needs to be improved

rust is still an young language and many rust packages (crates) still
have 0.x versions. Also crates use semantic versioning and describe
dependencies the same way. Thus, when importing or updating a package,
the packager has to validate *every* dependency manually.

To give you a number: When updating seqouia-pgp, one new dependency was
added, which introduced 151 dependencies - each of which need to be
checked and adopted *manually*.

How the crates importer needs to be improved

  *

Automatically add the semantic version base to the package's
variable name (e.g. rust-aaa-1, rust-aaa-0.7). This is stupid work,
currently to be done manually. Anyhow, this should be easy to implement.

  *

When creating the package sexp, refer to each dependency using its
semantic versioned variable name. This is stupid work, currently to
be done manually. Anyhow, this should be easy to implement, once the
next point is done.

  *

When looking up dependencies, follow the semantic version
requirement. Looking this up manually is the most elaborate, stupid
work - and it is demotivating.

  *

When checking whether a dependency is already packaged, take the
semantic version into account. This is another demotivating,
elaborate work, done by the computer much faster ans less error-prone.

Anybody taking up this job? I can provide more details, e.g. links, API
end-points, etc.

(Side-note: I'm not a rust developer, I'm just trying to make
sequoia-pgp and pEp available for guix.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Ludovic Courtès  ezt írta (időpont: 2020. szept. 16., Sze, 
> 15:25):
>>
>> Hi,
>>
>> Gábor Boskovits  skribis:
>>
>> > I have two reasons for that: backwards compatibility is really
>> > important, so we should not break it, and I believe this would not be
>> > hard to do.
>> > On the other hand it would be nice to have a more integrated backend,
>> > and move as many things into the services infrastructure as practical,
>> > and I think this is a good candidate for that. Wdyt?
>>
>> There’s already ‘setuid-program-service-type’.  I think the way forward
>> would be to:
>>
>>   1. Define the  record type you propose.
>>
>>   2. Have ‘setuid-program-service-type’ accept that through its
>>  extensions.  When it receives something else, it should
>>  transparently turn it into a  record, for backward
>>  compatibility, and emit a deprecation warning.
>>
>>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>>  records.
>>
>> How does that sound?
>
> Sounds good to me. I will have a look.
>
>>
>> Thanks,
>> Ludo’.
>
> Best regards,
> g_bor

Hi!  It's been a bit since progress has been made on this, and I wonder
if I can help?

Getting Postfix included in Guix is my last step before moving my main
servers from Debian -> Guix so I'm feeling motivated. ;)

Add emacs-source-reference for C code discoverablity.

[Zhu Zihao]

GNU Emacs can navigate and reference the source code of C function. But
the variable source-directory should be setup properly.

Current Emacs package discard C source code during the build. There's
serveral solution to add it.

1. Modify the emacs package definition, this trigger the rebuild of
all emacs-xyz, and increase the closure for who doesn't want the source
reference.

2. Like 1. But put the source to another output in emacs package. Still
trigger rebuild but doesn't increase closure size. 

3. Create a new package named emacs-source-reference to hold it. I think
this is the better way.

BTW, if we add source reference, what about also generate etags file for
them?

Please leave your comments on these ideas. Thanks a lot.
-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Re: Fixing Zabbix db-secret-file documentation.

[Tobias Geerinckx-Rice]

Oleg Pykhalov 写道：
front 
end

 ^
 front-end 
 as in
 other 
 places 
 of
 the 
 documentation


Thanks for pointing it out, I hadn't noticed!  The other places 
are mistaken, though.


‘Front-end’ is an adjective (‘a front-end component’), not a noun 
(‘the front end’).  Worse, it looks jarring.  Even GCC agrees[0] 
with me for once.


I've changed it to front-end just for consistency... for now ;-) 
and pushed to master as 83dee0e5b29dee75cffd5aa2a7748697eb73b036. 
If nobody objects I'll cherry-pick it to version-1.2.0 before the 
release.  That'll be the on-line manual for some time to come.


Thanks!

T G-R

[0]: http://gcc.gnu.org/codingconventions.html#Spelling


signature.asc
Description: PGP signature

Re: Fixing Zabbix db-secret-file documentation.

[Oleg Pykhalov]

Hi,

Tobias Geerinckx-Rice  writes:

[…]

>  @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.
 ^
 front-end as in
 other places of
 the documentation

Otherwise I agree with a change.  Thanks.


signature.asc
Description: PGP signature

Re: Japanese Input wont't without manually adding environmental variables?

[yasu]

Hi Leo,

Oh this looks like like exactly what I need!!

https://issues.guix.info/44354

Very much looking forward to this being picked up!!

Thank you so much!

-Yasu


On Sat, 2020-11-07 at 10:23 +0100, Leo Prikler wrote:
> Hello, yasu
> 
> I recently submitted #44354, which would set GUIX_GTK*_IM_MODULE_FILE
> from the system configuration.  Once this patch is merged, you should
> be able to add ibus and ibus-anthy to your operating-system packages
> and have them picked up from there by gnome.
> 
> Note, that this patch would as it is currently likely only set
> GUIX_GTK3_IM_MODULE_FILE, because the gnome package does not contain
> anything linked against gtk+-2.  If that is a concern, you can add an
> application that does to it.  Mine currently looks like this:
> 
> ```
>   (package
> (inherit gnome)
> (propagated-inputs
>  `(,@(package-propagated-inputs gnome)
>;; IBus
>("ibus" ,ibus)
>("ibus-anthy" ,ibus-anthy)
>;; World
>("dconf-editor" ,dconf-editor)
>("evolution" ,evolution)
>("evolution-data-server" ,evolution-data-server)
>("gitg" ,gitg)
>("gnome-tweaks" ,gnome-tweaks)
>("polari" ,polari)
>("seahorse" ,seahorse
> ```
> 
> [As you can see, just ibus and a few more Gnome packages, but none
> using Gtk+ 2.]
> 
> Best regards,
> Leo
> 

Re: Japanese Input wont't without manually adding environmental variables?

[宋文武]

yasu  writes:

> I see..., thank you anyway!
>
> I wonder if we can collect of this kind of usability tips in wiki-like
> systems somewhere so we don't have to keep digging google for
> information. 

Well, I don't know if a guix wiki existed, but we have Guix Cookbook:
, it's a info manual build from the guix
git repository, need to work on it more...

>
> I am very excited about Guix - I switched from Nix and I am not going
> back!

Me too, thank you!

Re: Japanese Input wont't without manually adding environmental variables?

[宋文武]

yasu  writes:

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

Yes, guix lack supports for input methods.

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

For these kind of environment variables, we usually set them in
'.guix-profile/etc/profile' via 'native-search-paths' of a package.

But adding 'GUIX_GTK3_IM_MODULE_FILE' to the 'native-search-paths' of
'gtk+' is not good enough or won't solve this issue as we usually don't
install 'gtk+' into the profile.  I'd like to find another way set them,
could be add some code to '(guix profiles)' with the 'gtk-im-modules'
profile hook.  Need more thinking... 


In the meantime, we have to set those environment variables manually..

Re: Japanese Input wont't without manually adding environmental variables?

[Leo Prikler]

Hello, yasu

I recently submitted #44354, which would set GUIX_GTK*_IM_MODULE_FILE
from the system configuration.  Once this patch is merged, you should
be able to add ibus and ibus-anthy to your operating-system packages
and have them picked up from there by gnome.

Note, that this patch would as it is currently likely only set
GUIX_GTK3_IM_MODULE_FILE, because the gnome package does not contain
anything linked against gtk+-2.  If that is a concern, you can add an
application that does to it.  Mine currently looks like this:

```
  (package
(inherit gnome)
(propagated-inputs
 `(,@(package-propagated-inputs gnome)
   ;; IBus
   ("ibus" ,ibus)
   ("ibus-anthy" ,ibus-anthy)
   ;; World
   ("dconf-editor" ,dconf-editor)
   ("evolution" ,evolution)
   ("evolution-data-server" ,evolution-data-server)
   ("gitg" ,gitg)
   ("gnome-tweaks" ,gnome-tweaks)
   ("polari" ,polari)
   ("seahorse" ,seahorse
```

[As you can see, just ibus and a few more Gnome packages, but none
using Gtk+ 2.]

Best regards,
Leo

Re: Japanese Input wont't without manually adding environmental variables?

[yasu]

I see..., thank you anyway!

I wonder if we can collect of this kind of usability tips in wiki-like
systems somewhere so we don't have to keep digging google for
information. 

I am very excited about Guix - I switched from Nix and I am not going
back!

-Yasu



On Sat, 2020-11-07 at 16:41 +0800, 宋文武 wrote:
> yasu  writes:
> 
> > 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? 
> 
> Yes, guix lack supports for input methods.
> 
> > 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" 
> > 
> 
> For these kind of environment variables, we usually set them in
> '.guix-profile/etc/profile' via 'native-search-paths' of a package.
> 
> But adding 'GUIX_GTK3_IM_MODULE_FILE' to the 'native-search-paths' of
> 'gtk+' is not good enough or won't solve this issue as we usually
> don't
> install 'gtk+' into the profile.  I'd like to find another way set
> them,
> could be add some code to '(guix profiles)' with the 'gtk-im-modules'
> profile hook.  Need more thinking... 
> 
> 
> In the meantime, we have to set those environment variables
> manually..