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: Outreachy project infrastructure

[Laura Lazzati]

Hi everyone!

> I like storing the information at a central place where it gets
> collected and condensed, on the mailing list it is quickly lost in
> history.
>
Yes, me too, that is why I was suggesting it, wherever that is possible :).

Concerning the graph, I'm also struggling with it ;-)
>
Yes me too :) These days I will be switching between reading the
documentation more carefully to see what information is more relevant for
creating the videos, playing with guix commands I have not tried yet, and
also playing with the suggested tools for creating the videos.

Regards!
Laura

Fw: FOSDEM 2019 stand applications

[Björn Höfling]

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


pgpW6wzuV0sm3.pgp
Description: OpenPGP digital signature

Re: Outreachy project infrastructure

[Björn Höfling]

On Wed, 21 Nov 2018 17:18:54 -0300
Laura Lazzati  wrote:

> Hi again!
> 
> I went through past emails and this new ones.
> 
> In a previous mail, Bjorn suggested using the wiki -
> https://libreplanet.org/wiki/Group:Guix - for my proposed timeline
> and the decisions about the videos. Is it that possible? WDYT?

Ludo, Ricardo, 

what do you think of this idea?

I like storing the information at a central place where it gets
collected and condensed, on the mailing list it is quickly lost in
history.

But is libreplanet wiki suitable for this? Or if not, is there any
alternative?

Ricardo, I like your idea as a first thing to do.

Concerning the graph, I'm also struggling with it ;-)

Björn


pgp9TpOSNXqlf.pgp
Description: OpenPGP digital signature

supporting EOL ruby in Guix

[Alex Vong]

Hello,

I find out that ruby 1.8, 2.1 and 2.2 are all EOL. Do we still intend to
support them (say because they are needed in web development)? If so, I
think we should provide security updates.

I have look into Debian LTS support[0]. For 1.8, the LTS support has
gone as Debian old old stable[1] is no longer supported since May. For
2.1, it will be supported til 2020 through old stable LTS
support[2]. For 2.2, the package was removed when 2.3 was out[3].

What should we do?

[0]: https://wiki.debian.org/LTS
[1]: https://tracker.debian.org/pkg/ruby1.8
[2]: https://tracker.debian.org/pkg/ruby2.1
[3]: https://tracker.debian.org/pkg/ruby2.2

Cheers,
Alex


signature.asc
Description: PGP signature

Re: Getting ‘core-updates’ merged

[Björn Höfling]

On Thu, 22 Nov 2018 10:41:59 +0100
l...@gnu.org (Ludovic Courtès) wrote:


> I’m running GuixSD from ‘core-updates’ and everything is working fine.
> :-)  (I’m using Xorg, NM, etc., but not GNOME.)
> 
> Please check if it works for you!  We need your help!

I did a guix reconfigure from core-updates and it worked too (X-less
VirtualBox image). Maven compiles on core-updates.

Björn


pgpUwp8vzqg6F.pgp
Description: OpenPGP digital signature

Re: push right for trivial commits

[Alex Vong]

Leo Famulari  writes:

> On Thu, Nov 22, 2018 at 04:07:33AM +0800, Alex Vong wrote:
>> I think ECC key works with commit signing precisely because commit
>> signing simply requires Savannah to store the key. However, for
>> functionalities provided by Savannah (e.g. sending email to your address
>> encrypted with your ECC public key), it wouldn't work (as mentioned in
>> ).
>
> To clarify, Savannah doesn't require you to store any key at all in
> order to sign Git commits. I think that Savannah accounts don't
> integrate with Git at all; they simply offer hosted Git repositories,
> and commit signing is a feature of Git.
>
> We require Guix contributors to upload their keys to their Savannah
> account so that there is an authoritative source of signing keys.

I see, so it's a guix policy rather than a technical
requirement. Indeed, we can download the key from



signature.asc
Description: PGP signature

