Re: Guix pronunciation

[mikadoZero]

Laura Lazzati writes:
> ... The person I met interested in at least
> playing whith Guix told me that was thinking of both Guix and Nix, and
> I was asked before about the differences. Is it in the manual? Because
> I don't remember reading it.  ...

I just searched through the manual for Nix and it looks like the closest
thing to to covering differences between Nix and Guix is "15
Acknowledgments".  Although it does not cover differences and is just an
acknowledgment.

I was just reading the README in the Guix repository and found a section
called Guix & Nix that does covers differences between them.

Re: Request for commit access

[Laura Lazzati]

Hi Alex!

> Hope it help :)
Thank you very much! I have it installed but did not have headsets by
that time, ended up recording them the hard way.

Regards :)
Laura

Re: Go build system updates and future work?

[Leo Famulari]

On Thu, Mar 14, 2019 at 11:51:06PM +0100, Pierre Neidhardt wrote:
> Agreed!  This should also make the Go importer more trivial to write/finish!

Okay, I'll try it.

The only part I'm not sure about is what to "build" or "test" for these
library collections. Currently many of them run test suites, which is
nice because it gives us some confidence the package is in good shape.
We don't install any compiled libraries but it does help get the
dependency graph in good shape.

But the top level of the x/net repo, for example, does not have any Go
files at all, so the package will effectively be source only with no
testing. Maybe it won't be a problem in practice, I don't know.


signature.asc
Description: PGP signature

Re: Go build system updates and future work?

[Leo Famulari]

On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote:
> Erratum: You've packaged go-github-com-kr-text a second time :p

Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970

> This has happened to me once.  I think we should have a linter to protect
> against this.  Thoughts?

I think it's been discussed before but I'm not sure — try searching the
archives.


signature.asc
Description: PGP signature

Re: Improve package search

[Tobias Geerinckx-Rice]

Pierre!

Pierre Neidhardt wrote:
Absolutely.  Adding this to the package record manually is a 
maintenance
nightmare.  It's data that can be trivially auto-generated (ls 
…/{,s}bin,
basically), and storing it in-line takes up too much screen and 
mind space for

my taste.


"Program names" might even be too limited, if not too 
shortsighted.  At the end
of the day, programs are not necessarily stored in /bin/.  More 
importantly,
users don't necessarily look for programs, they could very well 
be looking for a

library.


Oh, sure, {,s}bin was just an example.  I don't really think 
there's a package manager that indexes only those two directories. 
'T would be silly.


Extending the search with file listings might result in too much 
noise, so
instead we could have a separate command.  "guix which" for 
instance, as


Or ‘guix where’ or guix whatever.

(16 days left for someone to implement ‘guix whatever’.)

suggested Tobias, but since we are not just talking about 
executables, maybe

"guix filesearch" would be more appropriate.


Well, we can deathmatch about the name and the number of hyphens 
once it does something.  ;-)


I haven't though through the details, but I am under the 
impression that the
file listing could be retrieve with the same mechanism as "guix 
size", i.e. from
the substitute index.  I think it would work well on the build 
farm, without

more complexity than just another entry to the substitute index.


What do you mean by substitute index?

By complexity, I meant: if it would depend on a network connection 
to the build farm (or elsewhere), at all.


And would this information be provided by a naked ‘guix publish’? 
I guess that depends on the meaning of ‘substitute index’.


Kind regards,

T G-R

Re: Improve package search

[Pierre Neidhardt]

> Absolutely.  Adding this to the package record manually is a maintenance
> nightmare.  It's data that can be trivially auto-generated (ls …/{,s}bin,
> basically), and storing it in-line takes up too much screen and mind space for
> my taste.

"Program names" might even be too limited, if not too shortsighted.  At the end
of the day, programs are not necessarily stored in /bin/.  More importantly,
users don't necessarily look for programs, they could very well be looking for a
library.

So instead of including a program name listing, I suggest to we index the
complete file listing of all packages.This would allow us to add the only
feature that's missing in Guix that other package managers have (dpkg, portage,
pacman...): find file names in non-installed packages.

Extending the search with file listings might result in too much noise, so
instead we could have a separate command.  "guix which" for instance, as
suggested Tobias, but since we are not just talking about executables, maybe
"guix filesearch" would be more appropriate.

