Re: util-linux and perl rename
On 26/11/2018 06.12, Alex Vong wrote: To eliminate this conflict, I can think of 2 solutions: 1. Use 2 separate profiles where one has util-linux installed and the other has rename installed. 2. Install util-linux into the default profile, but invoke rename by "guix environment --ad-hoc rename -- rename ..." instead of "rename ..." These 2 solutions work in general as well, such as for conflicting library versions, conflicting language runtimes... I prefer the 2nd solution since maintaining 2 separate profiles just for using rename seems too "heavy weight" to me. Thanks for 2 solutions. Luckily, I don't need access to the util-linux rename. I have to note, that if I was working on scripts with the intention to share them with users of other distributions, the 2nd wouldn't be an option. Too bad we don't have command URIs :} I would have been tempted to put a symlink in /usr/local/bin, but there's no "latest-of-package-foo" to link to, right? Is there a way to get a list of all name clashes on the system? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/
Re: util-linux and perl rename
Alex Vong writes: > Thorsten Wilms writes: > >> 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? >> > I think it is chosen based on some random criterions It's not random, but rather a very simple criterion. The packages listed first in the package manifest take priority over ones that come later. If you don't use manifests, "guix package -i " puts at the top of the new manifest, even if it was already present in the previous manifest. Mark
Re: util-linux and perl rename
Mark H Weaver writes: > Alex Vong writes: > >> Thorsten Wilms writes: >> >>> 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? >>> >> I think it is chosen based on some random criterions > > It's not random, but rather a very simple criterion. The packages > listed first in the package manifest take priority over ones that come > later. If you don't use manifests, "guix package -i " puts > at the top of the new manifest, even if it was already present in the > previous manifest. > I see, so this explains how Thorsten managed to get the right rename (not because of luck or magic...) I personally had given up using the imprerative "install" interface and switched using the declarative "manifest" interface. IMO, it makes it clearer what I've installed and allows me quickly comment / un-comment fail-to-build packages. With the imprerative interface, I've to remember which fail-to-build packages I didn't upgrade last time. So in fact we have a 3rd solution: to re-order the packages in your manifest. >Mark Cheers, Alex signature.asc Description: PGP signature
Re: Outreachy project infrastructure
On Sun, 25 Nov 2018 21:30:03 -0300 Laura Lazzati wrote: > > > > Laura, I saw you already have an account for libreplanet. Feel free > > to go on editing this page. I really just copy/pasted Ricardos > > email here. > > > > Great! Yes, I created it to edit the file about attending to > > FOSDEM, was > that wrong? Not all all. I'm only (positively) surprised how quick you are and how much you do on your own. Björn pgpQWSma2xVFo.pgp Description: OpenPGP digital signature
Re: Packaging Arcan
Hello,
Thank you for the help.
I decided to package appls on their own as they are not part of Arcan
itself and can be written by anyone.
My plan, if I understood correctly, is to copy appls file to
'%out/share/arcan/appl' as the folder already exists in Arcan package so
that everything is "merged" in a single folder in the user profile.
I first thought that setting a search-path in the Arcan package would
then let the user deal with the rest. (Are search-paths honored
automatically under GuixSD?)
But after installing Arcan, 'guix package --search-paths'
doesn't output anything related to the variable I set. I don't have any
hint telling me to set it myself during installation.
Am I misunderstanding something about search-paths?
Here is the piece of code I added to the Arcan definition:
(search-paths
'((search-path-specification
(variable "ARCAN_APPLBASEPATH")
(files '("share/arcan/appl")
Last question here, in a specific appl (Durden), there a little shell
script which set some variables/folders and start arcan. Is it ok to put
it in "%outbin"?
Lprndn
Re: Packaging Arcan
Thank you! For the record, for OpenAl, I ended up adding the patched version as an input without packaging it (following the git example given by swedebugia). Then, copying the files in the right place, the build system seems to be smart enough to deal with the rest on its own. It's one less package to deal with! Lprndn
Re: Outreachy project infrastructure
Not all all. I'm only (positively) surprised how quick you are and how > much you do on your own. > Oh, thank you :) I though I was writing too much for help. And sometimes I get a little bit discouraged by the timezone, we have around 4 hs difference, and maybe when I get up you are already at midday. I will be doing several things this week: I will be getting help with the trip, I would like to make a new post to my blog about the pre-internship experience, if it is ok, I would like to post that I will be attending Guix-Days and FOSDEM. I have taken a quick look to the wiki on libreplanet for video documentation. I find it similar to Readmine somehow. Is it OK to add internal links for my proposed timeline, for example, even though it will be changing in the future, and other discussion stuff related to it? Regards and thank you for your compliment again :) Laura
Re: Getting ‘core-updates’ merged
On Thu, 22 Nov 2018 10:41:59 +0100 l...@gnu.org (Ludovic Courtès) wrote: > 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. You can also compare it to master, I think this gives a better picture than comparing two consecutive core-updates evaluations: https://hydra.gnu.org/eval/110331?compare=master#tabs-now-fail (Update evaluation-number when a newer evaluation is finished) It's also worth looking at the "New jobs" tab, as new jobs can initially fail and version-updates are handled as old-version-out-new-version-in. Björn pgpK9n9hPDIE1.pgp Description: OpenPGP digital signature
Re: Getting ‘core-updates’ merged
Hi Ludo, On Sun, 25 Nov 2018 16:54:53 +0100 l...@gnu.org (Ludovic Courtès) wrote: > It seems that this bug is not fully resolved. Do you know how we could > skip it in the meantime? Yes, just try the build again. It's a thread synchronization problem. pgp02d52wDw0l.pgp Description: OpenPGP digital signature
Re: Getting ‘core-updates’ merged
Or this: (delete-file-recursively "src/test/run-make/issue-26092") pgpf6fw1ThcXf.pgp Description: OpenPGP digital signature
Re: Preparing the reduced bootstrap tarballs
Hi Jan, Jan Nieuwenhuizen writes: > Timothy Sample writes: > >> I wanted to let you know that I’ve been doing more work on the little >> Shell backend that we were talking about earlier. It’s kind of like the >> worse-is-better version of Gash: it is certainly not as nice, but the >> development pace is much faster. I did take a look at just working on >> Gash directly, but it looked like it was going to be a lot slower. > > Oh, that's great news! We have been making good progress on Gash. The > parser has been completely revamped. The next target is to add a > transformation that should result in a eval'able shelly Guile script, > ideally something that you'd want to write by hand. That’s what I like best about Gash. My “shelly” code is a mess and no one should write it by hand! :) > To achieve that will take some time. It would be nice if we could work > together shaping this shelly script language . I agree, but I am hesitant to worry about this now. The more I work on Geesh the more I realize that building a shell is a big project. I’ve consistently been moving from worrying about making things work nicely to just making them work. I hope that once the basic features are in place it will be a lot more fun to improve things gradually. Does that make sense? > If Gash and Geesh would produce (after transformation) the same shelly > script language, we can also share the backend implementation, WDYT? I’m a little bit confused about this. After we exchanged notes last time, I thought we were going to share front-ends. Now it seems you’ve doubled-down on Gash’s PEG parser and want to share back-ends. Why the change in plans? It makes more sense to me to share front-ends because the parser in Geesh is quite complete. Also, you already wrote some code to transform its output into a Gash script. >> So, keeping in mind that software estimates are very unreliable, I would >> say that I might have a workable interpreter in the next week or two. >> There are three big features missing: globbing, asynchronous commands, >> and arithmetic substitutions. I am almost finished globbing, >> asynchronous commands should be pretty easy, and I plan to leave >> arithmetic substitutions on the road-map for as long as possible (it’s a >> little bit boring). > > Hehe. I had a look and you did make lots of progress! So have you! It’s pretty funny that we both picked up working on this at about the same time. In hindsight, I should have contacted you before diving in again in order to minimize duplicated work. On the other hand, it seems you’re guilty of the same thing! Oh well. ;) I‘m not too worried about it, and I’m having fun. I hope you are too. >> After I get those first two features working, I am going to start >> testing running build scripts for Bash. I will contact you then in case >> you have any new advice on which scripts are important or anything else. > > Great, > Keep up the good work! I skipped asynchronous commands and implemented a bunch of built-ins instead. Now Geesh will run most of Bash’s configure script. It runs until it tries to write “config.sub” which it writes incorrectly due to an unset variable (ironically, it seems to be the “$SHELL” variable). That means it chews through over 17,000 lines of configure script! It does this very s-l-o-w-l-y, but it’s exciting all the same. -- Tim
Re: Bug in my WIP-npm-importer with blacklist
Il giorno dom 25 nov 2018 alle ore 14:21 swedebugia ha scritto: > Hi > > I am still a novice in guile so I humbly ask for help with this error > trying to get the blacklisting to work: > > sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet > ice-9/boot-9.scm:222:17: In procedure map1: > Syntax error: > /home/sdb/guix-tree/guix/import/npm.scm:304:2: source expression failed > to match any pattern in form (if (member (cut guix-name "node-" <>) > blacklist)) > > The relevant code is in npm.scm as detailed in the error above. > > The files are attached. > > Thanks in advance! > > There are 2 observations I can give The first one is that member" returns a boolean value (#t or #f) and your function can return just that, you don't need the if But even if you needed the if, you have to pass it at least 2 forms: a test and another expression whose value will be returned if the tests succeeds (that is, it evaluates to #t) In your code you are passing the if form only one expression. The only expression you are passing to the if is (member (cut guix-name "node-" <>) blacklist) if this subexpression evaluates to #t, what is the if supposed to do ? You could have written (define (blacklisted? guix-name) "Check if guix-name is blacklisted. RETURN #t if yes, else #f." (if (member (cut guix-name "node-" <>) blacklist) #t #f)) in this exaple, if the subexression evaluates to #t, the if form can return #t, which is but as you can see (this is my second observation), this formulation is a bit redundant It can be rewritten without the if at all, lie this (define (blacklisted? guix-name) "Check if guix-name is blacklisted. RETURN #t if yes, else #f." (member (cut guix-name "node-" <>) blacklist))) In this formulation, if the subexpression (member (cut guix-name "node-" <>) blacklist)) returns #t, your function will return #t, because your function returns the value off its last subform if the subexpression returns #f, of course your function will return #f That's supposedly what you wanted to achieve, isn't it ? You can achieve it without the if 😊 Usually when Guile laments that a source expression doesn't match any pattern, that's because you messed up the parenses or because you passed the wrong number of subexpressions to a form Please note that in this case Guile is not denouncing that the wrong number of arguments were passed to a function Because the "if" is not a function, it's a special form (I think), and the expander tries to recognize a known "pattern" in it It fails and it gives up Hope this helps
Re: Bug in my WIP-npm-importer with blacklist
because I made so many typing mistakes, I corrected my text and I'm posting it again, corrected There are 2 observations I can give The first one is that "member" returns a boolean value (#t or #f) and your function can return just that, you don't need the if But even if you needed the if, you have to pass it at least 2 forms: a test and another expression whose value will be returned if the tests succeeds (that is, it evaluates to #t) In your code you are passing the if form only one expression. The only expression you are passing to the if is (member (cut guix-name "node-" <>) blacklist) if this subexpression evaluates to #t, what is the if supposed to do ? You could have written (define (blacklisted? guix-name) "Check if guix-name is blacklisted. RETURN #t if yes, else #f." (if (member (cut guix-name "node-" <>) blacklist) #t #f)) in this exaple, if the subepxression evaluates to #t, the if form can return #t, which is the second (sub)expression passed to it Of course, if the (first) subexpression evaluates to #f, then your if form will return #f, wich is the third (sub)expression passed to it but as you can see (this is my second observation), this formulation is a bit redundant It can be rewritten without the if at all, like this (define (blacklisted? guix-name) "Check if guix-name is blacklisted. RETURN #t if yes, else #f." (member (cut guix-name "node-" <>) blacklist))) In this formulation, if the subexpression (member (cut guix-name "node-" <>) blacklist)) returns #t, your function will return #t, because your function returns the value off its last subform if the subexpression returns #f, of course your function will return #f That's supposedly what you wanted to achieve, isn't it ? You can achieve it without the if 😊 Usually when Guile laments that a source expression doesn't match any pattern, that's because you messed up the parenses or because you passed the wrong number of subexpressions to a form Please note that in this case Guile is not denouncing that the wrong number of arguments were passed to a function Because the "if" is not a function, it's a special form (I think), and the expander tries to recognize a known "pattern" in it It fails and it gives up Hope this helps Il giorno lun 26 nov 2018 alle ore 20:39 Catonano ha scritto: > > > Il giorno dom 25 nov 2018 alle ore 14:21 swedebugia > ha scritto: > >> Hi >> >> I am still a novice in guile so I humbly ask for help with this error >> trying to get the blacklisting to work: >> >> sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet >> ice-9/boot-9.scm:222:17: In procedure map1: >> Syntax error: >> /home/sdb/guix-tree/guix/import/npm.scm:304:2: source expression failed >> to match any pattern in form (if (member (cut guix-name "node-" <>) >> blacklist)) >> >> The relevant code is in npm.scm as detailed in the error above. >> >> The files are attached. >> >> Thanks in advance! >> >> > There are 2 observations I can give > > The first one is that member" returns a boolean value (#t or #f) and your > function can return just that, you don't need the if > > But even if you needed the if, you have to pass it at least 2 forms: a > test and another expression whose value will be returned if the tests > succeeds (that is, it evaluates to #t) > > In your code you are passing the if form only one expression. > > The only expression you are passing to the if is > > (member (cut guix-name "node-" <>) blacklist) > > if this subexpression evaluates to #t, what is the if supposed to do ? > > You could have written > > > (define (blacklisted? guix-name) > "Check if guix-name is blacklisted. RETURN #t if yes, else #f." > (if (member (cut guix-name "node-" <>) blacklist) #t #f)) > > in this exaple, if the subexression evaluates to #t, the if form can > return #t, which is > > but as you can see (this is my second observation), this formulation is a > bit redundant > > It can be rewritten without the if at all, lie this > > (define (blacklisted? guix-name) > "Check if guix-name is blacklisted. RETURN #t if yes, else #f." > (member (cut guix-name "node-" <>) blacklist))) > > > In this formulation, if the subexpression > > (member (cut guix-name "node-" <>) blacklist)) > > returns #t, your function will return #t, because your function returns > the value off its last subform > > if the subexpression returns #f, of course your function will return #f > > That's supposedly what you wanted to achieve, isn't it ? > > You can achieve it without the if 😊 > > Usually when Guile laments that a source expression doesn't match any > pattern, that's because you messed up the parenses or because you passed > the wrong number of subexpressions to a form > > Please note that in this case Guile is not denouncing that the wrong > number of arguments were passed to a function > > Because the "if" is not a function, it's a special form (I think), and the > expander tries to recognize a known "pattern" in