Re: util-linux and perl rename

[Danny Milosavljevic]

Hi,

On Tue, 20 Nov 2018 22:10:24 +0100
Thorsten Wilms  wrote:

> I already had a "rename" binary via util-linux. Then I installed the 
> package "rename", resulting in another "rename" binary, as I prefer the 
> Perl version. This was a success in that I got what I wanted.
> 
> However, should this name clash be considered a bug?
> Is there a policy for such circumstances?
> What happens that the newly installed "rename" gets precedence?

That depends.  If you installed "util-linux" into your profile and also
"rename" into your profile, you should have gotten a collision warning.

(If we ever get these cleaned up then we should make the remaining ones
collision errors)

I've just tried it with guix master, I get no collision warning.  I think
that's a real bug.

(Didn't those work in the past? *scratches head*)


pgpIm560OR880.pgp
Description: OpenPGP digital signature

Re: push right for trivial commits

[Leo Famulari]

On Thu, Nov 22, 2018 at 04:07:33AM +0800, Alex Vong wrote:
> I think ECC key works with commit signing precisely because commit
> signing simply requires Savannah to store the key. However, for
> functionalities provided by Savannah (e.g. sending email to your address
> encrypted with your ECC public key), it wouldn't work (as mentioned in
> ).

To clarify, Savannah doesn't require you to store any key at all in
order to sign Git commits. I think that Savannah accounts don't
integrate with Git at all; they simply offer hosted Git repositories,
and commit signing is a feature of Git.

We require Guix contributors to upload their keys to their Savannah
account so that there is an authoritative source of signing keys.


signature.asc
Description: PGP signature

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

[Mathieu Othacehe]

Hey Ludo,

> If you add it to /etc/environment (through
> ‘session-environment-service-type’) it should be fine no?

LANG is already part of /etc/environment variables which are loaded by
the login program which is PAM aware. The installer isn't PAM aware and
it replaces the login program thus LANG is never loaded.

>   1. ./configure and (guix self) are adjusted to not build the
>  installer, at least by default.
>
>   2. The “old” installation method remains prominently available, either
>  by making it clear people can use ctrl-alt-f2 & co. to switch to a
>  terminal, and maybe adding a message on the welcome page stating
>  that the installer is “beta” or something.
>
>   3. The manual is updated to at least mention the new installer, maybe
>  not in detail.
>
> How does that sound?

I agree it would be great :), I'm currently focusing on parted support
but, I'll shift to the 3 points you described above so that it can be
merged on time.

> It seems to me that it’s OK to push it quickly because it looks pretty
> good already and if it happens to be buggy, people can always use the
> old method.

Sure, it is a big addition to the codebase, so its important people can
start debugging it as soon as possible.

Mathieu

Re: Outreachy project infrastructure

[Thorsten Wilms]

On 22/11/2018 14.12, Ricardo Wurmus wrote:

Still, the concept of using several layers in one file might be
worthwhile. An export script could toggle layer visibility before
calling inkscape with --export-ps (or -png or -pdf).



This can easily get crowded, in my experience, as pretty slides are
sometimes much more easily edited and laid out with the help of multiple
layers.


Layers can be nested.



I think it’s easier to handle separate files in the Makefile, but your
snippet could come in handy in case we end up using just one layered SVG
file in the end.


Yes, from that perspective it's certainly easier to have separate files.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Outreachy project infrastructure

[Ricardo Wurmus]

Hi Thorsten,

