emacs-jedi package bug missing crucial python server file

[jgart]

Hi Guixers,

Just wanted to report a bug with emacs-jedi:

This is all that is currently copied into gnu/store:

jedi-autoloads.el  jedi-autoloads.elc  jedi-core.el  jedi-core.elc  jedi-pkg.el 
 jedi.el  jedi.elc  test-jedi.el  test-jedi.elc  tryout-jedi.el  tryout-jedi.elc

But it's missing jediepcserver.py:

https://github.com/tkf/emacs-jedi/blob/master/Makefile#L132

You would then need to put this in your emacs config:

(setq jedi:server-command '("PATH/TO/jediepcserver.py"))

I'll try to work on it when I get a chance but feel free to fix it if you have 
the time.

all best,

jgart

Re: Set FORCE_SOURCE_DATE=1 by default

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian  writes:

> So, guix sets SOURCE_DATE_EPOCH=1 by default in
> guix/build/gnu-build-system.scm, which is great!
>
> This allows guix packages in many cases to build packages reproducibly,
> with a curious side-effect that takes us all back to the early 70s in
> some corner-cases (or even late 60s, dependent on timezone).
>
> That said, some projects (such as texlive) might be worried about
> messing with time too much (I get it, lots of cautionary sci-fi
> stories!), and so you *also* need FORCE_SOURCE_DATE=1 to be set in order
> to respect SOURCE_DATE_EPOCH.

That seems ridiculous.  Has anyone tried getting in touch with them to
get their arguments about why inventing another variable that means the
same thing was necessary?

I'd much prefer challenging that stance than "endorsing" it in Guix :-).
I think it'd be OK to reluctantly add it in as a stop-gap fix in Guix,
but *only* after opening an issue to discuss it upstream and linking to
that issue in Guix.

Thanks,

Maxim

Re: Teams: first draft list

[zimoun]

On Tuesday, 21 June 2022,  wrote:

> On +2022-06-21 17:21:11 +0200, zimoun wrote:
> >
> > Here below a collection of answers.  The teams are more or less.  Maybe,
> > we could join some for having another structure.  WDYT?
>
> Where is the RISC/MES team? :)
>

Embeded / Bootstrap ;-)

Re: Set FORCE_SOURCE_DATE=1 by default

[Vagrant Cascadian]

On 2022-06-15, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian 
>> Date: Fri, 10 Jun 2022 16:12:59 -0700
>> Subject: [PATCH] guix: gnu-build-system: Set FORCE_SOURCE_DATE in
>>  set-SOURCE-DATE-EPOCH phase.
>>
>> * guix/build/gnu-build-system.scm (set-SOURCE-DATE-EPOCH): Set
>>   FORCE_SOURCE_DATE=1. Update URL.
>
> [...]
>
>>  (define* (set-SOURCE-DATE-EPOCH #:rest _)
>> -  "Set the 'SOURCE_DATE_EPOCH' environment variable.  This is used by tools
>> -that incorporate timestamps as a way to tell them to use a fixed timestamp.
>> -See https://reproducible-builds.org/specs/source-date-epoch/.;
>> -  (setenv "SOURCE_DATE_EPOCH" "1"))
>> +  "Set the 'SOURCE_DATE_EPOCH' and 'FORCE_SOURCE_DATE' environment 
>> variables.
>> +This is used by tools that incorporate timestamps as a way to tell them to 
>> use
>> +a fixed timestamp.  See 
>> https://reproducible-builds.org/docs/source-date-epoch/.;
>> +  (setenv "SOURCE_DATE_EPOCH" "1")
>> +  (setenv "FORCE_SOURCE_DATE" "1"))
>
> I’d mention above that FORCE_SOURCE_DATE is honored exclusively by
> TeX Live.