Example:

--8<---cut here---start->8---
$ guix filesearch foo
74i7r7qp1km0gw1i22fnq3szbgc9mpdx-foobar-1.0/bin/foo
74i7r7qp1km0gw1i22fnq3szbgc9mpdx-foobar-1.0/lib/libfoo.a
109sdfvp1km0gwjdksl982fjidsfji9s-…-foobar-1.2/bin/foo
109sdfvp1km0gwjdksl982fjidsfji9s-…-foobar-1.2/lib/libfoo.a
--8<---cut here---end--->8---

And full paths would be supported, so that we can "filter" by executables for 
instance:

--8<---cut here---start->8---
$ guix filesearch bin/foo
74i7r7qp1km0gw1i22fnq3szbgc9mpdx-foobar-1.0/bin/foo
109sdfvp1km0gwjdksl982fjidsfji9s-…-foobar-1.2/bin/foo
--8<---cut here---end--->8---

This has been discussed before, if someone can find the threads... :p

> People have suggested using the build farm for this, but that adds
> disproportionate complexity and decouples/delays updates from the commits that
> caused them.  It's just not the right place.

I haven't though through the details, but I am under the impression that the
file listing could be retrieve with the same mechanism as "guix size", i.e. from
the substitute index.  I think it would work well on the build farm, without
more complexity than just another entry to the substitute index.

I'd really love to work on this Very Soon™ ;)

Cheers!

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


signature.asc
Description: PGP signature

Re: Improve package search

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice wrote:
On the other hand, we'd be able to map commands only to package 
names,


s names specs .

Kind regards,

T G-R

Re: Improve package search

[Tobias Geerinckx-Rice]

Leo, mikadoZero,

This has been suggested many times and is a good idea.  Now all we 
need is someone to do the work, but that's the easy part, right?


Leo Famulari wrote:

On Thu, Mar 14, 2019 at 02:31:36PM -0400, mikadoZero wrote:

# Proposed idea

* Add a "programs" field to package definitions that list the 
programs
  that are included in a package. 
* Include this field in search results.
* Have this field factor into the search result relevance 
scores.


We should also expose it directly like other package managers do. 
‘guix which’ would be very handy, and allows 
‘command-not-found’-style suggestions for those who like that kind 
of thing.



# Feedback

This is an initial idea that would benefit from the input of 
others.


For me, it would be better to have this "program listing" built
automatically, rather than relying on packagers to get it right 
and keep

it up to date. It would be a great feature once it is in place.


Absolutely.  Adding this to the package record manually is a 
maintenance nightmare.  It's data that can be trivially 
auto-generated (ls …/{,s}bin, basically), and storing it in-line 
takes up too much screen and mind space for my taste.


People have suggested using the build farm for this, but that adds 
disproportionate complexity and decouples/delays updates from the 
commits that caused them.  It's just not the right place.


A separate simple (text) database (included in the git repository, 
and updated in the same commit) would be faster to search and stay 
out of our way.


On the other hand, we'd be able to map commands only to package 
names, not to specific objects.


Just thinking out loud,

T G-R

Re: Status update on 1.0

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2019. márc. 13., Sze, 16:21):
>
> Hello Guix!

>   • IPv6 support in ‘static-networking-service’: as discussed at the
> Guix Days, we’ll probably need to Linux Netlink sockets to do that
> rather than the old ioctls currently used in (guix build syscalls).
>
> The netlink interface for network config is vaguely documented at
> .
> Writing bindings for ‘sendmsg’ and the associated data structures
> looks reasonable… it just needs to be done.
>

I am interested in doing this. However, there are a few points that needs
to be clarified:
1. I came to the same conclusion regarding the netlink stuff, but the old ioctl
cannot be fully dropped. (It still provides funcions that are needed to get
the netlink working)
2. This might be linux specific. What do we do on other kernels?
(It might be reasonable to provide the abstractions in a module, and
from there select an available implementation, or signal an error that
the functionality is not yet implemented for this system...)
Wdyt?

Also a nice low level binding written in C is available as libmnl:
https://netfilter.org/projects/libmnl/index.html

>
> Ludo’.
>

Best regards,
g_bor

Re: Improve package search

[Leo Famulari]

