Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

John Soo  writes:

> It can be hard to review a patchset with multiple revisions
> (particularly when sent as attachments).

I agree.

> It is hard to find how patchsets differ - let alone where
> revisions start and end.

Do you have an idea how to improve this?  Should we use, for example,
the message subject to detect revisions?  (E.g. [PATCH 3/3] will
indicate that the end of the patch set has been reached.)

How would we indicate different patch sets visually?  Should there be
links somewhere to jump to patch sets?

--
Ricardo

New Russian PO file for 'guix-manual' (version 1.1.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll  writes:

> Searching with "mdate:2w..now" does show a single issue,
> is that really so ?

mdate actually no longer exists.  It was used when we queried the
debbugs service directly.  Now that we only query a local database we
only have “date”.  I’ll update the help.

-- 
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

On Mon, Mar 30, 2020 at 1:07 PM Ricardo Wurmus  wrote:
> mdate actually no longer exists.  It was used when we queried the
> debbugs service directly.  Now that we only query a local database we
> only have “date”.  I’ll update the help.

Thanks for the update, and many thanks for working on this. The site
is already useful, and will be even more in the future. I hope you are
not swamped under the avalanche of suggestions. ;-)

-- 
Vincent Legoll

Re: Proxy settings wrt guix daemon

[Vincent Legoll]

Hello

On Sun, Mar 29, 2020 at 5:00 PM Ludovic Courtès  wrote:
> So my recommendation would be to fix [4] specifically for ‘guix-daemon’
> by adding a ‘set-proxy’ action or something.

Trying to understand what that would imply, I stumbled upon my
ignorance of how to test attempts at implementing that.

Would the following be useful :
make + pre-inst guix system container in a git checkout / branch
with modifications to nix/libstore/builtins.cc::builtinDownload (for
the server part)

Then how to implement the "asking the server to change its
proxy setting" ? Where should I look ?

What UI (client-side) ?

`guix daemon set-proxy` or something like that ?

I.e. I'm willing to try, but will need guidance...

-- 
Vincent Legoll

Re: non-deterministic test suite failure for diffoscope

[Vagrant Cascadian]

On 2020-03-05, Vagrant Cascadian wrote:
> I've occasionally seen non-deterministic failures in diffoscope's test
> suite only on GNU Guix, and wondering if someone more familiar with how
> guix's python-build-system calls pytest could look into it. The bug is
> reported upstream here:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/issues/74
>
> I'm not sure if there's a guix bug related to this issue.

About to look at packaging the next diffoscope version, but it would be
good to troubleshoot this issue. It only seems to fail when built under
guix daemon, and not even deterministically then... so help from someone
with debugging python issues under guix would be much appreciated.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Update MATE to 1.24

[Jonathan Brielmaier]

I have opened bugs for the issues, so we don't loose them.

On 25.03.20 22:32, Jonathan Brielmaier wrote:
> Other findings
> ==
> * You can't shutdown or reboot. There is now button in MATE nor in GDM
> after logging outhttp://debbugs.gnu.org/cgi/bugreport.cgi?bug=40327

> * If you install a program or add it to your config.scm it only appears
> in the App menu after the next reboot.
> * pluma: installing external plugins fails with: "plugin loader python3
> not found". Can be maybe fixed with propagating python. Plugins who are
> installed by default do work.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40328

> * atril: Logo in about page is not an SVG.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40329

> * mate-control-center: `Preferred Applications` does not start/work.
> `Time and Date Manager` does not work as well (dbus error).
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40330

Re: Update MATE to 1.24

[Jonathan Brielmaier]

On 25.03.20 22:58, sirgazil wrote:
> Other problems I noticed in 1.22 were:
>
> * Overlapping icons in panel applets.
I added some applets to the panel. Their icons doesn't overlap. At least
not to my eyes :)

> * Not possible to add/remove workspaces.
You mean the workspace switcher in the applet panel? Or do you mean that
one cannot reduce/increase the number of shown workspaces (default: 4)?
This also doesn't work at 1.24.

> * Not possible to enable system alert sounds.
> * IBus didn't run when I activated it.
>
> I have more information about these issues, but was waiting to see if they 
> were solved in MATE 1.24 before reporting them.

Redox OS?

[bijan ghavami-kia]

