bug#51145: Cuirass should tag the Javascript it uses as free

[Maxim Cournoyer]

Hello Guix!

While offering the page https://ci.guix.gnu.org/eval/30234/dashboard to
a user having problems with the current installation image (1.3.0, due
to TLS failures during substitution:

--8<---cut here---start->8---
guix substitute: error: TLS error in procedure
'write_to_session_record_port': Error in the push function
--8<---cut here---end--->8---

They pointed to me that the page wouldn't load in LibreJS, which is true
(I had forgotten the issue myself, having whitelisted the domain long
ago).

Thanks,

Maxim

bug#51141: guix home reconfigure does not apply changes to shepherd services

[Oleg Pykhalov]

After changing a home shepherd service I tried to reconfigure with 'guix
home reconfigure'.

Process started by a service did not restart.  Assuming home shepherd is
like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the
process restarted but without changes in a service definition.

To forcely apply the changes I invoked 'herd stop root' and then ran
'guix home reconfigure' again which spawned new shepherd with applied
changes.

Oleg.


signature.asc
Description: PGP signature

bug#50897: Octave package installation

[Zacchaeus Scheffer]

That certainly works as a hack.  I ended up installing from source locally
because I needed it to work now.  It is strange that my local build didn't
encounter this problem when all I did was grab the tarball, untar, cd in and
>./configure --prefix=~/.local && make && make install
which should be more or less equivalent to how guix builds it (build system
is gnu-build-system).  An octave-build-system is definitely a good idea,
but the ability to install octave packages the "normal" way should probably
be resolved first and preserved (just like you can still install emacs
packages through (M)ELPA or through guix).

-zacchae

bug#48327: guix system image uses cross-compiler even on native system

[Mathieu Othacehe]

Hello Vagrant,

This is fixed on master with d5073fd113c621fe0b55382f7dd336ee118e759f.

Thanks,

Mathieu

bug#45613: (no subject)

[Raphaël Mélotte]

To me it looks like this bug is now solved.

I remember having the same problem months ago, but today it seems to work fine 
(on a foreign distro).


Guix:
---
  guix 6eded1a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6eded1a04186e3118b293486b038c994e05efedf
---

Icecat:
---
icecat  78.14.0-guix0-preview1  out 
/gnu/store/xwzp1lj8b429yc9nbx3nwy1ia9r1sr2x-icecat-78.14.0-guix0-preview1

---

It worked both with https://u2f.bin.coffee/ and other services.

Note that I'm "cheating" a little bit though: I'm using an emulated device, not 
an actual USB device (but the same emulated device previously didn't work with a 
Guix-built icecat).

bug#47672: [PATCH] gnu: owncloud-client: Update to 2.9.0.5150.

[Liliana Marie Prikler]

Am Montag, den 11.10.2021, 14:24 +0200 schrieb Daniel Meißner:
> > Thanks for checking.  Your workaround LGTM aside from indentation
> > which I can fix.  If the updater is still patched away as intended,
> > I could apply it on top of this one.  Did you check that as well?
> 
> Cool, thanks, that would be great.  I have not found any updater
> widgets in the GUI and the client did not seem to attempt any auto-
> updates.  However, I have never used the owncloud-client outside Guix
> so I do not really know where the updater widget was in the first
> place. Sorry :/
Sounds good enough to me.  Pushed both.

Thanks

bug#50299: [PATCH v3 15/27] gnu: ecl: Don't pretend to enable tests when cross-compiling.

[zimoun]

Hi Maxime,

I was roaming on this series and the message:

Don't pretend to enable tests when cross-compiling.

or elsewhere

Don't run tests when cross-compiling.

appears to me misleading.  I would write:

Remove unconditional tests.

or something along these lines which is what these commits are doing, IIUC.

On Thu, 30 Sept 2021 at 00:50, Maxime Devos  wrote:

> * gnu/packages/lisp.scm
>   (ecl)[arguments]<#:tests?>: Move comment about failing tests to ...
>   (ecl)[arguments]<#:phases>{check}: ... this deleted phase.
>   (ecl)[arguments]: Remove #:tests? instead of unconditionally setting it to
>   #t.

Thanks for working on that.

Cheers,
simon

bug#50981: Typo in ‘Invoking ‘guix home’’ documentation

[Oleg Pykhalov]

Hi Maxime,

Maxime Devos  writes:

> ‘there are few auxuliary actions’
> should be
> ‘there are few auxilliary actions’
>
> in ‘11.4 Invoking ‘guix home’’.

Fixed.

Thanks,
Oleg.


signature.asc
Description: PGP signature

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Roel Janssen]

