<divoplade>I sent a patch to guile, CCing the previous discussion on the guix user list. <divoplade>So now, if anyone replies to all in the guix discussion, it will open a new bug in guile. <jlicht>so, I'm about to push the wip- branch: besides `make authenticate', is there something else I should also do to not break things? <zimoun>divoplade: I think it is ok. Since I guess it works using Message-ID and not addresses. I guess. <divoplade>I should have known not to cross the streams. <zimoun>divoplade: let’s check now my assumption. :-) <colemickens>Do Guix build times differ significantly from Nix build times due to "all being in Guile" rather than a bunch of bash invocations? I don't know much about Guile, hopefully this isn't too bad/wrong of a question. <zimoun>colemickens: most of the time is compiling, so the glue code (Bash/Guile) is negligible, IMHO. <divoplade>So now we need a "The discussion continues here: 44186@debbugs.gnu.org" in the guix thread <zimoun>divoplade: I have sent a reply to bug-guile and until now, no new Guile bug :-) <halfdann>colemickens: how much do the build times between Nix and Guile differ, approximately? (just interested) <colemickens>halfdann: I haven't actually compared them myself yet. I am waiting for a new laptop to actually jump into a Guix system and get more experience. <colemickens>I'm reading/watching talks about typing in Nix, the new Nickel language, and the elegant Guix image builder api post that was on Lobsters yesterday, has me thinking about Guix again. <jlicht>so, the wip-node-14 branch should be on Savannah now; looking forward to see what amazing things folks will be doing with it :-) <zimoun>colemickens: new Nickel language? <cbaines>jlicht, exciting! I'd like to look at more javascript packaging at some point <halfdann>colemickens: Ok :) I've heard about there being a difference, but haven't used Nix enough myself to notice. Would be interesting to see some numbers <zimoun>colemickens: thanks! Another Tweag :-) <jlicht>cbaines: as do many folks, I imagine <jlicht>I just really hope I didn't do something fundamental wrong that means that it all has to be redone _again_ <zimoun>colemickens: really interesting, thanks! <leoprikler>Not sure how y'all feel about this, but I'd rather write my configurations in Guile. <leoprikler>I'll settle for Guile-interpreted Javascript or Python as a compromise. <zimoun>colemickens: well, in this regard, Guix seems better because all is Scheme (except the daemon). On the Nix land, the story is more complicated… :) <zimoun>and Nickel seems implemented in Rust… <colemickens>zimoun: I also started thinking about this because there was discussion about running shellcheck in the build process automatically to improve the quality of shell code. Something that presumably would be fundamentally unnecessary in Guix, based on my rough understanding. <jlicht>colemickens: at Guix Incorporated, we do our bikeshedding the old fashioned way; artisinal and manually ;-) <leoprikler>Guix does produce some very arcane looking shell scripts, but other than that you're safe from the weirdness of the bash language. <zimoun>maybe Nix folks is planning to move from core C++ to Rust. <jlicht>leoprikler: you forget to mention the obvious solution to the entire problem: "you rewrite mkdir-p in Rust". <leoprikler>Although in 2.0 we "seriously" consider writing all our things in gash. Yes, also /etc/profile. <leoprikler>My exposure to Rust is still weak. I have more experience with people, who would rather optimize it in Assembly. <cbaines>I'm happy to discover that sqlite3_analyzer is available, but it doesn't seem to work, and I'm confused as to why it's in the tcl package? Anyway, I'm going to get some sleep and investigate that tomorrow... o/ <maav>leoprikler about gash: that's the reason behind standards, you can freely change between (as complete as needed) implementations :) <leoprikler>maav: Emphasis on complete *as needed*. Our profiles are known not to load in fish ;) <zimoun>colemickens: I am not sure to see if the ratio “complexity” vs features will pay off on the long term. But what could be missing in Guix (because of Guile) is a better (good? evven real?) type system (opinionated POV :-)) Thanks for the link, really interesting! <maav>leoprikler: neither lots of code from CLisp run in Scheme, they openly say in their page it's not POSIX compatible <maav>zimoun: type system in guile and in all scheme implementations is very real, but dynamic by definition, do you mean static typing? <zimoun>maav, gradual typing for example. <leoprikler>The closest you get to having types visibly bound to your procedures is GOOPS and that is checked at runtime. <leoprikler>By the way, I think I have a new idea regarding procedure typing information. <leoprikler>(define (name (arg1 <type1>) (arg2 <type2>) ...) "Documentation" <return-type> code) <zimoun>well we could spend all the “night“ to define what is static or dynamic. :-) When you come from Haskell or OCaml, the Lisp type system appears poorer. But as I said, it is very opinionated. :-) <leoprikler>Might also want to <return-type> "Documentation" possible. <leoprikler>That version would even work with curried-definitions, but there's still a bit of a conflict with optargs. <maav>zimoun: i've just read the wiki page, and actually those languages learn their lessons from lisp, so surely you aren't the only one who feels that way :) <maav>OTOH, the lisp type system is very extensible too... :) <zimoun>However, the win for Lisp is macro and eval. Where it is more complicated in Haskell (and I do not know for OCaml). <maav>OriansJ: nonetheless these rules created a schism too ;) <leoprikler>Come to think of it, the "type system" of an ordinary lisp as viewed by a user is actually nothing but predicates. <OriansJ>maav: well understandably; #(1 2 3 4) or (make-vector 1 2 3 4) <leoprikler>So perhaps instead of being hung-up about types, we should give contracts a try. <maav>OriansJ: no, i mean common lisp (two or more namespaces depending on the position) vs scheme (same namespace on all positions of the list) <zimoun>Racket implements some nice stuff with Gradual Typing. <maav>zimoun: i was checking typed racket :) <divoplade>Do we have theorem provers for guile? I've looked a bit at frama-c, and this thing is awesome. <zimoun>it is something promissing from my point of view. BTW, Python is doing something similar with mypy and then PEP 484. <leoprikler>FWIW C++ concepts are also like contracts beyond types. <leoprikler>it'd be a bit more typing, but you could still get "static" typing by having (require (integer? a)) (require (integer? b)) etc. <leoprikler>It'd probably be harder to evaluate at compile time, though. <divoplade>I suppose all the control flow madness will make things convoluted <leoprikler>yeah, actually checking postconditions would be a pain <maav>one quick question before leaving, does anybody here use btrfs with /gnu/store in a subvolume with a different name? Checking reinstall-bootloader it seems to me that it won't work with that configuration, as the subvolume information is not provided to grub.cfg generation... <maav>well, today wasn't my lucky day with the questions... at least i've just sent the latest translation for the manual; just 30 to catch with master :) <sneek>vagrantc, you have 1 message! <sneek>vagrantc, apteryx says: I reverted the update to u-boot, which caused the u-boot-tools to fail to build. The later is indirectly pulled-in by the childhurd service (through genimage). <vagrantc>really, the u-boot-tools tests mostly have nothing to do with u-boot-tools ... it's mostly a testsuite for u-boot-sandbox <vagrantc>maybe that should be it's own package... <vagrantc>it indirectly tests some of the tools, but not much *vagrantc build all the u-boot targets, just on aarch64 where the u-boot-tools tests aren't run <vagrantc>even tested on real hardware for several different boards ... ***wleslie_ is now known as wleslie
<apteryx>vagrantc: I see! Looks like some (new?) tests were expecting to find openssl <vagrantc>apteryx: yeah, i made a change to the debian package ... i think the substutite* .. CONFIG_FIT_SIGNATURE needs to be updated <vagrantc>apteryx: i think it doesn't respect CONFIG_FOO=n ... has to be "# CONFIG_FOO is not set" <vagrantc>going to boot an x86 machine to test and resubmit :) <apteryx>vagrantc: OK! I'll be happy to review. Thank you for taking care of it! *vagrantc finds it hilarious having to boot to x86 in order to build u-boot, of all things <vagrantc>faster to just boot a reasonably fast machine <vagrantcish>heh. though now i have to refresh my guix git checkout... <vagrantcish>there appears to be something else pulling in the signatures... <Noclip>Does guix system support Appimages? How reliable do they work? <vagrantcish>it has "packs" which are sort of like appimages ... though uncontainerized <Noclip>vagrantcish: Appimages aren't containerized, too. <bavier[m]1>I use guix's relocatable packs all the time; they're great. <Noclip>But that's not what I mean, I'm talking about real Appimages. <bavier[m]1>no, guix doesn't do that. But now I'm curious if it could. ***amfl_ is now known as amfl
<Noclip>bavier: Usually Appimages ship with all or most of their dependencies so supporting them shouldn't be that hard. <Noclip>If you run an Appimage it's content gets mounted into a subpath of /tmp. Iirc I read somewhere that guix system wouldn't support that process. <vagrantcish>guix could probably produce appimages ... not sure the status on using them <vagrantcish>at least in theory it could produce them ... the binary parts of them are much like guix packs, if i understand <ryanprior>I recall somebody was working on getting AppImages to run on Guix System, but that it isn't easy because they aren't fully self-contained. They need certain things from the host. <nalaginrut>someone asked me if guix support mac now, I guess it's possible to use guix to build packages locally, but maybe there's no pre-built binaries <apteryx>nalaginrut: mac support this was discussed on the mailing lists before <apteryx>I don't recally exactly why, but it isn't feasible (something with the glibc not having been ported for macOS, perhaps) <orly_owl>you should ask such questions before buying, not after <orly_owl>'As of 5.1 this WiFi card works by default, in a clean install of the Guix system.' <xelxebar>Man, guix environment --ad-hoc is so useful. Find myself using it quite often. <vits-test>xelxebar: never run `gc` before starting all U'r envs. <vits-test>+ `man` do not working out of the box in `environment`. Need to get from $GUIX_ENVIRONMENT/share/man <xelxebar>Exactly. I also find myself writing little manifest.scm specs for different projects and/or dev tasks. The gc problem is kind of annoying though. There must be a way to pin the profiles as a root and update just like a normal user profile, no? <xelxebar>Yeah, I have this in my .profile: [ "$GUIX_ENVIRONMENT" ] && MANPATH=$GUIX_ENVIRONMENT/share/man${MANPATH:+:}$MANPATH ***jess-o-lantern is now known as jess
<wleslie>how does one get the hash of a git repo + commit for use in a package expression? <xelxebar>Here's a thing: guix environment --ad-hoc tftp-hpa; export MANPATH=$GUIX_ENVIRONMENT/share/man${MANPATH:+:}$MANPATH; man tftpd # blastoff <divoplade>Although I'm not sure it works with git commits <wleslie>thanks, that's a great place to start <rekado>xelxebar: will MANPATH not be set automatically when you include the man reader? ***jesse- is now known as halfdann
<mfg>What do cmake install targets normally do? i have package which tries to invoke "install" for every file that should be installed, but i get the error "`(assoc-ref outputs "out")`/include not writable" <mfg>i mean it does make sense because the store is not writable <mfg>but how does the installation step work then (normally)? <civodul>the outputs of a package are writable during its build process <civodul>but maybe it expects OUT/include to already exist? <civodul>you could try adding (mkdir-p (string-append out "/include")) before 'install <mfg>ah, makes sense. I will check that! <mfg>i have the feeling most libraries/programs produced by universities are strange to package... everything is bundled or the cmakefiles are way to hard to read or... <civodul>yeah, though universities don't have a monopoly on such things :-) <mfg>civodul: you're right btw, creating those directories works :) <civodul>cbaines: i'm working on lifting the --cache first-hit restrictions in 'guix publish' <civodul>it's a rather simple change, after all <cbaines>I don't quite follow though, what's the cache first hit thing? <cbaines>I remember that guix-publish can operate in two modes, either baking nar/narinfo things in the background, or doing it on request <civodul>right, i'm referring to the "--cache" mode, where things are baked on the first .narinfo request <civodul>until now, you'd get 404 on that first narinfo request <civodul>there's an asterisk though: you get 200 *if* the requested store item is "small enough" <civodul>this is so the "guix publish" admin can control resource usage <cbaines>well, given the time it takes to bake some things, you'd need to probably work to keep the request alive <cbaines>it's nice to be able to return 200 most of the time though <civodul>try "guix gc -R /gnu/store/zb4pfvj7pdplw6bfymkaynj7cgkk5s29-rust-arrayvec-0.4.12.drv" <cbaines>Ah, yeah, it says guix gc: error: path `/gnu/store/zb4pfvj7pdplw6bfymkaynj7cgkk5s29-rust-arrayvec-0.4.12.drv' is not valid <cbaines>I wonder how that happened... and how I can get it to be valid? <cbaines>Ok, fetching substitutes for it seems to remedy the situation, I think I'm just using file-exists? rather than valid-path? in some more places in the coordinator... <maav>well, i'm opening a bug report for btrfs subvolumes installation <maav>guix system delete-generations breaks grub.cfg <civodul>apteryx can perhaps help as the implementor of btrfs subvolume installations <civodul>but yeah, reporting a bug is a good idea <maav>civodul: i'm confident enough to say again, we have to change boot-parameters ;) <maav>i have already the solution too :-P *civodul never took the time to play with Btrfs <maav>the thing is, e.g. reinstall-bootloader, need the information about the subvolume to generate grub.cfg <maav>i was testing the installer with that today, hehehe <maav>i must test what i translate <civodul>now you know when the manual is lying :-) <civodul>i had the idea of storing the bootloader installation code in each generation <maav>not really, it works forward, but not backwards or the cleanup ;) <maav>roll-back-managed-host, yup <maav>that's why my locale patches touched there too <maav>but the param for the store prefix is missing in those calls (i saw the problem before the test, you know) <maav>also, the keymap doesn't work in stage2 neither, that's another one <maav>but it's easy, i could push that one right now <maav>the change in boot-parameters... needs some consensus at least :) <maav>nvm, it didn't work as expected, oops <civodul>well if we have to change boot-parameters, so be it; i'm just cautious about changing it too often <maav>because the prefix /gnu/store is not removed when <maav>*when it's mounted elsewhere <mbakke>civodul: any idea how to update the guix-daemon --cores option of the build machines behind berlin? reboot? <sneek>I think I remember nckx in #guix 8 days ago, saying: C'est TODO, as the French say.. <cbaines>mbakke, I guess so, otherwise all the non-core packages wouldn't have substitutes at the point core-updates is merged <mbakke>cbaines: oh, are we freezing it? <cbaines>mbakke, I dont' know. I saw you looking freezing staging, but I don't remember anything about core-updates. <mbakke>normally Berlin only builds a small subset in between "merge cycles" to ensure the low-level packages are fine <maav>another open question for today, what title should have a change on the grub.cfg generation? "system: fix xxxx" or "bootloader: grub: fix xxxx" <maav>the change is in gnu/bootloader/grub.scm :) <cbaines>mbakke, that's news to me, I was under the impression it built everything <GuixSession>Welcome back raghavgururajan! Do you spit or swallow? <cbaines>mbakke, checking guix-maintenance suggests it should only be building the core subset though <mbakke>not sure what to do about the 44k pending jobs though <cbaines>as I say, the spec already has (subset . core) in it <cbaines>mbakke, I guess there's a question about whether the database is consistent with the config <cbaines>and whether the config still actually has the intended effect <mfg>that's a bot isn't it? <maav>mfg, raghavgururajan: probably, at least a troll... it left just after that <maav>i saw this: *** GuixSession <maav> (ae5915f9@bras-vprn-ckvlon0125w-lp130-03-174-89-21-249.dsl.bell.ca) has <maav> left channel #guix: #guix <mbakke>cbaines: I checked the Cuirass DB and it does have (subset . core), not sure what's going on. <raghavgururajan>maav: Yeah, same one who left a abusive message via sneek yesterday. <cbaines>mbakke, on this topic, I sent an email to guix-devel about reducing the load on ci.guix.gnu.org by not doing unnecessary stuff with core-updates/staging with it <cbaines>on the other hand, it's nice to see ci.guix.gnu.org actually sucecessfully evaluate core-updates! <mfg>Hm, does guix support ssh checkout of git repos? Or is there an option to write a package definition for a package whose upstream is only available with an account? <mbakke>silly Cuirass has no problems building 45k jobs for 'core-updates', but struggles with the 20k jobs on 'staging' :P <mfg>Ah, does guix understand file:// URLs? <mbakke>cbaines: for 'staging', I've recently started to only build for x86_64-linux in between "merge cycles" <mbakke>cbaines: no, in the Cuirass job specification on Berlin. <civodul>bah it's not the first time we see "GuixSession" here <cbaines>mbakke, the config in the maintainence repository suggests that one set of systems is used for all branches <mbakke>cbaines: yes, I've been fiddling with the Cuirass DB manually :P <clone11>I'm trying to package a python app that uses python build system (setup.py build) and also gtk. All of the python gtk apps I've been able to find use meson build system. Do you know of any apps like this packaged for guix? I'm not sure what I have to do, I'm thinking probably I'll have to make a hybrid of python-build-system and glib-or-gtk-build-system. <cbaines>clone11, the terminator package seems to be similar to what you describe <clone11>Thanks, that's exactly what I was looking for! <rndd>hi everyone! i had problem, i cannot type cyrilic in games (for example xonotic) =( <mbakke>cbaines: I filed a bug about the current 'core-updates' evaluation <mbakke>I also have to go and am busy until ~monday <vits-test>sneek: later tell rndd: А нафига кириллица, да ещё в шутере? Is it work in Emacs, btw? <vits-test>sneek: later tell rndd: Some apps may require the person to switch a layout _before_ start the app. I'd that in gtypist. <mfg>How does git-fetch verify that a given uri is a git repo? i get a "does not appear to be a repo" error when using file:// as the url in git-reference. <mfg>and the path does exist <rekado>mfg: is it a real git repository? libgit probably verifies that. <vits-test>rekado: Hallo. Ist das `git clone` schafft die repo? <vits-test>vits-test: Ja-ja-ja. `git clone` machts sehr gut. <mfg>rekado: it has a .git directory inside :) <mfg>if that's what makes a "real" git repo :D <mfg>vits-test: why translating to german? <vits-test>people may point out the errors from time to time. <mfg>Ah, so what did you try to say? ***rEnr3n_ is now known as rEnr3n
<vits-test>"do git clone creates a repo?" "yes-yes-yes. git clone do very good" <mfg>With the first one you want to ask if it works when using git clone on the command line directly? <vits-test>No. If it is same as what was cloned. Funny question, indeed. <mfg>Ah so, you mean if the cloned repo locally works in the same way as the remote one from which it was cloned from? <mfg>Interesting question. I guess it does. It's possible to do git clone /path/to/repo /other/path and it works. <mfg>vits-test: regarding the translation, now that i know what you meant, i think it could be along "verhält sich ein lokales git repo genauso wie das auf dem Remote?" <mfg>but as always: to much different possibilities which could mean the same :D <mfg>what is your native language vits-test? :) <civodul>sneek: later tell lfam re linux-libre 5.9, no comments from me other than "thanks"! <mfg>Ah, now i see why it doesn't work: guix uses http requests to get information about a repository this obviously fails when the repo is a local folder <mfg>i don't know exactly i have used python -m http.server 80 to serve the directory containing it <mfg>i see: GET /hypro/info/refs?service=git-upload-pack HTTP/1.1" 404 <mfg>in the python output <vits-test>mfg: try now `git` on terminal. Chances are it's git-app itself send those. <mfg>Ah okay, you're right! same when using git in the terminal <vits-test>IDK, but unlikely 'origin need a http to get info about something that already was 'git-fetch. The guix/build/git.scm have a simple chain of 'invoke to `init`, `remote add origin uri`... <vits-test>> "it worked for me because i'm doing something a bit different in git-mirrors" <mfg>vits-test: thx for those links! <mfg>also: running the invocations in guix/build/git.scm manually works ***amiloradovsky1 is now known as amiloradovsky
<mfg>i'm going off for today. o/ <vagrantc>apteryx: pushed u-boot 2020.10 with some fixes to the u-boot-tools test suite <vagrantc>should reduce the likelihood of future failures... <vagrantc>and actually enabled some tests that were disabled <PotentialUser-29>hi! anyone know if its possible to allow peer authentication to postgresql on guix system? I cannot understand how to do it via the options listed in the manual because that only lists an overridable config file record. but I guess this is the pg-hba file and not the config file, per se? or is there any way I can peek at the record in question? <janneke>PotentialUser-29: yeah, that could be pretty tricky <janneke>unless i'm mistaken, you'd have to create your own postgres.conf file that references your own pg_hba.conf file <cbaines>I recently changed a bit of the PostgreSQL service as well, but the online manual hasn't updated yet <cbaines>Unfortunately, the manual doesn't document the postgresql-config-file record, which is the problomatic bit here <PotentialUser-29>ok I see the normal postgresql.conf file references the pg_hba file. hadnt noticed that before :) <joshuaBPMan>Hey, I think I noticed that guix has an open issue for shepherd services defining a "reload" service. How does that differ from "restart?" <PotentialUser-29>cbaines: yes. I realize that my guix edit/develop setup is very lacluster but how would I go about inspecting that record? is that possible? can I do it in the repl? <cbaines>joshuaBPMan, reload often means re-read the config, but don't start a new process. It's very service specific though. <cbaines>Interestingly, my own mistakes are catching up with me... I didn't document <postgresql-config-file> back in March 2018 when I introduced it 936e7a5245d5b50be8b968b39760220066ae24f5 <PotentialUser-29>joshuaBPMan: in systemd reload is just a different set of instructions that make up a "reload" I think there are some guidelines as to what "should" do what but it does is service specific as mentioned above. In general "reload" is less disruptive and can reload the config but often it it it not enough like with nginx if you want to "reload" to r <PotentialUser-29>cbaines: ty for the link. any chance you have a guix config file or block for emacs you could share also? I cannot make much use of the official emacs dev env instructions "geiser-run" seems like it does not work for me or rather it gives me a guile repl but I do not know how to make use of that to reason about my .scm files <cbaines>PotentialUser-29, I'm unsure what you mean? I think this https://paste.debian.net/plain/1168574 is quite similar to the way you want to adapt your config. Some closing brackets are missing, and you might want to tweak the hba config if you don't want trust auth, but that's a PostgreSQL thing <cbaines>If you've already got (postgresql-service ...) or (service postgresql-service-type) in your config, then that'll need adapting to include the custom hba-file, otherwise you need to add something like what's included in that paste in to the (services ...) bit of your operating system record <PotentialUser-29>abases so I can read the code. but yea Im not sure what you all do here? do you use the guix repl somehow? how do you develop new packages or hack on your system config.scm ie? <cbaines>Well, personally, I do use Emacs, but I (ab)use ag (the silver searcher) for most of my jumping around. I haven't got a fancy geiser jumping to definition thing working. <cbaines>Someone else might have that setup working, so I'd ask the question more widely. <nefix>hello! I have two questions: 1- how am I supposed to install plymouth? Just guix install plymouth and thats it? 2- how can I disable gdm and end in a tty (as if I did ctrl + alt + f2). Thanks! :) <joshuaBPMan>nefix: I believe that "guix install plymouth" will install plymouth for you. <joshuaBPMan>If it's a specific python package then the command might be "guix install python-plymouth" <nefix>joshuaBPMan: the thing is that it modifies your boot generation and needs configuration, so I'm not really sure how to do it <cbaines>sounds like Plymouth needs to be used through a service in Guix. I can't see any reference to it, so that bit might still need implementing <nefix>cbaines: hmmm thats what I thought <civodul>i vaguely remember someone working on Plymouth support some time ago <jonsger>hm, qgis on current master fails in qgis_meshlayerrenderertest. Can other build it? ci never builds it, or at least the web ui strikes while searching it <nefix>"You are not supposed to install this on your own, it is only useful with system integration." <maav>IIRC, the missing bits are the integration into our boot process <maav>AFAIK plymouth provides some utilities (i don't remember if they were calls of binaries) that have to be called to show the splash screen, ask for a password, and so on <maav>nefix: to disable gdm you should remove or not introduce at all the service innto your operating-system declaration (%base-services does not include it, unlike %desktop-services) <maav>btw, could someone take a look into my last patch for #44196 and give me some hint about how to avoid that kind scope dancing? :) <maav>the biggest offense to my eyes is this: (normalize-file #~(format #f "~a" #$grub:locale)... <maav>but I don't know how to get the locale output... :-( <vagrantcish>anyone familiar with debugging python pytest from guix build? trying to update diffoscope, but getting a test failure and struggling