I am very interested in guix and am happy to see the hurd being ported as well 
as all the wonderful developments recently with guile 3 and bootstrapping,
so I hope it's not sacrilige to ask whether anyone has looked at this new rust 
based microkernal https://www.redox-os.org/ 
https://gitlab.redox-os.org/redox-os that is under development,
and whether it could be ported to the guix system also?
there is already an effort of some degree to port to nix 
https://gitlab.redox-os.org/redox-os/redox-nix, (so why not guix??)
it seems like a promising system and although it may be too underdeveloped to 
yet be usable, (could it it may be interesting for the development of the hurd 
in some way),
as well as potentially a viable alternative in the future (see videos from the 
developer, who works at system76 and ARM representative. 
https://www.youtube.com/watch?v=qpazyDkuqLw&t=2119s 
https://www.youtube.com/watch?v=G4VlHzyKZeE&t=2547s.
It has a package manager under development as well which might be worth a look, 
for interest if nothing else, also 
https://www.redox-os.org/news/pkgar-introduction/ 
https://gitlab.redox-os.org/redox-os/pkgar.
Finally, if nothing else would components, such as the shell 
https://gitlab.redox-os.org/redox-os/ion, or file system 
https://gitlab.redox-os.org/redox-os/tfs be possible to port for use?
Excuse my ignorance if this is out of place, I'm a non-programmer enthusiast😋

Re: Update MATE to 1.24

[sirgazil]

  On Mon, 30 Mar 2020 14:43:58 -0500 Jonathan Brielmaier 
 wrote 
 > On 25.03.20 22:58, sirgazil wrote:
 > > Other problems I noticed in 1.22 were:
 > >
 > > * Overlapping icons in panel applets.
 > I added some applets to the panel. Their icons doesn't overlap. At least
 > not to my eyes :)

Great :)

 > > * Not possible to add/remove workspaces.
 > You mean the workspace switcher in the applet panel? Or do you mean that
 > one cannot reduce/increase the number of shown workspaces (default: 4)?
 > This also doesn't work at 1.24.

When I right-clicked the worskpaces switcher, and selected preferences, I saw 
this:

https://multimedialib.files.wordpress.com/2020/03/mate-1.22-disabled-workspaces-spin-box-2020-03-23.png

The +/- buttons to add/remove workspaces don't work and you can even see that 
the number field (which shows 4 by default) is disabled. So you are not able to 
modify the number of workspaces, which is a bug, because MATE documentation 
says you can.

Re: Update MATE to 1.24

[Jonathan Brielmaier]

On 30.03.20 22:42, sirgazil wrote:
>  > > * Not possible to add/remove workspaces.
>  > You mean the workspace switcher in the applet panel? Or do you mean that
>  > one cannot reduce/increase the number of shown workspaces (default: 4)?
>  > This also doesn't work at 1.24.
>
> When I right-clicked the worskpaces switcher, and selected preferences, I saw 
> this:
>
> https://multimedialib.files.wordpress.com/2020/03/mate-1.22-disabled-workspaces-spin-box-2020-03-23.png
>
> The +/- buttons to add/remove workspaces don't work and you can even see that 
> the number field (which shows 4 by default) is disabled. So you are not able 
> to modify the number of workspaces, which is a bug, because MATE 
> documentation says you can.

I can confirm this. Can you open a bug for please?

Re: Update MATE to 1.24

[sirgazil]

  On Mon, 30 Mar 2020 15:43:42 -0500 Jonathan Brielmaier 
 wrote 
 > On 30.03.20 22:42, sirgazil wrote:
 > >  > > * Not possible to add/remove workspaces.
 > >  > You mean the workspace switcher in the applet panel? Or do you mean that
 > >  > one cannot reduce/increase the number of shown workspaces (default: 4)?
 > >  > This also doesn't work at 1.24.
 > >
 > > When I right-clicked the worskpaces switcher, and selected preferences, I 
 > > saw this:
 > >
 > > https://multimedialib.files.wordpress.com/2020/03/mate-1.22-disabled-workspaces-spin-box-2020-03-23.png
 > >
 > > The +/- buttons to add/remove workspaces don't work and you can even see 
 > > that the number field (which shows 4 by default) is disabled. So you are 
 > > not able to modify the number of workspaces, which is a bug, because MATE 
 > > documentation says you can.
 > 
 > I can confirm this. Can you open a bug for please?

Sure.

Re: LHC for guixHPC?

[bijan ghavami-kia]

