GSoC 2019

[Gábor Boskovits]

Hello,

Ludo created the GSoC ideas page for this year:
https://libreplanet.org/wiki/Group:Guix/GSoC-2019

It is based on last year's page.

I removed the Cuirass Web Interface project, as it was completed. We
can discuss a project to improve it, but that would need repharsing
anyway. Would anyone like to propose something related to that?

I also removed the Daemon Rewrite project, as reepca is working on
that as an University project.

I would like to ask people who offered to be mentors last year to
review, and notify us if they can't mentor. I intend to notify the
gnu-soc mailing list about the new page no eariler than 2019.01.30,
12:00 UTC.

Anyone is welcome to add more project ideas to the page, if you would
like to propose something, please do so.

Best regards,
g_bor

Re: Matrix & Nheko Packaging

[Nicolas Goaziou]

Hello,

Maxim Cournoyer  writes:

> It's already packaged in Guix as emacs-matrix-client, no?
>
> I tried it myself before, but it was not performing well (it was very
> slow).

"matrix-client" is already packaged, indeed. 

Unfortunately, at the moment, there are some hiccups with the build
process, and the library is not usable without a tweak. I sent a fix
upstream a few days ago, and I'm now waiting for them to apply it. If it
takes too long, I will simply patch it in the package definition.

> I ended up using a Weechat relay + SSH connection, which works very well for 
> my needs.

There is another Matrix client for Emacs, Maelstrom[1]. I didn't test
nor package it yet, but it would be good to look into it.

Regards,

Footnotes: 
[1]  .

-- 
Nicolas Goaziou

“Which important packages fail to build?”

[Ludovic Courtès]

Hello Guix!

I’ve just added a new ‘--coverage’ option to ‘guix weather’.  The goal
is to answer the question: “which important packages fail to build?”, or
at least, “which important packages have no substitutes?”.  I believe
this is what we want to know in particular to determine whether a branch
can be merged.  Demonstration:

--8<---cut here---start->8---
$ ./pre-inst-env  guix weather --substitute-urls=https://ci.guix.info -c 10
computing 8,983 package derivations for x86_64-linux...
looking for 9,343 store items on https://ci.guix.info...
updating substitutes from 'https://ci.guix.info'... 100.0%
https://ci.guix.info
  64.7% substitutes available (6,048 out of 9,343)
  18,642.5 MiB of nars (compressed)
  54,068.6 MiB on disk (uncompressed)
  0.018 seconds per request (164.6 seconds in total)
  56.8 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
updating substitutes from 'https://ci.guix.info'... 100.0%
2502 packages are missing from 'https://ci.guix.info' for 'x86_64-linux', among 
which:
58  kcoreaddons@5.49.0  
/gnu/store/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
47  kcoreaddons@5.49.0  
/gnu/store/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
46  qgpgme@1.11.1   
/gnu/store/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1
37  perl-http-cookiejar@0.008   
/gnu/store/2npd0vs3ipyqms06kbgh7ialp9n0fr6m-perl-http-cookiejar-0.008
30  qgpgme@1.11.1   
/gnu/store/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1
26  ocaml4.02-ppx-deriving@4.1  
/gnu/store/siv42br9h06i1zhmmj6s2qian45zacgm-ocaml4.02-ppx-deriving-4.1
18  ruby-ansi@1.5.0 
/gnu/store/p5adbp7bhvjzpjxr8brnfm52imqc4f07-ruby-ansi-1.5.0
16  cl-rt@1990.12.19
/gnu/store/vs9ddw7avffmnzxcknvyazay29vihy28-cl-rt-1990.12.19
16  ecl-rt@1990.12.19   
/gnu/store/765znwnf4bxdaz82akx60pkx2ac59fyn-ecl-rt-1990.12.19
13  ecl-trivial-gray-streams@0.0.0-1.0483ade
/gnu/store/lyj6w0p9v3kfkzmar1pd46qlg36zp7dd-ecl-trivial-gray-streams-0.0.0-1.0483ade
11  ruby-brass@1.2.1
/gnu/store/jxf63lbwv2rg95pf5zmznjzv8s367xqc-ruby-brass-1.2.1
11  ruby-rspec-expectations@2.14.5  
/gnu/store/6dacx02mn2skwbiajfwnx1q0fk5iw05y-ruby-rspec-expectations-2.14.5
11  ruby-rspec-mocks@2.14.6 
/gnu/store/9lirirccwslkghpps1al23m7pdi5yw1b-ruby-rspec-mocks-2.14.6
11  ruby-rspec-core@2.14.8  
/gnu/store/xrpaql4jldvvd08im37x8k42crsxpip0-ruby-rspec-core-2.14.8
11  ecl-slynk-boot0@1.0.0-beta-2.cbf84c3
/gnu/store/l23p319knfzygsc38zxf7l5g892bqy1z-ecl-slynk-boot0-1.0.0-beta-2.cbf84c3
11  python2-oslotest@3.4.0  
/gnu/store/7f87w09iinxv06dld394x7w47chcy3ip-python2-oslotest-3.4.0
10  pt-scotch@6.0.5a
/gnu/store/gw4mzjlwlf010ijhyznhr5sjmpxizl9v-pt-scotch-6.0.5a
--8<---cut here---end--->8---