> On 21/11/2018 23.28, Ricardo Wurmus wrote:
>>> Thank you very much for the workflow as well as for the suggested tools. I
>>> did not know that slides were created with inkscape :)
>
>> I’ve been using Inkscape for all of my presentations (after exporting to
>> PDF).  It’s more flexible than software made specifically for
>> presentations, but the flexibility comes at the cost of convenience
>> (e.g. in Inkscape you have one file per slide, and to create a slide
>> deck you need to combine all these files to a single PDF with another
>> tool like Ghostscript).  In this project I think the flexibility
>> outweighs these minor drawbacks.
>
> Years ago, I created dozens of presentations with Impress (then
> OpenOffice, now it would be LibreOffice). I shudder at the though of
> doing more involved presentations with Inkscape, even though it's my
> primary bread and butter tool :)
>
> Impress may quite likely be the most mature and full-featured Free
> Software WYSIWYG presentation tool. That said, of course it may seem a
> bit clunky and the file format is not suited for versioning and
> manipulation from external tools.
[…]
> Main issues I see in using Inkscape for presentations:
> 1. Lack of master pages (page templates)
> 2. Lack of text-styles
> 3. Much harder to see and edit the sequence of pages

For live presentations I would agree with you, but for our videos
presentation features (like slide transitions, templates, bullet lists,
etc) are much less important than the flexibility and expressivity
provided by an SVG drawing tool like Inkscape.

I’d be a little disappointed if the video looked like it came straight
out of Powerpoint / Impress ;)

> Still, the concept of using several layers in one file might be
> worthwhile. An export script could toggle layer visibility before
> calling inkscape with --export-ps (or -png or -pdf).

This can easily get crowded, in my experience, as pretty slides are
sometimes much more easily edited and laid out with the help of multiple
layers.

I think it’s easier to handle separate files in the Makefile, but your
snippet could come in handy in case we end up using just one layered SVG
file in the end.

Thank you!

--
Ricardo

Re: Outreachy project infrastructure

[Thorsten Wilms]

On 21/11/2018 23.28, Ricardo Wurmus wrote:

Thank you very much for the workflow as well as for the suggested tools. I
did not know that slides were created with inkscape :)



I’ve been using Inkscape for all of my presentations (after exporting to
PDF).  It’s more flexible than software made specifically for
presentations, but the flexibility comes at the cost of convenience
(e.g. in Inkscape you have one file per slide, and to create a slide
deck you need to combine all these files to a single PDF with another
tool like Ghostscript).  In this project I think the flexibility
outweighs these minor drawbacks.


Years ago, I created dozens of presentations with Impress (then 
OpenOffice, now it would be LibreOffice). I shudder at the though of 
doing more involved presentations with Inkscape, even though it's my 
primary bread and butter tool :)


Impress may quite likely be the most mature and full-featured Free 
Software WYSIWYG presentation tool. That said, of course it may seem a 
bit clunky and the file format is not suited for versioning and 
manipulation from external tools.


Even though Inkscape saves unpacked SVG, it's not version control 
friendly, either. AFAIK, Inkscape tends to reorganize more of the SVG 
than necessary, when saving after a change.


Main issues I see in using Inkscape for presentations:
1. Lack of master pages (page templates)
2. Lack of text-styles
3. Much harder to see and edit the sequence of pages

On 1: There are at least 2 approaches to achieve a similar feature via 
scripting.


On 2: I guess this can be done with CSS.

Inkscape presentation extension "JessyInk" seems to offer helpful 
features, but I worry that there's no straight way to get the kind of 
export out of it, that you need.

http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-JessyInk.html

Still, the concept of using several layers in one file might be 
worthwhile. An export script could toggle layer visibility before 
calling inkscape with --export-ps (or -png or -pdf). I recently did 
something like that, where the central bash script line is:


xmlstarlet ed -P -S -L -u "//_:g[@inkscape:label='templates']/@style" -v 
display:none $file


That is: Edit the file in-place and set the display attribute of a group 
that has the label 'templates' to none. Thus the layer won't appear in 
export.


Instead of bash and xmlstarlet, a Racket or Guile script may end up 
longer, but more readable :)


Looking for a Guile presentation tool, I found out that Andy Wingo went 
down that route and further:

https://wingolog.org/archives/2007/07/11/fold-xml-presentations