Thank you kindly for the reply! I have one question born out of my ignorance, 
so please be patient with me; I am looking at the various packages, which 
belong to various repos eg CRAN, TeXlive etc;
for the julia language..., is there a similar thing, or the packages are 
through the julia built in package manager only (although it seems a very 
decent one https://julialang.org/blog/2019/11/artifacts/)? And if so, is there 
a reason and is there any loss or conflict in relation to the guix package 
management interaction with these?
Apologies if these are stupid queries, I am not experienced and I'm sure there 
are simple answers
Pkg + BinaryBuilder -- The Next 
Generation
Over the past few months, we have been iterating on and refining a design for 
Pkg in Julia 1.3+ to reason about binary objects that are not Julia packages. 
While the motivating application for this work has been improving the 
installation experience for binaries built with BinaryBuilder.jl, the artifacts 
subsystem is much more general and is widely applicable to all Julia packages.
julialang.org



From: Ludovic Courtès 
Sent: Wednesday 11 March 2020 14:23
To: bijan ghavami-kia 
Cc: guix-devel@gnu.org 
Subject: Re: LHC for guixHPC?

Hi!

bijan ghavami-kia  skribis:

> https://m.youtube.com/watch?v=Ee8k97Rx3DA
> https://cds.cern.ch/record/2633268?ln=en
> https://gitlab.cern.ch/lhcb-nix
> https://www.researchgate.net/publication/335864271_Software_packaging_and_distribution_for_LHCb_using_Nix
>
> Just wanted to highlight this interesting work to guix, if it wasn't already 
> known, in particular regards to the existing hpc project.
> The lhc seems to be looking for options to move away from rhel scientific os 
> and cent os.
> I'm not sure if guix was on the radar for this particular researcher.
> Would the guix project team consider an outreach and discussion, particularly 
> if theres anything to help him achieve his goals.
> Seems natural since guix is establishing in the hpc/ academic arena..

I agree!  As part of the Guix-HPC effort, Ricardo Wurmus and myself gave
a talk about Guix a couple of years ago at CERN, but CERN is vast and
the people we met are perhaps far away from those mentioned above.

If anyone has contact with folks at CERN, we can surely have a
discussion.  :-)

Thanks for the heads-up,
Ludo’.

Re: Update MATE to 1.24

[sirgazil]

  On Mon, 30 Mar 2020 15:43:42 -0500 Jonathan Brielmaier 
 wrote 
 > On 30.03.20 22:42, sirgazil wrote:
 > >  > > * Not possible to add/remove workspaces.
 > >  > You mean the workspace switcher in the applet panel? Or do you mean that
 > >  > one cannot reduce/increase the number of shown workspaces (default: 4)?
 > >  > This also doesn't work at 1.24.
 > >
 > > When I right-clicked the worskpaces switcher, and selected preferences, I 
 > > saw this:
 > >
 > > https://multimedialib.files.wordpress.com/2020/03/mate-1.22-disabled-workspaces-spin-box-2020-03-23.png
 > >
 > > The +/- buttons to add/remove workspaces don't work and you can even see 
 > > that the number field (which shows 4 by default) is disabled. So you are 
 > > not able to modify the number of workspaces, which is a bug, because MATE 
 > > documentation says you can.
 > 
 > I can confirm this. Can you open a bug for please?
 > 

Done: http://issues.guix.gnu.org/issue/40334

By the way, Jonathan, can you reproduce this one?

## Steps to reproduce

* Go to System → Control Center → Sound.
* Go to the Sound Effects tab.

## Expected result

I can pick a sound theme, and then a sound from the list of alert sounds.


## Unexpected result

The sound theme and list of sounds are disabled, so I have to use the selected 
default (which provides no sound).

Patchwork + the Guix Data Service for assisting with patch review

[Christopher Baines]

Hey,

I sent out an email [1] yesterday on data.guix.gnu.org and the Guix Data
Service software that runs there, but I focused that email around
data.guix.gnu.org, this email relates in some way to the first
application of the Guix Data Service, which was the prototype I set up
for automating parts of reviewing Guix patches.

1: https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00268.html

This email is in four rough parts, some rambling, then an update on the
"Current Status" of the patch review tooling I've been trying to setup,
then a description of "How you can use Patchwork for reviewing patches",
then a small comment on "Next steps".

All the way back at the end of October 2018, I sent out an email about
Patchwork [2], followed by one about the Guix Data Service in February
of 2019 [3] and then an email [4] in March which described automatically
building packages which are affected by patches.

2: https://lists.gnu.org/archive/html/guix-devel/2018-10/msg00638.html
3: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00089.html
4: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html

It's a little frightening where all the time has gone! But while I don't
think much has changed in terms of automating and assisting with patch
review, the Guix Data Service software, and the deployment at
data.guix.gnu.org has moved forward a lot. It can load and store data
about packages, derivations, git repositories, lint warnings, builds,
substitutes and can already make this data available in useful ways.

Which brings the subject back to assisting with patch review. Back when
I originally tried to setup Patchwork + the Guix Data Service + Cuirass
to build packages related to patches, the building packages never really
worked, and even if it did, it would have been very difficult to spot
things like a patch breaking a package that used to build. Similarly,
while Patchwork + the Laminar jobs could help spotting patches that
didn't apply, it still couldn't do much to assist people reviewing
patches.