What we see here is that on current master, kcoreaddons and (presumably)
the 115 packages that depend on it¹ have no substitutes.  Likewise for
qgpgme and its 76 dependents.

As it turns out, these two packages fail to build:

  
https://berlin.guixsd.org/log/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
  https://berlin.guixsd.org/log/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1

If you fix them, you’ll unlock no less than 191 packages and surely
fellow hackers will acclaim you when you arrive at the Guix Days.  :-)

In some cases, like ‘ocaml4.02-ppx-deriving’, it seems the package
simply hasn’t been built, for obscure reasons that build farm admins
should investigate.

Anyway, I think we should start looking at info, in particular so we can
finally get our act together and merge ‘staging’!

Feedback welcome!

Ludo’.

¹ Why do kcoreaddons and qgpgme appear twice?  Because there are two
  distinct (in the sense of ‘eq?’) package objects for each of these,
  even though they map to the same derivation.  The redundant package is
  introduced by ‘package-input-rewriting’ in kde-frameworks.scm.  Oh well!

Re: build failed: acquiring/releasing lock

[Manolis Ragkousis]

Hello Rene,

madvise() is not implemented on GNU/Hurd and I had once started
implementing a fix for guile [1]. We need to restart that old thread and
find a correct solution to this.

In the meantime you could use that patch for guile as a workaround.

Manolis

[1] https://lists.gnu.org/archive/html/guile-devel/2017-06/msg0.html

On 1/25/19 6:23 AM, Rene wrote:
> Hello,
> 
> I have the following error in Debian/Hurd; I have reviewed the file 
> `nix/libstore/pathlocks.cc` but I do not finish by understanding how it works.
> 
> ---
> ./pre-inst-env guix build hello
> madvise failed: Function not implemented
> madvise failed: Function not implemented
> guix build: error: build failed: acquiring/releasing lock: Invalid argument
> ---
> 
> Attached the log, rpctrace.
> 
> Thank you
> Rene
> 

Removing greenisland?

[Ricardo Wurmus]

Hi Guix,

the greenisland package cannot be built.  The upstream repository has
been archived and its replacement has also been archived.  The work is
supposedly merged back into QtWayland.

Since no package depends on greenisland I suggest removing it.

--
Ricardo

Re: “Which important packages fail to build?”

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve just added a new ‘--coverage’ option to ‘guix weather’.  The goal
> is to answer the question: “which important packages fail to build?”, or
> at least, “which important packages have no substitutes?”.  I believe
> this is what we want to know in particular to determine whether a branch
> can be merged.

Very nice!  This will be very useful.

> As it turns out, these two packages fail to build:
>
>   
> https://berlin.guixsd.org/log/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
>   https://berlin.guixsd.org/log/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1

I just fixed the qgpgme test failure on master and staging.

-- 
Ricardo

Re: “Which important packages fail to build?”

[Christopher Baines]

Ludovic Courtès  writes:

> Feedback welcome!

This looks great, thanks Ludo!


signature.asc
Description: PGP signature

Re: Removing greenisland?

[swedebugia]

Ricardo Wurmus  skrev: (25 januari 2019 14:24:11 CET)
>Hi Guix,
>
>the greenisland package cannot be built.  The upstream repository has
>been archived and its replacement has also been archived.  The work is
>supposedly merged back into QtWayland.
>
>Since no package depends on greenisland I suggest removing it.
>
>--
>Ricardo

Sounds resonable to me.
-- 
Sent from my p≡p for Android.

Listing all packages with --search now impossible

[swedebugia]

Hi

Yesterday when I played around with guix I noticed that the default 
behavior of

$ guix package --search
guix package: error: invalid argument: Missing required argument after 
`--search'


has changed recently from showing all packages to now showing none.

also:

$ guix package --search *
guix package: error: invalid argument: Missing required argument after 
`--search'


This is a bug. "*" should match everything.

Is this intentional?

This means that now users have to know guile to list all packages with 
all the fields. :/

--
Cheers
Swedebugia

GuixDays: Perfect Setup: Speaker wanted

[Björn Höfling]

Hi,

on the page for the Guix-Days I added this one:

Demonstration and explanation of The Perfect Setup (Emacs, Geiser, Magit)

The reason is that I failed working with the Perfect Setup. So, is
there anyone who like to show what's so perfect about that setup and
how to set it up?

Thanks,

Björn



pgpSdmmXkEEuE.pgp
Description: OpenPGP digital signature

Re: Listing all packages with --search now impossible

[Ricardo Wurmus]

Hi swedebugia,

 writes:

> Yesterday when I played around with guix I noticed that the default
> behavior of
> $ guix package --search
> guix package: error: invalid argument: Missing required argument after
> `--search'
>
> has changed recently from showing all packages to now showing none.
>
> also:
>
> $ guix package --search *
> guix package: error: invalid argument: Missing required argument after
> `--search'
>
> This is a bug. "*" should match everything.