For maximal version-control-friendliness and guaranteed consistency, one 
would have to opt for entirely script-driven slide generation. Aside of 
something Latex-based, there's:

https://wingolog.org/projects/guile-present/doc/
https://docs.racket-lang.org/slideshow/


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

import libjs-*.deb from Debian? (was Re: NPM importer)

[Giovanni Biscuolo]

Hi Guix!

sorry if I'm going to reinvent some wheels but I've not found previous
discussions nor documentation about what I'm writing

what about reusing work already done from the Debian JavaScript
Maintainers team [1]?

they set up some interesting policies we could adapt to Guix needs and
pusblish somewhere (where?)

I mean pages like:

- https://wiki.debian.org/Javascript/Policy
- https://wiki.debian.org/Javascript/Nodejs

they have an npm2deb importer
https://wiki.debian.org/Javascript/Nodejs/Npm2Deb
... we could import what they import :-)

I see in Apr 2016 a brief discussion on a .deb importer was done

  https://lists.gnu.org/archive/html/guix-devel/2016-04/msg01053.html

what is the updated situation today?

Brett Gilio  writes:

[...]

> 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.

could a .deb importer help us to manage this *very big* workload,
sharing this burden with Debian JavaScript maintainers?

I found this project as a starting point

  https://gitlab.digitalcourage.de/htgoebel/guix-import-debian

[...]

> 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.

should we ignore/deprecate npm packages with licensing issues and work
with the ethically conscious like Debian JavaScript Maintainers?

having a fully free software _and_ reproducible [3] nodejs/javascript
dev environment would benefit a **huge** amount of web
developers... they will be so happy to be guixified! :-)

[...]

ciao
Giovanni



[1] https://wiki.debian.org/Javascript

[2] https://packages.debian.org/stretch/libjs-jquery

[3] and bootstrappable?

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: (cuirass) Consistent naming and presentation on the front page.

[Clément Lassieur]

Hi swedebugia,

swedebugia  writes:

> Hi
>
> I propose we stick to one naming scheme and keep it in both urls and the
> web-ui.

The reason why they differ is historical: the API comes from hydra
(which uses words such as 'jobset'), and the web UI uses Cuirass' own
vocabulary (evaluations, specifications, builds).

> I propose to completely drop the words "evaluation(s)" and "build(s)" as this
> is just confusing and implement the following changes:

We would need to change all of Cuirass' code too, which is, in my
opinion, too much work.  Plus, Cuirass and Hydra behave differently, so
it makes sense to use another vocabulary for Cuirass.  Changing the API
would be annoying because it's used by several people.  So overall, I
like the status quo.

> Look at http://berlin.guixsd.org/ and see how it looks now.
>
> Specifications:
> --
> Name  Inputs
> wip-rust  wip-rust (on wip-rust)
>
> Jobsets (for specification: wip-rust)
> 
> Jobset ID Input changes   Success  Status
> 1321  wip-rust → 4df3e06  4340 active/inactive
> ...
>
> Jobs in jobset #1231:
> --
>   ID  Specification   Completion time 
> (icon)586752  wip-rust12 Nov 21:59 +0100
>
> Jobname   Packagename
> rust-1.24.1.x86_64-linux  rust-1.24.1 
>
> SystemLog
> x86_64-linux  raw
> ...
>
>
> I changed:
> Jobs renamed /job/jobname/ and /name/packagename/ and removed "builds of
> evaluation"

Note that there is no notion of "package" in Cuirass.  Most builds refer
to packages, but some of them, for example, refer to tests.

> Jobset renamed /#/jobset id/ and removed "evaluations of"
>
> Jobs have status succede/failed/canceled/pending and logs.

> Jobsets can be active/inactive

Yes, and for that we need an admin interface.  But this is off-topic :)
That could be a seperate bug/wishlist though.

> Specifications does not have a status but an input.

I don't understand this.  :-)