On Fri, 2021-10-08 at 15:00 -0400, Mark H Weaver wrote:
> Roel Janssen  writes:
> 
> > On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote:
> > > Ludovic Courtès  writes:
> > > 
> > > > Maxim Cournoyer  skribis:
> > > > 
> > > > > We should patch GnuTLS so that it also honors the SSL_*
> > > > > environment
> > > > > variables documented in the Guix manual.
> > > > 
> > > > Note that (1) the SSL_* variables are originally from OpenSSL, and
> > > > (2)
> > > > GnuTLS developers made the conscious decision to not honor any
> > > > environment variable, leaving it up to application developers to do
> > > > that.
> > > > 
> > > > That’s the reason we are in this situation.  See the thread at
> > > > <
> > > > https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html
> > > > > .
> > > 
> > > That thread is worth reading, but for those who are short on time, I
> > > want to call attention to a specific point I made:
> > > 
> > >   However, GnuTLS does not support an environment variable setting,
> > > so we
> > >   would have to patch the code (add_system_trust in lib/system.c).  I
> > >   strongly considered doing this, but I'm worried about the possible
> > >   security implications.  For example, consider a setuid program that
> > > uses
> > >   GnuTLS and assumes that the person who ran the program will not be
> > >   capable of changing the trust store that GnuTLS uses.  This
> > > assumption
> > >   would be correct for the upstream GnuTLS, but not for ours.
> > > 
> > > 
> > > 
> > 
> > Would it be an idea to propose the patches, or the idea, for supporting
> > the SSL_* variables to the GnuTLS developers?
> 
> Sure, please feel free to discuss it with them.

I submitted a feature request here:
https://gitlab.com/gnutls/gnutls/-/issues/1279

> > Or is there a more fundamental reason why GnuTLS does not support
> > changing certificate stores at run-time?
> 
> I don't know.  It's been many years since I looked at this.
> 

Well, thank you for having looked at it in the past. :)
Hopefully we will find out more by means of the feature request I submitted.

Kind regards,
Roel Janssen

bug#50568: Missing source code

[zimoun]

Hi Ludo,

On Thu, 7 Oct 2021 at 15:53, Ludovic Courtès  wrote:
>
> Ludovic Courtès  skribis:
>
> >   https://ci.guix.gnu.org/eval/27221?status=failed
>
> We’re left with the following missing bioconductor.org tarballs:
>
>   AnnotationFuncs_1.40.0.tar.gz

I pick this one.  Cuirass says Succeeded with the log:

https://ci.guix.gnu.org/build/1000819/log/raw

Well, I do not know what is this 141.80.167.131 IP address.  Something
related to Bayfront, right?


>   AneuFinderData_1.18.0.tar.gz
>   BiocCaseStudies_1.52.0.tar.gz
>   chromstaRData_1.16.0.tar.gz
>   genomationData_1.22.0.tar.gz

> Zimoun, Ricardo: do you know how to address the bioconductor.org issue?

>From the evaluation you mention above, all these had succeeded.  Could
you confirm it is fine?


BTW, for the interested reader, I would like to point this bug#39885
[1] about Bioconductor, URI, fallback and time-machine which appears
to me related.  In addition to the two options proposed, another one
not listed but discussed elsewhere is to switch Bioconductor packages
from url-fetch to git-fecth.

1: 


