How to write a compute-file producing utf8 output?
Hello Guix, I am currently struggling when trying to create a computed-file producing internationalized content. Simple reproducer is: (use-modules (gnu packages base) (guix gexp)) (computed-file "utf8-display" #~(with-output-to-file #$output (λ () (display "猫\n" This, when executed and printed, gives following result: /tmp $ guix build -e '(load "/tmp/yy.scm")' /gnu/store/fyr9h82v9hhbjm4f7lqsdnhs4c45sn3y-utf8-display /tmp $ cat /gnu/store/fyr9h82v9hhbjm4f7lqsdnhs4c45sn3y-utf8-display ? As you can see, ? does not equal 猫. I would expect the root cause to be the same as #66777. Any ideas what can I do about this? Or, even better, why this does not just work out of the box? Thanks for your help, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: branch master updated (2bea3f2562 -> 6745d692d4)
On 2024-05-10 11:28:48 -0400, kiasoc5 wrote: > > Yeah, it's very annoying that I missed these two FIXUP commits :-/ > > > > Seeing that these are the only 2 FIXUP commits on the master branch history > so far, would it make sense to force push and edit the history? Yes, it > would mess up everyone's local checkout And *every* installation that already pulled those commits. So it would affect not only developers, but also users. At least as far I understand it. > , but if editing the history for Guix > would ever be justified, I feel like this would be one such scenario. I do not believe that is a bridge that should be crossed, definitely not in this case. The commits look bit ugly, but practically speaking do little harm (in my opinion). Yes, they might break bisect, but so do other commits from time to time. We will just have to live with it. But that is just like, my opinion. :) Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: The `channels' field of `operating-system' record
On 2024-04-10 17:17:27 +0200, Ludovic Courtès wrote: > Yes, we could change the default to #f: it’s equivalent to > ‘%default-channels’ but wouldn’t cause the undesirable side effect you > experienced. > > Do you want to prepare a patch (or two)? :-) Well it took me approximately forever to get to, but finally: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70839 Cheers, T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
On 2024-05-01 08:29:29 -0700, Ian Eure wrote: > If Guix is going to continue to facilitate license violations, I will have no > choice but to remove my software from it to defend them. Purely hypothetically, if it would come to this, how would you go about it? Assuming the software is under free license (requirement for inclusion into Guix), I am unsure based on what would the removal be demanded. Do you have some specific approach in mind? Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: The `channels' field of `operating-system' record
On 2024-04-10 17:17:27 +0200, Ludovic Courtès wrote: > Hello, > > Tomas Volf <~@wolfsden.cz> skribis: > > > After ~2 hours of digging I realized this is caused by the changes in > > 883e69cdfd226c8f40b6e3b76ce0740b59857de6. > > > > I see couple of issues here (in no particular order, questions prefixed > > with Q): > > > > * My configuration file just *silently* stopped working. > > > > That is not great for obvious reasons. > > > > * There is no news entry > > Oops, my apologies; the change felt pretty innocuous when I merged it, > but in hindsight, it seems clear that a news entry was warranted. > Lesson learned. > > We can still add that news entry, though fewer people will see it now. > > Thoughts? Sorry for the late response, I have sadly been somewhat busy. I see, so even if you add the news entry now, only people who had not yet pulled the commit in question would see it. If that is the case, there is probably not much of a reason to do it now. > > > * Broken default behavior. > > > > Currently, out of the box, extra-special-file with "/etc/guix/channels.scm" > > just > > does not do anything. No error, no warning. That is pretty unexpected. > > Yes, why is that? At first sight, that’s because ‘extra-special-file’ > does things at activation time; there’s no check happening at > configuration time. > > It was really meant for /bin/sh, /usr/bin/env, and similar. The reason > its effect is silently dismissed in this case is, I think, because its > activation runs before the /etc activation. So it’s really bad luck. > > I’m not sure what to do here, apart from maybe recommending against > broad use of this service. I will re-phrase the above into a documentation patch. > > > * There is no terse way to turn it off > > > > Currently my configuration contains this: > > > > (modify-services %base-services > > (guix-service-type > > config => (guix-configuration > > (inherit config) > > (channels #f > > Hmm right. You do want to create /etc/guix/channels.scm though, right? > (Since you had it initially.) Yes, I do want to create it, but with (channels #f) the (extra-special-file) works again. ^_^ > > > * Q: Is there an easy way to fill (channels)? > > > > After I learned that (channels) is a thing, I wanted to use it, but did not > > find > > any simple way how to do so. My channels are in channels.scm produced by > > `guix > > describe --format=channels', and I do not see any simple way to pass the > > content > > of that file into (channels). No, it does not accept (local-file). I tried > > just (read)-ing it, but that too does not work. > > That would be: (guix-configuration … (channels (load "channels.scm"))). That does not seems to work, I am getting this error: /tmp $ guix system build os.scm ;;; compiling /tmp/channels.scm ;;; /tmp/channels.scm:1:7: warning: possibly unbound variable `channel' ;;; /tmp/channels.scm:2:9: warning: possibly unbound variable `name' ;;; /tmp/channels.scm:3:9: warning: possibly unbound variable `url' ;;; /tmp/channels.scm:4:9: warning: possibly unbound variable `branch' ;;; /tmp/channels.scm:5:9: warning: possibly unbound variable `commit' ;;; /tmp/channels.scm:7:9: warning: possibly unbound variable `introduction' ;;; /tmp/channels.scm:8:11: warning: possibly unbound variable `make-channel-introduction' ;;; /tmp/channels.scm:10:13: warning: possibly unbound variable `openpgp-fingerprint' ;;; compiled /home/wolf/.cache/guile/ccache/3.0-LE-8-4.6/tmp/channels.scm.go Backtrace: In guix/scripts/system.scm: 1306:4 19 (_) In ice-9/boot-9.scm: 1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 661:37 17 (thunk) 1300:8 16 (call-with-build-handler # …) 2180:25 15 (run-with-store # _ #:guile-for-build _ …) In guix/scripts/system.scm: 848:2 14 (_ _) 722:8 13 (_ #) In gnu/system.scm: 1300:19 12 (operating-system-derivation _) 837:11 11 (operating-system-services #< kernel: #) In /tmp/os.scm: 19:12 10 (services #< kernel: #) In gnu/services.scm: 383:23 9 (%modify-services (#< type: # v…> …) …) In srfi/srfi-1.scm: 460:18 8 (fold # …) In gnu/services.scm: 384:37 7 (_ #< type: # value: #< …) 354:28 6 (apply-clauses _ #< type: # value: …> …) In /tmp/os.scm: 23:36 5 (_ #< type: # value: #<) In ice-9/boot-9.scm: 2836:4 4 (save-module-excursion #) 4388:12 3 (_) In /tmp/channels.scm
Re: The `channels' field of `operating-system' record
On 2024-04-08 23:06:00 -0500, Nathan Dehnel wrote: > I don't think you're supposed to edit /etc/guix/channels.scm directly, Is this documented anywhere? I used the code for over a year and it worked just fine. I cannot find any instruction to not touch it anywhere in the info manual. > I think it's generated by guix system reconfigure. > https://gitlab.com/nonguix/nonguix/-/issues/33 > I have ~/.config/guix/channels.scm generated by putting > home-channels-service-type in my guix home config. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: The `channels' field of `operating-system' record
On 2024-04-09 06:16:12 +0200, Marek Paśnikowski wrote: > 09.04.2024 06:06:00 CEST Nathan Dehnel: > > I don't think you're supposed to edit /etc/guix/channels.scm directly, > > I think it's generated by guix system reconfigure. > > https://gitlab.com/nonguix/nonguix/-/issues/33 > > I have ~/.config/guix/channels.scm generated by putting > > home-channels-service-type in my guix home config. > > Now that you mentioned it — is this not root user’s channel list, and > one is not supposed to use guix as root? Not really, it is a system-wide channel list. Root's channel list would be /root/.config/guix/channels.scm. > > I use home-channels-service-type and the only issue with this solution > is that it requires a 'guix home reconfigure' before the new channels > can be used in 'guix pull'. Though one could also use the -C flag to > a channels.scm file including the list of channels. The /etc/... one has advantage of applying to all users. Which is nice. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
The `channels' field of `operating-system' record
Hello, yesterday I had to debug a really weird problem. I had a extra-special-file in my system configuration used to create /etc/guix/channels.scm, but it was not working, the channels file contained something completely else then I put into it. In particular, this sequence in the configuration: (extra-special-file "/etc/guix/channels.scm" file/channels.scm) (extra-special-file "/etc/guix/xxx" file/channels.scm) (extra-special-file "/etc/guix/yyy" file/channels.scm) Produced this on the file system: channels.scm -> /gnu/store/icw828kvva25ns9p0y0np7lp3c7xl0n6-channels.scm xxx -> /gnu/store/w3gip7zqrqxbp8kaplq6kia85i5c4fh8-channels.scm yyy -> /gnu/store/w3gip7zqrqxbp8kaplq6kia85i5c4fh8-channels.scm Notice that, despite being created by the exact same code, the store items differs. After ~2 hours of digging I realized this is caused by the changes in 883e69cdfd226c8f40b6e3b76ce0740b59857de6. I see couple of issues here (in no particular order, questions prefixed with Q): * My configuration file just *silently* stopped working. That is not great for obvious reasons. * There is no news entry I did not realize it stopped working for some time (but it explains few weird issues I had lately) until I tried to install completely new system where I actually went to check it works as expected. * Broken default behavior. Currently, out of the box, extra-special-file with "/etc/guix/channels.scm" just does not do anything. No error, no warning. That is pretty unexpected. * There is no terse way to turn it off Currently my configuration contains this: (modify-services %base-services (guix-service-type config => (guix-configuration (inherit config) (channels #f That is 5 lines instead of single token %base-services just to restore the original non-broken behavior. Would be nice to have guix-extension for this turning it into 2 lines. * Q: Is there an easy way to fill (channels)? After I learned that (channels) is a thing, I wanted to use it, but did not find any simple way how to do so. My channels are in channels.scm produced by `guix describe --format=channels', and I do not see any simple way to pass the content of that file into (channels). No, it does not accept (local-file). I tried just (read)-ing it, but that too does not work. I could steal the code from scripts/pull.scm, but that cannot be the intended way, right? So how should I do this? What procedure did I failed to find? * Q: Is the default value right? Currently it defaults to %default-channels, which causes all this magic. Would it not be better to default to #f, so that it would do nothing magical out of the box and would be backwards compatible? You could still turn it on by (Somehow? See above.) providing desired value. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Backdoor in upstream xz-utils
Hello, On 2024-03-29 13:39:59 -0700, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: > > Is there a way we can blacklist known bad versions? > > Having said all that, I am not sure Guix is affected. > > On my systems, the 'detect.sh' script shows no referece to liblzma in > sshd. Everyone, please send additional reports. If nothing else, our xz is at 5.2.8. I think the question was if there is a way to blacklist specific known tarball to ensure no-one updates to it by accident. (I do not believe Guix would be vulnerable even when built from the malicious tarball, but that is a separate issue.) Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
On 2024-03-18 12:08:48 +, Daniel Littlewood wrote: > Hi everyone, > > I think the discussion so far splits into "should something be done" > and "what can be done". The "should something be done" is easier to > address, I think, so I'll deal with it first. I particularly have > Attila's reply in mind. > > > let's put aside the trans aspect of this question for a moment, > > is it reasonable for me to demand from somebody else to change their memory > > of my past actions? > > if so, then where is the line? what's the principle here? and what are its > > implications? > > i sure see some actors out there who can hardly wait to start erasing > > certain records at the barrel of the law > > I do not doubt that there are bad actors who might misuse the ability > to rewrite history generally. However, this only allows us to dismiss > the technical challenge if there is *no* legitimate use case for > rewriting history, ever, in any circumstance. So rather than removing > the trans aspect of the question to consider every possible use case > (good or bad) of rewriting history, it seems like we only need to come > up with a single case that's sufficient to justify altering someone's > identity, for it to be worth considering if the technical restriction > could be avoided. But then the answer is obvious: Someone might just > sign their commits wrong for whatever reason. Is it valuable for a > user or for guix generally to preserve metadata in the case where a > commit is signed incorrectly? Obviously not. So whether you are > sympathetic to the deadnaming issue or not (personally I am) it seems > like we can dismiss the question "should we do something about it". I do not think the situation is as black and white as you put it here. I believe the question of "should something be done" needs to be further split into two sub-branches. "should something be doable effective from some point in time" and "should something be doable retro-actively". For the former, I think most people here would agree that yes, and there already is a mechanism for that (.mailmap). For the latter, I do not think you can just "dismiss" it. While I agree with you there is a little value in the act of Guix preserving wrong metadata by itself, any history-modifying operation would have quiet large impact on the ecosystem, so that needs to be taken into account as well. And it that light I would say yes, preserving wrong metadata (when viewed from this angle) does have a value. And I say this as a contributor perfectly matching your example of "signed their commits wrong", which is why you will find me in the .mailmap. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Guix role in a free society
On 2024-03-18 18:48:27 +0100, Vivien Kraus wrote: > The guix users, I claim, would rather have a distribution of guix (and > the packages it provides) with accurate personal information, even if > it means to be annoyed for a moment with a security system. Single data point: As a Guix user (and occasional contributor, albeit not a committer), I would very much prefer a system that does not rewrite the history. When someone wants to correct their name (for whatever reason), I would prefer it to be done going forward, not retroactively. I think making such broad statements without some empirical study is not great, since it is, as you said yourself, just your claim not supported by anything (as far as I can tell). Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
On 2024-03-17 12:53:54 +0100, paul wrote: > only a 35 yrs old white cis boy Could you stop labeling people like this? It makes me feel uncomfortable and not welcomed... T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
On 2024-03-17 00:16:26 +0100, Vivien Kraus wrote: > Hello! > > Le samedi 16 mars 2024 à 17:50 +, Christopher Baines a écrit : > > This is probably worth thinking about as Guix is in a similar > > situation > > regarding publishing source code, and people potentially wanting to > > change historical source code both in things Guix packages and Guix > > itself. > > I see two problems: > > 1. providing packages; > 2. developing Guix itself. > > I am sure that 1. is not a real problem, we could just ask the > developer to release a new version incrementing the patch number, > upgrade it on our side, and forget the old version. Garbage collection > would ultimately get rid of the old tarballs. How would that approach interact with `guix time-machine'? If developer takes the approach of the package mentioned here (rewrite the history), would that not cause the previous version to be no longer buildable, since the commit would no longer exist? I am not sure what the developer would do for old tarballs in this situation. Re-release them from the re-written history or just drop them? Either would be a problem. Or would they not care about dead name in the tarballs? Currently SWH protects against the first (git commit), not sure if there is any protection against the second currently (does SWH injects tarballs as well?). Either I am missing something, or this would actually be a problem for the time-machine use case. > 2. is more difficult, because Guix contributors sometimes change their > names too, and a commit reading “update my name” is not the best > solution. If I understand correctly, rewriting the history would be > understood as a “downgrade attack”, contrary to the ftfy case where the > developer could rewrite the history without such consequences. Is my > understanding correct? For my use case using .mailmap was enough, but that was not a dead name situation. However it is a solution that works today, and changes the name visible in most git operations (afaict) without modifying the history. So something to consider. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
On 2024-03-16 12:06:27 -0700, Ian Eure wrote: > > Christopher Baines writes: > > > [[PGP Signed Part:Undecided]] > > > > Ian Eure writes: > > > > > Hi Guixy people, > > > > > > I’d never heard of SWH before I started hacking on Guix last fall, > > > and > > > it struck me as rather a good idea. However, I’ve seen some things > > > lately which have soured me on them. > > > > > > They appear to be using the archive to build LLMs: > > > https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/ > > > > > > I was also distressed to see how poorly they treated a developer who > > > wished to update their name: > > > https://cohost.org/arborelia/post/4968198-the-software-heritag > > > https://cohost.org/arborelia/post/5052044-the-software-heritag > > > > > > GPL’d software I’ve created has been packaged for Guix, which I > > > assume > > > means it’s been included in SWH. While I’m dealing with their (IMO: > > > unethical) opt-out process, I likely also need to stop new copies > > > from > > > being uploaded again in the future. > > > > > > Is there a way to indicate, in a Guix package, that it should > > > *never* > > > be included in SWH? > > > > Not currently, and I don't really see the point in such a mechanism. If > > you really never want them to store your code, then you need to license > > it accordingly (and not make it free software). > > > > I don’t want my code in SWH *because* it’s free. A primary use of LLMs is > laundering freely licensed software into proprietary, commercial projects > through "AI" code completion and generation. Any Free software in an LLM > training set can and will be used in violation of its license, without a > clear path for the author to seek recourse. I deleted my code off Github > and abandoned it completely for this exact reason, and am deeply irked to be > going through this nonsense again. > > A more salient question may be: Is there a process within Guix (either the > program or the organization) which uploads source to SWH? Or does it rely > on SWH indepently? `guix lint PKG-NAME' schedules SWH archival if possible. No code is directly uploaded (at least currently), so assuming you have a IP list of SWH, it should be possible to block it. At least AFAIK. If you have the list, or know how to get it, could you share it? I would be interesting in blocking it as well from my git hosting. > > If the latter, my problem is likely solved by blocking SWH at my network > edge and opting out of their archive (or trying to) and the downstream > training models they’ve already put it in. If the former, the only control > I currently have to protect my license is removing packages from Guix which > contain it. I don’t want that outcome. > > Noting also that the path here seems to be SWH->huggingface->bigcode > training set, and the opt-out process for the training set appears to be a > complete sham. To opt-out, you must create a Github Issue; only one opt-out > has *ever* been processed, and there are 200+ sitting there, many with no > response for nearly a year[1]. I want no part of any of this. > > > > > Is there a way to tell Guix to never download source from SWH? > > > > Also no, and it's probably best to do this at the network level on your > > systems/network if you want this to be the case. > > > > I’ll investigate this, though I’d prefer if there was a way to configure > source mirrors in the Guix daemon. > > > > Skipping back to this though: > > > > > I was also distressed to see how poorly they treated a developer who > > > wished to update their name: > > > https://cohost.org/arborelia/post/4968198-the-software-heritag > > > https://cohost.org/arborelia/post/5052044-the-software-heritag > > > > This is probably worth thinking about as Guix is in a similar situation > > regarding publishing source code, and people potentially wanting to > > change historical source code both in things Guix packages and Guix > > itself. > > > > Like Software Heritage, there's cryptographical implications for > > rewriting the Git history and modifying source tarballs or nars that > > contain source code. > > > > We have 17TiB of compressed source code and built software stored for > > bordeaux.guix.gnu.org now and we should probably work out how to handle > > people asking for things to be removed or changed (for any and all > > reasons). > > > > It's probably worth working out our position on this in advance of > > someone asking. > > > > Yes, I agree that Guix needs a better solution for this. > > Thanks, > > — Ian > > [1]: https://github.com/bigcode-project/opt-out-v2/issues > T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
On 2024-03-16 20:24:50 +0200, MSavoritias wrote: > > > I was also distressed to see how poorly they treated a developer who > > > wished to update their name: > > > https://cohost.org/arborelia/post/4968198-the-software-heritag > > > https://cohost.org/arborelia/post/5052044-the-software-heritag > > This is probably worth thinking about as Guix is in a similar situation > > regarding publishing source code, and people potentially wanting to > > change historical source code both in things Guix packages and Guix > > itself. > > > > Like Software Heritage, there's cryptographical implications for > > rewriting the Git history and modifying source tarballs or nars that > > contain source code. > > > > We have 17TiB of compressed source code and built software stored for > > bordeaux.guix.gnu.org now and we should probably work out how to handle > > people asking for things to be removed or changed (for any and all > > reasons). > > > > It's probably worth working out our position on this in advance of > > someone asking. > > I would go a step further actually. Software Heritage is effectively > breaking CoC of Guix now. > > Im not proposing removing all code or something obviously that connects to > Software Heritage, but there should be some social action we can take. > > > For example until the matter is resolved and Software Heritage implements a > process that respects trans rights Software Heritage should not be welcome > in Guix Spaces. I did skim the articles and I did not see any details on what the technical solution should be. SWH, among other things, archives the repositories and allows fetching them by commit hash. At least as far as I know. Since that commit hash does contain the author field, what is the proposed solution here to change the author name without changing the commit hash? While I am not a huge fan of the ability to map the "fake" author name over the real one in the UI, what other solutions do you or the article author envision? I am genuinely curious what you think can be done here. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: You're invited to the first patch review session!
On 2024-03-06 11:36:29 +, Etienne B. Roesch wrote: > That's the link I have https://meet.jit.si/london-guix-meetup Great, thank you very much, looking forward to tomorrow. :) Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: You're invited to the first patch review session!
Hi, On 2024-03-06 10:40:14 +0100, Andreas Enge wrote: > > Looking forward to tomorrow, > I would just like to point out that the link to the jitsi meeting is not on the wiki page and was not shared here neither (for those of us who have issues with meetup.com). I think it was said before the link would be shared somewhere, so please take this as a reminder (since it is tomorrow already). Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: You're invited to the first patch review session!
On 2024-02-22 23:27:31 +, Steve George wrote: > Hi > > We're going to run some online patch review sessions. The first one is on > *Thursday, 7th March* and you can sign-up here: > > https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 > > The background is that Guix has many fantastic contributions that are waiting > to be reviewed and added to the archive. We have the QA system that does test > builds, but each patch also needs to be evaluated and checked. Anyone can > review patches, and reviews help to confirm that a patch is in good shape to > be added to the archive. > > Doing patch reviews is also a great way to learn about Guix, the different > packages and methods involved in packaging. To encourage new reviewers to > step forward, and to have some fun we're going to run on-line patch review > sessions. These will be informal, probably chaotic - but fun - with the aim > that we learn as a group how to review packages. > > Each session will be hour 1:30 and they are rotating through the week, so > there should be plenty of opportunities to come along. We're using the Guix > London's Meet-up and the sessions run on Jitsi. Will the Jitsi link be shared somewhere (here, irc, ...) for those of us who are not able to sign up on the page? I am getting this error: > Your IP address has been flagged as a source of spam and is blocked from > Meetup. Since meetup.com is a commercial, third-party service, I assume there is not anything you can do about that, so I am curious if there are any alternatives how to get into the review session. Thank you and have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: On the road to the next release: testing the installer
On 2024-02-10 11:43:33 +0100, Vivien Kraus wrote: > Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit : > > Grub asked me right away my passphrase and… it did not work! > > After several attempts, I figured out that the keyboard layout > > was apparently set to `qwerty` even though I had selected `bépo > > AFNOR` > > during the configuration. When I eventually typed my passphrase > > in `querty` Grub started and boot my system and… I had to type the > > passphrase a second time, but, fortunately this time in `bépo`! > > I checked the `config.scm` and the layout was properly set in the > > bootloader declaration. > This is unfortunate, but a known workaround is to boot and log in, then > run cryptsetup luksAddKey , then enter your passphrase (to > unlock the drive), then switch your keyboard layout to qwerty, then hit > the exact same keys, and confirm by hitting the exact same keys. So > now, you can unlock the drive with either your passphrase in a bépo > layout or your passphrase in a qwerty layout. > It would probably make sense to have the second (qwerty) password in the first key slot, to make the unlocking faster. Or, just use the key file unlock and enter password just once (albeit it would be the qwerty one). Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
On 2024-02-06 13:09:15 +0100, Clément Lassieur wrote: > Hi! Why is it more complicated with services? You don't need forks at > all to use packages and services outside of Guix proper. For packages we have transformations, or I can just inherit. But I am not aware of such option for services (is there anything?). Example: For long time the connman-configuration did not support a way to provide a configuration file (well, it still does not but that is not the point). But I needed it. So, what options I had? 1. Copy the definition (-configuration, -service-type, ...?) into my system configuration and modify it. 2. Modify it in-place in my fork. I tried 1. first, but keeping it up-to-date proved annoying, having zero support from git. Since I already made my fork (due to #65002, which just is not possible to do outside Guix repository), I later switched to 2. and it worked well, so I prefer that approach now. I agree there is no issue for new packages nor new services, I should have clarified that in my original message. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote: > Guix offers ways to use packages outside of Guix proper in a pretty feasible > and maintainable way (manifests, setting up channels), maybe promoting them as > an alternative to having things in guix proper "as soon as possible" (as > that's not the only option to have things in a usable form) would be > beneficial. I would just like to point out that while this applies to packages, it is bit more complicated for services and other core parts of the Guix. Combined with the fact that Guix severely restricts what workflow model can forks use (e.g. merge not being possible if the fork should be authenticated), maintaining non-package modifications for longer periods of time can be a hassle. So it could be beneficial to put some though into that as well. Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
On 2024-02-05 09:07:05 -0500, Leo Famulari wrote: > However, I think the question assumes that all contributions should be > accepted, and that the entire problem is that we are not accepting them > efficiently enough. We should not unconsciously accept this assumption. > > Guix can reject contributions, either in a general way (we don't want that > type of thing in Guix), or due to specific reasons (the code is not > idiomatic, the contributor can't work effectively with the rest of the group, > etc). And I believe that is fine and completely within the rights of the committers. However, in my experience contributing, the issue is not that people explicitly tell me to go away, but that the patches are just ignored. I would say that the outcome (for any specific patch) from the proposed "review session" can very well be patch just being closed, or tagged as "need-more-work" (or whatever tag is Guix using). In ideal world, there would always be *some* reaction from the project, even if that reaction would be "we do not want this change". Even if it would be just an auto-close (for the "contributor can't work effectively..." case). Or, to put it in a different way: The problem is not that too few patches get merged. The problem is that too few patches get reviewed. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Symlinks in "guix pack" and "guix shell"
On 2024-01-29 10:30:21 +0100, Konrad Hinsen wrote: > Dear Guix experts, > > I am seeing inconsistent behavior with the creation of symbolic links > in containers and exports, and I wonder whether this is a bug or missing > documentation. > > According to the documentation, there are no constraints on what I can > link to. In practice, some symbolic link requests have no effect, but > there is no error message either. That is interesting, at least in the guix shell case, I do get an error: $ guix shell -S /etc/ssl=etc/ssl -C bash coreutils -- ls -l /etc Backtrace: In guix/ui.scm: 2287:10 19 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 18 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 674:3 17 (guix-environment* _) In ice-9/boot-9.scm: 1752:10 16 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 661:37 15 (thunk) 1300:8 14 (call-with-build-handler _ _) 1300:8 13 (call-with-build-handler # …) In guix/status.scm: 839:4 12 (call-with-status-report _ _) In guix/scripts/environment.scm: 1162:11 11 (_) In guix/store.scm: 2180:25 10 (run-with-store # …) In guix/scripts/environment.scm: 873:8 9 (_ _) In gnu/build/linux-container.scm: 397:16 8 (call-with-container (#< device: "none…> …) …) 265:16 7 (run-container _ _ (cgroup mnt pid ipc uts user net) _ # …) In guix/scripts/environment.scm: 903:14 6 (_) In srfi/srfi-1.scm: 634:9 5 (for-each # …) In ice-9/boot-9.scm: 1747:15 4 (with-exception-handler # …) 1747:15 3 (with-exception-handler # …) In gnu/build/install.scm: 108:23 2 (_) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: symlink `.//etc/ssl' points to nonexistent file `/gnu/store/kxvplpa4c0xf5pap6br8abip2bq9f0p8-profile/etc/ssl' > > Example: I am trying to tell programs in a container to use the > certificates from package nss-certs, instead of requiring the user > to share /etc/ssl from the host machine. So I add > >-S /etc/ssl=etc/ssl > > to my command lines for "guix shell -C" and "guix pack" (for creating > Docker or Singularity images. > > Sometimes this works, sometimes it doesn't. With "guix shell", I never > got it to work. With "guix pack", the observed behavior is random. > Adding a completely unrelated package to my container can make the > difference. I think the relevant part is whether some certificate package is installed (via propagated inputs) or not. If I explicitly add nss-certs to the command above, it starts to work: $ guix shell -S /etc/ssl=etc/ssl -C bash coreutils nss-certs -- ls -l /etc total 12 -rw-r--r-- 1 wolf users 32 Jan 29 11:14 group -rw--- 1 wolf users 20 Jan 29 11:14 hosts -rw-r--r-- 1 wolf users 92 Jan 29 11:14 passwd lrwxrwxrwx 1 wolf users 59 Jan 29 11:14 ssl -> /gnu/store/s0mdc10pkb9kcmnzjfywax1d42rm4car-profile/etc/ssl Could you please share some examples where you get no error, but it has no effect? Maybe they really are bugs (and should be reported). Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: How to always keep build tree when run guix build.
On 2024-01-17 16:21:05 +0800, Adam Faiz wrote: > Hello, > > > Hello: > > > > How to always keep build tree when run guix build, at the moment, I > > use --keep-failed, but it will remove build tree when build success, the > > problem is that build success alway not right build success :-), I need > > go to build tree to check some thing. > > > > Thanks! > > > > > > -- > > You can add the `--cache-failures` option when starting the guix-daemon, > which tells it to keep the build failures by default. > It's explained in more detail in the "Invoking guix-daemon" section of the > Guix manual: > https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix_002ddaemon.html > I think the question was how to keep all build trees, including the build trees from successful builds. Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Golang check phase skipping some tests?
On 2024-01-14 22:12:38 +0100, Troy Figiel wrote: > Hi everyone, > > When looking into the Go build system, I noticed the default check phase > runs (invoke "go" "test" import-path), which only runs the tests in the > root directory of the source. Running the tests in all subdirectories > would require something like this instead: > > --8<---cut here---start->8--- > (define* (check #:key tests? import-path #:allow-other-keys) > "Run the tests for the package named by IMPORT-PATH." > (when tests? > (invoke "go" "test" (string-append import-path "/..."))) > #t) > --8<---cut here---end--->8--- > > For example, if the -v flag is added (which might be a better default?) > to the check phase of go-github-stretchr-testify, it can be seen that > only `TestImports' runs, none of the tests in assert, http, etc. > However, the source code in these subdirectories is still recursively > copied to out during the install phase. > > Is this desired behaviour? I assumed it isn't, because it looks like we > are skipping a lot of tests during the check phase. However, I might > also simply be overlooking something here as I am new to packaging > Golang with Guix. I tend to agree (on both accounts). I am not aware of anything Guix specific here that would prevent it, but maybe someone from golang team will chime in. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Module unavailable on build side
Hi, On 2024-01-13 20:12:38 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: > Hi, > > How may I make code from a channel available inside 'modify-phases', > please? > > I tried #:modules, but it says "no code for (x y z)." Thanks! Based on some quick experimentation `source-module-closure' seems to be the way. Package definition importing a (nonguix licenses) module follows: (use-modules (guix build-system gnu) (guix gexp) (guix modules) (guix packages) (nongnu packages linux)) (package (name "test") (version "1") (source #f) (build-system gnu-build-system) (arguments (list #:imported-modules (source-module-closure `((nonguix licenses) ,@%gnu-build-system-modules) #:select? (λ (m) (or (guix-module-name? m) (eq? (car m) 'nonguix #:phases #~(modify-phases %standard-phases (add-before 'unpack 'foo (λ _ (use-modules (nonguix licenses)) (error nonfree)) (home-page #f) (synopsis #f) (description #f) (license #f)) This does "build" resulting in the expected error: ice-9/boot-9.scm:1685:16: In procedure raise-exception: # However it took me a while to find a module that actually works. Due to the web of dependencies, it can get complex quickly and you would need to properly manage the #:select? value. Just putting (const #t) in there sadly does not work. Not sure, maybe there is a better way. If there is, I hope someone will tell me (us). In the mean time, I hope this helps to some degree. Have a nice day, Tomas Volf PS: My understanding it that #:modules is equivalent to (use-modules), that is why I used #:imported-modules to add them into the build environment first. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
When is check-system run?
Hello, I would like to inquire regarding system tests. There is check-system make target, however it seems like at least some of them are broken. Can someone check whether that is case even on their machine? Do they all pass for you? I already have patches fixing 4 of them, and debugging 5th, but I would like to ask when exactly are the those tests run and where are the failures reported to? Since the breakage sneaked into the master, I assume they are not run as part of the regular patches? Are there any measures the project is planning to take to prevent this from happening again? Thank you and have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: GNU Shepherd 0.10.3 released
On 2024-01-11 13:41:39 +0100, Ludovic Courtès wrote: > Tomas Volf <~@wolfsden.cz> skribis: > > > Otherwise the shepherd would be stuck on shutdown waiting for process named > > > > [mt76-tx phy0] > > > > to terminate with messages along the lines of: > > > > shepherd[1]: waiting for process termination (processes left: (1 678)) > > > > It is a kernel thread as far as I can tell (based on > > https://stackoverflow.com/a/12231039): > > > > $ cd /proc/678 > > $ cat cmdline > > $ readlink exe; echo $? > > 1 > > > > Removing the module mt7921e stops the thread, so shepherd does not wait for > > it. > > Ooooh. > > Then I’m afraid this bug isn’t fixed yet because that code (“waiting for > process termination”) is currently in Guix, not in Shepherd. > > However, ‘processes’, which is what is used here and which is defined in > (guix build syscalls), already checks for kernel threads, though it > does it differently than what I implemented in shepherd: > > (define (kernel? pid) > "Return #t if PID designates a \"kernel thread\" rather than a normal > user-land process." > (let ((stat (call-with-input-file (format #f "/proc/~a/stat" pid) > (compose string-tokenize read-string > ;; See proc.txt in Linux's documentation for the list of fields. > (match stat > ((pid tcomm state ppid pgrp sid tty_nr tty_pgrp flags min_flt > cmin_flt maj_flt cmaj_flt utime stime cutime cstime > priority nice num_thread it_real_value start_time > vsize rss rsslim > (= string->number start_code) (= string->number end_code) _ ...) > ;; Got this obscure trick from sysvinit's 'killall5' program. > (and (zero? start_code) (zero? end_code)) > > It would be great if you could check whether this approach works for > you. Ah, that code indeed returns #f for the pid in question: scheme@(guix-user)> ((@@ (guix build syscalls) kernel?) 688) $1 = #f The stat file: $ cat /proc/688/stat 688 (mt76-tx phy0) S 2 0 0 0 -1 2129984 0 0 0 0 0 0 0 0 -2 0 1 0 964 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 5 1 1 0 0 0 0 0 0 0 0 0 0 0 So the start_code is not zero (I would guess it is -1). I have no idea what that means though. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: How/where/when to ask for a patch review?
On 2024-01-10 00:33:11 +0100, Ludovic Courtès wrote: > Hi again Tomas, > > Tomas Volf <~@wolfsden.cz> skribis: > > > What I tried so far: > > > > 1) Asking on the IRC (2x). Once I even got a review, but from a > > non-committer. > > 2) Sending email directly to the main author of the edited source file. No > >response. > > > > Technically I even mentioned it to the main author directly in person, but > > it > > was at a conference, so I can hardly blame them for it just slipping by. :) > > Uh, I think I’m the guilty party, my sincere apologies! Do not worry about it! I will not pretend it is not a bit frustrating to have patches just sit there, but I do realize how busy your are and much you do already. I do appreciate all the work you do on Guix and around it. It is unavoidable that some things just slip through. > > I have to admit I have a hard time keeping up. I review tons of > patches, but I also like to do stuff by myself, which means I tend to > select “easy” patches. > > As a project, the ratio of available reviewer time to incoming patches > remains chronically small. I feel like there are more people reviewing > and pushing patches these days, but there’s also more patches coming > in—a good problem to have, but certainly also a source of frustration. I do not propose any magical solution, because I do not have one. :) Let's hope it keeps getting better. > > The good news is that I’ve now reviewed > <https://issues.guix.gnu.org/65002> and it looks almost ready to me. So > perhaps you’ll have to ping me or some other committer one last time, > but I encourage you to not give up, not so close to the finish line. Thank you very much for the review, I will send the next revision sometime this week. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: GNU Shepherd 0.10.3 released
PS: On 2024-01-10 17:38:17 +0100, Tomas Volf wrote: > scheme@(guile-user)> ((@@ (shepherd service) pseudo-process?) 688) The pid is different than above, because this was after a reboot. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: #:modules and #:imported-modules, and more
On 2024-01-10 11:23:22 +0100, Ludovic Courtès wrote: > Hi! > > Tomas Volf <~@wolfsden.cz> skribis: > > > However even in that light, I still consider the 3 and 4 to be worth > > considering. Aaand even without 3, at least doing 4 in some shape or form > > would > > be in my opinion useful. Current situation is bit... copy > > In ‘core-updates’, commit 9e4ce281dbd92e3c52b831824ebb1f77023c960c by > Maxim should address these concerns (IIUC) by distinguishing and > renaming the variables for the default set of imported and in-scope > modules for ‘gnu-build-system’. > > Is that one of the things you had in mind? Ah, yes, thank you for pointing that commit out, pretty much that, just for all the build systems (it seems only gnu-build-system was modified on core-updates). Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: GNU Shepherd 0.10.3 released
On 2024-01-10 00:34:48 +0100, Ludovic Courtès wrote: > Tomas Volf <~@wolfsden.cz> skribis: > > > On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote: > > [...] > > >> ** Do not accidentally wait for Linux kernel thread completion > >> (<https://issues.guix.gnu.org/67132>) > >> > >> In cases a PID file contained a bogus PID or one that’s only valid in a > >> separate PID namespace, shepherd could end up waiting for the > >> termination of > >> what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”). This > >> situation is now recognized and avoided. > > > > This is great, I will not have to remember to run `modprobe -r mt7921e' > > before > > each shutdown anymore. I hope. Looking forward to getting it in the Guix > > :) > > D’oh, why did you have to do that? Otherwise the shepherd would be stuck on shutdown waiting for process named [mt76-tx phy0] to terminate with messages along the lines of: shepherd[1]: waiting for process termination (processes left: (1 678)) It is a kernel thread as far as I can tell (based on https://stackoverflow.com/a/12231039): $ cd /proc/678 $ cat cmdline $ readlink exe; echo $? 1 Removing the module mt7921e stops the thread, so shepherd does not wait for it. > How did Shepherd end up with “wrong” PID? That I do not know. It is visible in `ps' output, so I assume shepherd picked it up on its own somehow. > > I hope this release fixes it! As far as I can tell, the 0.10.3 was already added into guix: $ ps 1 | cat PID TTY STAT TIME COMMAND 1 ?Sl 0:01 /gnu/store/bhynhk0c6ssq3fqqc59fvhxjzwywsjbb-guile-3.0.9/bin/guile --no-auto-compile /gnu/store/06mz0yjkghi7r6d7lmhvv7gryipljhdd-shepherd-0.10.3/bin/shepherd --config /gnu/store/klkqq2y65k141rlipq4ls0w2rlhds12h-shepherd.conf So I have to say it sadly did not resolve this issue. I am unsure why though. I am not familiar with Shepherd's code base, but quick look at the git log suggested that procedure (@@ (shepherd service) pseudo-process?) is the relevant one. When I try it from a REPL, it returns #t. $ guix shell guile shepherd guile-fibers -- guile GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> ,use (shepherd service) scheme@(guile-user)> ((@@ (shepherd service) pseudo-process?) 688) $1 = #t So it *should* work? However the issue is caused by non-free WiFi driver on a corrupted kernel, so I am not sure if it is even problem that needs to be solved... I would (obviously) like to see it resolved, but I probably cannot even bug report it, since it requires non-free hardware and software to reproduce. Tomas PS: It is interesting that `guix shell guile shepherd' is not enough, the guile-fibers have to be explicitly specified as well. Is that expected? -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: #:modules and #:imported-modules, and more
On 2024-01-09 23:49:33 +0100, Ludovic Courtès wrote: > Hello! > > Tomas Volf <~@wolfsden.cz> skribis: > > > As seen in the example above, currently there is a need to manually > > merge the list of additional modules with the original one. Failing > > to use the correct base can lead to issues (like crash in netsurf). > > > > I would like to propose adding two new fields into the build system, > > `#:extra-modules' and `#:extra-imported-modules'. Those would be > > automatically appended to the `#:modules' and `#:imported-modules', > > removing the need to merge the lists in the package definition. > > Therefore the example above would turn into: > > As a rule of thumb, I personally always avoid the #:extra-things > pattern, instead letting users pass #:things in their entirety and > documenting the default value. > > I believe (1) this is clearer (when I see “extra”, I’m always like “extra > compared to what?”), and (2) it gives more control over the things in > question (since one can also remove stuff from the default value). Well you could still remove the default stuff, since the "non-extra" would not be going anywhere. > > So yes, that’s a bit more boilerplate when all you want is import one > additional module, but I think it’s overall a better interface than > #:extra. > > I hope this makes sense! I see your point. Not sure I fully agree, but do understand what you mean and will not push on it further. However even in that light, I still consider the 3 and 4 to be worth considering. Aaand even without 3, at least doing 4 in some shape or form would be in my opinion useful. Current situation is bit... copy Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: GNU Shepherd 0.10.3 released
On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote: > We are pleased to announce the GNU Shepherd version 0.10.3, a bug-fix > release of the new 0.10.x series, representing 51 commits over 6 months. Congratulations on the release :) > > ** Do not accidentally wait for Linux kernel thread completion > (<https://issues.guix.gnu.org/67132>) > > In cases a PID file contained a bogus PID or one that’s only valid in a > separate PID namespace, shepherd could end up waiting for the termination of > what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”). This > situation is now recognized and avoided. This is great, I will not have to remember to run `modprobe -r mt7921e' before each shutdown anymore. I hope. Looking forward to getting it in the Guix :) Have a nice 2024, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
How/where/when to ask for a patch review?
Hello Guix, I would like to inquire what is the proper channel to ask for a patch review and how long should one wait before doing so. Bit of backstory: At the beginning of the August 2023 I sent a patch to the mailing list. However it had no interaction at all (well, one user tried it and deemed it working and useful). So I am unsure what to do about it and how to push it forward. What I tried so far: 1) Asking on the IRC (2x). Once I even got a review, but from a non-committer. 2) Sending email directly to the main author of the edited source file. No response. Technically I even mentioned it to the main author directly in person, but it was at a conference, so I can hardly blame them for it just slipping by. :) Just to be completely clear, I do not feel entitled to a review. If there is no interest (from Guix), that is fine and within your rights. But I realized there is a mistake in the patch (code is fine, commit message is off), and before I spent more time on it, I would like to know if it even makes sense to send v2. I assume it will just sit in the same void, therefore this inquiry. Thank you and have a nice 2024, Tomas Volf PS: This patch being ignored was the last push I needed to start my personal fork, so technically I should be grateful I guess, but still, I would like to diverge as little as possible. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: home-syncthing-service-type wants /root paths, yet syncthing can work
Hi, On 2024-01-05 15:05:38 +0100, Sébastien Lerique wrote: > Hi Guix! And dear helpers and devs, > > I'm running into a weird failure of home-syncthing-service-type. > > Running syncthing manually from the terminal works fine (here's an example > log: <https://pastebin.com/1dLMKkyK>). > > So I Ctrl-C syncthing, then add home-syncthing-service-type to my > home-configuration > <https://gitlab.com/wehlutyk/guix-config/-/blob/master/home-configuration.scm> > (bottom lines). > > After restarting, home-syncthing-service-type fails synchronizing because it > bases all user folders inside /root, to which it doesn't have writing > rights. This happens whether all syncthing configurations in > `.local/state/syncthing` had been removed in the meantime or not. Here's a > log: <https://pastebin.com/14LwbvRn> > > Could this be a bug? A mistake in the configuration files? After some digging in the source code, I managed to pinpoint the cause. Your configuration does not set user nor home, which causes Guix to call (getpw #f). That returns the root user. I would say this is a bug. The code probably should be something like this (untested): (or #$home (passwd:dir (getpw (if (and #$home-service? (not #$user)) (getuid) #$user For your immediate problem, explicitly setting the (home) field in the syncthing-configuration should help. I think. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Why is it acceptable to have digital-ocean-configuration in the Guix?
On 2024-01-04 14:22:48 -0500, Thompson, David wrote: > On Thu, Jan 4, 2024 at 5:34 AM Tomas Volf <~@wolfsden.cz> wrote: > > > > Greetings, > > > > I would like to inquire regarding digital-ocean-configuration type used for > > provisioning DigitalOcean Droplets. I do not understand why it is > > acceptable to > > have this type in the source code. Reading the Free GNU/Linux distributions > > criteria[0] I see this sentence (emphasis mine): > > > > > This means they will include, and *propose*, exclusively free software. > > > > As far as I know DigitalOcean Droplets are not free software (please > > correct me > > if I am wrong). I contemplated on this for a bit, and I do not understand > > why > > it is acceptable. > > > > Would someone be so kind to explain the reason to me? > > Perhaps this will help explain why you can't simply call a web service > nonfree: > https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.en.html Ah, thank you very much for the link. Interesting reading. One consequence I did not (until now) realize is that I could (in theory) implement a Free GNU/Linux distribution that would be tied into various APIs of (for example) AWS and require it to run. And, based on my reading, it would still qualify to be on the list. That is unexpected. > > To use a different example: Google doesn't publish the source code for > YouTube. Guix includes the free software yt-dlp program that can talk > to YouTube and download videos. Would you consider this a violation of > the FSDG? > > Guix also downloads a lot of source code from GitHub. Is this an issue? I did not consider these examples, because it did not even occur to me that it *could* be an issue. I guess the perceived difference came from the Droplets having their own dedicated place in the manual including their own type. My takeaway from this is that when I get around to implementing this for AWS and/or Azure, I can submit the patch. Thank you again and have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: How to answer all people in a thread?
On 2024-01-04 08:27:53 +0100, Christian Miller wrote: > Hello, > > I created this thread[0]. Now instead of answering each individual > person, I want to answer all to say thanks. The structure would > probably look like this in that case. > > > Questions about packages because of license and other, Christian Miller <= > Re: Questions about packages because of license and other, Andreas > Enge, 2023/12/06 > Re: Questions about packages because of license and other, Felix > Lechner, 2023/12/06 > Re: Questions about packages because of license and other, Ada > Stevenson, 2023/12/07 > Questions about packages because of license and other, Christian Miller, > 2024/01/04 > > Would I just write to "guix-devel@gnu.org" with the subject "Questions > about packages because of license and other" and Cc all people? I do not think creating a new, completely separate thread is ideal. I would, in your place, just respond to my own top-level message > Questions about packages because of license and other, Christian Miller <= thanking all the people in it. That would create Re: ..., properly putting it into the (already existing) thread. There might however be a different custom over here, so I am looking forward to what other people have to say about this. > > I use Emacs Rmail if anyone uses the same tool as well. > > [0] https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00022.html > -- > Christian Miller > Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Why is it acceptable to have digital-ocean-configuration in the Guix?
Greetings, I would like to inquire regarding digital-ocean-configuration type used for provisioning DigitalOcean Droplets. I do not understand why it is acceptable to have this type in the source code. Reading the Free GNU/Linux distributions criteria[0] I see this sentence (emphasis mine): > This means they will include, and *propose*, exclusively free software. As far as I know DigitalOcean Droplets are not free software (please correct me if I am wrong). I contemplated on this for a bit, and I do not understand why it is acceptable. Would someone be so kind to explain the reason to me? Thank you and have a nice day, Tomas Volf 0: https://www.gnu.org/distros/free-distros.html -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
#:modules and #:imported-modules, and more
Hello Guix. Table of Contents _ 1. My understanding 2. #:extra-modules, #:extra-imported-modules 3. %...-build-system-modules 4. %default-modules 5. Other comments .. 1. What are the reasons for the naming scheme of build systems? 6. Conclusion 1 My understanding == In the process of fixing crashes of libreoffice and netsurf (patches coming soon), I was trying to understand the difference between #:modules and #:imported-modules. My conclusion is that the former are modules that are (use-modules)-ed automatically, while the latter are modules that are made available and can be (use-modules)-ed if desired. If one wants to add some modules, the way it is done, for gnu-build-system, is like this: , | #:imported-modules `((some module) | ,@gnu-build-system-modules) ` Is that summary correct? Assuming it is, I would like to propose few changes. I am willing to supply the implementation(s), but thought I should discuss it first in order not to waste time if it would be a no-go. They would be done in roughly this order over multiple patch series to allow smooth transition. 2 #:extra-modules, #:extra-imported-modules === As seen in the example above, currently there is a need to manually merge the list of additional modules with the original one. Failing to use the correct base can lead to issues (like crash in netsurf). I would like to propose adding two new fields into the build system, `#:extra-modules' and `#:extra-imported-modules'. Those would be automatically appended to the `#:modules' and `#:imported-modules', removing the need to merge the lists in the package definition. Therefore the example above would turn into: , | #:extra-imported-modules '((some module)) ` The original fields would still be available, so full control would be possible, if needed. There currently seems to be ~276 occurrences of `-build-system-modules' in the gnu/packages directory, and vast majority of them would be removed. 3 %...-build-system-modules === This variable seems misnamed, since it should be used with `#:imported-modules', so once the above is done (and the usage of it drops down), I would like to rename it to `%...-build-system-imported-modules'. 4 %default-modules == Situation with `#:modules' is more interesting, since there is no common pattern. Some build systems have `%default-modules' (non-exported), some just hard-code the list. In the step above the binding was released, so I would like to unify the build systems by reusing as public `%...-build-system-modules', which would be used as default for `#:modules' in all build systems. These steps are somewhat independent, but at least this last one I would think would be useful. Albeit without the previous ones different name would have to be used. 5 Other comments 5.1 What are the reasons for the naming scheme of build systems? It seems that all the build systems use a prefix-based naming scheme, so `gnu-build-system', `meson-build-system' and such. I am curious what is the reason for that? Since Guile modules support `#:prefix', would it not be a cleaner choice? So I could have something like: , | (define-module (gnu packages foo) | #:use-module ((guix build-system gnu)#:prefix gnu) | #:use-module ((guix build-system python) #:prefix python)) | ...) | | (define-public bar | (package | ... | (build-system gnu:build-system))) | | (define-public baz | (package | ... | (build-system python:build-system))) ` That, given there is a built-in support in the language, seems somewhat cleaner. And could possibly make introspection easier (maybe?). Could someone enlighten me regarding the reasons for the current implementation? 6 Conclusion Thank you for considering this proposal, and thank you in advance for any helpful insight you are willing to provide. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: --allow-downgrades
On 2023-12-11 20:35:27 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: > Hi, > > I have my own copy of Guix in order to hack on features. I 'pull' with > the option '--allow-downgrades'. > > After that, 'deploy' does not require it again, but 'home reconfigure' > does. Is that consistent? > > Also, would 'system reconfigure' require the option again? Thanks! If memory serves right, both home and system reconfigure do require the argument. So at least those two are consistent. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Should commits rather be buildable or small
On 2023-12-08 10:42:07 +0200, Saku Laesvuori wrote: > Hi, > > I'm planning on refreshing Guix's haskell packages as my fix for > https://issues.guix.gnu.org/66347 requires rebuilding all of them > anyway. Should I try to keep commits small with only one update per > commit (which is more work but managable if I don't care about the > commits being buildable) or should I try to keep them buildable (i.e. > update everything in one commit)? It is quite certain that most of them > will not build after updating ghc or a subset of their dependencies, so > making many small commits would cause nearly all of them to be > unbuildable. If for not other reason then to make git history bisectable, I think each commit should be buildable. But this is just a opinion from the peanut gallery. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: [maintenance] Compressed JSON files and served file extension?
On 2023-11-28 14:48:05 +0100, Simon Tournier wrote: > Hi Ludo, > > On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès wrote: > > > That said, if you become aware of actual breakage, we can revisit this! > > The actual breakage is my own interaction with this file. :-) > > Again, it happened to me yesterday. By habits, I do: > > $ wget https://guix.gnu.org/sources.json > $ cat sources.json | jq | head > > Then, > > --8<---cut here---start->8--- > parse error: Invalid numeric literal at line 1, column 16 > cat: write error: Broken pipe > --8<---cut here---end--->8--- > > Well, we are 6 days later my last message, 12 days after your message > and more than one month after my report; and again the same mistake. > That’s mistake because it does not jump to my eyes that the file is > compressed. Yeah, I could do many on my side as change my habits, as > use curl, as have a smarter cat, as write a note, as have a better > memory, as … > > However, the simplest still appears to me to have the extension > reflecting the format of the file. Similarly as it is ’sources.json’ > and not just ’sources’. But the problem is that the extension does reflect the format of the file. The Content-Encoding is just for transmission, it does not describe the file itself. It should be thought of as an implementation detail. Same way you do not really care if you get the file over HTTP 1.1 or HTTP 2.0. This just sound like a bug in wget, I wonder if there is a bug report and/or good reason to behave like this... Would it be possible to provide both files? Sources.json.gz would *not* set the content-encoding (and I guess content-type would be gzip?), so that one could pick between https://guix.gnu.org/sources.json and https://guix.gnu.org/sources.json.gz depending on their preference? Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: [maintenance] Compressed JSON files and served file extension?
On 2023-11-28 14:37:55 +0100, Simon Tournier wrote:
> Hi,
>
> On Mon, 20 Nov 2023 at 14:03, Attila Lendvai wrote:
>
> > TL;DR the filename shouldn't contain the .gz extension, and the HTTP
> > standard is crap ("If no Accept-Encoding field is present in a
> > request, the server MAY assume that the client will accept any content
> > coding.").
> >
> > use curl --compressed
>
> And if I do not want to use curl but instead another tool as wget? :-)
You could invoke the wget with -E flag I guess.
>
> Cheers,
> simon
>
>
>
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
Re: Better support remote deployment
On 2023-11-16 16:23:00 +0100, Ludovic Courtès wrote: > Hi, > > Maxim Cournoyer skribis: > > > Felix Lechner writes: > > [...] > > >> How about a 'remote-user-profile'? > > > > 'guix package' is already the command we use to create profiles; maybe > > it could accept a '--remote' argument to operate on a remote machine? > > Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package > > -m manifest.scm' can already accomplish? :-) > > Doing that confuses ‘guix package’ because it’d try to perform the > effectful part (switching symlinks) locally, even though everything was > built on another machine. (It’s also slow due to RPC round trips, as > Efraim wrote.) > > But yeah, I think we could do something along these lines by isolating > the effectful bits and evaluating them remotely when needed, like we did > to achieve code sharing between ‘guix deploy’ and ‘guix system > reconfigure’. > > That said, I wonder if this would really be more convenient than SSH’ing > into the target machine and running the commands right there. Perhaps > I’m missing something about the use case? I was following the debate, but maybe I have missed something, so I will put forward my use case as well. I have two properties I would like to have from a "remote deploy" mechanism, and they are not satisfied by SSH-ing to the machine and running the commands there. 1. No need for `guix pull'. I run (a little) custom Guix, so running `guix pull' is somewhat expensive. I do not want to do it just to deploy something (be it a system, or home, or profile). 2. No need to copy over the definitions. My configurations are part of a git repository, which I would like to keep local to just my development machine. So rsync-ing it over to the remote machine in order to run command there is something I would like to avoid. If, however, I can build a profile locally, `guix copy' it over, and *then* SSH into the machine and somehow activate the profile (be it home or regular profile), that would work for me. Is that currently possible? > > Ludo’. > Thanks, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Recommended way of packaging web themes
On 2023-11-08 15:44:46 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: > Hi Felipe, > > On Wed, Nov 08 2023, Luis Felipe wrote: > > > I'm looking into packaging the current Guix's website theme > > [...] I think it would be easier for other > > Guix websites and services (e.g. CI, QA, DATA) to use them and hopefully > > achieve a more uniform look and feel for the network of Guix web fronts. > > Could you simply publish the resources online (except Javascript, of > course) so any site can use them? If that will be done, please try to provide a versioned, well, version as well, so that subresource integrity can be used. > > It would be similar to Google Fonts. [1] > > Then I would package the resources being served in such a way that > anyone can easily set up a second server. > > Kind regards > Felix > > [1] https://fonts.google.com/ > Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: August/November update on qa.guix.gnu.org and related things
On 2023-11-02 16:38:29 +, Suhail wrote: > [..] > -- > Suhail > > This email is not an offer capable of acceptance, does not evidence an > intention to enter into an agreement, has no operative effect until a > definitive agreement is signed in writing by both parties, and that no > party should act in reliance on the email or any representations of the > sender until a definitive agreement is signed in writing by both > parties. I am unsure what is the takeaway from this paragraph. If you, for example, offer do implement something, should people wait for written agreement before being able to assume you will do so? So anything you say here should not be relied upon? > > This email may contain information that is privileged, confidential > and/or exempt from disclosure. No waiver whatsoever is intended by > sending this e-mail which is intended only for the named recipient(s). > Unauthorized use, dissemination or copying is prohibited. If you > receive this email in error, please notify the sender and destroy all > copies of this email. > > I would suggest not sending a privileged, confidential and/or exempt from disclosure information to a public mailing list. Also, I am not sure you cannot prohibit me from distributing the information once I receive it, since I did not sign any NDA or similar document. T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Re-evaluating the practice of automating user configuration
On 2023-10-21 17:32:13 +0200, Ricardo Wurmus wrote: > > Maxim Cournoyer writes: > > > All in all, I guess my position is unchanged: despite the potential for > > surprises, automating and enforcing these configs provide benefits that > > outweigh the cons, in my experience/opinion. > > I concur. > > In light of efforts to reduce cognitive overhead, I think it is a good > idea to automatically use the default configuration. Contributors can > opt out, How can I do that? > but I prefer not to have to think about yet another important > piece of configuration here. > > -- > Ricardo > -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Re-evaluating the practice of automating user configuration
On 2023-10-19 16:36:32 +0200, Liliana Marie Prikler wrote: > Hi Guix, > > as we all are more or less aware of, Guix automates quite much of the > user's configuration for comfortably hacking on our codebase. As has > been argued elsewhere, both by myself and fellow Guix, this is not > always a good thing. > > Let's start with the cleanest example of how to do things the right > way: Our Emacs configuration is split across two files (one of which is > a directory, but let's get back to that). One of them are the > directory-local variables stored in .dir-locals.el, the other the > snippets in etc/snippets–if you're using YASnippet, the former loads > the latter. I have no qualms with this being automated, as Emacs > itself gives me plenty opportunity of opting out of it. I could > declare any of the included variables or forms unsafe and ignore them > in future sessions. Likewise, I can mark them as safe to affirm my > consent that these variables be changed in /path/to/guix/checkout. > > None of this holds for the git config, which we install unasked in the > working tree with a DATA target that we want neither distributed nor > installed otherwise. This has led to confusion both in the mailing > lists and the IRC on multiple occasions, so I'd propose we instead use > PHONY targets for: > 1. git-hooks to install the git hooks that committers need. > 2. git-config to install all of the git config > a. git-config-diff to just install the diff xfuncs > b. git-config-format to just install the format block > c. git-config-pull to just install the pull block > d. git-config-sendemail to just install the sendemail block > 3. git-fullconfig for both 1 and 2. > > Internally, these would still be based on the actual file names to get > time-stamps to work. Thus, on a fresh pull or if you haven't pulled in > a while, you can run either `git fullconfig` or any of the above to set > things up. > > Incidentally, my .git/config currently reads the following: > > [include] > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig > > So clearly, automatically hooking up these configurations could be done > more cleanly :) > > WDYT? > I have to admit I was surprised, and not in a pleasant way. When I started playing with Guix, I went over the etc/git/gitconfig and copied the parts I liked into the .git/config. For some reason I do not like tools automatically touching the .git directory, and now I have the include there (5 times). I think turning it into a manual step, with the granularity proposed above, is a good and welcomed solution. At least in my opinion. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
