Re: Guix System video review on YouTube

[raingloom]

On Mon, 27 Apr 2020 12:11:05 +0200
Jonathan Brielmaier  wrote:

> $ echo "hello"
> hello
> $ guix install emacs
> 
> Then while installing emacs, try to reach the hello. It will be tricky
> as every new output line from `guix install emacs` will reset you to
> the bottom of your terminal. That's annoying.
> 

This is not related to the distribution, it's a terminal emulator
default. The behavior is the same in every other distribution I've used.
If they think this is a bad default, they should write on the
terminal emulator's bug tracker.

But then again, you usually want new (possibly quite important)
messages to catch the user's attention, so I'd say it's a good default.

Anyways, the option is trivial to change in the settings. You don't
even have to look too hard.

> So I would propose an interface like:
> $ guix search vim
> | Name  | Synopsis   | Version  | Outputs
> |
> +---++--+-+
> | vim   | Text editor based on vi| 8.2.0411 | out
> | | vim-airline   | ... [...]

Please don't, ASCII formatting always messes things up. Use the
terminal for text. If you want a more visual package manager, don't use
a CLI tool. A proper GUI will be more accessible.

As one example, ASCII formatting makes screen readers a lot harder to
use.

Re: Cookbook translations

[pelzflorian (Florian Pelz)]

On Tue, Apr 28, 2020 at 01:24:30AM +0200, Björn Höfling wrote:
> I wondered: do you know how the cookbook translations are organized?

I just replied to the bug
.

- Forwarded message from "pelzflorian (Florian Pelz)" 
 -

Date: Tue, 28 Apr 2020 01:36:40 +0200
From: "pelzflorian (Florian Pelz)" 
To: Björn Höfling 
Cc: 40...@debbugs.gnu.org, operator.n...@protonmail.com
Subject: Re: bug#40803: One page HTML cookbooks are 404

On Tue, Apr 28, 2020 at 01:01:03AM +0200, Björn Höfling wrote:
> BTW, the link to the translation project 404s too:
> 
> https://translationproject.org/domain/guix-cookbook.html

The cookbook is not available at the TP because no POT file is shipped
in Guix’ tarball.  Julien suggested moving the translation from the TP
infrastructure to a Weblate setup (which I agree Guix should try and
experiment with), so instead of waiting for inclusion of the cookbook
at the TP I just commited the German translation directly to Guix
master without going through the Translation Project.  (It is
important that the version at the TP is the most current version, but
since there is no cookbook at the TP, it does not matter currently.)

Regards,
Florian

- End forwarded message -

Cookbook translations

[Björn Höfling]

Hi,

while looking at this bug:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40803

I wondered: do you know how the cookbook translations are organized? I
see there is only one initial commit by Florian Pelz for the German
translation:

commit f98e83a17fa30587520e858231ec9c61f3624ecd
Author: Florian Pelz 
Date:   Mon Feb 17 07:35:26 2020 +0100

The cookbook itself:

https://guix.gnu.org/cookbook/en/html_node/

encourages one to use the translation project:

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

but that URL 404s.

On the Translation-Projects site:

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

I see projects for guix, guix-manual and guix-packages but not for the
guix-cookbook. Are there any plans to add the cookbook to the
Translation Project?

Thanks,

Björn


pgpwIS57PkDhC.pgp
Description: OpenPGP digital signature

Re: core-updates call for testing

[Jack Hill]

On Sat, 25 Apr 2020, sirgazil wrote:


 On Sat, 25 Apr 2020 21:19:26 + Jack Hill  wrote 

> Does GNOME-Web work for you? I'm wondering if others can reproduce the
> problem I'm seeing: https://issues.guix.gnu.org/40837

No it doesn't.


Hi all,

Unfortunately, I think I'm current stuck on fixing this bug. Any help of 
ideas would be appreciated.


Best,
Jack