All the best,
simoon

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[zimoun]

Hi,

On Thu, 7 Oct 2021 at 18:07, Ludovic Courtès  wrote:

> I guess, in our mind, the problem was fixed long ago.  :-)

Yes, to me the 2 remaining packages was from
 but moved already to Gitlab.
Whatever, :-)


> > As I am asking in this thread [3], the Guix project has the ressource,
> > storage speaking, to archive these tarballs -- waiting a robust
> > long-term automatic system.  But we (the Guix projet) cannot because we
> > duplicate the effort on keeping twice all the build outputs.  Somehow,
> > between Berlin and Bordeaux, coherent policies for conservancy are
> > missing. IMHO.
>
> So I think we’re lucky that we can try different solutions at once.

Well, it is not what I am observing.  Anyway. :-)


> The best solution is the one that won’t rely solely on the Guix project:
> SWH + Disarchive.  We’re getting there!

Yes.  Although, it is hard to define "the Guix project". :-)
Well, the remaining question is where to set the Disarchive
database... but hardware could be floating around once it is ready.
;-)


> The second-best solution is to improve our tooling so we can actually
> keep source code in a more controlled way.  That’s what I had in mind
> with .  We have storage space for
> that on berlin, but it’s not infinite.

If Berlin has space, why so much derivations are missing when running
time-machine?

Well, aside the implementation that ci.guix.gnu.org fetches from repo
every X minutes, i.e., drops all the commits (and the associated
derivations) pushed in the meantime.  And that bordeaux.guix.gnu.org
fetches from guix-commits the commit batch, i.e., builds only one
commit of this batch.


> Another approach is to use ‘git-fetch’ more, at least for non-Autotools
> packages (that’s the case for Scotch, for instance.)

This is what I suggested when opening this thread [1] more than one
year ago.  Reading the discussion and keeping in mind the inertia, I
do not think it is a viable path.  For instance, you know all the
pitfalls and you updated Scotch without switching to git-fetch -- no
criticism :-)  just a realistic matter of facts to have good coverage.




> So we can do all these things, and we’ll have to push hard to get the
> Disarchive option past the finish line because it’s the most promising
> long-term.

Agree.  Even, I think it is the only long-term option. :-)


All the best,
simon

bug#51021: detect loops in module/package graph

[zimoun]

Hi Ludo,

On Thu, 7 Oct 2021 at 15:34, Ludovic Courtès  wrote:
> Mark H Weaver  skribis:
> > raingloom  writes:

> >> I'll be short and blunt, currently it sucks big time whenever you have
> >> a loop in your packages.
> >
> > Agreed.  I've been concerned about this problem since the early days of
> > Guix.  See .
> >
> > Back in August 2014, there was a strongly connected component (SCC)
> > containing 51 package modules:
>
> Thanks for the analysis and for the updated patch!
>
> Module cycles are something we allow and even rely on, so finding cycles
> in itself is not necessarily helpful.  What would help is finding cyclic
> top-level references, which are those that cause problems, but that’s
> another story.

What Mark had implemented [1] works for any directed graph.  What do
you mean by "top-level references"?

1: 


> Now, I’m not sure if raingloom was talking about these cycles, or rather
> about cycles in the package dependency graph?

Probably. ;-)

But the way to detect cycle could be applied to any graph that Guix
uses.  For instance, something totally irrelevant that I would never
think of: channels [2]. :-)

2: 

> Chris Baines proposed a patch a while back to report those, though I
> can’t find it anymore.  IIRC, the difficulty was in making sure cycle
> detection would not be too expensive, and in keeping a readable style.

>From my memories about Graph Theory, the algorithm Mark is proposing
is an efficient way to detect cycles (cycle is strong connected
component).  BTW, detect cycle is (almost) the same complexity as
topological sort; since cycles are obstacle for topological sort to
exist, somehow.  I remember too the Chris's proposal but I do not
remember what they implemented.

I do not understand what you mean by "keeping a readable style".

All the best,
simon