Now this started to change around August last year, when the Guix Data
Service became capable of storing data for some lint warnings (those
that don't use the network). This now meant that at least getting data
about patches in to the Guix Data Service could tell you what these
patches did in terms of lint warnings for a subset of the checkers.

Another useful feature of the Guix Data Service that I've been
occasionally using when reviewing patches is it's ability to provide
substitutes for derivations. As I've got my computer setup to use the
guix-patches-data.cbaines.net instance of the Guix Data Service for
substitutes, building a derivation that's new or been changed as a
result of a patch is as easy as copying the full filename in to a
terminal and running guix build with it. Ideally, building derivations
that are new or that have been changed would be automated, and I think
the Guix Data Service providing substitutes might be able to help with
that.

## Current Status

I've got the stuff I setup previously somewhat working again, the
following parts are in play:

 - Patchwork: https://patchwork.cbaines.net/project/guix-patches/list/
   - getmail is running to listen for emails
 - Guix Data Service: https://guix-patches-data.cbaines.net
   - getmail is running to listen for emails
 - Laminar: https://laminar.cbaines.net/
 - Git stuff: https://git.cbaines.net/guix/patches/
   - A combination of Gitolite, cgit, python-git-multimail
 - My personal mailserver:
   - Used to subscribe Patchwork to guix-patches
   - Used to subscribe the Guix Data Service to guix-commits, as well as
 a mailbox on my mailserver which receives emails regarding the
 patches Git repository

Now not all these parts are essential, but I wanted to describe the
current state.

How this might work for a typical patch series is as follows:

- Patches sent by email to guix-patc...@gnu.org

- getmail for Patchwork receives the emails, passes them to Patchwork

- Patchwork attempts to make sense of the emails

- A Laminar job (patchwork-test-new) looks for new patch series in
  Patchwork, sees there's a new series, and starts the
  patchwork-test-series Laminar job to process them

- The patchwork-test-series Laminar job downloads the patch data from
  Patchwork, and (hopefully!) applies the patches to the Guix Git
  repository

- The resulting branch (series-NNN, where NNN is the Patchwork series
  number) is pushed to the git.cbaines.net/guix/patches/ Git repository

- The patchwork-test-series Laminar job also talks to Patchwork to fill
  in the "Checks" that provide links to the Git branch and Guix Data
  Service comparison.

- The python-git-multimail hook sends emails regarding the pushed
  commits

- getmail for the Guix Data Service picks up the emails about the
  commits for the patches on the series-NNN branch

- The Guix Data Service begins processing this revision


Hopefully this provides some insight. T

Re: native or not

[Vincent Legoll]

Hello Mathieu,

On Mon, Mar 30, 2020 at 8:57 AM Mathieu Othacehe  wrote:
> > Are those changes useful to do on their own ?
>
> Well yes it may reduce the closure size of the package (run `guix size
> sudo`) to get it.

I'm not seeing any size difference, but groff is not in the output:

on master, groff in inputs:

$ ./pre-inst-env guix size sudo
store item   totalself
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29
37.435.8  36.9%
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib
70.032.6  33.7%
/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31
90.016.5  17.0%
/gnu/store/vsvba1ilj2zj536pvsil6r0mf5rnjj45-sudo-1.8.31p1
96.9 3.5   3.6%
/gnu/store/dvs3acxwfnwgc7yma6h3y937ri2li47y-gmp-6.1.2
72.6 2.6   2.7%
/gnu/store/vkj5rdiavl87m21d9i0k69rfw79p13gj-linux-pam-1.3.1
73.2 2.1   2.2%
/gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7
1.6 1.6   1.7%
/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7
38.4 1.0   1.1%
/gnu/store/nffbgghxyvrj29lcgxs5fpmi3sx9zzql-acl-2.2.53
70.7 0.5   0.5%
/gnu/store/in1738m2zvhgpz78n2yqa972sdzc42ss-attr-2.4.48
70.3 0.3   0.3%
/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11
70.2 0.2   0.2%
/gnu/store/waw5ci4lazbf2a1x9v6gw1v274nk0gny-libcap-2.27
70.2 0.2   0.2%
total: 96.9 MiB

on a branch with groff in native-inputs:

$ ./pre-inst-env guix size sudo
store item   totalself
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29
37.435.8  36.9%
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib
70.032.6  33.7%
/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31
90.016.5  17.0%
/gnu/store/l320ig872ny66d1yi6v7n4zb93iz50dx-sudo-1.8.31p1
96.9 3.5   3.6%
/gnu/store/dvs3acxwfnwgc7yma6h3y937ri2li47y-gmp-6.1.2
72.6 2.6   2.7%
/gnu/store/vkj5rdiavl87m21d9i0k69rfw79p13gj-linux-pam-1.3.1
73.2 2.1   2.2%
/gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7
1.6 1.6   1.7%
/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7
38.4 1.0   1.1%
/gnu/store/nffbgghxyvrj29lcgxs5fpmi3sx9zzql-acl-2.2.53
70.7 0.5   0.5%
/gnu/store/in1738m2zvhgpz78n2yqa972sdzc42ss-attr-2.4.48
70.3 0.3   0.3%
/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11
70.2 0.2   0.2%
/gnu/store/waw5ci4lazbf2a1x9v6gw1v274nk0gny-libcap-2.27
70.2 0.2   0.2%
total: 96.9 MiB

> It can also fix cross-compilation. Because when cross-compiling, if
> groff needs to be run at build-time, it needs to be for the native
> architecture and not the target one.
>
> You can check it by running `guix build --target=aarch64-linux-gnu sudo`
> for instance.

That fails on master (libpaper) whereas with the patch it works,
so I guess the patch is useful on that front.

The patch for sudo will be in the following emails.

Is there anything else to check / test ?

-- 
Vincent Legoll

[CfP] 2020 Scheme and Functional Programming Workshop

[Jason Hemann]

Hello,

Thank you for your attention, and my apologies for any duplication you
receive. Please find below the Call for Papers for the *2020 Scheme and
Functional Programming Workshop*. We look forward to your submissions.


*Call for Papers*The 2020 Scheme and Functional Programming Workshop is
calling for submissions.

We invite high-quality papers about novel research results, lessons learned
from practical experience in industrial or educational setting, and even
new insights on old ideas. We welcome and encourage submissions that apply
to any language that can be considered Scheme: from strict subsets of RnRS
to other “Scheme” implementations, to Racket, to Lisp dialects including
Clojure, Emacs Lisp, Common Lisp, to functional languages with
continuations and/or macros (or extended to have them) such as Dylan,
ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the
relevance of its topic to the interests of Schemers will matter more than
the surface syntax of the examples used. Topics of interest include (but
are not limited to):

Interaction: program-development environments, debugging, testing,
refactoring
Implementation: interpreters, compilers, tools, garbage collectors,
benchmarks
Extension: macros, hygiene, domain-specific languages, reflection, and how
such extension affects interaction.
Expression: control, modularity, ad hoc and parametric polymorphism, types,
aspects, ownership models, concurrency, distribution, parallelism,
non-determinism, probabilism, and other programming paradigms
Integration: build tools, deployment, interoperation with other languages
and systems
Formal semantics: Theory, analyses and transformations, partial evaluation
Human Factors: Past, present and future history, evolution and sociology of
the language Scheme, its standard and its dialects
Education: approaches, experiences, curricula
Applications: industrial uses of Scheme
Scheme pearls: elegant, instructive uses of Scheme

*Important dates*
Submission deadline is 15 May 2020.
Authors will be notified by 12 June 2020.
Camera-ready versions are due 30 June 2020.
All deadlines are (23:59 UTC-12), “Anywhere on Earth”.
Submission Information
Paper submissions must use the format acmart and its sub-format acmlarge.
They must be in PDF, printable in black and white on US Letter size.
Microsoft Word and LaTeX templates for this format are available at:

http://www.sigplan.org/Resources/Author/

This format is in line with ACM conferences (such as ICFP with which we are
colocated). It is recommended to use the review option when submitting a
paper; this option enables line numbers for easy reference in reviews.

We want to encourage all kinds of submissions, including full papers,
experience reports and lightning talks. Papers and experience reports are
limited to 14 pages, but we encourage submitting smaller papers. Lightning
talks are limited to 192 words. Each accepted paper and report will be
presented by its authors in a 25 minute slot including Q&A. Each accepted
lightning talk will be presented by its authors in a 5 minute slot,
followed by 5 minutes of Q&A.

The size limits above exclude references and any optional appendices. There
are no size limits on appendices, but the papers should stand without the
need to read them, and reviewers are not required to read them.

Authors are encouraged to publish any code associated to their papers under
an open source license, so that reviewers may try the code and verify the
claims.

Proceedings will be printed as a Technical Report at the University of
Michigan and uploaded to arXiv.org

.

Publication of a paper at this workshop is not intended to replace
conference or journal publication, and does not preclude re-publication of
a more complete or finished version of the paper at some later conference
or in a journal.

Sincerely,


Jason Hemann, Northeastern University




*Organizing Committee*
Michael D. Adams (Program Co-Chair), University of Michigan
Baptiste Saleil (Program Co-Chair), IBM Canada
Jason Hemann (Publicity Chair), Northeastern University



*Program Committee*Michael D. Adams (Program Co-Chair), University of
Michigan
Baptiste Saleil (Program Co-Chair), IBM Canada
Maxime Chevalier-Boisvert, Université de Montréal
Ryan Culpepper, Czech Technical University
Kimball Germane, University of Utah
Yukiyoshi Kameyama, University of Tsukuba
Andy Keep, Cisco Systems, Inc
Julien Pagès, Université de Montréal
Alexey Radul



*Steering Committee*Will Byrd, University of Alabama at Birmingham
Will Clinger, The Larceny Project
Marc Feeley, Université de Montréal
Dan Friedman, Indiana University
Olin Shivers, 

Re: Brainstorming features for issues.guix.gnu.org

[John Soo]

Ricardo Wurmus  writes:

>> It is hard to find how patchsets differ - let alone where
>> revisions start and end.
>
> Do you have an idea how to improve this?  Should we use, for example,
> the message subject to detect revisions?  (E.g. [PATCH 3/3] will
> indicate that the end of the patch set has been reached.)
>
> How would we indicate different patch sets visually?  Should there be
> links somewhere to jump to patch sets?

Hmm. I don't know if I have a good answer yet. I think I like the
debbugs threaded view. Here are a couple ideas:

* Allow expansion/collapse of diffs
* Provide a thread view and a view of just one patchset (maybe computed
  via [PATCH 3/3] or by attachments as you mention)
* Provide an interdiff view between revisions
* Only show the most recent patchset like some large commercial products

I like the thread view idea since this is an email workflow, afterall.

It has been improving a lot and I am already using it a lot more now that
it has its own database.

John

Re: native or not

[Vincent Legoll]

Here is a set of patches, for starting discussion...

I only build-tested them natively on/for x86_64 (and
cross built for aarch64 for the sudo one)

On Mon, Mar 30, 2020 at 11:25 PM Vincent Legoll
 wrote:
>
> Hello Mathieu,
>
> On Mon, Mar 30, 2020 at 8:57 AM Mathieu Othacehe  wrote:
> > > Are those changes useful to do on their own ?
> >
> > Well yes it may reduce the closure size of the package (run `guix size
> > sudo`) to get it.
>
> I'm not seeing any size difference, but groff is not in the output:
>
> on master, groff in inputs:
>
> $ ./pre-inst-env guix size sudo
> store item   totalself
> /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29
> 37.435.8  36.9%
> /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib
> 70.032.6  33.7%
> /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31
> 90.016.5  17.0%
> /gnu/store/vsvba1ilj2zj536pvsil6r0mf5rnjj45-sudo-1.8.31p1
> 96.9 3.5   3.6%
> /gnu/store/dvs3acxwfnwgc7yma6h3y937ri2li47y-gmp-6.1.2
> 72.6 2.6   2.7%
> /gnu/store/vkj5rdiavl87m21d9i0k69rfw79p13gj-linux-pam-1.3.1
> 73.2 2.1   2.2%
> /gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7
> 1.6 1.6   1.7%
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7
> 38.4 1.0   1.1%
> /gnu/store/nffbgghxyvrj29lcgxs5fpmi3sx9zzql-acl-2.2.53
> 70.7 0.5   0.5%
> /gnu/store/in1738m2zvhgpz78n2yqa972sdzc42ss-attr-2.4.48
> 70.3 0.3   0.3%
> /gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11
> 70.2 0.2   0.2%
> /gnu/store/waw5ci4lazbf2a1x9v6gw1v274nk0gny-libcap-2.27
> 70.2 0.2   0.2%
> total: 96.9 MiB
>
> on a branch with groff in native-inputs:
>
> $ ./pre-inst-env guix size sudo
> store item   totalself
> /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29
> 37.435.8  36.9%
> /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib
> 70.032.6  33.7%
> /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31
> 90.016.5  17.0%
> /gnu/store/l320ig872ny66d1yi6v7n4zb93iz50dx-sudo-1.8.31p1
> 96.9 3.5   3.6%
> /gnu/store/dvs3acxwfnwgc7yma6h3y937ri2li47y-gmp-6.1.2
> 72.6 2.6   2.7%
> /gnu/store/vkj5rdiavl87m21d9i0k69rfw79p13gj-linux-pam-1.3.1
> 73.2 2.1   2.2%
> /gnu/store/cp72ncw4prnsga65n3pzll07hpsg524f-bash-static-5.0.7
> 1.6 1.6   1.7%
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7
> 38.4 1.0   1.1%
> /gnu/store/nffbgghxyvrj29lcgxs5fpmi3sx9zzql-acl-2.2.53
> 70.7 0.5   0.5%
> /gnu/store/in1738m2zvhgpz78n2yqa972sdzc42ss-attr-2.4.48
> 70.3 0.3   0.3%
> /gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11
> 70.2 0.2   0.2%
> /gnu/store/waw5ci4lazbf2a1x9v6gw1v274nk0gny-libcap-2.27
> 70.2 0.2   0.2%
> total: 96.9 MiB
>
> > It can also fix cross-compilation. Because when cross-compiling, if
> > groff needs to be run at build-time, it needs to be for the native
> > architecture and not the target one.
> >
> > You can check it by running `guix build --target=aarch64-linux-gnu sudo`
> > for instance.
>
> That fails on master (libpaper) whereas with the patch it works,
> so I guess the patch is useful on that front.
>
> The patch for sudo will be in the following emails.
>
> Is there anything else to check / test ?
>
> --
> Vincent Legoll



-- 
Vincent Legoll
From a782816fe096e786673c03dca3b2866e62933fff Mon Sep 17 00:00:00 2001
From: Vincent Legoll 
Date: Mon, 30 Mar 2020 22:21:08 +0200
Subject: [PATCH 1/4] gnu: privoxy: Make some inputs native.

* gnu/packages/tor.scm (privoxy)[native-inputs]: New field.
[inputs]: Move autoconf & automake to native-inputs.
---
 gnu/packages/tor.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm
index 61e52ba22c..841158871e 100644
--- a/gnu/packages/tor.scm
+++ b/gnu/packages/tor.scm
@@ -141,8 +141,9 @@ rejects UDP traffic from the application you're using.")
 (inputs
  `(("w3m" ,w3m)
("pcre" ,pcre)
-   ("zlib" ,zlib)
-   ("autoconf" ,autoconf)
+   ("zlib" ,zlib)))
+(native-inputs
+ `(("autoconf" ,autoconf)
("automake" ,automake)))
 (home-page "https://www.privoxy.org";)
 (synopsis "Web proxy with advanced filtering capabilities for enhancing privacy")
-- 
2.25.2

From 3887538d37256424d5654da5fce4c94c924a4e67 Mon Sep 17 00:00:00 2001
From: Vincent Legoll 
Date: Mon, 30 Mar 2020 22:42:28 +0200
Subject: [PATCH 4/4] gnu: procenv: Make some inputs native & make multiline.

* gnu/packages/linux.scm (procenv)[native-inputs]: New field.
[inputs]: Move groff to native-inputs, move each remaining item on its own line.
---
 gnu/packages/linux.scm | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index a45847cbe5..945c15d972 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -5867,9 +5867,11 @@ the MTP device as a file system.")

Re: [GSOC 2020] Booting via network

[Vincent Legoll]

Hello,

that's a great project, I hope to be able to lend a hand,
here and there...

-- 
Vincent Legoll

Re: [GSOC 2020] Booting via network

[Vagrant Cascadian]

On 2020-03-30, Brice Waegeneire wrote:
> I know it's quite late to submit a GSOC proposal but here it's.
> I would like to work on the project suggested by Danny to
> add PXE support to Guix. Which has been requested several
> times on IRC and in the ML. This would get us a step closer
> to provisioning bare bone machines directly from Guix.

I was just thinking Guix needed network boot support yesterday! Happy to
hear you're looking into it...

I've been the LTSP maintainer in Debian for almost 15 years, so have a
good amount of experience with network booting. LTSP was rewritten from
scratch last year and there might be elements of it useful to you:

  https://ltsp.org

None of it is scheme code, but there are possibly some useful ideas in
there you could make use of. One of the big changes is making extensive
use of iPXE, though that might need some further auditing to meet the
FSDG (Free Software Distribution Guidelines?) for inclusion into Guix.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [GSOC 2020] Final proposal

[Alberto EFG]

Ricardo Wurmus writes:

> Hi Alberto,
>
>> Hello, this is my final proposal for GSoC, there is still time to do
>> some changes in case anyone has feedback, otherwise this is it :)
>
> Thank you for this thorough proposal!
>
> For 8.5 it would be good to provide criteria that allow us to evaluate
> your progress.  Being able to look at the code is obviously a
> precondition, but what we really want to know is what features will have
> to have been completed (and to what degree) at the time of the
> evaluation.
>
> For some of the deliverables and goals it would be good to see a little
> more detail if possible.  You mention systemd.device and systemd.socket
> files, but I can’t imagine what your goals with regards to the Shepherd
> are — is it to implement a similar feature (what exactly would that
> be?), or support for reading these files…?

