Re: 33/33: daemon: Workaround issues for the Hurd.

2020-03-11 Thread Jan Nieuwenhuizen
Ludovic Courtès writes: Hello! > Jan Nieuwenhuizen skribis: > +#if !__GNU__ int status = pid.wait(true); if (status != 0) throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status)); +#endif >>> >>> Do you know

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

2020-03-11 Thread Jan Nieuwenhuizen
Vincent Legoll writes: > Hello > > On Wed, Mar 11, 2020 at 4:01 PM Jan Nieuwenhuizen wrote: >> + `(("libcap" ,libcap)) ;capability support is 'ls', etc. > > s/is/in/ or s/is/for/ maybe ? Yes, probably. Typo fixed in upcoming patch series; thanks :) janneke -- Jan Nieuwenhuizen

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

2020-03-11 Thread Vincent Legoll
Hello On Wed, Mar 11, 2020 at 4:01 PM Jan Nieuwenhuizen wrote: > + `(("libcap" ,libcap)) ;capability support is 'ls', etc. s/is/in/ or s/is/for/ maybe ? -- Vincent Legoll

Re: rust (build system) deficits

2020-03-11 Thread Hartmut Goebel
Hi John, >> This importer does not solve the declarations, and IMHO it should not >> anyway - as the are dependencies of another packages, which might change >> over time. >> > I’m not sure I fully understand why the recursive importer should not > solve the transitive dependencies. Could you elab

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

2020-03-11 Thread Gábor Boskovits
Hello, R Veera Kumar ezt írta (időpont: 2020. márc. 11., Sze 17:51): > On Wed, Mar 11, 2020 at 11:03:00AM +0100, Gábor Boskovits wrote: > > Hello, > > > > Veera ezt írta (időpont: 2020. márc. 11., Sze 1:31): > > > > > On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote: > > > >H

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

2020-03-11 Thread R Veera Kumar
On Wed, Mar 11, 2020 at 11:03:00AM +0100, Gábor Boskovits wrote: > Hello, > > Veera ezt írta (időpont: 2020. márc. 11., Sze 1:31): > > > On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote: > > >Hello, > > >Veera <[1]v...@vkten.in> ezt írta (időpont: 2020. márc. 8., Vas > > 8

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

2020-03-11 Thread Efraim Flashner
On March 11, 2020 4:20:26 PM UTC, Jan Nieuwenhuizen wrote: >Efraim Flashner writes: > >> If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you >> should go ahead and either use gcc-7 or gcc for the libstdc++-boot0 > >Ah...your patch but then with gcc-7 instead of gcc-5; gosh why

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

2020-03-11 Thread Jan Nieuwenhuizen
Efraim Flashner writes: > If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you > should go ahead and either use gcc-7 or gcc for the libstdc++-boot0 Ah...your patch but then with gcc-7 instead of gcc-5; gosh why didn't I think of that. Thank you! I'll give that a try...although

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

2020-03-11 Thread Efraim Flashner
On March 11, 2020 2:27:37 PM UTC, Jan Nieuwenhuizen wrote: >Jan Nieuwenhuizen writes: > >> Efraim Flashner writes: >> >>> On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote: guix-comm...@gnu.org skribis: > commit 7a57ca758c590742b63100944f07fddb7290f797 > Autho

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

2020-03-11 Thread Jan Nieuwenhuizen
Ludovic Courtès writes: > guix-comm...@gnu.org skribis: >> ;; Drop the dependency on libcap when cross-compiling since >> it's >> ;; not quite cross-compilable. >> - ,@(if (%current-target-system) >> + ;; Also, libcap is not available on the Hur

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

2020-03-11 Thread Pierre Neidhardt
Ludovic Courtès writes: > Other considerations: > > - Bandwidth requirement for source code downloads has never been a > criterion so far. > > - Git references are nice because they’re (roughly) content-addressed. > > - ‘guix lint -c archival’ archives Git references on Software > H

Re: 33/33: daemon: Workaround issues for the Hurd.

2020-03-11 Thread Ludovic Courtès
Hi! Jan Nieuwenhuizen skribis: >>> +#if !__GNU__ >>> int status = pid.wait(true); >>> if (status != 0) >>> throw Error(format("cannot kill processes for uid `%1%': %2%") % >>> uid % statusToString(status)); >>> +#endif >> >> Do you know what the rationale was? It looks like

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

2020-03-11 Thread Ludovic Courtès
Hi! Marius Bakke skribis: > Pierre Neidhardt writes: > >> Duh, I confused these with the github generated archive, sorry about >> that. >> >> Is there any preference between git-fetch and url-fetch? > > url-fetch requires less bandwidth, and does not depend on 'git'. > > Though the most importa

Re: [GSOC 2020] Introduction and asking for feedback

2020-03-11 Thread Ludovic Courtès
Hi Alberto, Blackbeard skribis: > I want to apply to Google Summer of Code. The ideas I am most interested are > a) for GNU Guix: 'Content-addressed protocol for substitutes' and b) for > GNU Shepherd:  "Syntax and semantics of systemd units in the Shepherd", > because I have a feeling any of th

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