I am having trouble explaining it, partly because I don't really believe
in it and kind of want to just leave that up to the URL... that said:

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index d84411c090..d69f8c42fd 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -56,10 +56,13 @@ (define time-monotonic time-tai))
   (else #t))
 
 (define* (set-SOURCE-DATE-EPOCH #:rest _)
-  "Set the 'SOURCE_DATE_EPOCH' environment variable.  This is used by tools
-that incorporate timestamps as a way to tell them to use a fixed timestamp.
-See https://reproducible-builds.org/specs/source-date-epoch/.;
-  (setenv "SOURCE_DATE_EPOCH" "1"))
+  "Set the 'SOURCE_DATE_EPOCH' and 'FORCE_SOURCE_DATE' environment variables.
+This is used by tools that incorporate timestamps as a way to tell them to use
+a fixed timestamp.  Setting 'FORCE_SOURCE_DATE' is needed in order for TeX
+Live to respect 'SOURCE_DATE_EPOCH'. See
+https://reproducible-builds.org/docs/source-date-epoch/.;
+  (setenv "SOURCE_DATE_EPOCH" "1")
+  (setenv "FORCE_SOURCE_DATE" "1"))
 
 (define (first-subdirectory directory)
   "Return the file name of the first sub-directory of DIRECTORY or false, when


Not really happy with it ... both variables are basically needed to make
SOURCE_DATE_EPOCH effective, and it's not clear to me what it really
adds to the statement to call out TeX Live explicitly... especially
given that other tools *might* actually do the same... even though I
sure hope we can contain the problem to TeX Live.

Would renaming it to set-SOURCE-DATE-EPOCH-and-FORCE-SOURCE-DATE add
anything? or come up with a generic name? or having both
set-SOURCE-DATE-EPOCH and set-FORCE-SOURCE-DATE as separate functions?
Or a more generic description?


> It’s a bit of a bummer that we have to do that here, but as you point
> out, TeX Live can be used pretty much in any package and we’d rather not
> track every possible issue by hand.

Agreed.


> I think it can go to ‘core-updates’.

I hope so too!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: D Packages in Guix

[Tobias Geerinckx-Rice]

Tobias Platen 写道：

I had a look at Inochi2D[1], which is written in D.
D has its own packagemanager called dub, so a dub-importer will 
be

needed to build Inochi2D with guix


Such an importer would certainly be welcome.  I recently 
encountered my first D package in the wild.


However: there's nothing stopping you from packaging D(ub) 
packages for Guix today.  You don't need an importer for that.


For inochi2d, it seems like you'll need[0]:

 imagefmt
 inmath
 silly
 bindbc-opengl
 bindbc-loader
 fghj
 mir-algorithm
 mir-core

Not nothing, but nowhere near ‘we absolutely need an importer to 
use this language’ levels either.


Aside: there are some unmerged improvements to the 
dub-build-system at  that might 
be of interest to you.


Kind regards,

T G-R

[0]: 
https://raw.githubusercontent.com/Inochi2D/inochi2d/main/dub.sdl


signature.asc
Description: PGP signature

Re: D Packages in Guix

[Tobias Platen]

On Tue, 2022-06-21 at 18:55 +0200, Tobias Platen wrote:
> I had a look at Inochi2D[1], which is written in D.
> D has its own packagemanager called dub, so a dub-importer will be
> needed to build Inochi2D with guix
> 
> [1] https://github.com/Inochi2D/inochi2d
> 
> Tobias
> 
> 
In the meanwhile I saw
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/dlang.scm#n423

but it does not support ppc64le and aarch64 yet, so I'll try that out
on my machine. I'll submit patches if something does not work. I'll try
aarch64 first.

Re: Teams: first draft list

[bokr]

On +2022-06-21 17:21:11 +0200, zimoun wrote:
> 
> Here below a collection of answers.  The teams are more or less.  Maybe,
> we could join some for having another structure.  WDYT?

Where is the RISC/MES team? :)

D Packages in Guix

[Tobias Platen]

I had a look at Inochi2D[1], which is written in D.
D has its own packagemanager called dub, so a dub-importer will be
needed to build Inochi2D with guix

[1] https://github.com/Inochi2D/inochi2d

Tobias

Re: On commit access, patch review, and remaining healthy

[zimoun]

Hi Hartmut,

On Mon, 20 Jun 2022 at 14:53, Hartmut Goebel  
wrote:

>  my system is set up to emacs could send out mails.

Well, if you are already using Emacs, the Emacs front-end is not the
nicest interface but does part of the job.  I have this:

--8<---cut here---start->8---
(setq
   debbugs-gnu-default-packages '("guix-patches")
   gnus-summary-line-format "%I%(%[ %n%]%) %s\n")
--8<---cut here---end--->8---

Then ’M-x debbugs-gnu’.  Yeah, I agree it is a bit slow. :-)


> I tried debbugs from time to time and for me it is disgusting:
>
>   * too complicated to get to the list of patches or bugs ( I never can
> remember the many key-presses to perform) ,

To me, the annoyance comes from that ’M-x debbugs-gnu-bugs RET’ returns
the 10 last submissions but it is for the whole GNU project; when I
would like to filter only ’guix-patches’ or ’guix’.