Thank you so much for all the feedback!! I add my proposal with the
suggested changes.

I tried to be more specific with the goals, and the milestones. I added
a section, so number 8.5 is now 8.6, however I tried to be more specific
in the timeline than in 8.5.

Ludovic told me to focus my main goal on improving Shepherd internals,
rather than the systemd unit files parsing as that would be the "icing on
the cake", I hope that it is reflected on my proposal.

There is still a really short amount of time for last minute changes,
but this will probably be it.


proposal-final.pdf
Description: Adobe PDF document

GSOC Draft Proposal

[Steven vanZyl]

Hello all,

I am a prospective Google Summer of Code student who would like to
work on improving the Guix importer system and writing some new ones
for the Go Modules and Arch Linux PKGBUILD formats.

I admit that I am a rather late with this, but the last month has been
a bit more hectic than we'd all anticipated and there is still some
time left before the deadline.

Linked below is my proposal as a Notion document, and the same
proposal is attached in the Markdown format.
https://www.notion.so/rushsteve1/GNU-Guix-Proposal-d13dd543c5224ca395a9cad849bbe0db

Any and all feedback is greatly appreciated! And thank you for your
patience for this late submission.

Thank you,
Steven vanZyl
# GNU Guix Proposal

Steven vanZyl 

Please submit feedback as a Notion comment (requires account) or email me at the address above. All questions and criticisms welcome!