Re: hint: Run `guix search ... | less' to view all the results

[Vagrant Cascadian]

On 2020-04-27, Jan Synacek wrote:
> While we're at it, let me also give my opinion about supporting PAGER. If
> it means that if PAGER is set, use it, otherwise don't page, then that's
> perfectly valid and, in my opinion, how PAGER support is supposed to
> work.

I don't think PAGER is an indicator of weather to paginate output, it's
a variable to allow the user to specify which pager they want to use
when the program chooses to output paginated output.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix System video review on YouTube

[Bengt Richter]

Hi zimoun, Jonathan,

On +2020-04-27 14:44:08 +0200, zimoun wrote:
> On Mon, 27 Apr 2020 at 12:11, Jonathan Brielmaier
>  wrote:
> 
> > >> * While installing packages via `guix install` you can't scroll in the
> > >> terminal, you always get reset to the bottom.
> > >
> > > I missed what it mean. Could you quickly extend a bit?
> >
> > $ echo "hello"
> > hello
> > $ guix install emacs
> >
> > Then while installing emacs, try to reach the hello. It will be tricky
> > as every new output line from `guix install emacs` will reset you to the
> > bottom of your terminal. That's annoying.
> 
> Does not it depend on the terminal emulator?
>
Yes, I think this is an example of how answering the question
"What code shall we modify/add to solve this usability annoyance?"
can affect system architecture, positively or negatively.

You could have guix fork the install into a thread that outputs to and scrolls
the uppper half of the screen, while wrapping your terminal cli so it keeps
to the bottom half, but I think that is a wrong solution.

OTOH there could be a --progress=... option so you could end the line with '&'
and continue your shell interaction. Simple options might direct output
to another tty or a file, with \r...line...\r lines stripped until \r?\n,
or pipe to whatever (could be a wayland client that makes a status line window 
on
top and filters the stream for interesting progress items to present -- if
that's available -- but guix doesn't need to know what's on the other end
of that optional progress report pipe, so it. KISS, avoid needing to know :)

Or with a terminal emulation app like tilix, it's easy to run several things
in split or overlaid terminal windows, doing whatever.

> 
> > >> * guix show/search does not show if a package is installed.
> > >
> > > Installed where? In which profile?
> > > I am not sure that "installed" make sense at the level of "guix 
> > > show/search".
> >
> > It definitely does. It could show packages installed to the profile,
> > such coming from the config.scm etc.
> 
> I am not using Guix System so I do not have config.scm.
> 
> Well, you propose that to loop over all the user profiles (i.e., "guix
> package --list-profiles) to check if it is installed in one of them,
> right?
> I am not convinced it is useful.
> Create a new profile and install what I need is cheap so I do not see
> why it could be useful to know if the package is already installed or
> not. If it is, nothing to be done; if not it is installed where I need
> it.
> However, what is useful is to know if the item already exist or not in
> the store, IMHO.
> 
> When "guix install vim", for example the package 'tcsh' goes in the
> store but is not considered "installed" by the profile say
> '~/.guix-profile'. Therefore, does "guix show tcsh" display
> 'installed' or 'not installed'?
> 
> Because of the profiles -- and I am even not talking about grafts -- I
> am not sure that "installed" make sense at the level of "guix
> show/search". ;-)
> There is too much corner cases, IMHO.
> 
> 
> > >> * `guix search ... | less can be confusing at the beginning.
> > >
> > > There is room of improvements for "guix search". ;-)
> > >
> > > There is 3 behaviours
> > >  1. return the N packages fitting the screen size (current: default)
> > >  2. display all the list in PAGER (current: |less)
> > >  3. display all the list in stdout (current: |cat)
> > >
> > > The feature request is: be able to configure which behaviour by
> > > default for "guix search". Maybe via an environment variable.
> > > (as discussed elsewhere by Ricardo and Tobias, if I understand correctly)
> > >
> > >
> > > WDYT?
> >
> > To be honest I would like the search to behave more like `guix package
> > -A`. Then we don't need this `less` thing. And we could add something
> > like `guix search --expanded` which behaves like the current search.
> 
> I agree.
> There is room of improvement about "guix search".
> 
> Some time ago, I also proposed to have something like: "--format"
> (inspired by "git log --format=")
> 
>guix search vim --format="%name %synopsis"
>guix search vim --format="%name \n %license \n"
>guix search crypto library --format=full
> etc.
>

For alternative formatting, I like the convention used by lsblk and ps
of specifying field/data names as -o,field,another,etc to select how and what
to display. I'd guess there's some FLOSS code in lsblk that could be re-used by 
guix.

> It should be also used by "guix show" and we could even imagine by
> "guix package -A".
> 
> Well, as one said: patches welcome. :-)
> 
> 
> 
> > $ zypper search vim | wc -l
> > 84
> > $ guix package -A vim | wc -l
> > 22
> > $ guix search vim | less
> > 828 lines and you have to search again in less because you are overwhelmed
> 
> I do not know 'zypper', only 'aptitude' of Debian. :-)
> 
> And there is a big difference between "guix search" and such tools:
> the relevance scoring.
> Well, "guix search" does not sort alphanumerically by name but 