This is not a bug.

The argument must be separated from the option with an “=”.  The second
problem is that “*” is not a regular expression but a shell glob
pattern.  You need to provide a regular expression.  This works:

guix package --search=.*

-- 
Ricardo

Re: “Which important packages fail to build?”

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

>> As it turns out, these two packages fail to build:
>>
>>   
>> https://berlin.guixsd.org/log/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
>>   
>> https://berlin.guixsd.org/log/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1
>
> I just fixed the qgpgme test failure on master and staging.

Woohoo!  Now *you* will be acclaimed when we meet in Brussels!

Ludo’.

Re: build failed: acquiring/releasing lock

[Ludovic Courtès]

Hi,

Manolis Ragkousis  skribis:

> madvise() is not implemented on GNU/Hurd and I had once started
> implementing a fix for guile [1]. We need to restart that old thread and
> find a correct solution to this.

Note that the “madvise failed” message is not fatal; nevertheless, I’ve
fixed it in Guile (will be in Guile 2.2.5):

  
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=45e4ace6603e00b297e6542362273041aebe7305

Ludo’.

Re: Overview of build machines

[Ludovic Courtès]

Hi,

swedebugia  skribis:

> I just found a thread from september about adding more arm build machines.
>
> How did it go?
>
> Is there a list of all our build machines and locations somewhere?

Yes, you can find details here:

  https://www.gnu.org/software/guix/donate/
  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/machines.rec

HTH,
Ludo’.

Re: Changes in the spending committee for the FSF Fund

[Ludovic Courtès]

Hi,

Gábor Boskovits  skribis:

> swedebugia  ezt írta (időpont: 2019. jan. 24.,
> Cs, 23:04):
>>
>> On 2018-09-08 17:11, Christopher Lemmer Webber wrote:
>> > Ludovic Courtès writes:
>> >
>> >> Thanks Mark for your time on the spending committee, and welcome Tobias!
>> >
>> > Yes, thank you both!
>>
>> Thanks to you all for doing this work.
>>
>> It would be nice I think to have transparency towards the community.
>> Given the very large donations I think this is important.
>>
>> Are the decisions of the committee public and published somewhere?
>>
>> Is there a public account balance also somewhere and a list of prior
>> spendings so we can get an overview?
>>
>
> I believe this information is available in the maintenance repository.

There’s a ledger for the Guix Europe non-profit¹, which is a separate
entity, but most of the transactions on the funds held at the FSF have
been made via Guix Europe.  Another use of the FSF fund has been the
Outreachy internship (that predates the recent donation by Handshake and
the change on the spending committee.)  I think it’s now time to add a
new ledger to write this down.  Tobias, Ricardo?

Thanks,
Ludo’.

PS: guix-fina...@gnu.org is an alias for the spending committee members.

¹ 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/accounting/accounting.ledger

Re: Current state of cargo-build-system

[Ivan Petkov]

Thank you all for the responses!

> Cycles.  Also, often Cargo.lock specifies exact versions of dependencies (in
> programs, at least)

Yes, this is pretty much the main issue I immediately hit when doing a naive
crate import, more on this further down.

> First, we'd have to find out what kind of things Cargo can build and how to
> detect it.

Cargo supports a subcommand called `metadata` which essentially dumps its
manifest in JSON format, which will include build scripts, binary outputs, etc.
I think this should give us enough information to figure out which packages have
targets to install (right now we try to install every single package which
doesn't work for libraries) among other things.

> After that, we can decide whether to compile libraries or just ship them as
> source (right now, we do the latter pretty often - almost everything in Guix
> Rust library packages ends up in the "src" output).
>  
> Getting the unit tests to run often requires breaking many cycles, so maybe
> skip that at first.

I tried breaking up cycles by hand for a couple days on another sample import,
but its just too tedious and error prone, especially when cycles span multiple
packages...  I'd really like for us to solve the issue altogether if possible.

Cargo (thankfully) checks and rejects an true dependency cycles, but its
notion of dev-dependencies (deps only used for running tests) is what throws
guix in for a loop. Dev-depencency cycles are permitted by cargo because it
builds the target crate independently, then it builds any extra dependencies
which may or may not depend on it, and then it builds a test crate which depends
on both. There are potentially legitimate cases which trigger this scenario
(such as testing your own public API through an upstream crate, see proc-macro2
for an example), or are just exacerbated by optional dependencies.

I think depending on the "src" output of crates is the right way to get things
started (this is what cargo essentially does anyway, it figures out what crates
are in the dependency, pulls their sources down and builds them), we can always
optimize this in the future to avoid recursively rebuilding crates over and
over.

However, it appears that guix still insists on building the entire package even
if we only depend on the "src" output. Is it possible to lazily build packages
based on the type of dependency? Is this something the build system can finagle,
or is this an inherent limitation to guix?

--Ivan

Re: Adding versioning to our recursive importer

[Ivan Petkov]

I’m interested in this as well, this is something the cargo importer will 
greatly benefit from too.

—Ivan