## Name of Project: GNU Guix

# Summary

Improve the existing Guix package importers and write new importers for the `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)` and [Go Modules](https://github.com/golang/go/wiki/Modules) formats so that the software available in this sources is more readily available on Guix-based systems.

# Benefits

The importers are, in my opinion, one of the many selling features of the Guix package manager. The ability to easily import existing packages into the Guix ecosystem greatly reduces the friction of adoption and increases the number of packages available to the user.

A Go Modules importer would improve support for the [Go programming language](https://golang.org/) ecosystem with Guix, expanding the software catalog and offering the superior dependency management of Guix for the language.

The `PKGBUILD` importer has the key benefit of vastly increasing software selection and availability, as well as opening up the possibility of importing packages from the [Arch User Repository](https://aur.archlinux.org/). [Arch Linux](https://www.archlinux.org/) is well known for their bleeding-edge software repositories, so an importer would allow many users to try newer versions of software easily. 

# Deliverables

- Improve existing importers and attempt to reach a feature parity between them.
- A basic importer of the `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)` format commonly used by Arch Linux, including recursive importing.
- An importer of Go 1.11 modules including using the `go.sum` versions and hashes, as well as recursive importing.

# Initial Research

Both file formats and their ecosystems are stable and standardized, with thorough documentation available from their primary sources.

## [Go Modules](https://github.com/golang/go/wiki/Modules)

Prior to the introduction and later [stabilization of modules in Go 1.14](https://golang.org/doc/go1.14) it was difficult, of not impossible, to automatically import a Go module in a reproducible manner. However with the introduction of modules and the [Go Checksum Database](https://sum.golang.org/) it is now far more feasible.

## `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)`

`PKGBUILD` is simply put, a complex format. It is even Turing Complete in some scenarios. However the vast majority of `PKGBUILD` files are relatively simple, containing only a source and a basic set of build instructions, making them largely no different from Guix `package` declarations.

Therefore I believe that in the interest of simplicity, security, and best practices, it is better to only implement a large subset of the `PKGBUILD` format, with room left to expand into full support if desired.

# Plan

Following the [official GSOC timeline](https://summerofcode.withgoogle.com/dashboard/timeline/) I have come up with the following three checkpoints in line with the evaluations.

## First Checkpoint (June 19)

Dive headfirst into the Guix codebase and try and get up and running. This is also a good opportunity to find places where the [Contributing](https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing) section of the Guix Manual can be improved for new developers.

Specifically during this period I would like to explore the existing importers to fix bugs and attempt to get all of them to roughly the same feature-parity, as [according to the documentation](https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html#Invoking-guix-import) they do not all support the same features and options as each other.

## Second Checkpoint (July 17)

During this time period I would like to work on the Go module importer. If functional I would also like to contribute a number of packages to the Guix repositories and generally expand support for Golang-based sofware.

## Final Checkpoint (August 17)

Create an initial importer of a subset of the `PKGBUILD` file format that allows users to import software intended for Arch Linux. This will likely become an ongoing effort due to the complexity of the `PKGBUILD` format, however I hope to have an initial implem