2020-03-11 Thread Jan Nieuwenhuizen
Jan Nieuwenhuizen writes: > Efraim Flashner writes: > >> On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote: >>> guix-comm...@gnu.org skribis: >>> >>> > commit 7a57ca758c590742b63100944f07fddb7290f797 >>> > Author: Jan Nieuwenhuizen >>> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100 >>

Re: LHC for guixHPC?

2020-03-11 Thread Ludovic Courtès
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 in

Re: Guix Data Services - Outreachy Applicant

2020-03-11 Thread Ricardo Wurmus
Hi Danjela, > I am trying to build the Guix Data Service project locally and it prompts > me to install Guile-Squee. I tried to install Squee but I am running into > other build problems when I run 'make'. Apparently it can't find libpq, > which I checked and is downloaded. > Here is the error m

Re: branch core-updates updated: gnu: guix: Fix cross-compilation.

2020-03-11 Thread Mathieu Othacehe
Hey, > I suppose we need to adjust ‘guile3.0-guix’ as well, and perhaps > ‘guix-daemon’ too? Yes, you were right about guile3.0-guix, fixed on core-updates! "guix-daemon" seems to work fine. Thanks, Mathieu

Re: Guix Data Services - Outreachy Applicant

2020-03-11 Thread Gábor Boskovits
Hello Daniela, Daniela Lura ezt írta (időpont: 2020. márc. 11., Sze 0:19): > Hello, > > This is Danjela, an outreachy applicant and a second year computer science > student. > How is everyone doing? > Fine so far. And you? > > I am trying to build the Guix Data Service project locally and it pr

Fwd: [gnu-soc] GSoC-2010: Call for Mentors

2020-03-11 Thread Gábor Boskovits
To prospective GSoC mentors for GSoC 2020: The GNU coordinators reached out to me with the following communication. Please register yourselves as advised. Also, if ,you have not done so, please subscribe to summer-of-c...@gnu.org mailing list. -- Forwarded message - Feladó: Darshi

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

2020-03-11 Thread Gábor Boskovits
Hello, Veera ezt írta (időpont: 2020. márc. 11., Sze 1:31): > On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote: > >Hello, > >Veera <[1]v...@vkten.in> ezt írta (időpont: 2020. márc. 8., Vas > 8:41): > > > > On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrot

Re: kmscon not working on MacBook

2020-03-11 Thread pelzflorian (Florian Pelz)
On Wed, Mar 11, 2020 at 08:14:37AM +0100, pelzflorian (Florian Pelz) wrote: > I’m not sure if that is a good means for detection. > > > Perhaps one could go by whether /dev/fb0 exists. I wonder if /dev/fb0 is missing on all affected devices. I will check mine later. Regards, Florian

Re: kmscon not working on MacBook

2020-03-11 Thread pelzflorian (Florian Pelz)
On Mon, Mar 09, 2020 at 05:45:45PM +0100, Ludovic Courtès wrote: > However, in cases where kmscon does *not* exits and simply produces a > black screen, I don’t see what can be done. In the cases you list > above, does kmscon simply sit there without exiting? > When run with --debug, kmscon disp