On Thu, Mar 14, 2019 at 02:31:36PM -0400, mikadoZero wrote:
> # Proposed idea
> 
> * Add a "programs" field to package definitions that list the programs
>   that are included in a package. 
> * Include this field in search results.
> * Have this field factor into the search result relevance scores.

> # Feedback
> 
> This is an initial idea that would benefit from the input of others.

For me, it would be better to have this "program listing" built
automatically, rather than relying on packagers to get it right and keep
it up to date. It would be a great feature once it is in place.


signature.asc
Description: PGP signature

Re: Using openjdk9 as the default JDK

[Alex Vong]

Thanks, people. I'm looking forwards to playing with jaotc :)

Gábor Boskovits  writes:

> Hello,
>
> 2019. márc. 5., K 20:00 dátummal Alex Vong  ezt írta:
>
>  Ricardo Wurmus  writes:
>
>  > Hi Gábor,
>  >
>  >>> there are a few packages now that require Java 9, such as
>  >>> java-eclipse-jdt-compiler-apt (that I’m currently packaging).
>  >>>
>  >>> We should aim to use openjdk9 as the default JDK.
>  >>>
>  >>> What do you think?
>  >>>
>  >>
>  >> Do you think that aiming for openjdk11 directly is too much?
>  >> 9 is not supported, but 11 will be supported until 2026.
>  >>
>  >> For further information see 
> https://en.wikipedia.org/wiki/Java_version_history
>  >
>  > Good point.  Let’s use openjdk11 then.
>
>  From this page , the
>  latest icedtea is for openjdk 8. Does this mean that we have to patch
>  icedtea to build openjdk 11?
>
> As of openjdk9 openjdk became free, so there is no longer a need for icetea. 
> That is why
> there is no newer version, and you can find openjdk 9 10 and 11 in guix.
>
> Best regards,
> g_bor


signature.asc
Description: PGP signature

Re: CDN Test Results - Should We Continue Using a CDN?

[Leo Famulari]

On Sun, Mar 10, 2019 at 08:47:59PM -0700, Chris Marusich wrote:
> In addition, CloudFront reports that traffic came from the following
> locations (sorted by bytes transferred):
> 
> Location Request Count  Request %  Bytes
> -
[...]
> China17,841 0.48%  16.45   GB

Looks like someone was benefitting from the CDN in China:

https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00222.html

I vote that we continue using it. During the Guix Days, the availability
of substitutes was identified as a frequent problem with Guix. Anything
we can do to increase availability and download speeds is a good thing
for the project.


signature.asc
Description: PGP signature

Improve package search

[mikadoZero]

# Motivation

>From Ludovic Courtès response to bug#34828:
> "I would recommend against turning descriptions into lists of commands
> just for the sake of package search (we should instead have another
> mechanism to determine which package provides a given command) ..."

`guix package -s` often returns no useful results for a program that is
part of a larger multi program package with a different name.  This is
heightened by the very reasonable desire to prevent descriptions form
turning into lists of commands.

# Examples

Here two examples of programs that do not have useful package search
results:

`as` in `gcc-toolchain`
`recsel` in `recutils`

There are other programs that also have this issue.

# Proposed idea

* Add a "programs" field to package definitions that list the programs
  that are included in a package. 
* Include this field in search results.
* Have this field factor into the search result relevance scores.

# Implementation

I am not familiar with how package search works and do not know how
much work this would be to implement.

A requirement for a "programs" field could be included in package
linting.  I am not familiar with the inner workings of linting and do
not know how much work this would be to implement.

# Roll out

* New packages could be given the "programs" field when they are
  created.
  
* Existing packages that are being updated could be given the "programs"
  field.

* Existing packages with relevant irc questions or bug reports could
  be given the "programs" field.

* Existing packages without relevant irc questions or bug reports that
  are not being updated could remain unchanged.  This could save
  significant effort as many programs may never require the "programs"
  field to be added.

# Advantage

Allow users to better find what package includes the program they want
to install.

# Disadvantage

More effort required to package multi program packages.

I know that the coreutils package includes a very large number of
programs.  I do not know if there are many other packages that are also
as large.

# Feedback

This is an initial idea that would benefit from the input of others.

Given the uncertainties I mention in the Implementation and
Disadvantages sections this may not be a good solution for the
Motivation section.