Re: hint: Run `guix search ... | less' to view all the results

[Vincent Legoll]

Hello,

On Mon, Apr 27, 2020 at 1:59 PM  wrote:
> imo the best option would be to page, print or truncate depending on
> an envvar and/or a commandline flag

PAGER="head -20" maybe ?

I'm also of the opinion to respect PAGER. Untruncated ouput if unset.

-- 
Vincent Legoll

Re: package requests

[Catonano]

Il giorno lun 27 apr 2020 alle ore 18:07 sirgazil  ha
scritto:

>   On Mon, 27 Apr 2020 04:14:52 + Catonano 
> wrote 
>  >
>  >
>  > Il giorno sab 25 apr 2020 alle ore 15:06 Tobias Geerinckx-Rice <
> m...@tobias.gr> ha scritto:
>  > Hi Catonano,
>  >
>  > Catonano 写道：
>  > > Say that some people file bugs in the Guix issue tracker
>  > > requesting the
>  > > packaging of some software projects
>  > >
>  > > Can a list of such requests be seen in any way ?
>  >
>  > […]
>  >
>  > > Is there any specific tagging scheme to be used for package
>  > > requests filing ?
>  >
>  > Not that I know of.  It's all very ad-hoc and things get lost &
>  > forgotten.
>  >
>  >  is the closest
>  > thing we have to an ‘official’ list.
>  >
>  > While a structured approach would be much better than our wiki
>  > page, I prefer that wiki page over *our* bug tracker.
>  >
>  > don't you like Debbugs ?
>  > I can see why
>  > Have you seen this, anyway ?
>  > https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00238.html
>  > Sirgazil proposed to send a patch to allow Debbugs to tag package
> requests so that they could be easily searched
>
> Not really patch Debbugs, but patch the website with proposed changes to
> make any list of requested packages visible (and add instructions to
> request new packages).
>

Ah sorry , I had misunderstood.

Re: package requests

[sirgazil]

  On Mon, 27 Apr 2020 04:14:52 + Catonano  wrote 

 > 
 > 
 > Il giorno sab 25 apr 2020 alle ore 15:06 Tobias Geerinckx-Rice 
 >  ha scritto:
 > Hi Catonano,
 > 
 > Catonano 写道：
 > > Say that some people file bugs in the Guix issue tracker 
 > > requesting the
 > > packaging of some software projects
 > >
 > > Can a list of such requests be seen in any way ?
 > 
 > […]
 > 
 > > Is there any specific tagging scheme to be used for package 
 > > requests filing ?
 > 
 > Not that I know of.  It's all very ad-hoc and things get lost & 
 > forgotten.
 > 
 >  is the closest 
 > thing we have to an ‘official’ list.
 > 
 > While a structured approach would be much better than our wiki 
 > page, I prefer that wiki page over *our* bug tracker.
 > 
 > don't you like Debbugs ?
 > I can see why
 > Have you seen this, anyway ?
 > https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00238.html
 > Sirgazil proposed to send a patch to allow Debbugs to tag package requests 
 > so that they could be easily searched

Not really patch Debbugs, but patch the website with proposed changes to make 
any list of requested packages visible (and add instructions to request new 
packages).

I still think Debbugs could be used for package requests, even if it doesn't 
support custom tags like "package request". One could instruct people to send 
requests to bug-g...@gnu.org using a provided template. For example:

   Subject: [PACKAGE REQUEST] Add Some Software
   Body: Some other necessary information (website, license?)   

Then, maybe link to issues.gnu.org with a query like this:

  
https://issues.guix.gnu.org/search?query=%5BPACKAGE+REQUEST%5D+in%3Asubject+is%3Aopen

(The in:subject filter doesn't exist, though).

Re: 02/02: image: Disable compression for ISO images.

[Mathieu Othacehe]

Hey Tobias,

> guix-comm...@gnu.org 写道：
>> +   ;; XXX: Temporarily disable compression to speed-up the tests.
>> +   (compression? #f)))
>
> Interesting!  What kind of improvement do you see, roughly?

I posted some figures here:
https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00374.html.

Here's a more complete summary:

--8<---cut here---start->8---
|| Host (wip-disk-image) | VM (master) |
|+---+-|
| No compression | 4min  | 12min   |
| Compression| 8min  | 19min   |
--8<---cut here---end--->8---

> When I added zlib compression I was surprised to learn that here it made no
> significant difference in wall clock time (less than a minute; 5% or so) or
> CPU time.  The disks they spin and CPU she is fast, but still I would have
> noticed a spike.

Strange we have different results, those benches are not very accurate
though.

Thanks,

Mathieu

Re: unexpected reproducibility of reproducible blog post?

[Leo Prikler]

Hi zimoun,

Am Montag, den 27.04.2020, 12:05 +0200 schrieb zimoun:
> Hi Leo,
> 
> Thank you for testing.
> 
> 
> On Mon, 27 Apr 2020 at 00:53, Leo Prikler <
> leo.prik...@student.tugraz.at> wrote:
> 
> > yours: /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar
> > mine:  /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar
> 
> Nice!
> 
> What is your "guix describe"?
I used the same time-machine as you did, so I don't think it matters,
but I'm currently at 1e700c656a7a25ff2eb27fa552bc213cc50efb2a.  The
result is the same for 86081d9d7f88a7faee6fd14e8a085cb95ac1e36a (a
"random" commit in January), as long as you remember to actually use
the time-machine to jump back to the commit mentioned in the blog post.

> > I don't know, what configuration exactly went into the blog post,
> > but I
> > assume, it is not the same as for the time-machine experiments
> > before.
> > Since the prefix `guix time-machine --channels=guix-version-for-
> > reproduction.txt --` appears to be missing from the command, that
> > hash
> > is therefore probably not indicative of anything.
> 
> I do not know. That's why I am asking. :-)
> Because when reading the blog post, I naively assume that all had
> been
> run with the same version of Guix and the post mentions only one
> commit. Well, if it is not the case, it should be mentioned in the
> blog post because it is currently misleading, IMO.
I agree.  There should probably be an addendum correcting the
information.  Perhaps adding some up-to-date hashes would probably not
be a bad idea either.

> > I think the larger problem here is that, while Guix itself is
> > reproducible, Guix + org-mode (specifically the latter) is not.
> 
> Why?
There are too many ways to bork org-mode -- you yourself specifically
list one of them later.  I don't think org-mode not being reproducible
is a big secret.

> > Particularly, looking at the source[1,2], it appears as if all code
> > blocks were evaluated once, but evaluating them again in a new
> > environment would bring different results.
> 
> Do you mean evaluate twice in a row leads to different results?
> By results, I mean items in '/gnu/store'.
> Because, yes the org-babel cache should not be reproducible. But that
> another story and should not impact the result of a source block.
That by itself is no biggie, but it becomes particularly bad when you
throw in partial evaluation.  If you don't evaluate all the code blocks
once, your results may get stale and then you'd export those stale
results.  Throw in some command that hasn't been evaluated yet and
evaluate it on export and you get yourself a recipe for deluxe bogus.

> My point is:
>  - only one Guix commit is provided by the post, so it seems
> legitimate to assume this commit had been used for all the post
>  - using this commit leads to different item in the store
This assumption may appear intuitive, but by reproducing the time-
machine on many Guix systems and verifying that it is indeed
reproducible (albeit with a different hash), we can invalidate it.

> The question is why?
>  - another commit had been used. Which one? Could be mentioned in the
> post?
>  - or there is something unexpected and let inspect what.
I assume it was accidental.  Had it been known earlier, that a
different commit was used, the blog post would have been updated
between Jan 14th (last update in git) and Jan 24th (official post),
would it not?

All the best,
Leo

Re: 02/02: image: Disable compression for ISO images.

[Tobias Geerinckx-Rice]

Mathieu,

guix-comm...@gnu.org 写道：
+   ;; XXX: Temporarily disable compression to speed-up the 
tests.

+   (compression? #f)))


Interesting!  What kind of improvement do you see, roughly?

When I added zlib compression I was surprised to learn that here 
it made no significant difference in wall clock time (less than a 
minute; 5% or so) or CPU time.  The disks they spin and CPU she is 
fast, but still I would have noticed a spike.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Medium-term road map

[Christopher Lemmer Webber]

Andy Wingo writes:

> On Sat 25 Apr 2020 15:37, Ludovic Courtès  writes:
>
>>   2. Performance.  There are many things we can improve there, first and
>>  foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>>  compiler terrible time and space requirements
>
> I think I have a solution here, as discussed on IRC.  Basic idea is to
> make a direct compiler from Tree-IL to bytecode, skipping the CPS step.
> The result won't be optimal in terms of generated code quality (I
> estimate on average 2x slowdown) but it will be very cheap to produce (I
> estimate 10x improvement in time, and going from O(n log n) space to
> O(n), with better constant factors.  We'd use this compiler for -O0 or
> maybe even -O1 code.
>
> Got to spend a few days working it up tho!
>
> Andy

That sound like a nice path to an improvement!

Re: Guix System video review on YouTube

[zimoun]

On Mon, 27 Apr 2020 at 12:11, Jonathan Brielmaier
 wrote:

> >> * While installing packages via `guix install` you can't scroll in the
> >> terminal, you always get reset to the bottom.
> >
> > I missed what it mean. Could you quickly extend a bit?
>
> $ echo "hello"
> hello
> $ guix install emacs
>
> Then while installing emacs, try to reach the hello. It will be tricky
> as every new output line from `guix install emacs` will reset you to the
> bottom of your terminal. That's annoying.

Does not it depend on the terminal emulator?


> >> * guix show/search does not show if a package is installed.
> >
> > Installed where? In which profile?
> > I am not sure that "installed" make sense at the level of "guix 
> > show/search".
>
> It definitely does. It could show packages installed to the profile,
> such coming from the config.scm etc.

I am not using Guix System so I do not have config.scm.

Well, you propose that to loop over all the user profiles (i.e., "guix
package --list-profiles) to check if it is installed in one of them,
right?
I am not convinced it is useful.
Create a new profile and install what I need is cheap so I do not see
why it could be useful to know if the package is already installed or
not. If it is, nothing to be done; if not it is installed where I need
it.
However, what is useful is to know if the item already exist or not in
the store, IMHO.

When "guix install vim", for example the package 'tcsh' goes in the
store but is not considered "installed" by the profile say
'~/.guix-profile'. Therefore, does "guix show tcsh" display
'installed' or 'not installed'?

Because of the profiles -- and I am even not talking about grafts -- I
am not sure that "installed" make sense at the level of "guix
show/search". ;-)
There is too much corner cases, IMHO.


> >> * `guix search ... | less can be confusing at the beginning.
> >
> > There is room of improvements for "guix search". ;-)
> >
> > There is 3 behaviours
> >  1. return the N packages fitting the screen size (current: default)
> >  2. display all the list in PAGER (current: |less)
> >  3. display all the list in stdout (current: |cat)
> >
> > The feature request is: be able to configure which behaviour by
> > default for "guix search". Maybe via an environment variable.
> > (as discussed elsewhere by Ricardo and Tobias, if I understand correctly)
> >
> >
> > WDYT?
>
> To be honest I would like the search to behave more like `guix package
> -A`. Then we don't need this `less` thing. And we could add something
> like `guix search --expanded` which behaves like the current search.