> Also I would like to propagate the status and links from the jobset-page to
> the header of the jobs-page (now with the uri /eval/) below the title like
> this:
>
> "Browse by jobstatus: # succeded # failed # pending" (with textlinks)

Hmm, I don't think this should be a priority because we can already
browse by jobstatus from the Specifications page.

> Presentation:
> -
> If somebody really want to mention evaluation and build I suggest to describe
> the whole build-server rationale on the frontpage in a paragraph.
>
> There we could also describe the machines, hardware and status of the whole
> shabang and a paragraph with thanks to MDC for donating/hosting the hardware
> to make this possible.
>
> What do you think?

This is too specific.  What we need is a way to customize the front
page.  That could be another bug/wishlist too.

Cheers,
Clément

Re: Getting ‘core-updates’ merged

[Ludovic Courtès]

Hi there!

l...@gnu.org (Ludovic Courtès) skribis:

> What remains to be done is mostly (1) ensuring that there’s no
> significant regression in terms of build failures compared to ‘master’,
> and (2) making sure GuixSD boots and works fine.
>
> For #1, a simple test is to try and upgrade your profile and see if
> everything builds and works well.  In addition, you can look at these
> dashboards to identify build failures that need to be addressed:
>
>   https://hydra.gnu.org/jobset/gnu/core-updates
>   https://berlin.guixsd.org/jobset/core-updates-core-updates

There are still failures out there!

  https://hydra.gnu.org/eval/110331?full=1#tabs-still-fail

The above list is slightly outdated so I’m restarting an evaluation on
hydra.gnu.org.

A prominent issue is LibreOffice:

  https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00332.html

There are also many more issues on armhf and i686 than on x86_64.

> For #2, running “make check-system”, or at least the inexpensive subset
> of system tests (the expensive tests are the installation tests) should
> give a good overview—Mark already reported an issue at
> .  The next step of course is to
> try it on the bare metal for your own system config.

I’m running GuixSD from ‘core-updates’ and everything is working fine.
:-)  (I’m using Xorg, NM, etc., but not GNOME.)

Please check if it works for you!  We need your help!

Ludo’.

Re: NPM importer

[Giovanni Biscuolo]

Hi Guix,

sorry: reading at today messages from swdebugia and your comments below
I realize that mine was just noise from a packaging-ignorant :-S

Julien Lepiller  writes:

[...]

>>  https://spin.atomicobject.com/2016/12/16/reproducible-builds-npm-yarn/
>> 
>> is yarn a viable solution to the NPM packaging problems?

[...]

> How different is it to build an npm package and a yarn package?

no difference

> Could you elaborate a bit on your idea?

I'm not able: I was mislead by the title of this article I cited

  https://spin.atomicobject.com/2016/12/16/reproducible-builds-npm-yarn/

"reproducuble builds" and "npm/yarn" seems like an oxymoron to me, now :-)

> We can already build packages with our wip node-build-system, as long as 
> we have build- and run-time dependencies available. The real hard parts 
> are: sometimes build-tools depend on what they build, there is just too 
> many dependencies and some packages don't declare a license properly.

ACK, now I finally understand the problems

[...]

thany you for your patience

ciao
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> I was going to suggest the ‘login-program’ way.  :-)  What’s the story
>> with PAM env variables?
>
> The LANG env variable is important so that the installer can install the
> right locale at start. However, it is not available yet when using
> login-program. Any idea how to overcome this?

If you add it to /etc/environment (through
‘session-environment-service-type’) it should be fine no?

I’d like to make a release within 10 days, meaning ‘core-updates’ is
merged by then.

Do we go ahead and use the installer in the image as well?  That would
get real-world testing.  The conditions for this IMO would be that:

  1. ./configure and (guix self) are adjusted to not build the
 installer, at least by default.

  2. The “old” installation method remains prominently available, either
 by making it clear people can use ctrl-alt-f2 & co. to switch to a
 terminal, and maybe adding a message on the welcome page stating
 that the installer is “beta” or something.

  3. The manual is updated to at least mention the new installer, maybe
 not in detail.