Go build system updates and future work?

[Leo Famulari]

I just pushed a revamped Go build system with commit
e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.

The main change is that instead of putting the list of Go-language
dependencies store paths in the GOPATH environment variable, these store
paths are union-symlinked into the build directory, and GOPATH points
there.

This fixes the issue of spurious store references
 and should dramatically reduce the closure
size of certain Go packages. So now there is less reason to use bundled
libraries for Go programs.

I think we should consider another change in how we build Go software:
let's stop splitting up Go libraries instead sub-packages.

For example, the packages 'go-golang-org-x-net-ipv4' and
'go-golang-org-x-net-ipv6' are both from the same Git repo at
. We should just package
'go-golang-org-x-net'. It's unidiomatic to split them up. In practice, a
Go programmer would have cloned the Git repo into their Go workspace,
and would never have a "split view" of the x/net libraries.

Thoughts? I can work on this in the next week.


signature.asc
Description: PGP signature

Re: Request for commit access

[Alex Vong]

Hello all,

Laura Lazzati  writes:

> Hi Paul :)
>
>> I am looking forward to viewing the videos after I have cloned the
>> repository as a member.  Initially, I am not planning to make any
>> changes, just to make an estimate of the total speaking time.
> I more or less added what it took to me, but when you record even a
> draft because of the format, that would be the "real timing". I guess
> I told you but the only parts in which I did not record the audios was
> in the cli session videos. Now that I have a headset and the
> environmental noice is reduced quite a lot, I could try to add my
> voice to them, WDYT Guix? But for the slide videos, my voice and the
> transcript are enough for a reference :)
>
Just in case people don't know about it, there's a wonderful piece of
free software called audacity, which can be used for audio processing.

While I haven't tried it before, I believe it can be used for noise
reduction. (I myself mostly use audacity for fade in, fade out, loudness
normalization, changing tempo, adding silence and overlaying tracks.)

Hope it help :)

> Regards :)
> Laura

Cheers,
Alex


signature.asc
Description: PGP signature

Re: Request for commit access

[Laura Lazzati]

Hi Paul :)

> I am looking forward to viewing the videos after I have cloned the
> repository as a member.  Initially, I am not planning to make any
> changes, just to make an estimate of the total speaking time.
I more or less added what it took to me, but when you record even a
draft because of the format, that would be the "real timing". I guess
I told you but the only parts in which I did not record the audios was
in the cli session videos. Now that I have a headset and the
environmental noice is reduced quite a lot, I could try to add my
voice to them, WDYT Guix? But for the slide videos, my voice and the
transcript are enough for a reference :)

Regards :)
Laura

Re: Request for commit access

[Paul Garlick]

Hi Laura,

I am looking forward to viewing the videos after I have cloned the
repository as a member.  Initially, I am not planning to make any
changes, just to make an estimate of the total speaking time.

I will update on progress and post any questions or comments on the
'Video narration' thread.

Best regards,

Paul. 

Re: Status update on 1.0

[L p R n d n]

Hello,

"pelzflorian (Florian Pelz)"  writes:

> On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
>> mikadoZero  writes:
>> 
>> >>   • “GuixSD” has been removed from the web site and from almost all of
>> >> the source code.  Still need to fix the file names that appear in
>> >> Makefile.am.
>> >
>> > Is it to be changed to "Guix SD"?
>> 
>> Just “Guix system”.
>> 
>
> In the manual I sometimes see “Guix System” with a capital S.  Which
> is correct?
>
> When doing translations, should the English name be kept as a proper
> name as with GuixSD?  I would prefer to translate it to a German
> “Guix-System” (with hyphen) to avoid misunderstandings (many Germans
> would read an English “Guix System” with German pronunciation anyway).
> For other languages “Guix Système” or maybe “Guix 系统” or so of
> course does not resemble the guix system command as much anymore.
>
> Regards,
> Florian

Seems I sent an empty message. Sorry...
So I was just saying I was in favor of translating "system" in Guix
system and probably without capital "S" but not sure really.

Have a nice day,

Lprndn

guix download seem to very slowly recently in China

[tumashu]

1-2 month ago, guix download become very quick, 500k/s - 1M/s,
now, down to about 20k/s, does any thing happen?