I agree.
There is room of improvement about "guix search".

Some time ago, I also proposed to have something like: "--format"
(inspired by "git log --format=")

   guix search vim --format="%name %synopsis"
   guix search vim --format="%name \n %license \n"
   guix search crypto library --format=full
etc.

It should be also used by "guix show" and we could even imagine by
"guix package -A".

Well, as one said: patches welcome. :-)



> $ zypper search vim | wc -l
> 84
> $ guix package -A vim | wc -l
> 22
> $ guix search vim | less
> 828 lines and you have to search again in less because you are overwhelmed

I do not know 'zypper', only 'aptitude' of Debian. :-)

And there is a big difference between "guix search" and such tools:
the relevance scoring.
Well, "guix search" does not sort alphanumerically by name but sort by
relevance depending on the query.

The order is not predictable. Sometimes we want to order by relevance
(for discoverability), sometimes not. Therefore, it should be possible
to order by any keys than the relevance (using alphanumerical
ordering)


> So I would propose an interface like:
> $ guix search vim
> | Name  | Synopsis   | Version  | Outputs |
> +---++--+-+
> | vim   | Text editor based on vi| 8.2.0411 | out |
> | vim-airline   | ...
> [...]
>
> The the search command would fulfill it's function by giving you an
> overview about the available options.

I agree as explained above. :-)
Room of improvements for "guix search". :-)


