Re: Commit access

[Brett Gilio]

Miguel Ángel Arruga Vivas  writes:

> Hello, everybody!
>
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits.  This text has been signed with
> it, which has the following information and fingerprint:
>
> pub   rsa3072 2020-09-09 [SC] [expires: 2022-01-01]
>   888784C41459ACCB83E7E84C634C6E8979FABEC2
> uid   [ultimate] Miguel Ángel Arruga Vivas 
> sub   rsa3072 2020-09-09 [E] [expires: 2022-01-01]
>
> Happy hacking!
> Miguel
>

Welcome!

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Re: Did nmap just become non-free?

[Brett Gilio]

zimoun  writes:

>
> It will be interesting to know what FSF licensing will say.
>

Indeed, this may need to be opened on the FSDG mailing list.

-- 
Brett M. Gilio

https://brettgilio.com

Re: Specifying dependencies among package outputs?

[Brett Gilio]

Simon South  writes:

> Am I right in thinking there is no way to specify dependencies among the
> outputs of a single package? To specify that a package's "out" output
> depends on its "lib" output, for instance.
>
> I ask because the Knot package (in gnu/package/dns.scm) builds a number
> of logically distinct targets---daemon, libraries, administrative
> utilities, general-purpose utilities, and documentation---and it would
> be nice to separate at least some of these into individual outputs, in
> part because we could then specify only the libraries as a dependency of
> Knot Resolver.
>
> However, Knot's daemon and utilities have the same dependency on its own
> libraries, so pulling those into a separate "lib" output would be liable
> to break everything else.
>
> I've searched and can't find an example of this being done, nor can I
> find any mention of it in the documentation. So I assume it's simply not
> possible, and you would need to define an entirely separate package that
> builds from the same source code---right?

Unless I am mistaken, this is not possible. When using a specific
output, it still fetches the entire package closure. But only that
specific output propagates to the profile. Adding an output as a
dependency would surely cause a non-termination situation with the
interpreter.

I have cc'ed guix-devel as I think that is the better fit for this
question.

Best


-- 
Brett M. Gilio

https://brettgilio.com

Re: Did nmap just become non-free?

[Brett Gilio]

Marius Bakke  writes:

> Having re-read the original text (without the annotations), the thing
> that stands out is:
>
>   Proprietary software companies wishing to use or incorporate Covered
>   Software within their programs must contact Licensor to purchase a
>   separate license. Open source developers who wish to incorporate parts
>   of Covered Software into free software with conflicting licenses may
>   write Licensor to request a waiver of terms.
>
> From .
>
> So a "proprietary software company" cannot use or incorporate nmap
> within a program, even if that program is free (as in software)?

I believe that clause about "proprietary software companies" (if such a
thing could even be defined, legally) violates freedom 0.

Do let me know what the licensing lab says.

-- 
Brett M. Gilio

https://brettgilio.com

Re: Did nmap just become non-free?

[Brett Gilio]

Marius Bakke  writes:
>
> ...I'm fairly certain this is not an acceptable license for Guix, or
> free software distributions in general.
>

This is definitely not a consistent license for us.

> So I think we should revert the license change, as well as the update
> to 7.90 which introduced the new license.
>
> Now to read the previous license text, perhaps that will help me sleep..
>


As to how to fix it, I think we will need to revert the change, and also
make note of the FINAL version of nmap that was still compliant with FSDG.


-- 
Brett M. Gilio

https://brettgilio.com

Re: Outreachy internship

[Brett Gilio]

Joshua Branson  writes:

>
> I personally think it would be great to see some improvement to the GNU
> Shepherd.  It could use some love.  :)
>

+1

-- 
Brett M. Gilio

https://brettgilio.com

Re: Add the librewolf webbrowser to the guix packages

[Brett Gilio]

romulasry  writes:

> A fork of Firefox, focused on privacy, security and freedom.
>
> https://gitlab.com/librewolf-community/browser/common
>
> Sent with ProtonMail Secure Email.
>

Have you taken a crack at trying to package it? If so, perhaps it would
best to submit a patch and host it from a channel in the meantime.
Otherwise, please feel free to submit it to our wishlist [0]. I am not
familiar with this browser, so hopefully it is fully compliant with our
requirements (sic. the FSDG) [1], which means removing DRM. Is that the case?

-- 
Brett M. Gilio

https://brettgilio.com

[0] https://libreplanet.org/wiki/Group:Guix/Wishlist
[1] https://www.gnu.org/distros/free-system-distribution-guidelines.en.html

Re: Guix Europe yearly assembly minutes increasing membership

[Brett Gilio]

Joshua Branson  writes:

>
> One quick way to do this, may be to sign the user up to be a member of
> the FSF.  Becoming a member of guix, would transparently sign them up to
> be an associate member of the FSF, which would give them the 5 email
> aliases, an irc nick, and I think a meet.jit.si instance.
>

Do you mean an IRC Cloak?

Brett Gilio

Re: Hello from new Outreachy applicant

[Brett Gilio]

Lulu  writes:

> Hello everyone,
>
> My name is Lulu and I'm a DevOps engineer and Scheme hobbyist from
> Turkey. I just got accepted to Outreachy and I would like to
> contribute to GNU Guix. My pronouns are they/them and my timezone is
> UTC+3. I go by `erkin' on Freenode and GitHub.
>
> Looking forward to working with you!
>
> --
> Lulu (they/them)


Hey Lulu,

Pleasure to meet you. Congratulations on your Outreachy acceptance. Do
you have any ideas for what you might want to contribute? I am on
Freenode in #guix and open for privmsg under `brettgilio`

Best,
Brett Gilio

CUDF and race conditions

[Brett Gilio]

Hey all,

I am currently working on a new branch wip-ocaml to try and get our
ocaml packages to build against latest 4.11

For some reason, when building ocamlbuild against 4.11 there is a race
condition which is introduced where cudf fails to build. I can not seem
to decipher how to resolve the issue, though.

--8<---cut here---start->8---
Failure:
  Error during command "mkdir 
/tmp/guix-build-ocaml-cudf-0.9.drv-0/cudf-0.9/_build": 
Ocamlbuild_pack.My_std.Exit_with_code(10).
make: *** [Makefile:61: _build/cudf.cma] Error 2
--8<---cut here---end--->8---

I did manage to find this relevant issue though:
https://github.com/ocaml/ocamlbuild/issues/300.

Any help would be appreciated.

Brett Gilio

Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.

[Brett Gilio]

Mark H Weaver  writes:

> Agreed, or perhaps 'emacs' itself should have been updated on a separate
> branch.

+1 for WIP-emacs branch in future.

Brett Gilio

Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.

[Brett Gilio]

Ludovic Courtès  writes:

> Hi Morgan, Mark, and all,
>
> morgan.j.sm...@outlook.com skribis:
>
>> From: Morgan Smith 
>>
>> * gnu/packages/emacs.scm (emacs): Update to 27.1.
>> [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add
>> restore-emacs-pdump phase.
>> [inputs]: Add cairo, libxaw, jansson, gmp, and harfbuzz. Remove imagemagick
>> and libxft.
>> [native-inputs]: Add texlive.
>> (emacs-wide-int): Mark as deprecated package.
>> (emacs-no-x):
>> [arguments]: Add --with-jpeg=no --with-gif=no --with-tiff=no
>> to #:configure-flags.
>
> I see that Mark committed a similar patch just yesterday:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=36a09d185343375a5cba370431870f9c4435d623
>
> I suppose Mark hadn’t seen the ongoing discussion.
>
> Mark, Morgan: could you see if there’s anything we’re missing from the
> patch Morgan submitted?
>
> At any rate, thanks a lot for the work everyone put in!
>
> Ludo’, a happy Emacs user.

Also, are we planning to keep emacs-next and have it track 28.x or
remove it?

Brett Gilio

Re: Praise for `guix import`

[Brett Gilio]

Josh Marshall  writes:

> Hello all,
>
> I've been quiet these past few months with a move, new job, and stuff.
> I'm doing a write up for my new work.  Came across `guix import`.
> Great work there, and definitely a time saver.

Thanks for the appreciation, Josh! The importers are some of the
toughest components to keep functional, along with `guix refresh`. If
you ever run into trouble with either of these, or wish some feature or
additional importer/refresh module were available definitely drop us a
bug report!

Brett Gilio

qemu-binfmt-service failing to identify compilers

[Brett Gilio]

Hi all,

When I try to test guix builds for other architectures using the
qemu-binfmt-service and the --system flag, the configuration step is
failing to identify the compiler with the CMake build system. I did some
investigating, and it appears this is a failing test in CMake itself but
it causes packages to fail on build. This seems to only be the case when
compiling for foreign architectures, as building on the true
architecture seems to work (as in the Guix CI).

--8<---cut here---start->8---
CMake Error at 
/gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26
 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  
/gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211
 (compiler_id_detection)
  
/gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230
 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  
/gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32
 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  
/gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111
 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:5 (project)


-- The CXX compiler identification is unknown
-- Check for working C compiler: 
/gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc
-- Check for working C compiler: 
/gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/c++
-- Check for working CXX compiler: 
/gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Unknown C compiler.  
--8<---cut here---end--->8---

when keeping the failing build, this is what I find in the CMakeError.log.

--8<---cut here---start->8---
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc 
Build flags: 
Id flags:  

The output was:
1
CMakeCCompilerId.c:20:52: error: expected ‘,’ or ‘;’ before ‘COMPILER_ID’
 char const* info_compiler = "INFO" ":" "compiler[" COMPILER_ID "]";
^~~
--8<---cut here---end--->8---

--8<---cut here---start->8---
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc 
Build flags: 
Id flags: --target=arm-arm-none-eabi;-mcpu=cortex-m3 

The output was:
1
gcc: error: unrecognized command line option ‘--target=arm-arm-none-eabi’
--8<---cut here---end--->8---

I am getting this error on both SWI-Prolog and Lean packages, both of
which I have needed to investigate on armhf and i686 because of failures
on those architectures.

I am not entirely sure how to proceed with these issues.

Any help? Thanks.

Brett Gilio

New Signing Key

[Brett Gilio]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all,

As per my email a few days ago, I have lost control of my signing key. I
have, as per instructions, refreshed the key on Savannah and am signing
this email.

I have familiarized myself with the changes to the contribution process,
and am looking forward to getting back into the groove! Thanks a bunch
for those who reached out, and those who kept in touch with me during my
hiatus.

Brett Gilio
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE6CrAJpXW/wJDyh5c9sUt0bony4cFAl8Q5rIACgkQ9sUt0bon
y4c4aggAr0/x2mhwJRRljrDmO0UC/jEV0VwH8TKBMZz60w8MLiJJYwiFyTSL4cJx
sE/Eo/b5B7kEw+nyPNvuw7qXAy8ie80S6frZ9/QrI3Q6ViEV274qex5YeCQfdnbf
oM+1ALAQsbG2wGh6TutdKFEx7vtbCefx/0QxHfj2dYD8nZ+SwoBma8jvogDcubxy
4mGhTqjEuoucJgGN5FwUFf2IimwgSN7O708rIPpcf3QTV0QM3t3bxIGQDnHJr8pb
xQTDsFySBzmZnGyHJVtDSUr+3TE1w11ZMVHd0dcX78STjJkEV3BcGcICOLVszJ2m
bBrUt82L6JU/Dgwjl6KYr3ZezRrHCQ==
=CU3q
-END PGP SIGNATURE-

OCaml 4.09

[Brett Gilio]

Hey all,

Short message! I am trying to get our OCaml development system up to
shape, as it is currently lagging some versions behind. I have opened a
wip-ocaml4.09 branch for this work. Here are some of the things that
need work that I have identified.

-- The opam importer needs revised and updated.

-- Basically all of the Jane Street components need reimported and
   modified.

-- The dune build system probably needs to be able to handle two
   versions of dune without complication.

-- We need to create some unison packages for things like
   dune-configuration.

-- Basically all OCaml dependent packages need to get rebuilt and
   tested, ensuring that test cases are also appropriately handled (some
   are disabled that could easily be enabled.)

-- Get our OCaml development components up to date and working, like
   ocamlformat, merlin, tuareg, the ocaml-lsp system (forked off of
   merlin).

-- Potentially add a Coq subimporter for opam.

-- Be able to have variant compilers for ocaml-flambda (and the upcoming
   ocaml-multicore) switches.

If any of these tasks interest you, I challenge you to help! :). I am
trying my best to do it myself so far, but I am running on a very
limited amount of contribution time these next couple of weeks. This is
an important task, too, for us Formal Methods people in the Guix
community, as a lot of formal methods utilities run on OCaml.

Carry on! Thanks.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: Commit log for reverts

[Brett Gilio]

Jan 4, 2020 4:20:12 PM Ludovic Courtès :

> Hola!
>
> guix-comm...@gnu.org skribis:
>
>
> > commit a06a4f918243dc784f9089d60690559b72a4e308
> > Author: Brett Gilio
> > Date: Fri Jan 3 20:15:44 2020 -0600
> >
> > Revert "gnu: Add swi-prolog."
> >
> > This reverts commit 3f37f3909712eb7269b6e8184c0d61bfc61b67f9.
> >
>
> When reverting changes, I think we should always add a sentence possibly
> with a link explaining the revert, to make it easier to those of us
> reading guix-commits and to our future selves looking at the commit log
> and wondering what was going on back then. :-)
>
> Thoughts?

Hey Ludo, yes that makes sense! Thanks for the suggestion. :)

>
> (Anyhow, I’m glad SWI-Prolog eventually made it!)
>
> Thanks,
> Ludo’.
>

Me as well. I am working on mercurylang.org now, which is like Prolog and 
Haskell mixed.


-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: new micro release to address bug 36074 for new binary installs on foreign distributions with systemd

[Brett Gilio]

Jan 3, 2020 9:16:58 AM Ludovic Courtès :

> Independently of that, I’d like us to put out a new release within a few 
> weeks!
>
> Ludo’.

+1.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Dec 30, 2019 3:34:22 PM Ludovic Courtès :

> Guix-HPC is “institutional”, that’s part of the reason behind this.
> Regarding gitlab.inria.fr, that’s because it used to be hosted at Inria.
> Also, is a channel developed
> by colleagues at Inria, so it’s more convenient to have it there.


Hey Ludo, thanks for the explanation.

It makes sense why Guix-HPC lives somewhere else. Given this, what do you 
propose for initiating the conversation on where the formal methods haunt page 
should live with the other maintainers? I personally think the repository 
should live on Savannah, but the address needs to be discussed.

Any other maintainers reading this, please feel free to weigh in.


-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Ludovic Courtès  writes:

> For the record, I don’t work with the formal methods people at Inria,
> but we chat occasionally, and I’d be happy to draw their attention to
> this effort.  :-)

I thought not, but I think this smells of potential for collaboration
maybe amongst a few there. I know some INRIA people from the Caml and
Coq community, so I think if they see a notification both internally and
externally of what is happening with this proposal (after we establish
it a bit more) it has the potential to get some attention.

> That’s sounds very ambitious, though it’s not like people here haven’t
> been ambitious so far.  ;-)

It is absolutely an ambitious task, and is definitely a daunting one to
try and make happen. I do have some experience with compiler
construction, but nothing quite to this extent. Amin and I have been
trying to establish connections with other people who might share this
goal, and from what we've received it is _this_ particular task of
making a bootstrapping compiler for ML that seems to be the most
attention-getting. There is definitely a need here, we realized. So, if
we are able to garner enough people to help make this task more
manageable then I say it is in the realm of possibility and will prove
useful for Guix.

> Note that there’s an alternative tradition of theorem provers in Lisp
> with ACL2, “The Little Prover”, etc.

I am familiar :). The Little Prover and the Little Typer are
foundational to my interest here. I have not considered ways to include
them, so food for thought!


> I agree with Julien that a separate IRC channel is unneeded at this
> stage; as for the structure, I would start with a web page explaining
> your areas of interests, similar to the Guix-HPC thing.
>
> To me, an important goal is to create ties with formal methods people,
> and to increase the bandwidth between us.  That can beget new ideas and
> perspectives.
>
> Then there are specific areas where we should be discussing: compiler
> bootstrapping (what can OCaml, GHC, SMLNJ, etc. developers do to make
> their compilers bootstrappable?), package management (how to turn OPAM,
> etc. into functional package managers, or how to get language X to use
> Guix instead of rolling its own?), development facilities (‘guix
> environment’, channels like Julien’s Coq channel), and so on.
>
> These things take time and we don’t necessarily have an idea what the
> outcome should be, but it’s definitely worthwhile.

Agreed! 100%. We have a lot of lateral connection making to do, and I
will help foster that any way I can. By the sound of it, Amin has
already been working with some of the Lean prover people on Zulip to see
what is possible for attracting some attention there. I will do my part
on this as well, and once we get an organizational page made for the
working group at whatever address it exists at, I think we will be able
to get some cross-pollination like we need. I definitely want to do this
the "right way".

Thank you Ludo for your help!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Ludovic Courtès  writes:

> The domain name would have to be discussed with others (other
> maintainers in particular; perhaps a better choice would be
> formal-methods.guix.info or fm.guix.info, next to hpc.guix.info), but
> the idea sounds great to me!

That is, of course, reasonable that we should pass this along for a
community decision among the maintainers. Though, I do wonder a bit
about the HPC project in its decision to host its domain on *.guix.info
and use the Gitlab instance instead of Savannah for developing the haunt
page? I am making an assumption it is for historical reasons, rather
than it being intentionally to distance itself from our relationship
with the GNU project, but I would like to know the story behind this
decision.

I am personally not partial to either domain: fm.guix.info or
fm.guix.gnu.org. I just wonder about how that original decision came
about :).

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Ludovic Courtès  writes:

> Hi!
>
> Julien Lepiller  skribis:
>
>> I'm afraid OCaml is not bootstrappable. It uses a bytecode version of
>> itself (using a bootstrapped bytecode interpreter written in C) to
>> build itself. Fortunately this situation is being worked on by a phd
>> student of Xavier Leroy (and nixOS user) :).
>>
>> The plan is to write a compiler in C or Scheme (it currently exists,
>> but is written in OCaml) for "miniML" a small subset of the OCaml
>> language. Then, there is already an interpreter in miniML able to
>> interpret the OCaml compiler compiling itself. Once the miniML
>> compiler is bootstrapped, we will have a path from C to OCaml :)
>
> Do you have pointers to this work?
>
> Hannes of MirageOS also mentioned it at the Reproducible Builds Summit.
> It sounds exciting!
>
> Ludo’.
>

I am also interested in this. MirageOS has a long lineage of making
sensible decisions in their development aside from just designing their
unikernel. So i'd really like to see if this becomes a possible bridge
from C or Scheme to a bootstrappable OCaml. For what I wonder, I think
this is something a formal methods community in Guix would be able to
contribute to so we see to it that GNU Guix has a good foundation for
making OCaml properly bootstrappable.

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Ludovic Courtès  writes:

> Hi!
>
> Julien Lepiller  skribis:
>
>> I forgot to metion I have a small channel at
>> https://framagit.org/tyreunom/guix-coq-channel that keeps track of
>> every coq version since 8.6. I use it to test my coquille plugin on
>> every coq version that exists, but I'm sure there are other use cases
>> :)
>
> That’s an interesting kind of channel that’d be worth promoting (I think
> many people have similar needs for their CI.)  If you feel like writing
> a blog post over the holidays…  ;-)
>
> It’s also a very concrete item that’s directly useful to formal methods
> people, a good way to create ties.

100% Agreed. Amin is also working on packaging the Lean prover and I am
taking an interest in seeing if we can extend the OPAM importer to have
a subimporter for Coq.

Ludo, what do you think about an https://fm.guix.gnu.org/ URL hosting a
haunt webpage designed by Amin and I (and maybe others) to detail the
purpose, goal, and maybe institutional use cases (research papers) of
GNU Guix in the formal methods community?

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Happy Holidays!

[Brett Gilio]

Hey there, GNU Guix!

I just wanted to take a moment to wish all of us (religious,
irreligious, and of varying spiritual groups) a happy holidays! GNU Guix
has become a home to me as a programmer, and a growing researcher. I
have made GNU Guix a crucial part of my computing life, and I consider
so many of you to be close friends of mine.

I especially want to remind us how fortunate we are to have people like
Ludovic, Ricardo, David, Andreas, Tobias, Marius, Danny, and Maxim
leading this project in a direction that basically no other projects
have dared to go. We have really taken our collective expertise, and
love for free software, to an unprecendented level.

I also want to take a moment to name drop (and remind) of the Formal
Methods in GNU Guix working group proposal, and thank Amin Bandali,
Simon, Leo Prikler, Jack Hill, and Janneke for their support as I have
been emailing you all countless times asking for support. Your feedback
as been always appreciated and so insightful. Genuinely, thank you! I
hope we can begin to see formal methods become more of a staple to our
innovative system.

To everybody else, thank you for working with me as I learn the ropes of
how to be a better contributor to this project. Your patience with me is
appreciated.

Happy Holidays, eat well, and love GNU!

-- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Amin Bandali  writes:

> Hello Guix!
>
> Thank you Brett for taking initiative and putting this awesome proposal
> together on all our behalves, and to everyone else for chiming in and
> expressing your interest and support!
>
> To share some of my (scattered) thoughts on this, as a researcher I
> think reproducible and verifiable research is a crucially important
> topic, yet traditionally and often a neglected one.  Throughout my
> graduate studies, too many times I stumbled on papers with interesting
> claims that I sadly could not reproduce or easily verify for myself.
> And I think this is especially ironic and painful for those of us doing
> research in formal methods, computing science, and software engineering;
> and is where projects like GNU Guix with their awesome efforts in
> reproducibility could act as role models and show what's possible.
>
> For instance, for better or worse many of the tools I have worked with
> over the last few years are primarily implemented in Java, often in form
> Eclipse plugins.  Suffice to say that release management, bundling, and
> distribution practices of most of these tools leave a lot to be desired.
> As part of the Formal Methods in GNU Guix Working Group, I'd love for us
> to try and get in touch with the developers of these tools and offer to
> work with them to challenge and improve the status quo, resulting
> ultimately in more readily and easily accessible tools, greatly useful
> for verifying and reproducing existing literature.
>
> As Brett and I alluded to, there's a large variety of tasks in all
> shapes and sizes that could use your help, from more "researchy" work
> like writing a bootstrapping SML '97 compiler, or exploring synthesis
> and verification for GNU Guile and GNU Guix, to less researchy ones like
> packaging (even more) formal methods-related software and helping their
> developers improve their release and package qualities.
>
> We would love to hear more from you about this in trying to gradually
> put together actionable plans.  If you'd like to chat with us, please
> come say hi to us in the #guix IRC channel on freenode.  My nick there
> is bandali, and Brett is brettgilio.
>
> Best,
> amin
>

Hello, everybody!

Thank you, Amin for your substantial contribution in this last email. I
am 100% in agreement with your assessment, and there is definitely a
plethora of work to be done here!

To kick-start the project I am wanting to make some suggestions, mostly
pertaining to the organization and up-keep of the working group.

1. Just as the bootstrappability and guix-hpc projects have their own
websites documenting their efforts, I think it would be nice to have
https://fm.guix.gnu.org/ which would host a Haunt-generated
website. This website would be hosted in the Savannah project structure
for GNU Guix. This would document who is active in the coordination and
oversight of this working group, and would express a clear and mutual
relationship with the GNU Guix / Guix System project.

2. Perhaps we should adopt a particular tag for the Guix Debbugs
tracker, so as to be able to clearly delineate that this particular
patch or bug is in relation with the formal methods working
group. Maybe something like [FM].

3. It was suggested that maybe a #guix-fm IRC channel might be useful,
but we have had a mixed bag of opinions on this. I personally think that
keeping everything together is the better solution, but I'd still like
to hear acceptance or criticism of this idea.

4. A lot of documenting working group milestones (Working on a Coq
sub-importer for OPAM, writing a bootstrapping compiler for SML97,
doing regular packaging duties for formal methods projects,
communicating upstream about distribution package quality, and perhaps
even trying to do formal methods work via synthesis in GNU Guile / GNU
Guix would be likely best expressed on the mailing list, and the
https://fm.guix.gnu.org/ website, but this likely rests in the hands of
the GNU Guix maintainers, of which I am not.

5. Additionally, maybe making an introductory post on the
https://guix.gnu.org/ blog about the preliminary goals of the working
group, after having our own subdomain established, would be a good way
to attract some attention to the project by distributing links to it on
HackerNews, Reddit, and Formal Methods/Functional Programming-related
mailing lists.

Anyways, I am going to CC Ludo' in this message to see what he might
have to say about these proposals.

Thanks for everybody who has chimed in!

- -- 
Brett M. Gilio
GNU Guix, Contributor | GNU Project, Webmaster
[DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]
 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE38DH957mDKeuVV4ZZyJDxKA/Du4FAl3+sdcACgkQZyJDxKA/
Du7YyhAAqEZqbOO1W37xKvd8EztAp/dYJ1Q9Bt/mw9eH0Aj95lxkFQkl9Iq+Bvqa
DGPiVeyR7nOn/AtKdZMwrgz9xZXE43pQ1C8IV8+Jbssv9l3G2UQdzwIiP4YyFKum
Lj7kkNEKC5GZ9CpgMcSHGevmW+YpTcTIVOZWFve/4eera27Ds9RMgME8q8FaKKLt

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Brett Gilio]

Dec 17, 2019 7:34:17 AM Kyle Meyer :

> G�bor Boskovits writes:
>
>
> > Konrad Hinsen ezt �rta (id?pont: 2019. dec.
> > 17., Ke 7:52):
> >
> [...]
>
> >
> > > How about a more drastic measure: deprecate "guix environment" and
> > > introduce a new subcommand with the desired new behaviour?
> > >
> > >
> > That is also the other option I was thinking about. Do you have any good
> > idea in mind as how to call it? Of course the classic guix environment2
> > comes to my mind, but it does not look very appealing to me.
> >
>
> Perhaps "guix env"?
>

+1 for guix env

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

John Soo  writes:

> Hey this is great!
>
> I’m a hobbyist too but I’m glad to see a formal methods community in Guix!  
> I’ll be following. 
>
> - John

Thank you for voicing your support John! Glad to see there is an
inspiring community following for this idea.

-- 
Brett M. Gilio 
GNU Guix, Contributor 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Jack Hill  writes:

> I'm not a formal methods researcher, but merely a hobbyist who is
> interested in programming languages and type system. That said, I find
> this proposal intriguing, and would like to follow along, and perhaps
> help as I am able. At the very least, I hope to learn some new things.

I am glad you say this. We all have a lot to learn from each other here.

> One of the things that attracted me to Guix is the ability to
> represent the pieces as objects in a programming language as opposed
> the the big mass of state that is a traditional system. I agree this
> property of Guix harmonizes with formal analysis.

Absolutely! This is the kind of thesis I was proposing, and something
that I wonder what Julien will think of as far as benefits particular
and specific to the formal methods community.

>> What follows is proposals for some of the work to be done by this
>> working group:
>>
>> -- A lot of proof assistants are based on dialects of ML. Most of these
>>   use SMLnj or MLton for their work. To date there is an issue of
>>   source-based bootstrapping of _all_ of the major ML compilers. We do
>>   have PolyML in our repositories, but even this uses space-inefficient
>>   text file blobs for compiling and is not a fully C-based source
>>   bootstrap. Basically, all of the ML compilers rely on some distinct
>>   pre-compiled something-or-other to get to their pristine state. I
>>   have explored the idea, along with Leo and Amin, about following in
>>   the tradition of MES (and mrustc) and starting an analogous GNU project for
>>   writing a reduced-size specification ML bootstrapping compiler. That
>>   way we can end the loop of a source-based build of ML97 compilers
>>   being basically impossible.
>>   [See issues #38605 & #38606 on DEBBUGS. Also, see
>>   https://github.com/MLton/mlton/issues/350.]
>
> This is the sub-area I'm most interested in. In addition to ML, I'd
> also like to be able to bootstrap GHC. I know that Ricardo has done
> some work in that area [0].
>
> [0]
> https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html

So far this idea has garnered the most attention. Amin Bandali and I are
both wanting to see this be taken to the next level, with maybe the
support of Janneke and other people working with minimal compilers /
formal methods in their day-to-day work. See some of my previous emails
to others about why I think this is important work. Basically, as I
mentioned to Ludo' the situation of bootstrapping ML from source is
occluded after 1993. We should reasonably be able to remedy this in
order to facilitate ML-based proof assistant development and use on
Guix. Especially things like the PRLs (NuPRL, RedPRL, JonPRL) which
offer nice dependent type systems. But first the compiler tower needs to
be there."

Maybe we could borrow some inspiration from miniML (mentioned by
Julien), CakeML (mentioned by Simon), or C Minor? I don't know. But I
think this is an important task.

> Thanks for proposing the idea!
>
> All the best,
> Jack

Thank you for voicing your support Jack! :)

-- 
Brett M. Gilio 
GNU Guix, Contributor 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Julien Lepiller  writes:

> I'm afraid OCaml is not bootstrappable. It uses a bytecode version of
> itself (using a bootstrapped bytecode interpreter written in C) to
> build itself. Fortunately this situation is being worked on by a phd
> student of Xavier Leroy (and nixOS user) :).
>
> The plan is to write a compiler in C or Scheme (it currently exists,
> but is written in OCaml) for "miniML" a small subset of the OCaml
> language. Then, there is already an interpreter in miniML able to
> interpret the OCaml compiler compiling itself. Once the miniML
> compiler is bootstrapped, we will have a path from C to OCaml :)

I did not know of this project. Thank you for telling me!

-- 
Brett M. Gilio 
GNU Guix, Contributor 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

zimoun  writes:

> Hi,
>
> I am not a Programming Language Theory guy so I speak as a pure noob. :-)
> Well, I am working in University Paris 7 Diderot doing some scientific
> computing.

We are all noobs of formal methods next to Vladimir Voevodsky, and
Grothendiek. ;)

>> so this could be more of a chance to see bigger institutions begin to
>> adopt Guix for their research work.
>
> IMHO, today the "win" is not about bootstrapping because it is
> strongly language dependent but this "win" offered by Guix is about
> the time-traveling reproducibility tools: today the key point in
> scientific research (IMHO).
> And yes, the reproducibility over the time means bootstrappability.
> But it is each scientific community that must take care of its
> outputs.
>
> The wider adoption could come from features as "time-machine",
> available packages (channels for the not GNU compliant), easy to
> distribute, to reproduce, be able to search in all the packages over
> all the Guix history, etc.

Undoubtedly the formal methods community, just as with all other
communities of scientific research stands to benefit from the
time-machine! No question about that. I would be intrigued to see in
what ways we can push that paradigm to its limits. Formal methods is
notorious for finding novel ways to bring change to our systems of
abstraction, and challenge our notions of things like "safety". So maybe
the time-machine could still stand to benefit from improvement, and maybe the 
formal
methods community by using it will find out ways to do that. Purely
speculation, here.

>> -- A lot of proof assistants are based on dialects of ML. Most of these
>>use SMLnj or MLton for their work. To date there is an issue of
>>source-based bootstrapping of _all_ of the major ML compilers. We do
>>have PolyML in our repositories, but even this uses space-inefficient
>>text file blobs for compiling and is not a fully C-based source
>>bootstrap. Basically, all of the ML compilers rely on some distinct
>>pre-compiled something-or-other to get to their pristine state. I
>>have explored the idea, along with Leo and Amin, about following in
>>the tradition of MES (and mrustc) and starting an analogous GNU project 
>> for
>>writing a reduced-size specification ML bootstrapping compiler. That
>>way we can end the loop of a source-based build of ML97 compilers
>>being basically impossible.
>>[See issues #38605 & #38606 on DEBBUGS. Also, see
>>https://github.com/MLton/mlton/issues/350.]
>
> It is a ambitious research project. Woow! Nice!! :-)
>
> CakeML [1] claims to be a subset of Standard ML and to be
> boostrappable. I do not know enough to have an relevant opinion.
>
> [1] https://cakeml.org/

I am quite familiar with CakeML, and I draw a lot of inspiration with
the things they are managing to do as a subset implementation of ML. I
think it would be interesting to see where a bootstrapping compiler
could go if it were fledged out into a full implementation for the GNU
project, filling a dual-role. Again, just proposing some ideas. :)

> What is the status of OCaml about boostrappability?

Julien answered this already, but there is a gap here.

> Yes, let spread the world! :-)
>
> And IMO a good start is to show in scientific communities why
> boostrappability matters.
>
> For example, the papers which were OK in [2] (2015), are they still OK
> in 2019? I bet that a lot of big binary blobs have disappear since
> then.
>
> [2] http://repeatability.cs.arizona.edu/
>
>
>
> All the best,
> simon

Simon, I am glad to have your support here! Please engage with us more
as more details come. You may be a "noob" (self-reported), but it is
noobs who provide us the most valuable information often times.

-- 
Brett M. Gilio 
GNU Guix, Contributor 

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Julien Lepiller  writes:

> OCaml stuff can easily be imported with guix import opam. I know coq
> packages use a separate opam repository, so it would be nice if the
> importer could take an optional parameter to indicate a custom opam
> repository url. I'm not sure the coq repo is converted to opam 2 yet
> though.

To my knowledge the Coq repo is not compliant with OPAM 2 quite
yet. Maybe this has changed since I last checked, but I would be more
than happy to ask upstream if this is still the case. I think working on
an importer for those modified OPAM->Coq packages would be a fantastic
start to that problem.

> I can see the benefits of formal methods and benefits of guix, but
> what does guix provide or could provide to formal method people
> specifically? Is it "only" the nice guarantees it gives to any
> programer, or is there something else? Maybe the question is why does
> it matter more to fm people than to other programmers?

I think it is a combination of what every other programmer is offered,
and the possibilities offered by what bootstrapping has to offer for
creating a machine from "nothing". There is still a lot of unknowns
here, but I speculate that there is definitely more to be found as the
concept progresses. I think your question is valid, and should likely be
a central thesis to the working group; "What does Guix offer to the
formal methods community that it could specifically benefit from?"

> I think we're still a small community, so we can continue talking
> about it on the main channel. We're trying to avoid dividing
> information, that's why we allow any language on tge channel, instead
> of having separate chans for each language. We also always hear about
> bootstrapping or the hpc effort on the main channel. Let's talk about
> fm :). You can count me in.

Agreed, lets not separate the community. Keep the communication
integrated. Though, I wonder if maybe I could draft an article for the
Guix website blog; or maybe we could organize our goals somewhere? I am
not quite sure what the best option here is. For example, one of the
goals is a possible bootstrapping compiler for ML that I mentioned
before, that would be dedicated to the GNU project in a similar fashion
to Jan's GNU Mes (which, thank you Jan for the supportive
messages). Combine this on maybe working out a bootstrap for OCaml,
creating an importer for Coq, working on some more programming
research-related questions in the context of Guix and suddenly we have
ourselves a trifecta of big questions that need to be articulated
_somewhere_ so we can retain some scope. Maybe Guix needs a wiki similar
to the wishlist, but dedicated to working groups? I really have no
idea. Just something, somewhere to centralize our goals.

Regardless, thank you for the supportive voice Julien. I am glad to have
your support.

-- 
Brett M. Gilio 
GNU Guix, Contributor 

Re: Remarks about commit 2c82d4ad10de8

[Brett Gilio]

Brett Gilio  writes:

> I think you are correct. I likely made a mistake. We should revert the change.
>
> Thanks!
>
> Dec 16, 2019 9:13:31 AM Mathieu Othacehe :
>
>> 
>> Hello Brett,
>> 
>> I have a few remarks on the aforementioned commit.
>> 
>> 
>> > + (list (string-append "-DCMAKE_CXX_FLAGS='-isystem "
>> > + (assoc-ref %build-inputs "gcc")
>> > + "/include/c++'"
>> > 
>> 
>> Why is this needed? The following snippet in clang-from-llvm isn't enough?
>> 
>> --8<---cut here---start->8---
>> ;; Make clang look for libstdc++ in the right
>> ;; location.
>> (("LibStdCXXIncludePathCandidates\\[\\] = \\{")
>> (string-append
>> "LibStdCXXIncludePathCandidates[] = { \"" gcc "/include/c++\","))
>> --8<---cut here---end--->8---
>> 
>> 
>> > + (inputs
>> > `(("clang" ,clang)
>> > - ("llvm" ,llvm)))
>> > + ("ncurses" ,ncurses)))
>> > + (native-inputs
>> > + `(("rapidjson" ,rapidjson)
>> > 
>> 
>> Rapidjson is an input (even if ccls is not linked against because its a
>> header-only library).
>> 
>> 
>> > + ("gcc" ,gcc)))
>> > 
>> 
>> This shouldn't be needed as it is an implicit input.
>> 
>> Thanks,
>> 
>> Mathieu
>> 
>
>

Mathieu,

I have reverted the affected commits. Thank you for bringing the issue
to my attention.

-- 
Brett M. Gilio
GNU Guix, Contributor <https://guix.gnu.org/>

Re: Remarks about commit 2c82d4ad10de8

[Brett Gilio]

I think you are correct. I likely made a mistake. We should revert the change.

Thanks!

Dec 16, 2019 9:13:31 AM Mathieu Othacehe :

> 
> Hello Brett,
> 
> I have a few remarks on the aforementioned commit.
> 
> 
> > + (list (string-append "-DCMAKE_CXX_FLAGS='-isystem "
> > + (assoc-ref %build-inputs "gcc")
> > + "/include/c++'"
> > 
> 
> Why is this needed? The following snippet in clang-from-llvm isn't enough?
> 
> --8<---cut here---start->8---
> ;; Make clang look for libstdc++ in the right
> ;; location.
> (("LibStdCXXIncludePathCandidates\\[\\] = \\{")
> (string-append
> "LibStdCXXIncludePathCandidates[] = { \"" gcc "/include/c++\","))
> --8<---cut here---end--->8---
> 
> 
> > + (inputs
> > `(("clang" ,clang)
> > - ("llvm" ,llvm)))
> > + ("ncurses" ,ncurses)))
> > + (native-inputs
> > + `(("rapidjson" ,rapidjson)
> > 
> 
> Rapidjson is an input (even if ccls is not linked against because its a
> header-only library).
> 
> 
> > + ("gcc" ,gcc)))
> > 
> 
> This shouldn't be needed as it is an implicit input.
> 
> Thanks,
> 
> Mathieu
> 

[Proposal] The Formal Methods in GNU Guix Working Group

[Brett Gilio]

Hello Guix!

This is going to be a rather lengthy email proposing a new working group
(if that is indeed the proper name for this) in the GNU Guix
project. Just as there are other "working groups" for GNOME packages,
bootstrapping Rust & JVM, and bootstrapping the entirely of the GNU
Corelibs (GNU Mes) in Guix, I am proposing a new working group based on
the synthesis of two fundamentally and mutually agreeable concepts.

This is a continuation of the discussion proposed by Amin Bandali, Leo
Prikler, and I from the #guix Freenode IRC. All three of us are either
students of formal methods in mathematics and computer science, users of
proof assistants, or interested in category theory and type theory. As
such as noticed and wondered what kind of community there is for formal
methods in GNU Guix, and by extension what kind of benefits GNU Guix has
to offer the formal methods community which is providing some of the
most rigorous research in computing methods to date.

First, some background. For those of you unfamiliar with formal methods
and software verification in computer science, it is by-and-large
applications of mathematical proof to the conceptions of how we design
our software. We design our software around proofs that have a certain
level of correctness thus we do not have to speculate about the behavior
of that software. To me that has a striking resemblence to the less
rigorous but all-the-more impressive goal of Guix to be functionally
deterministic. Many of the concepts of formal methods take from untyped
(and typed) lambda calculus and are then abstracted to have higher-order
guarantees in their construction.

Having Guix and the Formal Methods community aligned would mean a great
deal of power for both camps! Just as we see with the Software Heritage
project and Guix, for providing historical and state-consistent
reproducible environments for software testing we and correspond to
formal methods much of the same guarantees of deterministic
computational states, modeling, and reasoning in software correctness.

Amin, Leo, and I all likely agree that _some_ relationship here is good
to be opened and explored! I know that there are some of us who come
from institutions that have historical relationships to the proof
assistant community, Caml, HOL (looking at you Ludo', though IIRC you
are in a different working group at INRIA),
so this could be more of a chance to see bigger institutions begin to
adopt Guix for their research work.

What follows is proposals for some of the work to be done by this
working group:

-- A lot of proof assistants are based on dialects of ML. Most of these
   use SMLnj or MLton for their work. To date there is an issue of
   source-based bootstrapping of _all_ of the major ML compilers. We do
   have PolyML in our repositories, but even this uses space-inefficient
   text file blobs for compiling and is not a fully C-based source
   bootstrap. Basically, all of the ML compilers rely on some distinct
   pre-compiled something-or-other to get to their pristine state. I
   have explored the idea, along with Leo and Amin, about following in
   the tradition of MES (and mrustc) and starting an analogous GNU project for
   writing a reduced-size specification ML bootstrapping compiler. That
   way we can end the loop of a source-based build of ML97 compilers
   being basically impossible.
   [See issues #38605 & #38606 on DEBBUGS. Also, see
   https://github.com/MLton/mlton/issues/350.]

-- Begin adding more projects that are important works in the formal
   methods community. We have Coq, Idris, and Agda, but there is a lot of work
   to be done on keeping these projects not only up-to-date but also
   adding subprojects that use these toolchains. For example: C Minor,
   Metamath, Ynot, Formally verified Featherweight Scala, RustBelt,
   RedPRL, NuPRL, JonPRL, HOL/Isabelle, F*, kreMLin, CakeML, tons of
   various type checkers based on OCaml, Alloy, Frama-C, TLA+, Liquid
   Haskell, extensions to Z3, and tons more!

-- Possibly begin formally verifying some of the behavior and
   implementations of GNU Guix and GNU Guile. This is kind of an add-on
   idea, but it struck our interest so why leave it out?

-- Begin giving talks on the benefits of GNU Guix at conferences around
   Homotopy Type Theory, Coq, Formal Verification, Deepspec, etc.

All of this seems really nice and impressive, but what is it without
getting some feedback from the community? I'd _really_ love to hear your
thoughts, experiences, and more on this working group idea and other
working groups to avoid pitfalls. Maybe we should have a secondary
#guix-fm channel on IRC? There is definitely a lot of work to be done
here, and we will need some form of organizational structure to keep the
work consistent and neatly integrated with the goals and purposes of GNU
Guix.

I hope to hear from the community.

Thanks,

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

Re: Parallel downloads

[Brett Gilio]

Pierre Neidhardt  writes:

> Update: I've been using --max-jobs=2 by default for about 2 weeks now,
> and it feels like a much smoother experience overall: faster downloads, faster
> builds.
>
> This is obviously a very dumb "optimization" but at least it serves to
> underline that Guix could still do much better by parallelizing
> downloads and build in a smart way.

Agree.

>
> I couple of ideas were mentioned in this thread: Anyone interested in
> working on them? :)

When I get some time, I would be more than happy to help with this.

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/

Checking in, and an announcement!

[Brett Gilio]

Hello all!

At risk of being lampooned by RMS if he is reading this mailing list, my wife 
and I had our first baby delivered last evening! We are very excited, and quite 
exhausted.

I just wanted to thank you all who have reached out to me over Email, IRC, and 
Telegram. I _have_ received your message but I am waiting to respond.

Unfortunately, I do not think I can anticipate participating in Guix Days / 
FOSDEM2020. But I am so thrilled to be a more integral member of the Guix 
project, and I hope you all are mostly satisfied with my work so far. I use 
Guix at my job, so it is nice getting paid (in a way) to play around with Guix.

I have so much I am looking forward to helping with, but for now I am going to 
take a few days to rest and enjoy our little member of the GNU/Family, Matteo.

Thank you all again for the supportive messages, and I will respond ASAP!

Brett Gilio

Re: Status of Gnome upgrade?

[Brett Gilio]

Ricardo Wurmus  writes:

> Hi Guix,
>
> does anyone know what’s holding up the Gnome upgrade?  It’s sad to see
> the upgrade languish when it was almost ready for a merge into master.
>
> Are there any open issues?  Any problems that need solving?  I think
> this is a high priority item for Guix.  I’d love to help getting it
> done.
>
> Any ideas?
>
> --
> Ricardo
>
>

I do not know of any open issues, but I agree with Ricardo fully. This
is a high priority issue for Guix that needs to get done sooner rather
than later.

I am also willing to throw my weight behind it, even though I am not a
regular GNOME user.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

Re: Packaging Mercury & Some Struggles

[Brett Gilio]

Brett Gilio  writes:

> Greetings all!
>
> I am continuing my prolific streak of trying to move as many things from
> my channel to the main repository as possible.
>
> Up next on the menu: the Mercury language and compiler.
> http://mercurylang.org/
>
> So here are a few issues I am wanting to get resolved with this package,
> and I am hoping some support from the community can get this package
> further along.
>
> 1. Mercury comes with a number of "grades", which you can think of as
> anything relating to do with support for extra backends, libraries, and
> a number of other functionalities. The default setting in Mercury is to
> compile the compiler including all of the standard grades, which can
> take one heck of a long time! As a result, I was thinking of adopting
> something similar to `emacs-minimal`, for people who need to use the
> Mercury compiler but do not need all of that overhead of having all of
> the grades included by default.
>
> (define-public mercury-minimal
>   (package (inherit mercury)
>  (name "mercury-minimal")
>  (build-system gnu-build-system)
>  (arguments
> (substitute-keyword-arguments (package-arguments mercury)
>   ((#:configure-flags flags ''())
>`(list "--enable-minimal-install"
>(inputs
> `(("gcc-toolchain" ,gcc-toolchain)))
>(synopsis "A pure logic programming language (used only for
> compiling packages dependent on base Mercury)")))
>
>
> So this example comes with a few points I want to address. Most distinct
> is the modification of the inherited mercury args to use the
> minimal-install flag (disabling grades not related to the compiler
> itself). Additionally, to use the mercury compiler in projects it
> depends on having some C-based toolchain to handoff the extracted code
> to. Is including gcc-toolchain as an Input/Prop-Input the best solution
> here? I worry that it might conflict with versions of the toolchain
> already in a user profile, or if somebody wants to use a different
> version of the gcc-toolchain (though they could replace the input using
> the appropriate guix flag.)
>
> 2. The Mercury source tarball includes a git submodule copy of
> boehm-gc. Of course, I think the "Guix way"TM of doing this is to strip
> out the submodule and replace it using a Native-Input (assuming the two
> versions are compatible, anyways). Here is the method I have assumed for
> trying to get that done.
>
> (add-after 'unpack 'replace-boehm
>(lambda* (#:key inputs #:allow-other-keys)
>  (let ((boehm (assoc-ref inputs "libgc")))
>(map (match-lambda
>   ((src orig-name new-name)
>(with-directory-excursion "."
>  (apply unpack (list #:source src))
>  (apply patch-source-shebangs (list #:source src)))
>(delete-file-recursively new-name)
>(invoke "mv" orig-name new-name)))
> `((,boehm "source" "libgc"))
>
>
> Now, this code may not be perfectly correct (feel free to do the work
> for me here, if you want, but I can probably figure it out ;). But, the
> code is at least in the spirit of what I am trying to achieve here. The
> issue here may just be that I am tired, but for whatever reason
> `match-lambda' is not resolving.
>
> starting phase `replace-boehm'
> Backtrace:
>8 (primitive-load "/gnu/store/z0wfywmlbn079q07hgab4fafmqx…")
> In ice-9/eval.scm:
>191:35  7 (_ #f)
> In ice-9/boot-9.scm:
> 829:9  6 (catch srfi-34 # …)
> In srfi/srfi-1.scm:
>863:16  5 (every1 # …)
> In 
> /gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import/guix/build/gnu-build-system.scm:
>839:30  4 (_ _)
> In ice-9/eval.scm:
> 159:9  3 (_ #(#(#(#) (…)) #))
>182:19  2 (proc #(#(#(#) …) …))
>142:16  1 (compile-top-call _ (7 . match-lambda) ((10 (10 # …) …)))
> In unknown file:
>0 (%resolve-variable (7 . match-lambda) #)
>
> ERROR: In procedure %resolve-variable:
> Unbound variable: match-lambda
>
>
> Last I checked, match-lambda belongs to `(ice-9 match)`. Though it is
> very possible that there is just some syntactical issue here that I am
> just not seeing right now. Again, eyes on this would be appreciated :).
>
> 3. Last, but not least: If any of you can find documentation on how to
> run the tests for the Mercury compiler, I would greatly appreciate it! I
> am completely lost on how to run them. I can not find an appropriate
&g

Packaging Mercury & Some Struggles

[Brett Gilio]

Greetings all!

I am continuing my prolific streak of trying to move as many things from
my channel to the main repository as possible.

Up next on the menu: the Mercury language and compiler.
http://mercurylang.org/

So here are a few issues I am wanting to get resolved with this package,
and I am hoping some support from the community can get this package
further along.

1. Mercury comes with a number of "grades", which you can think of as
anything relating to do with support for extra backends, libraries, and
a number of other functionalities. The default setting in Mercury is to
compile the compiler including all of the standard grades, which can
take one heck of a long time! As a result, I was thinking of adopting
something similar to `emacs-minimal`, for people who need to use the
Mercury compiler but do not need all of that overhead of having all of
the grades included by default.

--8<---cut here---start->8---
(define-public mercury-minimal
  (package (inherit mercury)
   (name "mercury-minimal")
   (build-system gnu-build-system)
   (arguments
(substitute-keyword-arguments (package-arguments mercury)
  ((#:configure-flags flags ''())
   `(list "--enable-minimal-install"
   (inputs
`(("gcc-toolchain" ,gcc-toolchain)))
   (synopsis "A pure logic programming language (used only for
compiling packages dependent on base Mercury)")))
--8<---cut here---end--->8---

So this example comes with a few points I want to address. Most distinct
is the modification of the inherited mercury args to use the
minimal-install flag (disabling grades not related to the compiler
itself). Additionally, to use the mercury compiler in projects it
depends on having some C-based toolchain to handoff the extracted code
to. Is including gcc-toolchain as an Input/Prop-Input the best solution
here? I worry that it might conflict with versions of the toolchain
already in a user profile, or if somebody wants to use a different
version of the gcc-toolchain (though they could replace the input using
the appropriate guix flag.)

2. The Mercury source tarball includes a git submodule copy of
boehm-gc. Of course, I think the "Guix way"TM of doing this is to strip
out the submodule and replace it using a Native-Input (assuming the two
versions are compatible, anyways). Here is the method I have assumed for
trying to get that done.

--8<---cut here---start->8---
(add-after 'unpack 'replace-boehm
   (lambda* (#:key inputs #:allow-other-keys)
 (let ((boehm (assoc-ref inputs "libgc")))
   (map (match-lambda
  ((src orig-name new-name)
   (with-directory-excursion "."
 (apply unpack (list #:source src))
 (apply patch-source-shebangs (list #:source src)))
   (delete-file-recursively new-name)
   (invoke "mv" orig-name new-name)))
`((,boehm "source" "libgc"))
--8<---cut here---end--->8---

Now, this code may not be perfectly correct (feel free to do the work
for me here, if you want, but I can probably figure it out ;). But, the
code is at least in the spirit of what I am trying to achieve here. The
issue here may just be that I am tired, but for whatever reason
`match-lambda' is not resolving.

--8<---cut here---start->8---
starting phase `replace-boehm'
Backtrace:
   8 (primitive-load "/gnu/store/z0wfywmlbn079q07hgab4fafmqx…")
In ice-9/eval.scm:
   191:35  7 (_ #f)
In ice-9/boot-9.scm:
829:9  6 (catch srfi-34 # …)
In srfi/srfi-1.scm:
   863:16  5 (every1 # …)
In 
/gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import/guix/build/gnu-build-system.scm:
   839:30  4 (_ _)
In ice-9/eval.scm:
159:9  3 (_ #(#(#(#) (…)) #))
   182:19  2 (proc #(#(#(#) …) …))
   142:16  1 (compile-top-call _ (7 . match-lambda) ((10 (10 # …) …)))
In unknown file:
   0 (%resolve-variable (7 . match-lambda) #)

ERROR: In procedure %resolve-variable:
Unbound variable: match-lambda
--8<---cut here---end--->8---

Last I checked, match-lambda belongs to `(ice-9 match)`. Though it is
very possible that there is just some syntactical issue here that I am
just not seeing right now. Again, eyes on this would be appreciated :).

3. Last, but not least: If any of you can find documentation on how to
run the tests for the Mercury compiler, I would greatly appreciate it! I
am completely lost on how to run them. I can not find an appropriate
make target for them to run off of.

4. This one is not a real issue, per se; however, so far I am doing this
work in a new module (gnu packages mercury). I would have preferred to
place this in a (gnu packages prolog), but we only have 

Re: New POWER9 machines for the Guix build farm?

[Brett Gilio]

Tobias Geerinckx-Rice  writes:

> Fellow Guix,
>
> The Guix sysadmins are considering buying shiny hardware for the
> ci.guix.gnu.org build farm, and it would be awesome if that included
> our first POWER9 machine(s)!

I was curious the other day looking at multiarch compilation using the
qemu-binfmt service, is there support for POWER PC?

Anyways, I would love to see support for POWER9 come to Guix. I have
limited experience with this architecture, but I will keep lurking in
this thread.

Good luck!

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

Re: GNU Mes 0.21 released

[Brett Gilio]

w.gnu.org/software/mes
> [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
> [2] https://www.gnu.org/software/guix
> [3] https://bootstrappable.org
> [4] https://github.com/oriansj/mes-m2
> [5] https://github.com/oriansj/m2-planet
> [6] https://github.com/schemeway/lalr-scm
> [7] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html
> [8] https://www.nongnu.org/nyacc
> [9] https://gitlab.com/janneke/tinycc
> [10] 
> http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
> [11] https://savannah.nongnu.org/projects/stage0
> [12] https://nlnet.nl/project/GNUMes

Fantastic work to everybody involved!

Brett Gilio

Re: ABI and emacs-guix

[Brett Gilio]

Ludovic Courtès writes:

> Hi Brett,
>
> Brett Gilio  skribis:
>
>> Was there another ABI change to Guix? The last time this happened
>> emacs-guix began behaving improperly and spitting out unresolvable error
>> messages in the *Messages* buffer. This is happening again, and Ludo
>> fixed it by rebuilding it I think?
>
> Can you share those terrible error messages?
>
> As I write this, Emacs-Guix works awesomely fine for me.  :-)
>
>> If this is the case, is there a consistent way to have emacs-guix be
>> rebuilt after these changes?
>
> I haven’t checked how Emacs-Guix spawns its REPL server, but I think
> that to be safe, it should spawn it via ‘guix repl’, which is
> guaranteed to be using the right APIs and all.
>
> Thanks,
> Ludo’.

After pulling updates today, the issue is fixed on my end.

fuse & sshfs

[Brett Gilio]

Hi all,

With 1.0 around the corner, is there any priority for packages like
fuse? The latest release is 3.5 and we are using 2.9.

All of these packages depend on it
casync@2 multipath-tools@0.7.9 fio@3.13 python-llfuse@0.41.1
python-fusepy@2.0.4 python2-gdrivefs@0.14.9 python2-llfuse@1.3.5
borg@1.1.9 skopeo@0.1.28 flatpak@1.2.4 unionfs-fuse@2.0 fuseiso@20070708
fuse-exfat@1.3.0 archivemount@0.8.12 sshfs@2.10 testdisk@7.0 ifuse@1.1.3
spacefm@1.0.6 caja-extensions@1.22.0 mate@1.22.0 lxde@0.99.2
gnome-tweak-tool@3.26.4 gnome@3.24.3 httpfs2@0.1.5 curlftpfs@0.9.2
disorderfs@0.5.6 apfs-fuse@0.0.0-0.c7036a3 encfs@1.9.5 sra-tools@2.9.3
wimlib@1.13.0

Is it maybe lingering in one of our unmerged branches out there? If not,
I wouldn't mind trying to take a crack at bumping it. I know for a fact
that not updating it limits out ability to upgrade sshfs since it
depends on version >3.

Best

Brett Gilio

Re: ABI and emacs-guix

[Brett Gilio]

Ludovic Courtès writes:

> Hi Brett,
>
> Brett Gilio  skribis:
>
>> Was there another ABI change to Guix? The last time this happened
>> emacs-guix began behaving improperly and spitting out unresolvable error
>> messages in the *Messages* buffer. This is happening again, and Ludo
>> fixed it by rebuilding it I think?
>
> Can you share those terrible error messages?
>
> As I write this, Emacs-Guix works awesomely fine for me.  :-)
>
>> If this is the case, is there a consistent way to have emacs-guix be
>> rebuilt after these changes?
>
> I haven’t checked how Emacs-Guix spawns its REPL server, but I think
> that to be safe, it should spawn it via ‘guix repl’, which is
> guaranteed to be using the right APIs and all.
>
> Thanks,
> Ludo’.

Hey Ludo,

Thank you for picking this up again.

Here is the *Messages* with an attached backtrace from *Guix
Internal Repl*

guix-geiser-eval: Error in evaluating guile expression: texinfo.scm:745:27: 
Throw to key `parser-error' with args `(# "EOF while 
reading a token " "reading char data")'.

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

scheme@(emacs-guix)> ,bt
  12 (eval (#:19:16 ()>) #)
In emacs-guix/packages.scm:
   790:23 11 (package/output-sexps _ output _ _ (synopsis installed …))
In guix/discovery.scm:
179:3 10 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
45:26  9 (fold2 # …)
45:26  8 (fold2 # …)
In guix/discovery.scm:
   182:33  7 (_ # …)
In emacs-guix/packages.scm:
   338:23  6 (_ # …)
   369:22  5 (_ _)
In guix/ui.scm:
  1271:23  4 (texi->plain-text _)
In texinfo.scm:
  1131:22  3 (parse _)
   979:31  2 (loop # (*fragment*) _ _ _)
   910:31  1 (loop # #f # …)
   745:27  0 (_ # #f #f # …)
scheme@(emacs-guix) [1]>


Here is my `guix describe'.

Generation 95   Apr 26 2019 09:38:14(current)
  guix-system e29665d
repository URL: https://git.sr.ht/~brettgilio/guix-channel
branch: master
commit: e29665df7da5d4472896d28da6a3fe7d71487866
  guix 272db5b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 272db5bcf53d9d05d5c4b2df021d9e74f78866cd

ABI and emacs-guix

[Brett Gilio]

Hi all,

Was there another ABI change to Guix? The last time this happened
emacs-guix began behaving improperly and spitting out unresolvable error
messages in the *Messages* buffer. This is happening again, and Ludo
fixed it by rebuilding it I think?

If this is the case, is there a consistent way to have emacs-guix be
rebuilt after these changes?

Best,
Brett Gilio

Re: Deliver important Guix changes to users, please

[Brett Gilio]

Amin Bandali writes:

> Hi Ludo’, all,
>
> On 2019-04-15  2:56 PM, Ludovic Courtès wrote:
>
> [...]
>
>>
>> ‘guix pull’ already provides high-level “package news”, but I agree it’d
>> be nice to have a way to convey “system news” and perhaps free-form
>> messages like Debian’s change logs.
>>
>> I suppose we could use some specially-formatted Git commits to pass
>> messages to users.  I’m afraid it would be hard to get those messages
>> translated.
>>
>> Thoughts?
>>
>
> That’s an interesting idea.  Another alternative, perhaps, could be
> having a “news” or “breaking changes” section/topic on the Guix blog,
> ideally with a dedicated atom feed, where one could follow changes with
> drastic change in system and/or package behaviour, or ones potentially
> requiring a manual intervention of sorts.  Both Parabola and Hyperbola
> have that section on their website, with latest news shown on the front
> page.
>
> Thoughts?
>
> Best,
> amin

I second this idea.

Re: Updating mono. Adding MSBuild.

[Brett Gilio]

Ricardo Wurmus writes:

> Brett Gilio  writes:
>
>> Although, there is a possible issue here that needs to be
>> addressed. Both Mono and Chicken produce a binary called `csi`. This is
>> a naming conflict, and I do not know the Guix-way for resolving naming
>> conflicts.
>
> This is not a problem as during the build you probably won’t use Chicken
> together with Mono.
>
>> Most distributions renamed the Chicken csi to `chicken-csi`
>> and left mono to `csi`. Does Guix have namespaces for binaries we
>> produce? How should I proceed here?
>
> The Guix way is to install these things into separate profiles.

Hi all.

First, thank you ricardo for your response.

I have a few things that seem to be important to note. On the plus side,
I got Mono-5.0 to build successfully. But, during this process of
building mono-5.0 I discovered that the mono documentation is either
incorrect or misleading. Their documentation states that you need to
have a mono-lite binary seed or a previous version of mono to compile
newer versions. This doesn't seem to be true. Regardless of whether I
pass our older version of mono to build mono-5.0, it compiles a csc (C#
compiler) from its own source tree that it uses to build the full mono
stack. So, I am inclined to think that bootstrapping mono from an
earlier version isn't necessary since that csc compiler is C code.

Okay, great Mono-5.0 builds successfully. So with that knowledge, I
tried to compile the latest Mono-5.18. However, shortly after the
configuration step it throws

CMake Error: CMake was unable to find a build program corresponding to "Unix 
Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a 
different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also
"/tmp/guix-build-mono-5.18.1.0.drv-0/mono-5.18.1.0/mono/btls/build-shared/CMakeFiles/CMakeOutput.log".

The interesting thing is that it uses the gnu-build-system to build the
csc compiler, and I had to pass cmake as a native-input or else the
configuration step would fail. So, does anybody know how to deal with
this cmake issue?

Thanks,

Brett Gilio

Re: Updating mono. Adding MSBuild.

[Brett Gilio]

Danny Milosavljevic writes:

> Hi,
>
>> > Mono, for most distributions, seems to be bootstrapped with a prebuilt
>> > binary mono-lite. Due to this, I am unsure of how to make the first step
>> > in correctly repackaging Mono.  
>> 
>> Instead of adding a new binary mono-lite, can we reuse the existing
>> “mono” package to build the new Mono?
>
> +1
>
>> (I don’t know what MSBuild is and how it would help here.)
>
> MSBuild is something like Ant for .NET.  (or "make", but with more XML :) )
>
> I think Brett means that MSBuild is bundled with mono.
>
> I failed to unbundle some things just to have a CVE in one of the bundled
> dependencies DAYS later.  I think it's not a good idea in general to bundle
> things.  (But if it's from the same vendor and team anyway they'll probably
> update their bundled copy after fixing CVEs, too)

I will try to build a newer mono against the current version we have.

Although, there is a possible issue here that needs to be
addressed. Both Mono and Chicken produce a binary called `csi`. This is
a naming conflict, and I do not know the Guix-way for resolving naming
conflicts. Most distributions renamed the Chicken csi to `chicken-csi`
and left mono to `csi`. Does Guix have namespaces for binaries we
produce? How should I proceed here?

Updating mono. Adding MSBuild.

[Brett Gilio]

Hi all,

Our mono package is pretty severely out of date. I want to take care of
updating it to a version consistent with this century. However, there
seems to be an issue perhaps along the lines similar to bootstrapping
Rust and JDK.

Mono, for most distributions, seems to be bootstrapped with a prebuilt
binary mono-lite. Due to this, I am unsure of how to make the first step
in correctly repackaging Mono.

Additionally, this should ideally come with the newer MSBuild, which Nix
currently lacks. It is included in the Mono source tree, but I would
assume we would want that to be separated and rather called by a
propagated/native input?

Anyways, a lot to unpack here. I'd appreciate any help I could get.

Best,
Brett Gilio

Re: Raco importer

[Brett Gilio]

Pierre Neidhardt writes:

> That'd be awesome!


Maybe i'm jumping the gun here. But once I get a working raco importer,
would there be any objection to moving racket from scheme.scm to
racket.scm, and subsequently placing raco derived imports in
racket-xyz.scm?

Brett Gilio

Raco importer

[Brett Gilio]

Hey all,

Has there been any discussion about creating a raco importer for Racket
packages? This might be something i'd be willing to look into if it is
both compliant with the needs of the upstream racket people, and if
others might use it.

Best,
Brett Gilio

Re: Eliminate environment variable hints?

[Brett Gilio]

Ricardo Wurmus writes:

> Hi Guix,
>
> when installing a package into a profile Guix very helpfully tells you
> that you may need to set certain environment variables.  It doesn’t tell
> you that these environment variables can also be set by source’ing the
> generated etc/profile file.
>
> I have seen the bashrc and bash_profile files of many users and they are
> usually full of conflicting environment variable definitions.  In these
> files I often also see these Guix recommendations.
>
> I think Guix should suggest sourcing the generated etc/profile file
> instead of listing explicit environment variable definitions.  It would
> be less noisy and less confusing, in my opinion.
>
> What do you think?
>
> (What about people who don’t use Bash?)

I think this is a good idea. It may also be worth mentioning that these
suggestions can also be set in environments using the --search-paths
flag. I know that is said in the documentation, but maybe it could be
highlighted somehow?

Brett Gilio

Re: the upcoming Great Python2 Purge™

[Brett Gilio]

Efraim Flashner writes:

> I checked 'guix refresh -l python2' and I got a list of the python2-*
> packages which are leaf packages. I'm not suggesting that we right now
> get rid of them, but it seems to me something worth keeping an eye on.
>
> 'guix package -A ^python2- | wc -l' gave me 737
> the number of leaf python2 packages I found was 222.
>
> This is only a first round; I didn't check to see if we were to remove
> these packages how many more leaf python2 packages we would have.

There are a few leaf packages that are being used to generate the
python3 equivalent. So, maybe we should make a list of leaf packages
that are otherwise safe to be dismissed. Also, what is the status of
somebody deciding to move a lot of these to a channel?

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Brett Gilio]

Brett Gilio writes:

> Adonay Felipe Nogueira writes:
>
>> Em 16/02/2019 12:18, Julie Marchant escreveu:
>>> libre? The only argument I've seen on the matter is the way copyright
>>> works, but Chromium is under the Modified BSD License according to
>>> documentation I was able to find. If some files are not actually covered
>>
>> For what is worth, what I learned with projects that don't follow the
>> Open Source Definition (I know that I shouldn't support this term here,
>> but I had to mention it) is that they mask their non-compliance behind a
>> license. Of course we don't intend to foster open source here, as this
>> project, having the goal to provide a package manager that is under the
>> GNU project, also aims to create a system distribution that follows the
>> GNU FSDG and uses such package manager
>>
>> If the norm would be to only check the licenses, then we would have for
>> example, taken ages to figure out that the kernel source files from
>> upstream of GNU Linux-libre was/is non-free.
>>
>> Having a requirement for a package to be first throughly reviewed
>> eliminates some of the possibility of having non-free functional data or
>> non-distributable non-functional data. It's not a perfect protection
>> (since the package in review might have implemented things from other
>> works that one of the reviewers might not be aware of).
>>
>> As I said in a message to these mailing lists, I already started
>> reviewing Chromium, although this project is big and I might not have
>> the time nor all the skills to do it alone. Since today, I moved the
>> review, which was available at [1], to the appropriate Review namespace
>> at [2].
>>
>>
>> [1] https://directory.fsf.org/wiki/Talk:Chromium
>> [2] https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1
>
> Adonay, thank you for taking the initiative here! I think this is a
> needed step forward.
>
> Brett Gilio

Also, maybe it would be of some help to involve somebody from the FSF to
be a neutral mediator on this process until we come to some reasonable
conclusion?

Marius,

I think you can probably go ahead and push that patch, knowing full well
that Bill warned a bug report will be filed against the Guix source tree
until such time that an audit concludes or Adonay's suggestion is
followed through with.

Bill,

What do you think here?

Brett Gilio

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Brett Gilio]

Adonay Felipe Nogueira writes:

> Em 16/02/2019 12:18, Julie Marchant escreveu:
>> libre? The only argument I've seen on the matter is the way copyright
>> works, but Chromium is under the Modified BSD License according to
>> documentation I was able to find. If some files are not actually covered
>
> For what is worth, what I learned with projects that don't follow the
> Open Source Definition (I know that I shouldn't support this term here,
> but I had to mention it) is that they mask their non-compliance behind a
> license. Of course we don't intend to foster open source here, as this
> project, having the goal to provide a package manager that is under the
> GNU project, also aims to create a system distribution that follows the
> GNU FSDG and uses such package manager
>
> If the norm would be to only check the licenses, then we would have for
> example, taken ages to figure out that the kernel source files from
> upstream of GNU Linux-libre was/is non-free.
>
> Having a requirement for a package to be first throughly reviewed
> eliminates some of the possibility of having non-free functional data or
> non-distributable non-functional data. It's not a perfect protection
> (since the package in review might have implemented things from other
> works that one of the reviewers might not be aware of).
>
> As I said in a message to these mailing lists, I already started
> reviewing Chromium, although this project is big and I might not have
> the time nor all the skills to do it alone. Since today, I moved the
> review, which was available at [1], to the appropriate Review namespace
> at [2].
>
>
> [1] https://directory.fsf.org/wiki/Talk:Chromium
> [2] https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1

Adonay, thank you for taking the initiative here! I think this is a
needed step forward.

Brett Gilio

Re: [PATCH] gnu: Add ungoogled-chromium.

[Brett Gilio]

bill-auger writes:

> On Mon, 04 Feb 2019 23:34:45 +0100 Ludovic wrote:
>> It’s not entirely clear to me what the problems are, to be honest.  
>
> On Wed, 06 Feb 2019 22:04:59 +0100 Marius wrote:
>> Indeed, the only real breakthrough is that we now have a script to
>> create an Ungooglified source tarball with all unnecessary third_party
>> components removed.
>> I am of course happy to help other FSDG distributions liberate their
>> Chromium too.  
>

I agree with everything Bill said in his message, and I heavily
encourage all of us lurking in this mailing list with an opinion on the
matter to please state your opinion on this controversy and the Guix
relationship to the FSDG.

The free software guidelines are first and foremost put up by the free
software community by what is specified to be important to the values of
free software. This needs to be addressed sooner than later, because the
act of solidarity on the part of the community here is a tremendously
crucial and singular event.

I'd like to see the offerings of free software to grow, and include
chromium if chromium has a reasonable method of liberation. But there is
yet to be a complete audit to identify the problems. We can not rely
solely on speculation, so lets get to the bottom of this once and for
all.

Brett Gilio

Public key (and mailing list issue)

[Brett Gilio]

Hi everybody,

I am sending this email on behalf of a friend trying to install the Guix
binary using the shell script. It appears his email is being rejected as
"inappropriate by the moderator." for some unknown reason. I think it
might be a spam-filter mechanism against his @gmail.com mailing address,
but that is just a suspicion.

Anyways, here is his message paraphrased:

He is trying to install GNU Guix using the shell script.
It asks for a GPG verification step that fails due to a missing key.
When he tries to import the key using the appropriate gpg --recv-keys
command pointed at pool.sys-keyservers.net, it is saying

"gpg: keyserver receive failed: No data"

Upon investigation of the key server it seems that Ludo's key is
missing.

I did a key listing on my end for that key, and it is not expired until
February 18th of this month, but in either case the key is missing from
the server rendering the shell script unuseable without commenting out
the verification steps.

Thought I would pass this information along as it seemed important.

Brett Gilio

Re: Magit is painfully slow

[Brett Gilio]

Kyle Meyer writes:

> Hello,
>
> Ricardo Wurmus  writes:
>
> [...]
>
>> However, after compiling and generating several .po and .texi
>>> files Magit takes almost a whole minute to open.
>>
>> That’s because it’s trying to colorize the diff of thousands of lines of
>> .po and .texi changes.
>
> With the default settings and no cached visibility for the repo, the
> hunks should not be expanded, so Magit isn't actually coloring/painting
> them yet.  In this case, the processing of these diffs will be slow
> regardless of whether they are painted and the CLI "git checkout"
> suggestion is good, but I think the delayed painting is worth noting
> because users may not realize that their custom visibility settings are
> making things slower.

Ricardo,
Thank you for your suggestion.


Kyle,
What do you suggest here?

Brett

Magit is painfully slow

[Brett Gilio]

Hi all,

I am having the weirdest issue with the Guix repository cloned from
Savannah. Before compiling, Magit is very efficient and opens in no time
at all. However, after compiling and generating several .po and .texi
files Magit takes almost a whole minute to open. I can clean the
repository and it wont make any difference, nor does adding those .po
and .texi files to gitignore (which magit seems to not realize because
it still shows them as unstaged changes). Does anybody else have
experience with this issue, it is literally only with our Guix
repository.

Best,
Brett Gilio

Re: the upcoming Great Python2 Purge™

[Brett Gilio]

Leo Famulari writes:

> On Wed, Dec 26, 2018 at 11:38:12AM +0200, Efraim Flashner wrote:
>> We're now about a year out from the official EOL for python2 (Jan 1,
>> 2020). So far we've been not adding python2 variants of packages that
>> are new unless they're actually needed for something. Do we want to
>> start removing python2 packages when updating other packages if they are
>> leaf packages?
>
> This was previously discussed here:
>
> https://lists.gnu.org/archive/html/guix-devel/2018-06/msg00237.html
>
> That discussion didn't go very far. As you mentioned, the consensus
> seemed to be that we 1) relax the policy of always providing both Python
> 2 and 3 packages and 2) we'll act when we need to.
>
> My opinion is that we should remove Python 2 packages after the upstream
> EOL announcement if they are causing trouble somehow.
>
> But I don't think we need to remove them en masse. We offer many other
> packages that are basically abandoned upstream, so I think it will be
> okay to keep the Python 2 packages as long as there are no bugs or if
> they are maintained somehow.

I think we could also just move them to a different Guix channel
entirely as a sort of legacy-support option. I am almost positive
somebody among us would be willing to maintain them. Could be better
than everybody wanting to maintain their own channel for it.

Also, on a side note, how would this work for the python importers?
Would we stop offering python2 substitutes on the build servers? There
are some other questions here that I think aren't getting addressed.

Brett Gilio

clang-tidy

[Brett Gilio]

Hi all,

Just curious, do we have clang-tidy packaged somewhere? I have clang
installed and am not able to reference that binary in my exec path.
As far as I understand, it should be included in the default clang installation.

Best,
Brett Gilio

Re: The mirrors of hydra are down

[Brett Gilio]

swedebugia writes:

> On 2018-11-28 21:28, swedebugia wrote:
>> Hi
>>
>> I'm trying to install guixsd on an i686 machine.
>>
>> Both mirror.guixsd.org and mirror.hydra.gnu.org seem down.
>>
>
> Ludo is on it I saw now in bug#33539.
>
> Sorry about the noise.

I had a similar issue, I just substituted the hydra.gnu.org url rather
than the mirror, and it worked.

Best,
Brett Gilio

Re: Merging ‘wip-newt-installer’ in master?

[Brett Gilio]

Mathieu Othacehe writes:

> Hey Ludo!
>
>> Other than that, something I hadn’t realized earlier (sorry for being
>> foolish!): the installer actually stops after the user account selection
>> and does nothing more, right?  It doesn’t generate a config file nor
>> does it run ‘guix system init’, does it?
>
> Nope you're correct, for now it does nothing more.
>
>> If this is correct, we should probably delay merging until after the
>> release as people may be confused when they realize the installer has no
>> effect.  WDYT?
>
> Sure, I though I would be able to add config generation part before the
> release, but the partition step keeps me quite busy!
>
> Thanks for your patch :)
>
> Mathieu

Thank you for your work here, Mathieu. I will be looking forward to
testing it after the merge.

Re: Should we rename qtoctave to octave and octave to octave-cli? (was Re: Octave & QtOctave)

[Brett Gilio]

Alex Vong writes:

> n...@n0.is writes:
>
>> names for packages are (mostly) random, although in some
>> cases following classiifcations (see python-*, r-*, ...).
>>
> I am thinking that should we rename qtoctave to octave and octave to
> octave-cli (or octave-minimal)?
>
> Firstly, a new user wanting to install octave will probably do the
> obvious "guix package -i octave", but currently this command will do the
> counter-intuitive thing of installing the non-gui version of
> octave. Instead, they will have to install qtoctave to get the gui. I am
> in favour of making a package to support as many features as possible,
> while also making a minimal version for building other packages (or
> users who desn't want a gui). An example would be emacs vs
> emacs-minimal.
>
> Secondly, I suggest to name the minimal version as "octave-cli" because
> this is what the octave binary (the command-line only version) is
> called. Also, running "guix package -A '-cli$'" shows some of the
> existing packages also follow similar naming convention (I don't know it
> they have a corresponding gui version though).
>
> What do others think?
>
> Cheers,
> Alex

I am in favor of this idea:
Octave && Octave Minimal

Brett

Octave & QtOctave

[Brett Gilio]

Hey all,

Happy guix birthday!

Quick question, why is the octave package split up into two different
public definitions, rather than just having the QtOctave-GUI being a
"gui" output, like it is for transmissionBT and some others?

Best,
Brett Gilio

Re: FOSDEM 2019 stand applications

[Brett Gilio]

Ludovic Courtès writes:

> Hello!
>
> Pjotr Prins  skribis:
>
>> On Fri, Nov 23, 2018 at 09:02:42AM +0100, Björn Höfling wrote:
>>> On Thu, 22 Nov 2018 23:16:47 -0600
>>> Brett Gilio  wrote:
>
> [...]
>
>>> Anyway, it was a first trial, we didn't put too much effort into it and
>>> we can now just concentrate on the 2 Guix-days before FOSDEM.
>
> Thanks a lot Björn for dealing with the application.  It’s a bit sad we
> didn’t get it, but like you write, there’s a lot of competition for
> relatively little space.  Oh well, maybe next year!
>
> I’m really looking forward to the Guix days, I’m confident it’s going to
> be fruitful and pleasant.
>
>> What we still can do is have promotional materials and provide them
>> through an existing stand. There are probably a few sympathetic to GNU
>> Guix. There are also some common tables we can use for that and (of
>> course) the minimalism devroom on Saturday.
>
> I agree.  We should print stickers and hopefully the FSFE booth or some
> other location will happily host them!
>
> Speaking of which, if someone has ready-to-use SVG files with stickers
> (maybe including the word “Guix” and not just the horns), please share!
> Someone can order them and then we can likely get it reimbursed by the
> Guix fund at the FSF or through the Guix Europe non-profit.
>
> Thanks,
> Ludo’.


Who among us is planning on going to FOSDEM19? I might see if I can
procure plane tickets and rooms for my wife and I, and buy a beer or
something for a few of us. Also, sorry I am out of the loop here, but
what is "Guix days"?

Brett Gilio

Re: Happy birthday!

[Brett Gilio]

Ludovic Courtès writes:

> Hello Guix!
>
> Today, it’s been six years already!
>
>   https://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg0.html
>
> ‘git shortlog -s’ says 231 people gave some of their time to Guix, and I
> think we can congratulate ourselves for six years of good hacking and
> great human interactions.  Surely Guix will have had its 1.0 release by
> the time it gets to the “age of reason”.  :-)
>
> Until then, if you want to make Guix a gift, consider helping out on the
> ‘core-updates’ merge:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00410.html
>
> Happy birthday, and happy hacking!  :-)
>
> Ludo’.

Happy birthday to the inception of the most advanced distribution of the
GNU system, to date. I want to thank Ludovic, Pierre, Ricardo, and so
many others who have been paramount in the inception of this project.

Brett Gilio

Re: Fw: FOSDEM 2019 stand applications

[Brett Gilio]

Björn Höfling writes:

> Hi Guix,
>
> we do NOT have a stand at FOSDEM 2019, our application was not accepted.
>
> Thank you to everyone who helped in preparing it and who offered
> to spend their time at the stand.
>
> Björn
>
>
> Begin forwarded message:
>
> Date: Thu, 22 Nov 2018 20:58:21 +
> From: Alasdair G Kergon 
> To: FOSDEM 2019 Stands Team 
> Subject: FOSDEM 2019 stand applications
>
>
> You are receiving this message (bcc) because your email address was
> listed on an application for a stand at FOSDEM 2019.
>
> Thank you all for your patience, but on behalf of the FOSDEM Stands
> Team I regret to inform you that your application has not been
> successful.
>
> I hope you are not too disappointed and will still join us at FOSDEM
> 2019 in another capacity.  As an alternative, there is just still time
> to apply for a lightning talk about your project(s).
>
> Alasdair

Bummer,

Did they provide any more feedback so that we can be more prepared next
year as more likely candidates?

Best,
Brett Gilio

Re: NPM importer

[Brett Gilio]

swedebugia writes:

> Hi
>
> On 2018-11-22 00:22, swedebugia wrote:
> snip
>
>> A graph of all npm packages and top packages is also available:
>> https://exploring-data.com/info/npm-packages-dependencies/
>
> While investigating the top libraries* packages with most depends in
> npm I found the following:
>
> Lib   Dep DevDep  RecdevDep   Dependants  license
> underscore0   12  2400+   18000+  mit
> async 1   37  269626069   mit
>
> rec=recursive
>
> See also the issue I created here:
> https://github.com/caolan/async/issues/1600 asking which of asyncs 37
> devdeps are needed to build or build+test async.
>
> And similar here: https://github.com/jashkenas/underscore/issues/2790


Holy cow.

Thank you for taking the initiative on this, swedebugia. I tend to agree
with your licensee approach, but I think this will require an undoubted
good deal of man power before we are able to sufficiently move forward
on npm imports with a decent velocity.

I know that the largest issue of this as usual will be the JavaScript
trap, but there will have to be some compromises on the part of people
wanting to develop for Node on Guix when their libraries are missing due
to non-free or ambiguous licensing. Not the least of which being the
issues surrounding Electron on the Chromium licenses, which seems to be
where a lot of energy is lately on the Node development side.

I also do not want Guix to detract too much for "more important issues",
not to say this isn't important. Just perhaps it isn't as much of a
priority simply because that community and ours are not so cohesive at
the current moment.

I guess one could argue that we should be wanting to bring them to us,
but I also know how disuasive "a lack of convenience" can be to those
who are not as freedom and ethicality conscious as the rest of us.

Brett Gilio

Re: NPM importer

[Brett Gilio]

Mike Gerwitz writes:

> The JavaScript community has poor licensing practices, and the culture
> is somewhat hostile to the ideals of the free software movement (they
> focus on permissive licensing to empower non-free software developers
> using those libraries).

To say the least. It will take a good deal of implementing a license
checker on the importer, as well as human verification to ensure that we
are maintaining a high ethical standard.

Brett Gilio

Re: more space on berlin.guixsd.org

[Brett Gilio]

Ricardo Wurmus writes:

> Hey Guix,
>
> today we finally succeeded in attaching an external storage array to the
> server known as berlin.guixsd.org.  I relocated the /gnu/store directory
> from the local 1TB disk to the external storage.  The result is that we
> now have 36TB of free space on /gnu.
>
> This means that we can keep more binaries and source archives for
> longer.  The storage array is redundant and is equipped with two hot
> spares, so we don’t need to fear for /gnu/store to suddenly become
> unavailable due to disk failure.

Terrific news, thank you Ricardo et. al.

Brett

GNOME & Tracker-Sparql

[Brett Gilio]

Hi all,

I hate to be a nuissance: I remember about a month ago wondering when we
could get Tracker-Sparql upgraded, and there was some great input. There
seemed to be a delay in the GNOME channel carrying many updates to our
GNOME environment. I was digging through our gnome.scm module and
realized that I do not think I had heard anything further on the
progress of updating GNOME since it is carrying many out-dated packages.

Anybody have any further thoughts?

Brett Gilio

Re: Packaging ufw

[Brett Gilio]

swedebugia writes:

> On 2018-11-10 17:01, swedebugia wrote:
>> Hi
>>
>> I like this firewall, has anybody started packaging it?
>>
>> If not I'm going to try.
>>
> Where should it be? In networking.scm or python.scm?
>
> We have no other firewall packages judging from my emacs-guix regex search.

Since it is not a python library, I think it would make more sense for
it to be located in the networking module.

Re: New info-guix mailing list for important announcements

[Brett Gilio]

Ludovic Courtès writes:

> Hello Guix!
>
> We have created a new mailing list for announcements: releases, build
> farm news, security advisories, incompatibilities, etc.
>
>   https://lists.gnu.org/mailman/listinfo/info-guix
>
> This is going to be low-traffic, with posts by the developers in charge.
>
> Guix users are very much encouraged to subscribe!
>
> Ludo’.

Grazi, Ludo.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: guix development

[Brett Gilio]

Ali Nourmohammadi writes:

> Hi thereI'm working on a project that want to build a guix based operating 
> system.For the first issue my job is to run lxqt on guix with openbox window 
> manager.After searching alot i failed in my job.So my last hope is on you to 
> help me with that.As i said i want to build lxqt on guix with openbox so i 
> found this 
> git:https://github.com/Millak/guix/blob/master/gnu/packages/lxqt.scmSo i copy 
> that and made a scm file called lxqt.scm.But when i try to install that 
> with:guix package -f lxqt.scmit failes with this error:: 
> error: invalid field specifier
> So i dont know what to do.So please if you are reading this email help me in 
> that. i read all the wiki but i could not find anything.So if u just have a 
> link about what to just let me know.Thank you so much.
> With bests.Ali nourmohammadi.

Hi Alii

Have you set an environment variable corresponding to $GUIX_PACKAGE_PATH
for the guile interpreter to be able to find your package?



-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: Berlin is down

[Brett Gilio]

Mark H Weaver writes:

> Hi Brett,
>
> Brett Gilio  writes:
>> Hydra seems to be (at least in part) working on my end. I noticed Berlin
>> went down, though, when I was tracking a bug.
>
> Hydra.gnu.org has been offline since about 6 days ago, so there's no
> way it could be working for you.  However, mirror.hydra.gnu.org is a
> different machine with an nginx cache that should still have some
> popular substitutes that were served by Hydra when it was up.
>
>   Mark


My mistake, you're right.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Leiningen follow-up

[Brett Gilio]

Hi all,

I notice that in February 2017 "Alex . ter . weele" attempted to package
Leiningen for Guix. I was wondering if anybody has a latest attempt at
that. I wouldn't mind picking up on it and seeing if we can't get it
added.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: Berlin is down

[Brett Gilio]

Clément Lassieur writes:

> Hi,
>
> Berlin returns 502, there are about 1000 builds (triggered by the Qt
> update) that weren't built.  If Hydra is still down too, there's
> currently no way to upgrade Guix without rebuilding the world.
>
> Cheers,
> Clément

Hydra seems to be (at least in part) working on my end. I noticed Berlin
went down, though, when I was tracking a bug.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: Package variation

[Brett Gilio]

Ludovic Courtès writes:

> Hi!
>
> Brett Gilio  skribis:
>
>> I am trying to customize my the default gnome-package which gets
>> installed with the gnome-desktop-service.
>
> On this topic, don’t miss Chris’s excellent tutorial:
>
>   
> https://gnu.org/software/guix/blog/2018/customize-guixsd-use-stock-ssh-agent-everywhere/
>
> :-)
>
> Ludo’.

Thank you for the feedback Ludo. I read the article and made some
customizations, but something about setting the gnome-custom package is
still resulting in the regular gnome meta-package being used. I did some
interactive debugging using Guile, and it seems like nautilus is being
successfully removed, which is why my suspicion is on the package
setting being invalid. I've also tried a myriad of different ways of
setting the gnome-custom package, none of which seem to be resulting in
nautilus being removed. This isn't about "nautilus" per-say, but rather
being able to customize how gnome is used on my system.

Here is my current config.

(use-modules (gnu) (gnu system nss) (guix packages) (srfi srfi-1) (ice-9 match))
(use-service-modules desktop)
(use-package-modules certs gnome)

(define-public gnome-custom
(package (inherit gnome)
  (name "gnome-custom")
  (propagated-inputs (remove
   (match-lambda
 ((name _)
  (string=? name "nautilus")))
   (package-propagated-inputs gnome)


(operating-system

...

(services (cons* (gnome-desktop-service
#:config (gnome-desktop-configuration
  (gnome-package gnome-custom)))
   %desktop-services))


Any ideas?

Re: Mono and .NET Core

[Brett Gilio]

Adam Van Ymeren writes:

> I tried to package .NET Core a while ago but didn't produce anything useful.  
> Their GNU/Linux story was rapidly changing at the time.
>
> .NET Core was a pain to package partly because it bootstraps from a binary 
> version of .NET Core similar to Rust.  Although it may be possible to 
> bootstrap via Mono I didn't try it and it's definitely not an upstream 
> supported route ;).
>
> Personally I ended up with just sticking to Mono for my C# needs as I found 
> .NET Core didn't integrate as nicely into the GNU/Linux ecosystem.
>
> That being said it would certainly be nice to have packages for it in Guix.
>
> On October 24, 2018 10:03:29 PM GMT+09:00, l...@gnu.org wrote:
>>Hello!
>>
>>Brett Gilio  skribis:
>>
>>> Two questions here.
>>>
>>> 1) Has anybody already started taking to try and upgrade Mono to
>>latest?
>>> If not, I will give it a go.
>>>
>>> 2) Have we started any packaging on .NET Core, would like to know to
>>> prevent redundancy in work.
>>
>>AFAIK nobody worked in this area yet, so you’ll probably have the
>>privilege to be a pioneer!  :-)
>>
>>Mono was added by janneke (Cc’d), who might have something to add?
>>
>>Ludo’.


>From what I see, coreclr https://github.com/dotnet/coreclr/ now uses a
build.sh script. Is it wise to simply use this in the package definition
to build it (I suspect not), or should the build system be configured
from scratch?

Re: Package variation

[Brett Gilio]

Chris Marusich writes:

> Hi Brett,
>
> Brett Gilio  writes:
>
>> (define-public gnome-custom
>>   (package (inherit gnome)
>> (name "gnome-custom")
>> (inputs (alist-delete "nautilus" (package-inputs gnome)
>
> The spirit of this is correct, but the implementation isn't quite
> right.  The gnome package has no inputs:
>
>   scheme@(guile-user)> ,use (gnu packages gnome)
>   scheme@(guile-user)> ,use (guix packages)
>   scheme@(guile-user)> (package-inputs gnome)
>   $1 = ()
>
> Instead, it has many propagated inputs.  So, you should probably write:
>
>   (define-public gnome-custom
> (package (inherit gnome)
>   (name "gnome-custom")
>   (propagated-inputs (alist-delete
>"nautilus"
>(package-propagated-inputs gnome)
>
> This will work as you expect.  It's not incorrect to use alist-delete
> here, but FYI you can also use matching to do this as follows:
>
>   (define-public gnome-custom
> (package (inherit gnome)
>   (name "gnome-custom")
>   (propagated-inputs (remove
>(match-lambda
>  ;; Ignore the second value.
>  ((name _)
>   (string=? name "nautilus")))
>(package-propagated-inputs gnome)
>
> Whether or not you like that better probably depends on whether or not
> you view the value returned by (package-propagated-inputs gnome) as an
> alist or a list of 2-element lists.
>
>> (services (cons* (service gnome-desktop-service-type
>>  config =>
>>  (gnome-desktop-configuration
>>   (inherit config)
>>   (gnome-package gnome-custom)))
>> %desktop-services))
>
> It looks like you're using "config =>" from the modify-services syntax
> without actually using modify-services.  Try this instead:
>
>   (services (cons* (service gnome-desktop-service-type
> (gnome-desktop-configuration
>   (inherit config)
>   (gnome-package gnome-custom)))
>%desktop-services))
>
> This should create and add a gnome-desktop-service-type service instance
> with the configuration you've specified.
>
> Hope that helps!


Hi chris! Thank you for your feedback, and your insight. I appreciate it
greatly. I have applied your changes (Both variations) and neither one
seems to be working and nautilus remains on the system. I am honestly at
a loss of what is wrong with the approach.

Re: Package variation

[Brett Gilio]

Efraim Flashner writes:

> On Tue, Oct 23, 2018 at 01:04:05PM -0500, Brett Gilio wrote:
>> 
>> Efraim Flashner writes:
>> 
>> > On Tue, Oct 23, 2018 at 01:51:21AM -0500, Brett Gilio wrote:
>> >> Hi all,
>> >> 
>> >> I am trying to customize my the default gnome-package which gets
>> >> installed with the gnome-desktop-service.
>> >> 
>> >> My strategy here has been to define a gnome-custom package in my
>> >> config.scm which inherits the gnome package, and remove the dependencies
>> >> that I do not use (such as gedit or nautilus).
>> >> 
>> >> However, I am not successful. Below is my config.scm, does anybody have
>> >> any ideas?
>> >> 
>> >> --
>> >> 
>> >> ;; This is an operating system configuration template
>> >> ;; for a "desktop" setup with GNOME and Xfce where the
>> >> ;; root partition is encrypted with LUKS.
>> >> 
>> >> (use-modules (gnu) (gnu system nss) (guix packages))
>> >> (use-service-modules desktop)
>> >> (use-package-modules certs gnome)
>> >> 
>> >> (define-public gnome-custom
>> >>   (package (inherit gnome)
>> >> (name "gnome-custom")
>> >> (inputs (alist-delete "nautilus" (package-inputs gnome)
>> >> 
>> >> (define %my-gnome
>> >>   (modify-services %desktop-services
>> >>  (gnome-desktop-service-type config =>
>> >>  (gnome-desktop-configuration
>> >> (gnome-package 
>> >> gnome-custom)
>> >> 
>> > 
>> >> 
>> >>   ;; Add GNOME and/or Xfce---we can choose at the log-in
>> >>   ;; screen with F1.  Use the "desktop" services, which
>> >>   ;; include the X11 log-in service, networking with
>> >>   ;; NetworkManager, and more.
>> >>   (services (cons* (gnome-desktop-service)
>> >>%my-gnome))
>> >
>> > Here you still have the default gnome-desktop-service in the list, and
>> > I'd assume you'd have a 50-50 chance of getting the right one when
>> > logging in. I would change it to (untested!):
>> >
>> > (services (cons* (service gnome-desktop-service-type
>> >   config =>
>> >   (gnome-desktop-configuration
>> > (inherit config)
>> > (gnome-package gnome-custom)))
>> >  %desktop-services))
>> >
>> > and just remove %my-gnome from above.
>> 
>> Hi Efraim,
>> 
>> What you said makes sense, and I think we are on the right track
>> here. This is what I have now.
>> 
>> (define-public gnome-custom
>>   (package (inherit gnome)
>> (name "gnome-custom")
>> (inputs (alist-delete "nautilus" (package-inputs gnome)
>> 
>> ;; ...
>> 
>> (services (cons* (service gnome-desktop-service-type
>>  config =>
>>  (gnome-desktop-configuration
>>   (inherit config)
>>   (gnome-package gnome-custom)))
>> %desktop-services))
>> 
>> 
>> However, it doesn't seem to recognize the gnome-desktop-service-type,
>> which I know is coming from the desktop service. Perhaps we are defining
>> it incorrectly? The documentation on the configuration system seems to
>> suggest we use the gnome-desktop-service and then place the
>> gnome-desktop-service, and then inherit and set the gnome-custom
>> package. But I could be misreading it. Regardless, I am still
>> unsuccessful here.
>> 
>> Thank you for your time.
>
> according to gnu/services/desktop.scm gnome-desktop-service-type should
> work, but since it doesn't seem to like it then go ahead and try
>
> (service gnome-desktop-service
> config => ...

I tried that and also simply removing the service definition, but it
still doesn't seem to recognize it. I wonder if it is something to do
with the service-modules being incorrect in the header.

Re: Package variation

[Brett Gilio]

Efraim Flashner writes:

> On Tue, Oct 23, 2018 at 01:51:21AM -0500, Brett Gilio wrote:
>> Hi all,
>> 
>> I am trying to customize my the default gnome-package which gets
>> installed with the gnome-desktop-service.
>> 
>> My strategy here has been to define a gnome-custom package in my
>> config.scm which inherits the gnome package, and remove the dependencies
>> that I do not use (such as gedit or nautilus).
>> 
>> However, I am not successful. Below is my config.scm, does anybody have
>> any ideas?
>> 
>> --
>> 
>> ;; This is an operating system configuration template
>> ;; for a "desktop" setup with GNOME and Xfce where the
>> ;; root partition is encrypted with LUKS.
>> 
>> (use-modules (gnu) (gnu system nss) (guix packages))
>> (use-service-modules desktop)
>> (use-package-modules certs gnome)
>> 
>> (define-public gnome-custom
>>   (package (inherit gnome)
>> (name "gnome-custom")
>> (inputs (alist-delete "nautilus" (package-inputs gnome)
>> 
>> (define %my-gnome
>>   (modify-services %desktop-services
>> (gnome-desktop-service-type config =>
>> (gnome-desktop-configuration
>>(gnome-package 
>> gnome-custom)
>> 
> 
>> 
>>   ;; Add GNOME and/or Xfce---we can choose at the log-in
>>   ;; screen with F1.  Use the "desktop" services, which
>>   ;; include the X11 log-in service, networking with
>>   ;; NetworkManager, and more.
>>   (services (cons* (gnome-desktop-service)
>>%my-gnome))
>
> Here you still have the default gnome-desktop-service in the list, and
> I'd assume you'd have a 50-50 chance of getting the right one when
> logging in. I would change it to (untested!):
>
> (services (cons* (service gnome-desktop-service-type
>   config =>
>   (gnome-desktop-configuration
> (inherit config)
> (gnome-package gnome-custom)))
>  %desktop-services))
>
> and just remove %my-gnome from above.

Hi Efraim,

What you said makes sense, and I think we are on the right track
here. This is what I have now.

(define-public gnome-custom
  (package (inherit gnome)
(name "gnome-custom")
(inputs (alist-delete "nautilus" (package-inputs gnome)

;; ...

(services (cons* (service gnome-desktop-service-type
config =>
(gnome-desktop-configuration
 (inherit config)
 (gnome-package gnome-custom)))
   %desktop-services))


However, it doesn't seem to recognize the gnome-desktop-service-type,
which I know is coming from the desktop service. Perhaps we are defining
it incorrectly? The documentation on the configuration system seems to
suggest we use the gnome-desktop-service and then place the
gnome-desktop-service, and then inherit and set the gnome-custom
package. But I could be misreading it. Regardless, I am still
unsuccessful here.

Thank you for your time.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Package variation

[Brett Gilio]

Hi all,

I am trying to customize my the default gnome-package which gets
installed with the gnome-desktop-service.

My strategy here has been to define a gnome-custom package in my
config.scm which inherits the gnome package, and remove the dependencies
that I do not use (such as gedit or nautilus).

However, I am not successful. Below is my config.scm, does anybody have
any ideas?

--

;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.

(use-modules (gnu) (gnu system nss) (guix packages))
(use-service-modules desktop)
(use-package-modules certs gnome)

(define-public gnome-custom
  (package (inherit gnome)
(name "gnome-custom")
(inputs (alist-delete "nautilus" (package-inputs gnome)

(define %my-gnome
  (modify-services %desktop-services
   (gnome-desktop-service-type config =>
   (gnome-desktop-configuration
  (gnome-package 
gnome-custom)

(operating-system
  (host-name "oryxpro")
  (timezone "America/Chicago")
  (locale "en_US.utf8")

  ;; Use the UEFI variant of GRUB with the EFI System
  ;; Partition mounted on /boot/efi.
  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))

  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  (users (cons (user-account
(name "brettg")
(comment "Brett Gilio")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"))
(home-directory "/home/brettg"))
   %base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (cons* nss-certs ;for HTTPS access
   gvfs  ;for user mounts
   %base-packages))

  ;; Add GNOME and/or Xfce---we can choose at the log-in
  ;; screen with F1.  Use the "desktop" services, which
  ;; include the X11 log-in service, networking with
  ;; NetworkManager, and more.
  (services (cons* (gnome-desktop-service)
   %my-gnome))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

--


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Mono and .NET Core

[Brett Gilio]

Hi all,

Two questions here.

1) Has anybody already started taking to try and upgrade Mono to latest?
If not, I will give it a go.

2) Have we started any packaging on .NET Core, would like to know to
prevent redundancy in work.

Best,


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: rustup & cargo

[Brett Gilio]

Chris Marusich writes:


Hi Brett!

Welcome!  I'm also curious about the situation with Rust.  I'm 
learning
Rust because I find it interesting, and I use GuixSD, so here my 
two

interests (Rust and Guix) overlap.

Brett Gilio  writes:

Hi all, I am curious about the status of providing rustup 
toolchain
management and cargo for guix. I work often in rust, and these 
tools

are
pretty essential. I might be interested in helping with the 
packaging
here, but I would like to know what the Guix community has on 
this so

far.


I haven't done much with Rust yet, but I am able to compile 
programs and
run them using the Guix-installed Rust compiler.  I haven't 
tried using
rustup to install or upgrade Rust, though; I think the way to 
install
and upgrade Rust via Guix is to use Guix, not rustup, but I 
could be
mistaken.  I have no idea what the status of cargo is, but when 
I built
a project the other day, it successfully downloaded a bunch of 
crates

and built the code, so presumably it's working.

If you search the email list, you'll find some other interesting
discussions about Rust.  One problem we have is that Rust is not 
yet
fully bootstrapped, but that's somewhat orthogonal to using 
Rust.


https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=rust=Search%21=guix-devel=20=normal=score

Glad to have you here!


Thank you, Chris! I, too, have been working with Guix's packaging 
of
Rust. However, what I wish was available was a nightly build of 
the rust
branch. I know it is likely possible to make a guile definition 
for
this, I just have not gotten to it yet. That was mostly my inquiry 
as to

using rustup.


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Flagging packages

[Brett Gilio]

I was wondering if there has been any discussion on introducing a 
way to
flag out-of-date packages either through the guix package website 
or
using a guix package flag. I, personally, come from an 
Arch/Parabola

background, and such a feature was usually a good way to alert the
community of something corrective needing to be done. It could 
trigger a
mailing list alert, which could then be claimed by a member 
willing to

manage it and submit a patch.

Thoughts?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Gradio attempt

[Brett Gilio]

Leo Famulari writes:


On Thu, Oct 11, 2018 at 04:33:31PM -0500, Brett Gilio wrote:
Thank you for your feedback on the description. As for whether 
or not
the application works, yes. I click on "Add stations to 
library". It
takes a few seconds for it to populate, but I am eventually 
shown
several choices and something to click on. From there, after 
clicking on

a station, I receive a missing codec error.


Thanks, I got it to load the stations when run within GNOME.

The missing plugin error is related to GStreamer and the various
GStreamer plugins; I don't think Gradio uses LAME. I tried 
building with
all of the GStreamer libraries and plugins, or installing them 
all

alongside Gradio, but no luck.


I tried the same thing after I sent the initial email and looking 
at the
build process more closely. But, I am in the same position as you, 
no
luck. I am not sure how it is verifying the presence of the codec, 
if it
is looking in a specific path or something. What do you suggest I 
do

from here?

Brett

--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Gradio attempt

[Brett Gilio]

Leo Famulari writes:


On Wed, Oct 10, 2018 at 03:56:42PM -0500, Brett Gilio wrote:
1) The description is virtually null, because I am not quite 
sure I
understand fully what to put there. The documentation helped, 
but it

still feels ambiguous to this specific project.


The description is sometimes the hardest part of a package, 
especially
when there is nothing to copy from upstream :) I would mention 
that it's
a graphical program, what kind of internet radio stations it 
supports,
that it offers a tool to discover new stations (although it 
doesn't work

for me), and things like that.

2) I tried a propagated-input of `lame` to make the MP3 codecs 
work, but

it seems that was a failure.


Can you explain how it failed? I couldn't get the program to 
show me a
list of potential stations, or find a way to add an URL that I 
know

works. Are you able to use the program at all?


Hi Leo

Thank you for your feedback on the description. As for whether or 
not
the application works, yes. I click on "Add stations to library". 
It

takes a few seconds for it to populate, but I am eventually shown
several choices and something to click on. From there, after 
clicking on

a station, I receive a missing codec error.


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

QtCreator Packaging

[Brett Gilio]

Hi all,

I am beginning my attempt to package QtCreator. My approach, thus 
far,

has been to look over the build documentation for the project in
question, and then incrementally change the Scheme definition for 
the
package. Usually, this works out pretty well, but here I am 
running into
a configuring error that I am not sure how to make sense of 
because (as

far as I can see) it is not reporting an error.

Here is the current package definition:
http://ix.io/1oTH

Here is the kill ring for the build:
http://ix.io/1oTJ


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Gradio attempt

[Brett Gilio]

Hi all,

I have just attempted by first complete Guix packaging. I am 
submitting
it here for criticism. Here are a few things I am missing, or is 
not

working for me on my end.

1) The description is virtually null, because I am not quite sure 
I
understand fully what to put there. The documentation helped, but 
it

still feels ambiguous to this specific project.

2) I tried a propagated-input of `lame` to make the MP3 codecs 
work, but

it seems that was a failure.

I have linted and verified most things here, let me know what you 
think:


--- BEGIN ---

(define-module (gradio)
 #:use-module (guix licenses)
 #:use-module (guix packages)
 #:use-module (guix download)
 #:use-module (guix profiles)
 #:use-module (guix build-system meson)
 #:use-module (gnu packages glib)
 #:use-module (gnu packages gtk)
 #:use-module (gnu packages gnome)
 #:use-module (gnu packages gstreamer)
 #:use-module (gnu packages databases)
 #:use-module (gnu packages pkg-config)
 #:use-module (gnu packages base)
 #:use-module (gnu packages gettext)
 #:use-module (gnu packages freedesktop)
 #:use-module (gnu packages mp3))

(define-public gradio
 (package
  (name "gradio")
  (version "7.1")
  (source (origin
   (method url-fetch)
   (uri (string-append 
   "https://github.com/haecker-felix/Gradio/archive/v; 
   version ".tar.gz"))

   (sha256
(base32
 "0rm73fldzlk6h8lssk8jcw6k97acsln09x5a1l1zj02g2a1hadbv"
(build-system meson-build-system)
(native-inputs `(("glib" ,glib "bin")
("gtk+" ,gtk+)
("gtk+" ,gtk+ "bin")
("libsoup" ,libsoup)
("json-glib" ,json-glib)
("gstreamer" ,gstreamer)
("sqlite" ,sqlite)
("vala" ,vala)
("pkg-config" ,pkg-config)
("gst-plugins-base" ,gst-plugins-base)
("gnu-gettext" ,gnu-gettext)
("desktop-file-utils" ,desktop-file-utils)))
(propagated-inputs `(("lame" ,lame)))
(synopsis "Find and listen to internet radio stations")
(description "Find and listen to internet radio stations.")
(home-page "https://github.com/haecker-felix/Gradio;)
(license gpl3+)))

--- END ---


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: glib-compiler-resources

[Brett Gilio]

Tobias Geerinckx-Rice writes:


Brett,

Brett Gilio wrote:

Hi all, I am working on packaging the internet radio streaming
application, gradio.

Things seem to be going well, except during build-time I am 
getting


FileNotFoundError: [Errno 2] No such file or directory:
'glib-compile-resources': 'glib-compile-resources'


Any thoughts as to where this could be?


It's in glib:bin (add it as ',glib "bin"').

Kind regards,

T G-R


How about update-desktop-database?

I tried adding xdg-desktop-database but I do not think that is 
correct.

Not finding documentation here.

glib-compiler-resources

[Brett Gilio]

Hi all, I am working on packaging the internet radio streaming
application, gradio.

Things seem to be going well, except during build-time I am 
getting


FileNotFoundError: [Errno 2] No such file or directory: 
'glib-compile-resources': 'glib-compile-resources'



Any thoughts as to where this could be?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Is LLDB around?

[Brett Gilio]

Hi all. I am attempting to package the dotnet packages for Guix. 
One of
the build dependencies is LLDB. Is it not packaged with clang or 
llvm?
What is our procedure for dealing with LLDB or is it simply 
needing

packaged?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Tracker & Gnome

[Brett Gilio]

Ricardo Wurmus writes:

The interesting part is right before this backtrace.


Thank you for the insight Ricardo. Here is the first iteration of 
an

error and the backtrace.

/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/bash: 
../../utils/g-ir-merge/g-ir-merge: /usr/bin/env: bad interpreter: 
No such file or directory

make[3]: *** [Makefile:851: Tracker-2.0.gir] Error 126
make[3]: Leaving directory 
'/tmp/guix-build-tracker-2.0.4.drv-0/tracker-2.0.4/src/libtracker-sparql-backend'

make[2]: *** [Makefile:493: all-recursive] Error 1
make[2]: Leaving directory 
'/tmp/guix-build-tracker-2.0.4.drv-0/tracker-2.0.4/src'

make[1]: *** [Makefile:1061: all-recursive] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-tracker-2.0.4.drv-0/tracker-2.0.4'

make: *** [Makefile:787: all] Error 2
Backtrace:
  4 (primitive-load 
  "/gnu/store/zky7vlqj2ym3whln3iwng5klvf3…")

In ice-9/eval.scm:
  191:35  3 (_ _)
In srfi/srfi-1.scm:
   640:9  2 (for-each #   /gnu/store/wyf1zrn2ska…> …)
In 
/gnu/store/wyf1zrn2skakkc9indjz30v6lgc2zq2c-module-import/guix/build/gnu-build-system.scm:

  799:31  1 (_ _)
In 
/gnu/store/wyf1zrn2skakkc9indjz30v6lgc2zq2c-module-import/guix/build/utils.scm:

   616:6  0 (invoke _ . _)

/gnu/store/wyf1zrn2skakkc9indjz30v6lgc2zq2c-module-import/guix/build/utils.scm:616:6: 
In procedure invoke:
Throw to key `srfi-34' with args `(#[program: "make" arguments: ("-j" "8" 
"gtk_update_icon_cache=true") exit-status: 2 term-signal: #f 
stop-signal: #f] 9c6fc0>)'.
builder for 
`/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv' 
failed with exit code 1
build of 
/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv 
failed
View build log at 
'/var/log/guix/drvs/bm/bs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv.bz2'.
guix build: error: build failed: build of 
`/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv' 
failed



--- I see a few things here, a missing interpreter (or possibly 
   missing

   environment variable from bash-minimal?) I tried installing
   bash-mininal in my build environment, but that didn't seem to
   resolve anything as I expected it wouldn't.

   However, upon looking into the configuring step of tracker's 
   build,

   I notice that things look fine there.

Thoughts?

Best


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Matrix & Nheko Packaging

[Brett Gilio]

Hi all,

In my time using GuixSD I have had some relative success in not 
only
learning the environment, but also getting some of my peers to 
switch.
As with Guix still being very much a growing project, we all know 
the
excitement and struggle that comes with the repository lacking 
some

essential packages we are accustomed in a transition.

My peers and I use the Matrix protocol for most of our 
communication as
a secondary option to IRC and Email. I have been contemplating 
which
Matrix client would be easiest to package for Guix and have 
decided on

Nheko, which is free software.

This client has most of the necessary components already packaged 
on
Guix with the exception of a few. Thankfully, those missing 
packages are
also free software. So, in total, I would be looking at packaging 
three

or four components.

I am wondering if there are any other Matrix users who have any
objections or agreement to this possibility.

Anyways, carry on.

https://github.com/mujx/nheko

--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Tracker & Gnome

[Brett Gilio]

Ricardo Wurmus writes:


Ludovic Courtès  writes:

In fact, I see that Ricardo upgraded Tracker in 
‘wip-gnome-updates’:


  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome-upgrades=dd9110df3ad1efaf5cf716f6be5b710b5d348400

Ricardo, do you think we could cherry-pick it on ‘master’? 
‘guix

refresh -l tracker’ shows only 4 dependent packages.


That branch was supposed to be merged right after 
“core-updates”.  I
originally thought this would happen a little sooner, but we’re 
still

waiting for “core-updates” to be merged into “master”.

It’s fine to cherry-pick it, but ideally we would merge the 
whole

branch.


I'm not sure it is possible to cherry pick it, unless I am getting
something wrong. When I refresh tracker and try to build it using 
guix

build it is throwing a build error.

/gnu/store/wyf1zrn2skakkc9indjz30v6lgc2zq2c-module-import/guix/build/utils.scm:616:6: 
In procedure invoke:
Throw to key `srfi-34' with args `(#[program: "make" arguments: ("-j" "8" 
"gtk_update_icon_cache=true") exit-status: 2 term-signal: #f 
stop-signal: #f] a07fc0>)'.
builder for 
`/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv' 
failed with exit code 1
build of 
/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv 
failed
View build log at 
'/var/log/guix/drvs/bm/bs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv.bz2'.
guix build: error: build failed: build of 
`/gnu/store/bmbs64z3xz0w4ygmj3qcz31dxqmnamvr-tracker-2.0.4.drv' 
failed

Re: Tracker & Gnome

[Brett Gilio]

Björn Höfling writes:


On Mon, 08 Oct 2018 14:42:31 -0500
Brett Gilio  wrote:


Ludovic Courtès writes:

> Hello Brett,
>
> To complete what Nils wrote, Tracker is indeed lagging behind 
> on 
> master:

>
> --8<---cut 
> here---start->8---

> $ guix refresh tracker
> gnu/packages/gnome.scm:5715:13: tracker would be upgraded 
> from 
> 1.12.3 to 2.0.4
> --8<---cut 
> here---end--->8---

>
> You could try upgrading it and see what happens.
>
> In fact, I see that Ricardo upgraded Tracker in 
> ‘wip-gnome-updates’:

>
>   
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome-upgrades=dd9110df3ad1efaf5cf716f6be5b710b5d348400
>
> Ricardo, do you think we could cherry-pick it on ‘master’? 
> ‘guix

> refresh -l tracker’ shows only 4 dependent packages.
>
> Thanks,
> Ludo’.  


Hi Ludo,

Thank you for your insight.

I tried passing guix refresh -u tracker to the terminal and am 
getting

this output

guix refresh: error: mkstemp!: Read-only file system



Hi Brett,

it looks like you are trying this with the "installed" guix. But 
you

need to go from the checked out git repository. You will find
instructions here:

https://www.gnu.org/software/guix/manual/en/html_node/Building-from-Git.html#Building-from-Git

Basicly, you git clone the sources. Then with

guix environment guix

you enter an environment with all dev dependencies for Guix.

Then you can build it with

./bootstrap && ./configure --localstatedir=/var && make

Finally, execute guix from source:

./pre-inst-env guix refresh -u

After that, you will find local changes and you can check and 
prepare

the patch.

Björn


Thank you for the information, Bjorn. That makes more sense. I 
will get

back to you with the result of the changes ASAP.

Brett

Re: Tracker & Gnome

[Brett Gilio]

Ludovic Courtès writes:


Hello Brett,

To complete what Nils wrote, Tracker is indeed lagging behind on 
master:


--8<---cut 
here---start->8---

$ guix refresh tracker
gnu/packages/gnome.scm:5715:13: tracker would be upgraded from 
1.12.3 to 2.0.4
--8<---cut 
here---end--->8---


You could try upgrading it and see what happens.

In fact, I see that Ricardo upgraded Tracker in 
‘wip-gnome-updates’:


  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome-upgrades=dd9110df3ad1efaf5cf716f6be5b710b5d348400

Ricardo, do you think we could cherry-pick it on ‘master’? 
‘guix

refresh -l tracker’ shows only 4 dependent packages.

Thanks,
Ludo’.


Hi Ludo,

Thank you for your insight.

I tried passing guix refresh -u tracker to the terminal and am 
getting

this output

guix refresh: error: mkstemp!: Read-only file system

I am going to try and dissect this from the documentation, but I 
wanted

to pass it along.

Tracker & Gnome

[Brett Gilio]

Hi all.

I am still fairly new to the concept of packaging for Guix. I 
also, from
time to time, enjoy hacking on GNOME components. One of the 
components
that I am currently lacking is tracker-sparql-2.0. I am pretty 
certain
this is due to the tracker package being out-of-date. Do you all 
have
any insights on how I could go about upgrading this component in 
the
gnome package? Is there perhaps a reason why it has not been 
upgraded,

stability or such?

Best


--
Brett M. Gilio
Free Software Foundation, Member
https://parabola.nu | https://emacs.org