How does that sound?

It seems to me that it’s OK to push it quickly because it looks pretty
good already and if it happens to be buggy, people can always use the
old method.

WDYT?

Thanks,
Ludo’.

Re: push right for trivial commits

[Ludovic Courtès]

Alex Vong  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>>
>> Hmm?  I think it neither works nor doesn’t work with Savannah because
>> AIUI Savannah simply stores the keys.  Or am I missing something?
>>
> I think ECC key works with commit signing precisely because commit
> signing simply requires Savannah to store the key. However, for
> functionalities provided by Savannah (e.g. sending email to your address
> encrypted with your ECC public key), it wouldn't work (as mentioned in
> ).

OK, I didn’t know about this feature.  Thanks for explaining!

Ludo’.

Re: 01/01: gnu: ccl: Include x86-headers and remove missing "contrib" folder.

[Ludovic Courtès]

Hello,

Pierre Neidhardt  skribis:

> Oops!  Sorry for that.

No problem.  :-)

> What would be the most lispy way to return nothing from the match?
> I'm thinking of splicing the resulting lists, but that sounds a bit overkill:
>
> (let ((dirs '("lib" "library" "examples" "tools" "objc-bridge"
>   ,@(match (%current-system)
>  ("x86_64-linux"
>   '("x86-headers64"))
>  ("i686-linux"
>   '("x86-headers"))
>  (_ '())
>
> Thoughts?

LGTM.  Make sure ‘guix build’ and ‘guix lint’ are happy too.  :-)

Thanks,
Ludo’.

Re: GC Warning: Out of Memory

[Ludovic Courtès]

Hello Rene,

Rene  skribis:

> In Debian/Hurd using commit `2d546858b139e5fcf2cbdf9958a17fd98803ac4c` from 
> core-updates branch:
>
> When I try to build hello package, Guix shows:
>
> --     ;;; In procedure load-thunk-from-memory: ELF file does not have native 
> word size
>  ;;; WARNING: loading compiled file gnu/packages/wicd.go failed:

Looks like the .go files being used are incorrect.  This in turn leads
Guile to autocompile all of Guix, which eventually fails.

How did you obtain those .go files?

Thanks,
Ludo’.

Re: Patchwork + automated checking and testing of patches

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> This is still very much a prototype, but I think it's nearing the point
> where it actually might be doing something useful.
>
> Currently, taking the service running the FreeDesktop fork of Patchwork,
> you can go to the series page [10], and it will show you a list of patch
> series, along with a indication of the "tests" status, which currently
> is just whether the patch applied successfully to the master branch.
>
> 10: https://patchwork-fdo.cbaines.net/project/guix-patches/series/

The test part is nice!

> The Patchwork service running the upstream code is very similar, you
> just have to click in to the individual patches to get the information
> on the "Checks", for an example, have a look at [11]
>
> 11: https://patchwork.cbaines.net/patch/233/

Neat.

> Next, I'm planning to work on extending the test series job to actually
> start running some code, maybe perhaps just applying the patch, and then
> running make at first. Then maybe trying to use the (guix inferior)
> module code to intelligently determine changed packages that need
> building. If you have something that does this, or want to write
> something to do this, that would be awesome.

For this I would suggest building the code using (guix self).  You can
do that either in Scheme using ‘inferior-for-channels’ or with something
like:

  guix pull --url=file://… -p ./test-guix

As for determining the list of new and upgraded packages, see
‘display-new/upgraded-packages’ in (guix scripts pull).  We can separate
the computational part from the UI part in there.

Perhaps we could integrate the tests with Mumi as well.

Thanks for the great work!

Ludo’.

Re: swig failure on aarch64 on core-updates

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Sun, Nov 18, 2018 at 09:35:51AM +0200, Efraim Flashner wrote:
>> From the build log with --cores=1
>> 
>> checking guile testcase template_whitespace
>> checking guile testcase threads
>> checking guile testcase threads_exception
>> checking guile testcase throw_exception (with run test)
>> free(): invalid pointer
>> /gnu/store/3dzvi613nf3fz42rabksw6svslvanfz7-bash-minimal-4.4.23/bin/sh: line 
>> 1: 21784 Aborted (core dumped) env GUILE_AUTO_COMPILE=0 
>> LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH 
>> /gnu/store/7pb9ywfzvr8jwgykpj52vfd8d6kimc3w-guile-2.0.14/bin/guile -l .
>> /throw_exception_runme.scm
>> make[1]: *** [Makefile:36: throw_exception.cpptest] Error 134
>> checking guile testcase typedef_array_member
>> checking guile testcase typedef_class
>> checking guile testcase typedef_funcptr
>> checking guile testcase typedef_inherit (with run test)
>> checking guile testcase typedef_mptr
>> 
>> I don't see anything upstream about this, so I figured I'd post it here
>> first. This happens with and without the fix-swig-for-i686 patch.
>> 
>
> I don't know what's different about today, but swig built with no
> problems while I was test building my profile on core-updates.

The thing actually aborted (SIGABRT):

--8<---cut here---start->8---
scheme@(guile-user)> (status:term-sig 134)
$3 = 6
scheme@(guile-user)> SIGABRT
$4 = 6
--8<---cut here---end--->8---

So I guess this could have been caused by an OOM condition.

Ludo’.

Re: NPM importer

[Julien Lepiller]

Thanks! It made me wonder if we could better approximate the set of needed 
dependencies by looking at package tags. I'll try to improve my script in that 
spirit, and share it again here.

I think once we have a clearer view of what we want, we should focus on finding 
the best way forward: what packages do we need first, etc. I think build tools 
are obviously more important than test tools, which should have a greater 
priority than the rest of packages.

Le 22 novembre 2018 02:02:52 GMT+01:00, swedebugia  a 
écrit :
>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:
>
>LibDep DevDep  RecdevDep   Dependants  license
>underscore 0   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

(cuirass) Consistent naming and presentation on the front page.

[swedebugia]

Hi

I propose we stick to one naming scheme and keep it in both urls and the 
web-ui.


I propose to completely drop the words "evaluation(s)" and "build(s)" as 
this is just confusing and implement the following changes:


Look at http://berlin.guixsd.org/ and see how it looks now.

Specifications:
--
NameInputs
wip-rustwip-rust (on wip-rust)

Jobsets (for specification: wip-rust)

Jobset ID   Input changes   Success  Status
1321wip-rust → 4df3e06  4340 active/inactive
...

Jobs in jobset #1231:
--
ID  Specification   Completion time 
(icon)  586752  wip-rust12 Nov 21:59 +0100

Jobname Packagename
rust-1.24.1.x86_64-linuxrust-1.24.1 

System  Log
x86_64-linuxraw
...


I changed:
Jobs renamed /job/jobname/ and /name/packagename/ and removed "builds of 
evaluation"

Jobset renamed /#/jobset id/ and removed "evaluations of"

Jobs have status succede/failed/canceled/pending and logs.
Jobsets can be active/inactive
Specifications does not have a status but an input.

Also I would like to propagate the status and links from the jobset-page 
to the header of the jobs-page (now with the uri /eval/) below the 
title like this:


"Browse by jobstatus: # succeded # failed # pending" (with textlinks)


Thoughts?


Presentation:
-
If somebody really want to mention evaluation and build I suggest to 
describe the whole build-server rationale on the frontpage in a paragraph.


There we could also describe the machines, hardware and status of the 
whole shabang and a paragraph with thanks to MDC for donating/hosting 
the hardware to make this possible.


What do you think?

--
Cheers Swedebugia