> >> * Multi user package concept not clear (root as different packages then
> >> normal user).
> >
> > This is related to expectation about "installed", IMHO.
>
> Yes. But can be confusing for all the people coming from traditional
> package managers where root and user share the same packages.

Yes shifting is always difficult. :-)


Cheers,
simon

Re: hint: Run `guix search ... | less' to view all the results

[pinoaffe]

On 2020-04-27 08:38, Jan Synacek wrote:

While we're at it, let me also give my opinion about supporting PAGER.
If it means that if PAGER is set, use it, otherwise don't page, then
that's perfectly valid and, in my opinion, how PAGER support is
supposed to work. If it means that *unless* something is set *not to
use* a pager as some tools currently do (I can only think of some of
the systemd tools off top of my head), use pager by default, then
that's also backwards. But it's still much better than truncating
output by default.

imo the best option would be to page, print or truncate depending on
an envvar and/or a commandline flag

Re: Packaging ‘clang-tools-extra’ (‘clang-tidy’, etc.)

[Nikita Gillmann]

Hi,

Efraim Flashner transcribed 1.9K bytes:
> On Mon, Apr 27, 2020 at 09:31:01AM +0200, Ludovic Courtès wrote:
> > Hi!
> > 
> > Nikita Gillmann  skribis:
> > 
> > > Is it? The way we build clang and clang-tools-extra in pkgsrc is to
> > > have them separate.
> > > Refer to lang/clang-tools-extra and lang/clang to see how.
> > > The gist is, BUILD_TARGET for clang-tools-extra gets overridden
> > > and appended with targets to build.
> > 
> > Nice.  Do you have the URL of the build recipe?
> > 
> > Thanks,
> > Ludo’.
> > 
> 
> Here's a link to the Github mirror of pkgsrc for clang-tools-extra
> https://github.com/NetBSD/pkgsrc/blob/trunk/lang/clang-tools-extra/Makefile

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/clang-tools-extra/#dirlist
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/clang/

or navigating the (improve worthy) http://pkgsrc.se

But yeah github mirror should work out, or

https://anonhg.netbsd.org/pkgsrc/file/tip/lang/clang
https://anonhg.netbsd.org/pkgsrc/file/tip/lang/clang-tools-extra
 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Guix System video review on YouTube

[Danny Milosavljevic]

Hi,

On Mon, 27 Apr 2020 00:32:27 +0200
Jonathan Brielmaier  wrote:

> XFCE: no network-manager installed by default (seems not so important on
> a QEMU image)

Yeah, but it would be nice if we could warn the user if he tries to
install some package manually (using guix install) that would require a
service to work, the latter of which we would have anyway.

We could mention in the description of the package that there is a service
and people ought to really use that.

Maybe we could even extend guix lint to periodically traverse all Guix
service types for default packages and then check whether the warning is
in the desciption of those packages.

Very few other distributions make the distinction of service vs package.
I think the distinction is good to have, but still some kind of warning
would be nice if the service is missing in the os config.


pgpJYVvIV1a29.pgp
Description: OpenPGP digital signature

Re: Guix System video review on YouTube

[Efraim Flashner]

On Mon, Apr 27, 2020 at 11:08:47AM +0200, zimoun wrote:
> Hi Jonathan,
> 
> Thank you for translating the feedback.
> Because watching without understand German feels like "Guix is so cool!" ;-)
> 
> 
> On Mon, 27 Apr 2020 at 00:34, Jonathan Brielmaier
>  wrote:
> 
> > * There is no /etc/os-release file. I think it was proposed a while ago,
> > but the patch was rejected.
> 
> Naive question: what is useful for?
> And what does it mean on rolling-release distro?
> 

I don't remember why I originally suggested it but I have it up and
running on my machines. At this point I use it mostly to try to remember
if mail goes to bug-guix or guix-bug.

(ins)efraim@E5400 ~$ cat /etc/os-release
NAME="Guix System"
PRETTY_NAME="Guix System"
VERSION="1.1.0-1.7dd0539"
VERSION_ID="1.1"
ID=guix
HOME_URL="https://www.gnu.org/software/guix/;
SUPPORT_URL="https://www.gnu.org/software/guix/help/;
BUG_REPORT_URL="mailto:bug-g...@gnu.org;

https://gitlab.com/Efraim/guix-config/-/blob/master/config/os-release.scm

-- 
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: Guix System video review on YouTube

[Jonathan Brielmaier]

On 27.04.20 11:08, zimoun wrote:
>> * There is no /etc/os-release file. I think it was proposed a while ago,
>> but the patch was rejected.
>
> Naive question: what is useful for?
> And what does it mean on rolling-release distro?

If you log into a system, its a canonical way to find out which system
it is. It does fit also on rolling-release distros, we show the output
the results from `guix system describe` there.

>> * While installing packages via `guix install` you can't scroll in the
>> terminal, you always get reset to the bottom.
>
> I missed what it mean. Could you quickly extend a bit?

$ echo "hello"
hello
$ guix install emacs

Then while installing emacs, try to reach the hello. It will be tricky
as every new output line from `guix install emacs` will reset you to the
bottom of your terminal. That's annoying.

>> * guix show/search does not show if a package is installed.
>
> Installed where? In which profile?
> I am not sure that "installed" make sense at the level of "guix show/search".

It definitely does. It could show packages installed to the profile,
such coming from the config.scm etc.

>> * `guix search ... | less can be confusing at the beginning.
>
> There is room of improvements for "guix search". ;-)
>
> There is 3 behaviours
>  1. return the N packages fitting the screen size (current: default)
>  2. display all the list in PAGER (current: |less)
>  3. display all the list in stdout (current: |cat)
>
> The feature request is: be able to configure which behaviour by
> default for "guix search". Maybe via an environment variable.
> (as discussed elsewhere by Ricardo and Tobias, if I understand correctly)
>
>
> WDYT?

