***MightyJoe is now known as cyraxjoe
<Apteryx>silly thing is that I can't seem to find this option anymore... hmm. <ryanwatkins>Peeps, I have a job interview tomorrow and must use npm/yarn I assume in my GuixSD environment? Is there a ad-hoc to make them both work? <buenouanq>what is THE GUIX WAY for remapping keys (putting C next to SPACE) and setting trackpad `tap to click' and the like? <buenouanq>is this just deferred to the DE or should I be setting it in the os config? how? <buenouanq>I've again successfully installed GuixSD on a Macbook using rEFInd (-‿‿ - ) <ryanwatkins>how do I solve a /usr/bin/env: bad interpreter: No such file or directory error when doing an npm install :'( <buenouanq>the email thread regarding this needs to be updated slightly <buenouanq>ryanwatkins: edit the source to point to this proper guix path rather than the default? I actually don't know and have wondered what people are actually doing. <ryanwatkins>buenouanq: agreed but I don't know how to do that! seems that babel-node is trying to do /usr/bin/env by default but that's just a node package so how do I 'edit' it? <buenouanq>I have no idea - I still haven't made the time to really get dirty with packaging things with guix (;-___-) <ryanwatkins>buenouanq: how do I find out the location of a given thing like 'env'? <buenouanq>I will someday and it will be lovely and I'll lament not doing it sooner. <ryanwatkins>buenouanq: I don't know much. Was just checking symlinks from ls -la $HOME/.guix-profile/bin/ <ryanwatkins>buenouanq: someone needs to figure out why these node packages all make assumptions on default env location! It's annoying me like crazy! <buenouanq>ryanwatkins: it has to do with the standard/default unix path structure <ryanwatkins>buenouanq: that's fine but why couldn't base that on some env var or something lol <buenouanq>oh dear, I'm getting my first ever `out of memory' error with guix pull <buenouanq>I've done this same set up before with no problem, so something has changed on me. <pmikkelsen>While working on a build system for meson, I am experimenting with some different ways to keep the RPATH or RUNPATH after install, since meson by default deletes this. I have tried making a package called something like meson-for-build, where i patch out the part of meson that deletes the rpath of binaries. Would this be a good way to do stuff? <civodul>i don't know of a reliable way to do that, apart from fiddling with the ELF file and leaving blanks <civodul>oh we have MATE, congrats ng0 & efraim! <pmikkelsen>Meson it self just clears the runpath upon installation, for some reason :/ really not what we want, but it seems they are in favor of static binaries, which might explain it <efraim>i forgot how draining reviewing packages is <civodul>heh, especially large series like this, so thanks a lot! <civodul>pmikkelsen: so do you know how meson removes RUNPATH? <efraim>i built monero, with 4GB ram, 4GB swap and 6 cores I ran out of memory, it took about 6 hours with --cores=2 but I didn't have memory issues <efraim>would it be different if we packaged the last bundled lib and build it shared? <pmikkelsen>sort of, I am not very good at reading python code ;) What I have right now just deletes the lines of code that triggers the deletion, but it is not enough, as the runpath from the build time is not always what we want <civodul>efraim: on aarch64? it worked on my x86_64 laptop, with 16G of RAM though <pmikkelsen>for example, if the lib and executable of a project is in the same source dir, the bin will have '$ORIGIN/:/other/paths...' in its runpath, while it should really have '$ORIGIN/../lib:....' <efraim>pmikkelsen: does looking at lollypop help? meson&ninja are shoehorned into building that package <civodul>well using $ORIGIN is a good thing, in theory <civodul>maybe meson doesn't actually clear the RUNPATH, but it passes its own -Wl,-rpath, which has the effect of overridding what our ld-wrapper does <pmikkelsen>where 'fixing' is setting it to what ever the build option install_rpath is, and according to the devs, that option can not be set when building, but it must be in the build file :/ <civodul>1. meson is super-smart, and we just remove "ld-wrapper" from the implicit inputs of meson-build-system, and assume that meson will do the right thing <civodul>2. meson isn't so smart, and we need to patch out that "fix_rpath" functionality <civodul>i suspect we'll end up with #2, but it's worth trying #1 :-) <pmikkelsen>civodul: turns out, meson is not super smart ;) Going for #2 <jonsger>pmikkelsen: could we just ask them to fix that upstream? <civodul>yeah it would be nice to tell them in what way we meson's RUNPATH handling is "broken" in our opinion <civodul>that it overrides what ld-wrapper does is not a bug of theirs, for instance, so we'd have to see what meson does wrong in an ld-wrapper-less environment <pmikkelsen>I don't think they will fix it, but I can try and talk to them <civodul>you shouldn't present it as something that needs to be "fixed", but rather as questionable behavior <civodul>but for that we need to make sure we understand what goes wrong <jonsger>pmikkelsen: maybe the can hide it behind a config flag <pmikkelsen>I think I have an idea of how I can fix the runpath in meson-build-system, and after that i should have a good understanding of the issue <pmikkelsen>Don't want to bother them when I don't know all of the problem yet ;) <efraim>buenouanq: GuixSD on a Macbook, did you go OSX -> rEFInd -> GuixSD? I've been trying with the debian mac net-installer but it doesn't want to recognize the usb stick <buenouanq>efraim: yes, and for now I've left the 10GB OSX partition just incase something goes wrong <buenouanq>but the refind config had to be a little different for me <buenouanq>volume is the part uuid, and the other paths I did to the more general symlinks <buenouanq>depends on the model maybe, but to boot to any usb I have always had to use refind <buenouanq>has --no-grub been usurped by --no-bootloader ? <efraim>did you keep the --no-bootloader? I was planning on wiping osx completely <catonano>sneek later tell ng0 kudos for your MATE patch series <catonano>efraim: I replied to your patches about your gccgo on x86_64 <efraim>catonano: I'll send the patches again later today, I rebased them on master again on my other machine <efraim>catonano: patches sent off again, no rush :) ***jonsger1 is now known as jonsger
<catonano>efraim: ok, now I'm building the updated sqlite that jlicht just sent <catonano>in the afternoon I cold be busy, maybe tonight <catonano>efraim: it's building the gcc 7.x right now :-) <thomasd>is “bayfront” the same as mirror.hydra.gnu.org, or is that a different substitute server? <civodul>thomasd: that's a different server, bayfront.guixsd.org <thomasd>is there a reason it's not enabled as a substitute server by default? <civodul>yes, basically we'd had hardware problems with that machine <civodul>however we have berlin.guixsd.org, which is stable and well <civodul>we may enable it by default in the next release <thomasd>OK, I'll try berlin.guixsd.org first then. What is a secure method to get the server's signature? Is there a signed message by rekado somewhere? <civodul>thomasd: they key is actually bayfront.guixsd.org, which is in the repo, added by a signed commit <civodul>now, if you have the latest guix-daemon (from a day ago), you don't really need to register it <thomasd>as it happens I'm just reconfiguring my system :) <catonano>efraim: I replied to the last patches for gccgo <ng0>sneek: later tell efraim: many thanks for merging the Mate patches! <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, catonano says: kudos for your MATE patch series <ng0>ACTION back to the math homework <brendyn>How can I find the path to gnome-settings-daemon? <civodul>brendyn: guix package -p /run/current-system/profile -I gnome-settings <civodul>are you using the gnome desktop service? <civodul>i mean you can always run "guix build gnome-settings-daemon" to get the directory name <civodul>but i'm not sure whether it's really helpful <brendyn>i wanted to figure out how to run a tiling wm with the gnome panel and stuff. some people like that kinda setup <brendyn>I've been meaning to switch over to GuixSD for months now but that plan kinda went on hiatus <civodul>i guess you'd need to install a bunch of gnome-* packages in your profile <brendyn>well i have gnome installed with gnome-desktop-service, so i can launch that from the display manager <jlicht>brendyn: if you figure this out, I would very much be interested in your system config file, as well as any other steps you had to undertake to make it all work <brendyn>sure. i've had a lot of trouble with simple things on guixsd. guixsd does not seem to use .xinitrc so i am not sure how to run commands on login for my user, and set the keyboard layout for the login manager <jlicht>brendyn: I recall people using exwm via .xsession <elpogo>anyone aware of the existence of a guix cheat sheet? <brendyn>when i run reboot or shutdown i get error: connect: /var/run/shepherd/socket <civodul>brendyn: maybe the error message also says "Permission denied"? <civodul>brendyn: that would need you need to be root to run this command <brendyn>my computer is in chinese but i haven <brendyn>'t got chinese characters to display on the terminal yet <elpogo>thanks jlicht. guix-notes seems like what i want. don't want to read a big manual to use a package manager. <elpogo>at least not before i've decided whether or not i'm going to keep using guix <jlicht>elpogo: you really do not need the entire manual, it is imho written in a very modular way <elpogo>is there a talk(video) on guix that focuses on design decisions of the guix implementation and not on what functional package management is? every video i'm finding on youtube seems to assume that the audience needs to be educated about functional package management <elpogo>i just want to quickly understand what the .drv files in /gnu/store are, etc <davexunit>elpogo: I don't think so. there are papers on that subject, though. <davexunit>most talks are given to an audience that doesn't know what guix is in an effort to raise awareness of the project <elpogo>you must all be a bunch of academics (nothing against that). for some reason i can't get myself to read papers <davexunit>thanks civodul, had forgotten about that section :) <elpogo>civodul: last question. with gentoo, i could use the ebuild command to break down the various steps of the build process (fetching, extraction, patching, building, packaging and installing). is there a command to similarly to build a package step by step? <davexunit>well, fetching the source is its own derivation <davexunit>but the build process is a single derivation, which is a self-contained thing <elpogo>no real use case other than to understand how guix works. <elpogo>i figured understanding the building blocks (like ebuild is to emerge) would help <davexunit>most build systems have the notion of "phases", but the build daemon has no idea about those. <elpogo>so if a build fails, and you want to hack/debug in an attempt to fix it, you have to start from scratch every time? there's no way to 'pause' after extraction of source and run the build command by hand? <davexunit>I think learning about derivations in general will help <davexunit>in the case of failure there is the --keep-failed flag <davexunit>which will leave a temporary directory behind that can be inspected <davexunit>but we don't provide a way to insert an interactive session into a build process because that would be non-deterministic <elpogo>thanks davexunit jluttine civodul. i will attempt to understand derivations via the manual. if only there was a video <davexunit>when I got started with guix I actually didn't worry too much about what derivations really were <elpogo>i'm running guix on a debian stretch machine on google cloud. my only goal is to understand it and determine if it makes sense to contribute to this project. no real need for it. my crappy laptop is best running debian since i can get binary packages <elpogo>(the google cloud micro instance is free) <elpogo>i know. and the fact that it only has open source projects, and guix challenge is what i find attractive <efraim>I checked jamvm's sourceforge page, no support there for aarch64 <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, ng0 says: many thanks for merging the Mate patches! <davexunit>people sometimes compare us to gentoo but we really are quite different <elpogo>i don't have the time to maintain a gentoo distribution anymore. as of now i'm using debian testing, but if i get comfortable with guix my goal is to switch to debian stable + guix for latest packages <elpogo>do the prebuilt packages(mainly libc) have a minimum kernel version? <elpogo>and if so, how often does that minimum kernel version get bumped up? <civodul>elpogo: these days we're following what glibc decides, and for 2.26 that'll be 3.2 <elpogo>does guix check the kernel version on host and determine which version of libc to install? <elpogo>so when you bump up to a new libc version, do you nuke the old libc version from hydra? why not treat it as just another package? <elpogo>ignore my last question. i think i know the answer <Apteryx>elpogo: anser being it wouldn't be very convenient to swap the glibc version since you'd need to rebuild most of the packages in Guix? <elpogo>apteryx[m]: something like that. and unlike Python-3 and Python-2, i can't think of any reason a package would need to depend on a particular version of libc. <elpogo>i'm guessing in guix updating libc would mean updating almost all the packages simultaneously since most depend on libc <elpogo>they probably don't nuke the old libc from hydra either. the people who haven't guix pulled can still get the old libc+dependent packages from hydra <bavier>elpogo: we usually protect important "snapshots" from garbage collection on the build farms <bavier>elpogo: and nginx will retain packages in its cache too <elpogo>is there a 'lightweight' version of guix challenge where if you trust the person providing you the binary then you only check that the inputs are identical without actually doing the compilation? <elpogo>that way you know that if you ever need to debug that binary, you have the identical inputs necessary to create that binary <davexunit>elpogo: the inputs would have to be identical <elpogo>ah. makes sense. thanks davexunit and bavier <davexunit>the identity of a build is based solely upon its inputs, not the resulting content <elpogo>wait, the hashes in /gnu/store/.. don't take the outputs into account? <davexunit>the output directory is created before the build even begins <elpogo>oh wow. wouldn't have expected that. <elpogo>is the sha of the output stored somewhere as an optimisation for computing future input shas? (for eg i can't find it within /gnu/store/g88981k0w5ljbm30zd9p2gh1w8jgsqx3-curl-7.54.0) <bavier>elpogo: like davexunit said, the results of a build do not enter into the equation <bavier>elpogo: though we do try to make as many packages as possible build reproducibly, which is where 'guix challenge', et al enter in <elpogo>bavier: if curl-7.54.0 is used an input for building something else, which files are considered as part of the input? just the files actually used (say /gnu/store/...curl-7.54.0/lib/libcurl.so) or is every file within /gnu/store/...curl-7.54.0/ considered as part of the input? <bavier>elpogo: if a package declares curl as an input, all files under that curl's store directory is visible to the package during its build <bavier>elpogo: for hash calculations, its the contents of curl's derivation that is used <elpogo>do you get these kinds of questions in this channel often? or do most people just read the manual and so know this stuff? if anyone is thinking of doing a guix talk, please consider doing one on the implementation details! <bavier>different people are interested in different details ;) <elpogo>my previous manager would read all the gnu manuals of tools he was using. never used google. i always envied his ability but understood that's why he was so successful. <efraim>new numbers! as of evaluation 109781, total FTBFS and dependants are at 7.02% <efraim>I just realized gcc-4.9 and 5.4 can't change, the first is used in the bootstrap in commencement.scm and the second is used to build everything <catonano>jlicht: I'm building a core-updates guix right now to try to build some package that depends on your sqlite :-) <efraim>good news! I seem to have touched gcc.scm without causing a rebuild-world event <catonano>jlicht: though, I'm not sure it's a good idea. Now it's buildind coreutils. God nows how much stuuff it will have to build. Wouldn't just merge this patch of yours in core-updates and let the mules do the work ? <catonano>jlicht: when and if some sqlite dependee won't build, it'll be fixed. Will it ? <jlicht>catonano: if another regular core-updates contributor gives the thumbs up, I will merge it indeed. I am just very averse to breaking builds due to some dealings at the day job. <catonano>jlicht: anyway, it's churning now. Should anything go wrong, I'll report in the email thread <jlicht>catonano: my build-breaking-phobias are grateful, thanks <janneke>this means that cuirass lost support for dumb http by upgrading to guile-git :-( <jlicht>janneke: is there any reason one would like to use dumb http over any of the alternatives? <janneke>jlicht: yes, it's easier to configure and runs without cgi <janneke>jlicht: afaik the default debian apache+gitweb setup does dumb http <janneke>at least the version we were running <jlicht>Incidentally, what would be a good pointer on setting up a local cuirass instance to build my 'private' packages? <janneke>jlicht: there's an entry in the manual...but i'll be sending some patches to guix-devel soon <catonano>janneke: please notice that the patches should be sent to guix-patches, not to guix-dev ! <civodul>it's not the end of the world if it goes to guix-devel though :-) <catonano>Of course ! I didn't mean to sound pedantic ! <cbaines>I've just got around to replying about the Tryton service <cbaines>Looks like you've made lots of progress <marusich>Does anyone know offhand how to create file associations in GuixSD using GNOME? Does "the usual" way of doing it in GNOME work? (I'm unfamiliar with that method but can look it up) Or is it something special for GuixSD? <marusich>I'd like to double click a PDF and have it open using Evince, but I'm unsure of how to make that happen in GuixSD. <marusich>e.g. from the GNOME "Files" file browser. <cbaines>marusich, I believe the usual way works <cbaines>although the usual way, as I believe it to be of Settings -> Details -> Default Applications, is a little hidden <Steap>what is our "MIT" license again? I mean, in guix/licenses.scm <civodul>hmm, 2 GLib test failures on staging <civodul>has anyone fiddled with that branch lately? <civodul>hmm, it passed on the second attempt <janneke>testing my first guix-cuirass patch...totally flabbergasted <janneke>i now have this file: `g.scm': (format (current-error-port) "hello: ~s\\n" (current-filename)) <janneke>when i say: guix environment -l g.scm <janneke>...but only for g.scm in directory guix-cuirass <janneke>e.g. in ~/src/guix, it says: hello: "/home/janneke/src/guix/g.scm" <cbaines>I've found (current-filename) to be a bit inconsistent, I think the .go files have an effect on it working... <cbaines>maybe you have a .go file in your cache that matches it in one directory, but not another <civodul>janneke: did you try renaming "guix-cuirass" to "cuirass-guix"? :-) <janneke>of course i did: rm -rf ~/.cache/gui* <janneke>civodul: wow, that renaming works...amazing <civodul>without this fix, canonicalization would be broken in case of directories with common prefixes <janneke>okay well, then my first `fix guix.scm' patch is not necessary... <janneke>civodul: still pretty nasty that after git clone gnu:guix/guix-cuirass things don't work... <civodul>that renaming the dir solves the problem <janneke>oh, it's a guile fix ... misread guix.git and was sure i was up to date...good! <janneke>2 cuirass problems addressed without patch, probably two small patches to go :-) <civodul>thanks for your patience, it's probably not that fun <janneke>it's all a matter of expectations -- but you're right <janneke>i was checking up on cuirass, yay we now have a service...and then several weird problems <janneke>oh well, it's nice if us together here can make thing "just work" <marusich>cbaines, that setting in GNOME did not work for me (there is no option for PDF files or documents in general), but what did work was to right click on a PDF file (in Nautilus), go to "Properties", select the "Open With" tab, and then select "Document Viewer" (evince) from the list of "Recommended Applications". It "magically" showed up there, presumably because I've installed Evince. <marusich>I have no idea how Nautilus stores the information that it uses to remember what program it should use to open which file types, but I'm happy, so that's good. :) <cbaines>marusich, ah, yeah, I don't see anything about documents/pdf's in the settings either <janneke>yay, meanwhile Kei Kebreau fixed my 3rd cuirass problem <sneek>lfam, catonano says: than you ! <civodul>now you have to find out what this was referring to <janneke>i changed cuirass' port in config.scm, and did guix system reconfigure <janneke>started, restared cuirass but it didn't pick-up the change...a reboot did. what am I missing? <civodul>janneke: the service has to be stopped at the time you run "reconfigure" <civodul>otherwise you more or less have to reboot <janneke>ah! ... that's new to me, puzzled me. <dustyweb>civodul: where does this come from, do you know? import-x509-certificate <civodul>sometimes Geiser doesn't quite work, as in this case <dustyweb>civodul: I'm working on the http-signatures stuff and I was wondering if there was a module that already read the PEM format <dustyweb>(I guess PEM is just padded base64 encoded key data though?) <civodul>dustyweb: (gnutls) has stuff, but i'm not sure it's really usable outside of GnuTLS <civodul>but yeah i think PEM is something like that :-) <dustyweb>also I really need to make a public release of guile-gnutls, augh! <civodul>at some point we'll need a pure Scheme TLS implementation <dustyweb>it'd be nice, seems like a ton of work :) <civodul>Industria has/had something in that direction <civodul>i'm told TLS 1.3 is "relatively easy" <dustyweb>so many crypto corner cases to worry about <dustyweb>we see tons of vulnerabilities coming from C libraries <dustyweb>who knows which option would be less insecure ;) <dustyweb>civodul: don't take my "whoa really" as dissuading you from pulling an amazing crypto hacking library feat