>   * I did not manage to apply patches from there (emacs would need to
> know where my guix development directory is - how can I tell it?)
>   * commands withing debbugs feel complicated
>   * if a ticket contains several updated patches, its very hard to find
> those relevant (one of the reasons of forges' success is that they
> present you the current state)

Well, submitter should use ’git format-patch --reroll-count’. )-:

>   * actually testing the patches required to apply the patches to my
> worktree - and chances are high 'git am' will fail with some
> conflict - chances raise extremely for old patches

Again, submitter should use ’git format-patch --base’; as specified by
the manual. :-)  Using this ’base-commit’, you know where the patch
applies and so you can checkout against the right correct.


>   * Over all for me debbugs.el needs a much more "noops"-friendly
>   interface

Well, I think ’public-inbox’ could help.  An instance is:

https://yhetil.org/guix-patches/

where using lei, you can filter and receive to your inbox the patches.
For example, ’lei’ allows to filter (and thus follow), e.g., let query
for the patches submitted the last 3 months to
’gnu/packages/bioinformatics.scm’ touching R packages,

dfn:gnu/packages/bioinformatics AND b:r-build-system AND rt:3.months.ago..

where

   dfn: match filename from diff
   b:   match within message body, including text attachments
   rt:  match date-time range, git "approxidate" formats supported
Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
are supported



Then, ’lei up’ will request the public-inbox server for this query and
will download the messages if any.  Therefore, you can filter and
receive only the patches that interest you.  Then you could save such
patches and apply them using ’git am’.




Cheers,
simon

Teams: first draft list

[zimoun]

Hi,

On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus  wrote:

> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

Here below a collection of answers.  The teams are more or less.  Maybe,
we could join some for having another structure.  WDYT?


Cheers,
simon



* Python

 + Arun Isaac
 + Lars-Dominik Braun
 + Maxim Cournoyer
 + Ryan Prior

* Haskell

 + Lars-Dominik Braun
 + Simon Tournier

* R

 + Ricardo Wurmus
 + Simon Tournier

* Julia

 + Efraim Flashner
 + Simon Tournier

* OCaml / Dune

 + Julien Lepiller
 + Simon Tournier

* Java / Maven

 + Julien Lepiller

* Algebra / Maths

 + Andreas Enge
 + Eric Bavier

* Emacs

 + Arun Isaac
 + Maxim Cournoyer
 + Nicolas Goaziou

* Lisp

 + Arun Isaac
 + Guillaume Le Vaillant

* Ruby

+ Ryan Prior

* Go

+ Ryan Prior

* Embedded / Bootstrap

 + Ekaitz Zarraga
 + Ludovic Courtes
 + Thiago Jung Bauermann
 + Vagrant Cascadian

* Rust

 + Aleksandr Vityazev
 + Arun Isaac
 + Efraim Flashner
 + John Soo
 + Maxim Cournoyer
 + Maxime Devos
 + Nicolas Goaziou
 + Tobias Geerinckx-Rice

* Kernel

 + Tobias Geerinckx-Rice

* Core / Tools / Internals

 + Arun Isaac
 + Josselin Poiret
 + Ludovic Courtès
 + Ricardo Wurmus

* Games / Videos
 
 + Blake Shaw
 + Maxime Devos
 + raingloom

* Traductions

 + Florian Pelz
 + Julien Lepiller
 + Maxime Devos
 + Thiago Jung Bauermann
 + Tobias Geerinckx-Rice

* Installer

 + Josselin Poiret
 + Mathieu Othacehe

* Home

 + Andrew Tropin
 + Blake Shaw
 + Josselin Poiret
 + Ludovic Courtès
 

sssd, not nscd, foreign distro and release?

[zimoun]

Hi,

On Tue, 01 Mar 2022 at 18:24, Ludovic Courtès  wrote:
> Ludovic Courtès  skribis:
>> Chris Marusich  skribis:
>>
>>> The Guix manual recommends running nscd:
>>>
>>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
>>>
>>> However, Fedora intends to remove it:
>>>
>>> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>>
>> D’oh!  This is bad.  It might suggest that nscd will vanish from glibc
>> as well, given it’s partly developed by the same group of people.
>
> Carlos O’Donell (of glibc) was kind enough to start a discussion
> explaining why this is a concern for Guix (and Nix and others) and
> proposing possible ways forward:
>
>   https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html
>
> continued:
>
>   https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745

What is the status of this?  Can it be blocking for the next release?


Cheers,
simon