To be honest I would like the search to behave more like `guix package
-A`. Then we don't need this `less` thing. And we could add something
like `guix search --expanded` which behaves like the current search.

>
> What user expect by default is complicated and depends on the users
> themself. :-)
> For example, I always pipe with 'recsel' because coming from Debian
> and used to 'aptitude', I only want the name of the package and then
> show more if I need; i.e.,
>
>guix search crypto library | recel -C -P name
># optional: time to time I pipe the result with 'grep'
>guix show libb2
>
> Well, I find more confusing that "guix search" displays
> name,synopsis,description,etc. than to pipe. So, taste and colour...
> ;-)

I don't think a proper search is something against KISS. And people are
lazy, I don't want to type in some "| foo" stuff.

$ zypper search vim | wc -l
84
$ guix package -A vim | wc -l
22
$ guix search vim | less
828 lines and you have to search again in less because you are overwhelmed

So I would propose an interface like:
$ guix search vim
| Name  | Synopsis   | Version  | Outputs |
+---++--+-+
| vim   | Text editor based on vi| 8.2.0411 | out |
| vim-airline   | ...
[...]

The the search command would fulfill it's function by giving you an
overview about the available options.

>> * Multi user package concept not clear (root as different packages then
>> normal user).
>
> This is related to expectation about "installed", IMHO.

Yes. But can be confusing for all the people coming from traditional
package managers where root and user share the same packages.

Re: unexpected reproducibility of reproducible blog post?

[zimoun]

Hi Leo,

Thank you for testing.


On Mon, 27 Apr 2020 at 00:53, Leo Prikler  wrote:

> yours: /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar
> mine:  /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar

Nice!

What is your "guix describe"?


> I don't know, what configuration exactly went into the blog post, but I
> assume, it is not the same as for the time-machine experiments before.
> Since the prefix `guix time-machine --channels=guix-version-for-
> reproduction.txt --` appears to be missing from the command, that hash
> is therefore probably not indicative of anything.

I do not know. That's why I am asking. :-)
Because when reading the blog post, I naively assume that all had been
run with the same version of Guix and the post mentions only one
commit. Well, if it is not the case, it should be mentioned in the
blog post because it is currently misleading, IMO.


> I think the larger problem here is that, while Guix itself is
> reproducible, Guix + org-mode (specifically the latter) is not.

Why?


> Particularly, looking at the source[1,2], it appears as if all code
> blocks were evaluated once, but evaluating them again in a new
> environment would bring different results.

Do you mean evaluate twice in a row leads to different results?
By results, I mean items in '/gnu/store'.
Because, yes the org-babel cache should not be reproducible. But that
another story and should not impact the result of a source block.


> In other words, you'd have
> to use `guix time-machine` inside `guix time-machine` to get a truly
> reproducibly org-mode file, or else come up with a smart way of
> dynamically updating the hash in the source blocks themselves.

I do not know and I am not sure to follow.


My point is:
 - only one Guix commit is provided by the post, so it seems
legitimate to assume this commit had been used for all the post
 - using this commit leads to different item in the store

The question is why?
 - another commit had been used. Which one? Could be mentioned in the post?
 - or there is something unexpected and let inspect what.


All the best,
simon

Re: hint: Run `guix search ... | less' to view all the results

[zimoun]

Dear

On Mon, 27 Apr 2020 at 10:39, Jan Synacek  wrote:

> Yes, it is truncated in the sense of it doesn't show all the output, unless 
> you use a pipe, redirect or set the env variable. If I run 'guix package -A', 
> it outputs all the available packages without truncating anything and without 
> giving me "helpful" hints. And that's currently 13201 lines on my system. 
> That's how I expect commands to behave and that has been pretty much the 
> normal thing to do since forever.

There is a difference: "guix search" computes a relevance score
depending on the query and the result is sorted by relevance.
Therefore, the few first items should be the most relevant with the
query and page the result should not be "useful" (yes it is debatable!
:-))

There is room of improvement!
For example, 'aptitutde search ' returns (by default): name TAB
synopsis. I find that really handy. Even if it would not be the
default, it should be possible to display differently the result of
"guix search".
Another example, it should be possible to sort the result by another
key than the relevance, e.g., to group them by file origin or license
or your-name-it.

Patches welcome. :-)



> While we're at it, let me also give my opinion about supporting PAGER. If it 
> means that if PAGER is set, use it, otherwise don't page, then that's 
> perfectly valid and, in my opinion, how PAGER support is supposed to work. If 
> it means that *unless* something is set *not to use* a pager as some tools 
> currently do (I can only think of some of the systemd tools off top of my 
> head), use pager by default, then that's also backwards. But it's still much 
> better than truncating output by default.

Does Git work the way you suggest all the tools are working?


All the best,
simon

Re: hint: Run `guix search ... | less' to view all the results

[zimoun]

Dear,

On Mon, 27 Apr 2020 at 08:12, Jan Synacek  wrote:
> On Sun, Apr 26, 2020 at 11:38 AM zimoun  wrote:
>> On Sun, 26 Apr 2020 at 10:35, Jan Synacek  wrote:

>> > Seriously? Are you seriously forcing your users to either run emacs (or at 
>> > least
>> > to set the env variable) or use pipes to get the entire search result?
>>
>> It is "known" that Guix should respect the PAGER variable [1,2] and it
>> is already a feature request [3].
>>
> Why do you want to make things complicated? What's wrong with *just showing 
> the entire output*? And let users decide if they want to use a pager, recsel, 
> emacs or redirect the output somewhere else.
>
> I mean you run a command and the command shows its output. It makes me kind 
> of sad that there even has to be a discussion about this.
>
>> [1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00039.html
>> [2] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00150.html
>> [3] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00154.html


I do not have a strong opinion.
Personally, I do not find the default behaviour really handy and I
(almost) always pipe with 'recsel -C -P name' because I do not find
handy neither to display all the package fields by default. Well,
taste and colour. :-)
And my answer was just to point you that it is not an arbitrary
choice. And all choices can be discussed. ;-)


All the best,
simon

Re: Guix System video review on YouTube

[zimoun]

Hi Jonathan,

Thank you for translating the feedback.
Because watching without understand German feels like "Guix is so cool!" ;-)


On Mon, 27 Apr 2020 at 00:34, Jonathan Brielmaier
 wrote:

> * There is no /etc/os-release file. I think it was proposed a while ago,
> but the patch was rejected.

Naive question: what is useful for?
And what does it mean on rolling-release distro?


> * While installing packages via `guix install` you can't scroll in the
> terminal, you always get reset to the bottom.

I missed what it mean. Could you quickly extend a bit?


> * guix show/search does not show if a package is installed.

Installed where? In which profile?
I am not sure that "installed" make sense at the level of "guix show/search".

>From my point of view, it could be interesting to know if the package
is already available in the store. Basically, if "guix build
--dry-run" completes all the recursive phases without download or
build. For a couple of packages (guix show), it is doable but it is
too much expensive for "guix search".

WDYT?


> * `guix search ... | less can be confusing at the beginning.

There is room of improvements for "guix search". ;-)

There is 3 behaviours
 1. return the N packages fitting the screen size (current: default)
 2. display all the list in PAGER (current: |less)
 3. display all the list in stdout (current: |cat)

The feature request is: be able to configure which behaviour by
default for "guix search". Maybe via an environment variable.
(as discussed elsewhere by Ricardo and Tobias, if I understand correctly)


WDYT?


What user expect by default is complicated and depends on the users
themself. :-)
For example, I always pipe with 'recsel' because coming from Debian
and used to 'aptitude', I only want the name of the package and then
show more if I need; i.e.,

   guix search crypto library | recel -C -P name
   # optional: time to time I pipe the result with 'grep'
   guix show libb2

Well, I find more confusing that "guix search" displays
name,synopsis,description,etc. than to pipe. So, taste and colour...
;-)


> * Multi user package concept not clear (root as different packages then
> normal user).

This is related to expectation about "installed", IMHO.


Thank you for the feedback. Really interesting!

Cheers,
simon

Re: Packaging ‘clang-tools-extra’ (‘clang-tidy’, etc.)

[Efraim Flashner]

On Mon, Apr 27, 2020 at 09:31:01AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Nikita Gillmann  skribis:
> 
> > Is it? The way we build clang and clang-tools-extra in pkgsrc is to
> > have them separate.
> > Refer to lang/clang-tools-extra and lang/clang to see how.
> > The gist is, BUILD_TARGET for clang-tools-extra gets overridden
> > and appended with targets to build.
> 
> Nice.  Do you have the URL of the build recipe?
> 
> Thanks,
> Ludo’.
> 

Here's a link to the Github mirror of pkgsrc for clang-tools-extra
https://github.com/NetBSD/pkgsrc/blob/trunk/lang/clang-tools-extra/Makefile

-- 
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: hint: Run `guix search ... | less' to view all the results

[Jan Synacek]

On Mon, Apr 27, 2020 at 4:02 AM Bengt Richter  wrote:

> Hi zimoun, Jan,
>
> On +2020-04-26 11:38:01 +0200, zimoun wrote:
> > Dear,
> >
> > On Sun, 26 Apr 2020 at 10:35, Jan Synacek  wrote:
> >
> > > Seriously? Are you seriously forcing your users to either run emacs
> (or at least
> > > to set the env variable) or use pipes to get the entire search result?
> >
> > It is "known" that Guix should respect the PAGER variable [1,2] and it
> > is already a feature request [3].
> >
> > [1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00039.html
> > [2] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00150.html
> > [3] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00154.html
> >
> >
> > > That's just... backwards. Also, it feels like as if the author of that
> code sort
> > > of assumed that whoever runs the command is stupid enough not to be
> able to deal
> > > with long output. I'm sure that it wasn't meant like that.
> >
> > The manual recommands to use "guix search" in combination with
> > 'recsels' (see [4] '--search' paragraph).
> >
> > Therefore, the current philosophy of searching is:
> >
> >   1) guix search  | recsel -P name,synopsis | grep
> 
> >   2) guix show 
> >
> > I agree we could discuss that... as it was started for example see
> > this thread [5].
> >
> > [4] https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-package
> > [5] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00141.html
> >
> >
> > > Pretty please, fix this. Don't force your users into usage patterns
> that might
> > > be completely foreign to them. Don't truncate output from programs by
> default.
> >
>
> I had been assuming it had just been allowed to scroll off
> screen due to unimpeded output, as IIUC Jan wants. Is it
> actually truncated?
>

