bug#38528: Add test for `guix pull'
Hi Pierre, On Fri, 13 Dec 2019 at 10:45, Pierre Neidhardt wrote: > I tried it on two recent commits > (including eb8aad6a23442cf7b23e0df88b89b4cd030dfbf5) and I get Is it a pushed commit? Or a local one? [...] > Any idea? I have no idea. It can only propose to try to reproduce. If you send what is your Guix commit (to know in which environment you run) and your Git commit in which you run "make as-derivation". Cheers, simon
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > zimoun ezt írta (időpont: 2019. dec. 12., Csü > 17:47): >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option >> with a different effect? Or why do we want to conserve this option >> name? >> It appears to me simpler to give another name, for example >> "--inputs-of". And it is more meaningful. > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > that we do not break existing scripts. > Renamin the option would be ok. It even makes sense to me. What I propose is: - keep the option "--ad-hoc" with the current behavior; so same effect - add a new option "--inputs-of" with the new behavior; name more meaningful - and two env variables; to not break existing scripts >> First, when "--ad-hoc" is used then it reports a warning: deprecated >> option and falls in the current behavior. >> When "--inputs-of" is used then it falls in the new behavior. >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > That could be done. The problem is caused by uses of guix environment that > does not use any of these options. Those mean different things after the > change. The transition to such use-case was described below with the introduction of 2 env variables. :-) >> # Alice >> $ guix environment foo --ad-hoc bar >> Warning: deprecated... explanations... >>instead use: >> guix environment bar --inputs-of foo >> >> # Bob >> $ guix environment bar --inputs-of foo >> >> >> Second, the previous "guix environment foo" (dependencies of foo) is >> inconsistent with the new "guix environment bar" (only the package >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED >> variable to distinguish both, as you said. > > Ok. It is the easy part. ;-) Now the hard part: avoid to break existing scripts. >> # Alice >> $ guix environment foo >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 >> >> And Alice has now a new shell with the package foo. If she wants the >> dependencies, she has two options: >> >> $ GUIX_ENVIRONMENT=1 guix environment foo >> or >> $ guix environment --inputs-of foo >> >> >> # Bob >> $ guix environment bar >> Warning: previous behavior requires GUIX_ENVIRONMENT >> >> And if Bob is annoyed by the warnings each time, he globally turns off >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. >> >> >> Couple of months later -- after the period adoption -- we remove the >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; >> still keeping the warning with the "--ad-hoc" option. And then, after >> we can remove the "--ad-hoc" option if required. > We could recommend simply to use something like: > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > Instead in existing scripts that are fixed to use the new syntax. This indeed > looks like a better solution, and it is less of a maintenance burden. Good > idea. My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only be used by the scripts that call "guix environment pkg" without the options "--ad-hoc" or "--inputs-of". And I think that it represents really few scripts in real life. :-) > Summarizing: > Introduce the environment variable. > For fixed scripts recommend unsetting the environment variable. I am not to get your plan. :-) Cheers, simon
bug#38528: Add test for `guix pull'
On Fri, 13 Dec 2019 at 12:20, zimoun wrote: > On Fri, 13 Dec 2019 at 10:45, Pierre Neidhardt wrote: > > > I tried it on two recent commits > > (including eb8aad6a23442cf7b23e0df88b89b4cd030dfbf5) and I get > > Is it a pushed commit? Or a local one? My bad. I find the commit. :-) But I do not experiment the issue you described. No idea... Cheers, simon
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, Let me try again :) zimoun ezt írta (időpont: 2019. dec. 13., P, 13:02): > > Hi Gábor, > > > On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > > > zimoun ezt írta (időpont: 2019. dec. 12., Csü > > 17:47): > > >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > >> with a different effect? Or why do we want to conserve this option > >> name? > >> It appears to me simpler to give another name, for example > >> "--inputs-of". And it is more meaningful. > > > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > > that we do not break existing scripts. > > Renamin the option would be ok. It even makes sense to me. > > What I propose is: > > - keep the option "--ad-hoc" with the current behavior; so same effect > - add a new option "--inputs-of" with the new behavior; name more meaningful > - and two env variables; to not break existing scripts > > > >> First, when "--ad-hoc" is used then it reports a warning: deprecated > >> option and falls in the current behavior. > >> When "--inputs-of" is used then it falls in the new behavior. > >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > > > That could be done. The problem is caused by uses of guix environment that > > does not use any of these options. Those mean different things after the > > change. > > The transition to such use-case was described below with the > introduction of 2 env variables. :-) > > > >> # Alice > >> $ guix environment foo --ad-hoc bar > >> Warning: deprecated... explanations... > >>instead use: > >> guix environment bar --inputs-of foo > >> > >> # Bob > >> $ guix environment bar --inputs-of foo > >> > >> > >> Second, the previous "guix environment foo" (dependencies of foo) is > >> inconsistent with the new "guix environment bar" (only the package > >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > >> variable to distinguish both, as you said. > > > > Ok. > > It is the easy part. ;-) > > > Now the hard part: avoid to break existing scripts. > > >> # Alice > >> $ guix environment foo > >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 > >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 > >> > >> And Alice has now a new shell with the package foo. If she wants the > >> dependencies, she has two options: > >> > >> $ GUIX_ENVIRONMENT=1 guix environment foo > >> or > >> $ guix environment --inputs-of foo > >> > >> > >> # Bob > >> $ guix environment bar > >> Warning: previous behavior requires GUIX_ENVIRONMENT > >> > >> And if Bob is annoyed by the warnings each time, he globally turns off > >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. > >> > >> > >> Couple of months later -- after the period adoption -- we remove the > >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > >> still keeping the warning with the "--ad-hoc" option. And then, after > >> we can remove the "--ad-hoc" option if required. > > > > We could recommend simply to use something like: > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > > Instead in existing scripts that are fixed to use the new syntax. This > > indeed looks like a better solution, and it is less of a maintenance > > burden. Good idea. > > My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only > be used by the scripts that call "guix environment pkg" without the > options "--ad-hoc" or "--inputs-of". And I think that it represents > really few scripts in real life. :-) > > > > Summarizing: > > Introduce the environment variable. > > For fixed scripts recommend unsetting the environment variable. > > I am not to get your plan. :-) > > > Cheers, > simon So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this suspendable with an environment variable, like you described) 3. if only inputs-of present, then do the new behaviour. 4. if neither ad-hoc nor inputs-of present then a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the new behaviour. This would minimze friction, as there will be a few scripts falling under 4. This would also allow mirgating such scripts one by one. be defining GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are fixed to use the new syntax. What do you think? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello Zimoun, zimoun ezt írta (időpont: 2019. dec. 13., P, 17:32): > > Hi Gábor, > > Sorry to be slow. :-) I probably just did not express myself clearly enough. > > On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > > > > So in a more algorithmic manner: > > 1. if ad-hoc and inputs-of is present at the same invocation: fail > > hard. (With an error like incompatible options present) > > 2. if only ad-hoc is present, then print a deprecation warning (yes, > > we could make this suspendable with an environment variable, like you > > described) > > 3. if only inputs-of present, then do the new behaviour. > > 4. if neither ad-hoc nor inputs-of present then > > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > new behaviour. > > > > This would minimze friction, as there will be a few scripts falling under 4. > > This would also allow mirgating such scripts one by one. be defining > > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > > fixed to use the new syntax. > > > > > > What do you think? > > I am perfectly aligned! :-) Great! > It is exactly what I have tried to describe. > Sorry again for being slow. I am sorry for the confusion, my communication tends to slugghish, an I am also a bit bound to do some hand-waving :) I hope to improve on that > > Thank you. > Do you plan to implement it? Do I give a try? I would like to hear something from Ludo, as he was also a participant of the IRC discussion. After that I would not mind if you gave it a try, if you would like. Otherwise I will implement it. > > > All the best, > simon Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Sorry to be slow. :-) On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > So in a more algorithmic manner: > 1. if ad-hoc and inputs-of is present at the same invocation: fail > hard. (With an error like incompatible options present) > 2. if only ad-hoc is present, then print a deprecation warning (yes, > we could make this suspendable with an environment variable, like you > described) > 3. if only inputs-of present, then do the new behaviour. > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. > > This would minimze friction, as there will be a few scripts falling under 4. > This would also allow mirgating such scripts one by one. be defining > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > fixed to use the new syntax. > > > What do you think? I am perfectly aligned! :-) It is exactly what I have tried to describe. Sorry again for being slow. Thank you. Do you plan to implement it? Do I give a try? All the best, simon
bug#38447: Guix Stand-alone OS installation Error - T410 - x86 - intel - lenova
Hello ! Sorry for my late reply. This is strange because the error seems to indicate an issue with kmscon but you wouldn't get there if it was failing to start. Could you try to disable the NVIDIA GPU in the bios and report back? Thanks for your patience, Mathieu Afficher le text Le mer. 11 déc. 2019 à 17:08, Pon Arun Kumar R a écrit : > Hi Mathieu, > > When you get a chance, could you please share the details or suggestions > to proceed further with my GUIX installation on the lenova T410 x86 Intel? > > Appreciate your help! > > Regards, > Pon ArunKumar Ramalingam > > On Mon, Dec 2, 2019 at 9:18 AM Pon Arun Kumar R > wrote: > >> I downloaded the 1.0.1 image from the guix webpage and wrote a bootable >> DVD and used the graphical installer on a machine (lenova thinkpad t410 >> 64bit) >> >> On Mon, Dec 2, 2019 at 9:14 AM Mathieu Othacehe >> wrote: >> >>> >>> Ok thanks. Did you use 1.0.1 image from http://guix.gnu.org/download/? >>> >>> Mathieu >>> >>> Pon Arun Kumar R writes: >>> >>> > Hi Mathieu, >>> > >>> > I tried selecting two different locale/keymap config in two different >>> > attempts, 1. on the regular US english intl and 2. regular US eng,intl >>> with >>> > dead keys, >>> > >>> > I tried several attempts, and I doubt whether it is something to do >>> with >>> > the BIOS settings update as a pre-requite for the installation. >>> > >>> > Thanks, >>> > Pon ArunKumar R >>> > >>> > On Mon, Dec 2, 2019 at 8:54 AM Mathieu Othacehe >>> > wrote: >>> > >>> >> >>> >> Hello! >>> >> >>> >> > Could you please help in resolving this issue? >>> >> > >>> >> > “Unable to locate key map update file” >>> >> >>> >> Thanks for your report. Which locale/keymap did you choose before this >>> >> error occured? >>> >> >>> >> Mathieu >>> >> >>> >>>
bug#38524: [PATCH] services: dhcp-client: Ignore interfaces that need non-free firmware.
* gnu/services/networking.scm (dhcp-client-service-type): Filter interfaces that need non-free firmware. --- gnu/services/networking.scm | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm index 93d9b6a15e..7a57e33974 100644 --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -223,14 +223,14 @@ fe80::1%lo0 apps.facebook.com\n") (define valid? (lambda (interface) (and (arp-network-interface? interface) - (not (loopback-network-interface? interface) + (not (loopback-network-interface? interface)) + ;; XXX: Make sure the interfaces are up so that + ;; 'dhclient' can actually send/receive over them. + (false-if-exception + (set-network-interface-up interface) (define ifaces (filter valid? (all-network-interface-names))) - ;; XXX: Make sure the interfaces are up so that 'dhclient' can - ;; actually send/receive over them. - (for-each set-network-interface-up ifaces) - (false-if-exception (delete-file #$pid-file)) (let ((pid (fork+exec-command (cons* #$dhclient "-nw" -- 2.19.2
bug#38524: [PATCH] services: dhcp-client: Ignore interfaces that need non-free
This patch allow dhcp-client-service to start even when an interface that require non free-software is present; such device will be skipped.
bug#38600: Unbound variable for some package --show invocations.
Noticed the problem with cl-slime-swank, but seems to happen with a variety of packages including sbcl-cl-uglify-js itself. I checked javascript.scm, which does import lisp-xyz; Haven't done any deeper debugging to discover possible causes. Backtrace follows. $ guix package --show=sbcl-cl-uglify-js Backtrace: In ice-9/boot-9.scm: 222:29 19 (map1 (((gnu packages gettext)) ((gnu packages #)) (#) …)) 222:29 18 (map1 (((gnu packages ghostscript)) ((gnu packages …)) …)) 222:29 17 (map1 (((gnu packages gl)) ((gnu packages glib)) ((…)) …)) 222:29 16 (map1 (((gnu packages glib)) ((gnu packages gnome)) # …)) 222:29 15 (map1 (((gnu packages gnome)) ((gnu packages gnupg)) # …)) 222:29 14 (map1 (((gnu packages gnupg)) ((gnu packages #)) ((…)) …)) 222:29 13 (map1 (((gnu packages gstreamer)) ((gnu packages #)) # …)) 222:29 12 (map1 (((gnu packages gtk)) ((gnu packages image)) (#) …)) 222:29 11 (map1 (((gnu packages image)) ((gnu packages #)) ((…)) …)) 222:29 10 (map1 (((gnu packages imagemagick)) ((gnu packages …)) …)) 222:17 9 (map1 (((gnu packages javascript)) ((gnu packages #)) …)) 2800:17 8 (resolve-interface (gnu packages javascript) #:select _ …) In ice-9/threads.scm: 390:8 7 (_ _) In ice-9/boot-9.scm: 2726:13 6 (_) In ice-9/threads.scm: 390:8 5 (_ _) In ice-9/boot-9.scm: 2994:20 4 (_) 2312:4 3 (save-module-excursion #) 3014:26 2 (_) In unknown file: 1 (primitive-load-path "gnu/packages/javascript" #) In gnu/packages/javascript.scm: 460:10 0 (_) gnu/packages/javascript.scm:460:10: error: sbcl-cl-uglify-js: unbound variable
bug#38524: [PATCH] services: dhcp-client: Ignore interfaces that need non-free firmware.
This LGTM, though I'd add a comment noting this bug report or something so it is known why this behavior was adjusted. Dec 13, 2019 3:57:14 PM Brice Waegeneire : > * gnu/services/networking.scm (dhcp-client-service-type): Filter interfaces > that need non-free firmware. > --- > gnu/services/networking.scm | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm > index 93d9b6a15e..7a57e33974 100644 > --- a/gnu/services/networking.scm > +++ b/gnu/services/networking.scm > @@ -223,14 +223,14 @@ fe80::1%lo0 apps.facebook.com\n") > (define valid? > (lambda (interface) > (and (arp-network-interface? interface) > - (not (loopback-network-interface? interface) > + (not (loopback-network-interface? interface)) > + ;; XXX: Make sure the interfaces are up so that > + ;; 'dhclient' can actually send/receive over them. > + (false-if-exception > + (set-network-interface-up interface) > (define ifaces > (filter valid? (all-network-interface-names))) > > - ;; XXX: Make sure the interfaces are up so that 'dhclient' can > - ;; actually send/receive over them. > - (for-each set-network-interface-up ifaces) > - > (false-if-exception (delete-file #$pid-file)) > (let ((pid (fork+exec-command > (cons* #$dhclient "-nw" > -- > 2.19.2 >
bug#38524: [PATCH v2] services: dhcp-client: Ignore interfaces that need non-free firmware.
Fixes bug #38524 (see: https://bugs.gnu.org/38524). * gnu/services/networking.scm (dhcp-client-service-type): Filter interfaces that need non-free firmware. --- This patch version contains a link to the issue as Brett asked. gnu/services/networking.scm | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm index 93d9b6a15e..7a57e33974 100644 --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -223,14 +223,14 @@ fe80::1%lo0 apps.facebook.com\n") (define valid? (lambda (interface) (and (arp-network-interface? interface) - (not (loopback-network-interface? interface) + (not (loopback-network-interface? interface)) + ;; XXX: Make sure the interfaces are up so that + ;; 'dhclient' can actually send/receive over them. + (false-if-exception + (set-network-interface-up interface) (define ifaces (filter valid? (all-network-interface-names))) - ;; XXX: Make sure the interfaces are up so that 'dhclient' can - ;; actually send/receive over them. - (for-each set-network-interface-up ifaces) - (false-if-exception (delete-file #$pid-file)) (let ((pid (fork+exec-command (cons* #$dhclient "-nw" -- 2.19.2