Yes, it is truncated in the sense of it doesn't show all the output, unless
you use a pipe, redirect or set the env variable. If I run 'guix package
-A', it outputs all the available packages without truncating anything and
without giving me "helpful" hints. And that's currently 13201 lines on my
system. That's how I expect commands to behave and that has been pretty
much the normal thing to do since forever.

I believe in KISS for primitives, and I think the less they
> look at how they are being used the better for their design.
> Otherwise the implementation is implicitly getting ad hoc
> inputs from the environment, and incrementally it will grow
> messy.
>

> At the higher level, I think systems can be too eager to
> help, which can be really annoying to an advanced user, but
> really helpful to a noob.
>

In this particular case, I consider myself as an advanced user and yes,
it's annoying.

As I have already mentioned, I don't consider guix to be aimed at "noobs".
You would have to define what noob means here. If we consider a noob to be
someone who doesn't know how to use pipes or redirections, then, as I have
already mentioned, I don't believe it's the target audience of the guix
project. At least not for now. Currently, it actually takes a pretty
advanced linux user to use it.

So maybe Jan could be satisfied by a preference setting
> (USER_LEVEL expert) in that regard. Many apps have such
> features, E.g. emacs will want to take you into a tutorial
> until you tell it to stop pestering you.
>

This actually made me laugh, thanks for that! I'm not sure if it was meant
to be a joke or not, but I take it as you meant it. What you actually
suggest is: 1) I run 'guix package -s ...' which gives me the first few
results and a "helpful" hint that I should use pipes or emacs to get all of
it. 2) I get annoyed and happen to know about this USER_LEVEL configuration
option that I can use. 3) I set USER_LEVEL=expert and get the output that I
should have gotten in the first place.
If that's what you meant, then, please no, don't do that.

While we're at it, let me also give my opinion about supporting PAGER. If
it means that if PAGER is set, use it, otherwise don't page, then that's
perfectly valid and, in my opinion, how PAGER support is supposed to work.
If it means that *unless* something is set *not to use* a pager as some
tools currently do (I can only think of some of the systemd tools off top
of my head), use pager by default, then that's also backwards. But it's
still much better than truncating output by default.
Regards,
-- 
Jan Synacek
Software Engineer, Red Hat

Re: Medium-term road map

[Andy Wingo]

On Sat 25 Apr 2020 15:37, Ludovic Courtès  writes:

>   2. Performance.  There are many things we can improve there, first and
>  foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>  compiler terrible time and space requirements

I think I have a solution here, as discussed on IRC.  Basic idea is to
make a direct compiler from Tree-IL to bytecode, skipping the CPS step.
The result won't be optimal in terms of generated code quality (I
estimate on average 2x slowdown) but it will be very cheap to produce (I
estimate 10x improvement in time, and going from O(n log n) space to
O(n), with better constant factors.  We'd use this compiler for -O0 or
maybe even -O1 code.

Got to spend a few days working it up tho!

Andy

Re: Packaging ‘clang-tools-extra’ (‘clang-tidy’, etc.)

[Ludovic Courtès]

Hi!

Nikita Gillmann  skribis:

> Is it? The way we build clang and clang-tools-extra in pkgsrc is to
> have them separate.
> Refer to lang/clang-tools-extra and lang/clang to see how.
> The gist is, BUILD_TARGET for clang-tools-extra gets overridden
> and appended with targets to build.

Nice.  Do you have the URL of the build recipe?

Thanks,
Ludo’.

Re: hint: Run `guix search ... | less' to view all the results

[Jan Synacek]

On Sun, Apr 26, 2020 at 11:38 AM zimoun  wrote:

> Dear,
>
> On Sun, 26 Apr 2020 at 10:35, Jan Synacek  wrote:
>
> > Seriously? Are you seriously forcing your users to either run emacs (or
> at least
> > to set the env variable) or use pipes to get the entire search result?
>
> It is "known" that Guix should respect the PAGER variable [1,2] and it
> is already a feature request [3].
>
> Why do you want to make things complicated? What's wrong with *just
showing the entire output*? And let users decide if they want to use a
pager, recsel, emacs or redirect the output somewhere else.

I mean you run a command and the command shows its output. It makes me kind
of sad that there even has to be a discussion about this.

[1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00039.html
> [2] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00150.html
> [3] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00154.html
>
>
> > That's just... backwards. Also, it feels like as if the author of that
> code sort
> > of assumed that whoever runs the command is stupid enough not to be able
> to deal
> > with long output. I'm sure that it wasn't meant like that.
>
> The manual recommands to use "guix search" in combination with
> 'recsels' (see [4] '--search' paragraph).
>

Good, I actually like that recommendation.


> Thank you for sharing your opinion.
>

You're welcome.

Regards,
-- 
Jan Synacek
Software Engineer, Red Hat

Re: Guix System video review on YouTube

[Jan Nieuwenhuizen]

Jonathan Brielmaier writes:

> Guix System got a video review on YouTube:
> https://www.youtube.com/watch?v=IKsXecNJ_nE

> Although the reviewer was not really happy with the Guix System
> distribution, he was quite pleased with the package manager. So he would
> recommend his viewers to try Guix on a foreign distro, but not our distro.
>
> For the issues I could reproduce, I already filed bugs:

That's great.  Are you planning on leaving a reaction, maybe something
like: Thanks for the extensive testing, I filed bugs for the issues you
found here => ...

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com