<nckx>str1ngs: Why ‘would you like to use cons[*]’? <str1ngs>nckx: I want to be able to represent the alist as a data structure. if I use acons I have to map and use set!. unless there is easier way <str1ngs>I want to merge to alist together basically. <rekado>str1ngs: how about the lset-* procedures of srfi-1? <nckx>str1ngs: I still don't quite get it, but have you read the SRFI-1 section of the manual? I'd be very surprised if (assoc-)set! is really what you want here. *nckx would discuss further but → 😴 <str1ngs>right now I use (set! my-alist (acons "key" "data" my-alist)) <str1ngs>which mutates, I guess that fine. I just would prefer to represent data as an alist and just append or merge with another alist. maybe I'm not explaining well. I'll read srfi-1 though might help <nckx>(Of course I learned Scheme through, and am already naturally biased towards, Guix's more functional style. G'night!) <ison[m]>Is there any way to have a package maintain a symlink on the root fs, such as /usr/bin/env? Or is there a way that a package can add an extra-special-file service to shepherd? <str1ngs>ison[m]: you can use ("/usr/bin/env" ,(file-append coreutils "/bin/env")) with special-files-service-type <str1ngs>ison[m]: I don't know what the difference is between extra special and special <ison[m]>str1ngs: But my question was if it can be done from inside a package? Although, now I'm thinking the answer is No, because those packages wouldn't be installable for someone who isn't runnining shepherd (someone running guix on a different distro) <str1ngs>ison[m]: I don't think this is possible outside of GuixSD <str1ngs>ison[m]: hosted guix only ever writes to /var/guix /gnu and maybe /etc/guix . that's it not including user profiles <apteryx>is the guix builder running with the date set to somewhere in 1970? <apteryx>ah, maybe the set-SOURCE-DATE-EPOCH phase of gnu-build-system is responsible for that behavior <rekado_>apteryx: the SOURCE_DATE_EPOCH variable is respected by upstream tools and only affects embedded timestamps. <rekado_>the daemon itself resets the timestamp of files before adding them to the store. <rekado_>I fixed the store corruption on the cluster by replacing affected store items with copies from my workstation. <rekado_>thanks to reproducible builds I could simply compare the items and undo the damage. <rekado_>there might be more damage, but the fix is the same. <rekado_>for some reason I couldn’t run “guix gc --verify”, even as root, because Guix insisted that I don’t have sufficient privileges. *rekado_ mumbles something about NFS and root <Chaekyung>trying the guix again, guix update appears to have decided to compile icecat and it seems to only use one core <str1ngs>Chaekyung: --cores $(nproc) --max-jobs 1 <Chaekyung>str1ngs: is that supposed to be added to the guix update command? <thomassgn>Chaekyung: most guix commands that deal with pull, system, build and package can take thos flags yes (those flags are AFAIK just passed on to the build daemon). :) <thomassgn>Could anyone try exporting an (emacs) org-mode document to odt ('C-c C-e o o' or org-odt-export-to-odt) and see if it works? I get 'OpenDocument export failed: Opening directory: No such file or directory, /run/current-system/profile/share/emacs/yasnippet-snippets/nxml-mode' But emacs-yasnippet-snippets is installed in user profile... ***shtumf is now known as b0f0
***pukkamustard_ is now known as pukkamustard
<b0f0>bitlbee-dicrod plugin, how to add it in bitlbee ? <b0f0>thats bitlbee-discord plugin <b0f0>I have also put in config.scm so that sheppard runs the service, thats all fine <b0f0>but I dont know how to add the plugin to bitlbee <iyzsong>b0f0: Should be '(service bitlbee-service-type (bitlbee-configuration (plugins (list bitlbee-discord))))', according to the manual. <sneek_>iyzsong, civodul says: looks like you're the right person to look into https_proxy support :-) <mfg>Hi, what is the package name of libncurses5-dev in guix? <mfg>and generally: does guix even use -dev packages? <mfg>or is everything in one package ? <nckx>str1ngs: I tried Circe for real this time, but it chokes (badly) on my IRC setup ☹ (Which is probably special™: connect to ZNC with 86 open channels with 500 lines of scrollback each, except #guix, which has 2500.) <nckx>It means downloading and parsing a few megs every time, but Hexchat manages in ~15 seconds. <nckx>circe isn't even halfway after 5 minutes, when the first channels starts to time out, and the infinite loop begins… Oh well. <rvgn>I have few doubts. 1) Does GPT really have advantage over MBR because of backup partition table sectors and GUIDs? 2) Will GPT completely replace MBR over-time? 3) Does GNU Grub more compatible/supportive towards MBR or GPT? Thanks! <z0d>I think GPT is also better because it's more dynamic and can support larger partition sizes <nckx>1) GPT has several advantages over MBR, such as (many) more & (much) larger partitions, I don't think anyone is seriously saying it's the backup table that makes the difference 2) Nothing old is ever completely replaced, but it will probably replace the vast majority of MBR usage, and I for one welcome our new GPT overlords 3) Neither? Both are equally well supported in my experience. <b0f0>is list command the same as '() ? <nckx>b0f0: Yes and no? Both create lists, but list is a procedure and will evaluate its arguments: (list 'foo 'bar) is equivalent to '(foo bar), (list foo bar) to `(,foo ,bar). You can use both in any situation, but you can't just blindly substitute (list for '(. *nckx hopes they didn't make any typos there. <rvgn>z0d nckx Thanks! I was skeptical about GPT when I found out that GPT was designed by Intel as a part of EFI, where the "restricted boot" issue arised. So GPT have no issues with free software right? <z0d>as far as I know, it doesn't <nckx>rvgn: No, it's not related to restricted boot nor does it have any features to facilitate it. <nckx>Restricted boot requires UEFI, and UEFI requires GPT, that's the only ‘connection’. <mfg>Is there a short form for the github download uri when downloading releases with it ? <nckx>mfg: No, since they don't use mirrors. GitHub release URLs aren't that redundant, either… ‘https://github.com/’ and ‘releases?’ are the only constant, and IIRC not everyone even uses ’releases’. <nckx>That last bit might be nonsense though. Still, low redundancy. <nckx>mfg: There are folks who move HOME-PAGE above SOURCE so they can (STRING-APPEND HOME-PAGE …) but I'm not a fan of that pattern personally. <mfg>nckx: okay didn't know that :D, so duplication is the way to go? <nckx>mfg: What do you mean by duplication? I don't find the full GitHub URL *that* verbose. It's not like the insane SourceForge URLs… <nckx>You do you ☺ I've gots to go. <nckx>mfg: Actually, on second thought, please use the literal URL (minus version). Nothing more frustrating than having a working SF URL and having to figure out which portion(s) mirror://sourceforge/ takes and what it does to them. A (github-url …) procedure would be too much abstraction here. Nix (used to?) do this just because they could, I think, but it added little value. <mfg>I'm currently trying to build gperftools in order to be able to get klee done. i have this error: guix build -f gperftools.scm -> guix build: error: #<unspecified>: not something we can build <mfg>also i don't know if i need the arguments field and what i should put into t <civodul>mfg: make sure gperftools.scm returns the package you want to build <mfg>Hm, how do i debug this? i never used guile before ... :( <mfg>does that mean i'm missing some mandatory fields? <roptat>mfg, your file probably ends with a structure like (define-public ...) <roptat>define-public doesn't return any value, it defines a new guile variable <roptat>so, if you add the name of the package (variable name) you want to install at the end of the file, its content will be returned <mfg>Oh snap, yes i didn't notice ... thank you <mfg>Hm okay now i have another error which i can't interpret correctly ... <mfg>In procedure url-fetch: <mfg>Invalid keyword: #vu8(208 110 187 142 29 154 34 209 158 56 214 63 219 131 149 66 83 243 155 237 197 212 98 50 160 86 69 104 87 34 202 55) <mfg>did i forget a mandatory field? <roptat>no, the error would be different <roptat>can you share the content of the origin record? <mfg>of course with the other hint added which you gave earlier <roptat>yeah, I can reproduce your error message, but I can't see where the issue is... <mfg>then a generic question: how do i read the function calls in the backtrace in guile? <mfg>i don't understand what those underscores do <mfg>does it have something to do with ssl? because every other package definition i found which uses method url-fetch also uses http:// and when manually connecting it doesn't automatically redirect to https:// <mfg>and github doesn't provide http:// i guess <mfg>i found a definition which uses https <dongcarl>civodul: I have a riscv64 toolchain working on Guix, but I'm not sure where to put it in the codebase. It requires special things like `linux-libre-headers` > 4.15 and `gcc` > 7. I'm thinking that the `cross-base.scm` procedures should be parameterized a little more, and `standard-cross-packages` from `(guix build-system gnu)` can check if `target` is `riscv64` and pass `linux-libre-headers-4.15` and `gcc-7` down <civodul>dongcarl: have you tried on core-updates, which has all the newer tools? <civodul>that would also give us another incentive to get it ready :-) <civodul>the core-updates branch has a newer version of gcc, binutils, etc. <civodul>so it may be that you'd need fewer "special things" on that branch <civodul>and that would facilitate integration <ng0>mfg: it's a bit less non-obvious than "..." in guile as well as in C. it takes a while of reading until you find it. <mfg>ng0: sry i don't understand what you mean with "..." :( <ng0>for C, the ... parameter is easier to find. In guile I kept reading it and I only found it after a very long search through the documentation or maybe another book. <ng0>"_" is more or less inherited convention in syntax. Some of my early lisp books use it as well <mfg>Ahhhhh now i know what you are talking about :D i totally misunderstood <ng0>a variant of the base32, yes <mfg>it is the hash which is supposed to be set in the source form i guess ? <dongcarl>Well either way it would be better if the `cross-base.scm` procedures were more parameterized, just for reusability and the future <ng0>it's what you see as (sha256 (base32 "somethign...")) in packages <ng0>the variant of the base32 is in the source code somewhere. I haven't looked at it in a while... (I've started writing a small C application for this variant <mfg>Yes that't what i thought. At least the Documentation should mention that. <ng0>well it's still the sha256 but base32 variant encoded <mfg>Ah it even is stated in the Docs. One should read everything before complaining ... :p <ng0>though I'm a bit fuzzy on guix internals right now without reading my own docs <civodul>dongcarl: i agree about parameterization, though we also need to make sure cross-base.scm doesn't go out of hands ;-) <dongcarl>civodul: Completely agree. Hopefully I'll get those patches up soon! <mfg>At least i now managed to fix the error, but i really don't know how :D <ng0>Marlin1113: if in need and no source or package exists, a combination of ldd and patchelf worked for me back then (or a package which does this job). <civodul>my computer can only run binaries :-) <civodul>it looks like you're looking for something else though <civodul>and it looks like a déjà vu in fact :-) <ng0>civodul: iirc the only difference of nix and guix to rfc4648 section base32 is that the uppercase letters are out and no padding exists, basically a modification of the base32 extended hex alphabet. <ng0>at least in current day nix <mfg>How do i fix a bad interpreter error? A script in this pkg tries to run /usr/bin/env. how do i fill in the correct /gnu/store path? <str1ngs>mfg: you need to substitute /usr/bin/env <prog> to the store path of <prog> <ng0>you could create /usr/bin/env... I found that much easier than fixing every script I had. But maybe some of the proposals which were kicked around were realized. <str1ngs>no that's not the way to do it it. when packaging <ng0>i did not read this as packaging <ng0>but with packaging, i agree <mfg>str1ngs, ng0: indeed i am trying to package klee. Sry for possible confusion <mfg>i will search for an example in the repo <str1ngs>though I thought guix tries to auto patch shebangs? <str1ngs>or is that dependent on what build system you use? <mfg>maybe this is an generated file and guix does the substitution before this file gets generated <str1ngs>ah, good point. so the file is distributed ? <str1ngs>mfg: (substitute* "config" (("/usr/bin/env") (string-append (assoc-ref %build-inputs "coreutils") "/bin/env"))) <str1ngs>mfg: add that to the right build phase. <str1ngs>mfg: replace config with the file in question <ng0>str1ngs: that looks wrong. env usually calls something, and we should point to the something, not env.. or it depends on what is being pointed to and the content and purpose of the sript <mfg>Ah i found why guix didn't auto replace it ... It's a dependency not listed in the documentation :D it needs perl <str1ngs>ng0: it only replaces /usr/bin/env it would keep the env arguement $1 <str1ngs>though in this case if it requires perl. you can call perl directory <mfg>Yay!, the build and all tests succeeded. <mfg>So now i have it in the store. How do i use it now? <str1ngs>that will link into your profile. and off you go :P <katco>i need `libstdc++`. i did some poking into irc history and it looks like this has been asked a few times, but i wasn't able to find an answer. how can i install this in guix? <mfg>str1ngs: i built it with guix build -f, so it tells me now that the package is not known. So i do need a local channel to install it? <str1ngs>mfg: guix package -f ./file.scm iirc <str1ngs>katco: normally you would would use gcc:libs or lib forget which one. but gcc is has been hidden for some reason <ng0>this isn't gcc though, libstdc++ is done by llvm iirc <katco>ng0: at least in `gcc.scm` it's gcc <ng0>thought about a different libstd <katco>so currently it's uninstallable? <str1ngs>katco: I think if you use gcc-toolchain the effect will be the same. <katco>str1ngs: no, i won't be using g++. this is a runtime dep for a python cli util <str1ngs>for some reason gcc was hidden. I'm assuming you are using guix version > 1 ? <str1ngs>this makes gcc and gcc outputs unavailable. I'm not sure how to get around that. or the reasoning for it <str1ngs>maybe the alternative is to create a package with gcc:lib as an input <str1ngs>maybe someone else knows how to work around this . sorry <katco>no worries, str1ngs tyvm for taking the time to dig in <katco>if your package idea works, i can certainly do that, but this is an unfortunate situation for users who aren't familiar with guix packaging =/ <str1ngs>katco: I read some chatter that gcc was hidden. I'm not sure why. I'm assuming it's for a good reason of course. <str1ngs>katco: maybe there is something on guix-help ML about this <katco>hm a little chatter from ~1y ago. doesn't look like anything helpful... same with guix-devel <mfg>is there a complete guix function reference somewhere ? <pkill9>I don't think so, there is a reference for guile functions though <bavier>OriansJ: seems like a file that likely gets updated in place on the upstream website. <bavier>maybe you could find an older version on archive.org that has the expected hash <OriansJ>bavier: we may wish to consider caching such files in some way to prevent similiar problems from occurring in the future <bavier>OriansJ: my guess is that a substitute is available <bavier>I thought also that we'd fall back to a content-addressed lookup in most cases too <bavier>OriansJ: I can appreciate that. In this case, it seems like a missing bit is a piece of source though <dongcarl>d78010b81ee6ef4fd8803082e2f401b9e55b44db <dongcarl>BTW what do people use to inspect a package in `guix repl`? <dongcarl>Mostly for debugging... Like I want to see the version, name, uri, etc. all at once <str1ngs>dongcarl: thanks. I find it easier to just use emacs-guix <bavier>dongcarl: you can use the record accessors, like 'package-version', 'package-name', etc <dongcarl>bavier: ah right, I guess I was just hoping there'd be something that'd print out everything <pkill9>what's the difference between running `guix repl` and just `guile`? <pkill9>dongcarl: you could write your own function that prints all the package-* accessors and put it in the guile load path <OriansJ>bavier: Oh and for extra fun, manually downloading from archive.org all versions from 2015 to current and none of them match (might be a whitespace change???) I guess that is what I get for running guix gc <bavier>OriansJ: uff da, that's not good. <dongcarl>Any objections to bumping `linux-libre-headers` to be on par with `linux-libre`? Or just no one has submitted a patch yet? <dongcarl>Since we already have `flex-boot0` and `bison-boot0`, `linux-libre-headers-boot0` will also work <mfg>How do i change the directory before configuring a package because that package does not support in tree building ? <dongcarl>more context re: buming `linux-libre-headers`: `linux-libre-headers` is on 4.14, and `linux-libre` is on 5.1 <str1ngs>often though linux api headers do not have to have version parity. just a though <dongcarl>Well, I think it's more for internal consistency more than anything lol <str1ngs>I get it, I just wondering how it would effect rebuilds. I guess I should not comment I don't have enough grasp for guix toolchain. <dongcarl>str1ngs: Oh you mean it would force a rebuild of many things? <str1ngs>it's possible. I'm basing this theory though. not on a practical understand of guix's toolchain <str1ngs>maybe there is someway to gauge the impact of what would be effected after version bumping? <dongcarl>Haha yeah it's forcing a rebuild of my toolchain right now... <dongcarl>I think maintainers pull these multi-rebuild changes into `core-updates` first <str1ngs>yep, because glibc needs linux-headers. so if you use rebuild glibc guess what... :P <str1ngs>there must be something that show what would be rebuilt should you change a package. *dongcarl defers to the maintainer gods <str1ngs>also I wonder if the boot packages uses a set linux-headers ... hmmm <mfg>so i need to give the path to llvm@6 in a cmake configure flag i'm trying this: #:configure-flags '((string-append "-DLLVMCC=" (assoc-ref %build-inputs "clang") "clang")) <mfg>why does this not evaluate the append-string form? <mfg>and instead pass it unevaluated? <pkill9>str1ngs: `guix refresh --list-dependent` <kmicu>dongcarl: headers are older on purpose. That’s a good thing. <rekado_>dongcarl: we want the Linux headers to be a bit older. IIRC this helps with running binaries on older kernels, but I’m fuzzy on the details. <vagrantc>linux is usually very good about backwards compatibility, forwards-compatibility is tricker (e.g. predicting the future is hard) <vagrantc>so using older headers is generally safer <str1ngs>with the linux kernel yes, it's pretty safe <mfg>and i didn't even need to manually add the mkdir and chdir steps because cmake-build-system does out-of-src builds per default <rekado_>mfg: it doesn’t evaluate the form because ' quotes the expression <str1ngs>mfg: I almost mentioned that. but I didn't know for sure <rekado_>mfg: ' means “this expression is data” <mfg>ah so that's where i need the backtick comma thing? <rekado_>right, the backtick is a toggle switch <rekado_>I wouldn’t use quoting at all in this case: #:configure-flags (list (string-append "-DLLVMCC=" (assoc-ref %build-inputs "clang") "clang")) <rekado_>but I guess your string-append form is incorrect <rekado_>(assoc-ref %build-inputs "clang") becomes something like /gnu/store/…-clang-…/ <mfg>rekado_: why a plain list ? where is the difference ? <rekado_>mfg: the difference between (list 1 2 3) and '(1 2 3)? There is none. <rekado_>ultimately you just want a list value <rekado_>it doesn’t matter how you get there: via quoting, via “list”, via “fold” <mfg>and what did i do wrong with the string-append form? :D <b0f0>What is the standard pastbin tool for GNU Linux ? I mean if I want help with my config.scm file do I make a picture or is there a standard way to show text files beetween irc users ? <mfg>so it's just a matter of taste? <rekado_>mfg: '((string-append foo bar)) is a list of a list of symbols <rekado_>mfg: it’s the same as (list (list 'string-append 'foo 'bar)) <rekado_>mfg: in other words: it’s just data. <rekado_>mfg: you want this to be evaluated, so you need to either “switch to code mode” (using comma while quoting) or just not quote anything at all. <mfg>Thank you for the explanation rekado_ <pkill9>i think you need to use a backtick instead of an apostrophe if you want to use a comma <rekado_>yes, ' is “data mode” only. You can’t switch to “code mode”. <dongcarl>rekado_: Would it be bad to bump at least from `4.14.67` to `4.14.121`? I'm assuming same minor versions are compatible... <dongcarl>Only asking cuz we have `linux-libre-4.14` at `4.14.121` <rekado_>pkill9, mfg: Try this in a REPL: '(i want to use ,(the comma) here , but it doesn't work) <rekado_>you’ll get a list like this: (i want to use (unquote (the comma)) here (unquote but) it doesn't work) <rekado_>dongcarl: is there a reason for bumping? Since it’s old anyway I don’t see why any particular change in the minor version would be desirable. <mfg>the thing i find strange is the insertion of the semicolon which seems to be the error if i erad that correctly? <rekado_>mfg: can you show me which part of the paste is of interest? <mfg>second link in the middle <rekado_>mfg: it’s a ' — so this whole expression is plain old data. <rekado_>you’re using ` and , in there, but they get treated as data. <mfg>rekado_: you mean the arguments? <rekado_>so, LLVM_CONFIG_BINARY is wrong, because /gnu/store/bvnj04sqiwc1gcis29swk6likyc5dw8f-llvm-6.0.1llvm-config doesn’t exist <mfg>ah yes i pasted the wrong one <mfg>does not change anything <mfg>so it basically is the same paste but the path is correct <rekado_>I don’t understand what “correct” means when you get an error. <rekado_>(what I wrote above about line 58 being wrong is incorrect; I got confused with the evaluation order) <rekado_>LLVM_CONFIG_BINARY is still incorrect <rekado_>this file /gnu/store/bvnj04sqiwc1gcis29swk6likyc5dw8f-llvm-6.0.1/llvm-config does not exist <rekado_>it should be “/bin/llvm-config” or something like that <mfg>AAAAARRRRRRRGGGGGGGG ... <b0f0>is my config ok for bitlbee with bitlbee-discord plugin, can someone check my config.scm please. paste.debian.net/hidden/dfd7cc6f <mfg>nevertheless thank you rekado_, i guess i won't forget that in the future :D <dongcarl>line 89-93 of the diff can be simplified if we just do `(define-public linux-libre-headers linux-libre-headers-4.14)` <rekado_>dongcarl: I can’t seem to focus enough to follow :-/ <rekado_>dongcarl: parameterizing the linux-libre-headers seems like a good idea, even though I can’t seem to find a good reason for having more than one package providing the headers. <rekado_>dongcarl: framed this way I think it’s worth doing :) <dongcarl>rekado_: 25 and 26 are required post-4.15 I believe <dongcarl>I would like to drop the `-4.14.67` variant <dongcarl>but of course that bumps the default kernel-header <Marlin1113>civodul: yeah, i mean binaries as in non-packaged software <Marlin1113>there are some appimages i'd like to run, as well some itch games that are binaries <rekado_>dongcarl: this would probably be okay. <dongcarl>rekado_: Great! I'll drop the `-4.14.67` variant and it'll be much cleaner! <rekado_>not for the master branch, but I think the patch is fine. <dongcarl>rekado_: You mean it'll live in core-updates for a while since it'll trigger many rebuilds? <rekado_>I haven’t looked at the dependencies and the rebuild count, but I guess it’s a core-updates kinda change. <kmicu>So now headers depend on kernel version and kernel bump will update headers too? <kmicu>(Asking cuz Nixpks still hardcode headers version to avoid unnecessery mass rebuilds.) <kmicu>Nvm. It looks like it’s set in stone after all with ‘(define-public linux-libre-headers linux-libre-headers-4.14.67)’. <rekado_>kmicu: no, you’re right. If 4.14 gets regular updates because it’s a supported kernel package then this change would in fact lead to rebuilds whenever 4.14 gets updated. <rekado_>keeping an independent version number and hash that isn’t derived from any kernel package prevents this. *rekado_ needs to put brain to sleep *kmicu 😴 cuz it’s late here too. <dongcarl>kmicu: Yeah, I think my final patch will contain a `4.14.67` afterall... It'll get to master faster that way and hopefully not trigger mass rebuilds anytime soon... Not worth it just for code cleanliness <moet>how do i load firmware in the guix live installation environment? <moet>the documentation section 3.2 Hardware Considerations says "see firmware" but that section doesn't actually say how to load the included firmwares for wifi <dongcarl>If I `guix build` a package with no version number... Does it always build the latest version? <moet>vagrantc: according to that section, 3.2, "free firmware exists" for ath9k and b43-open <nly>Is anyone looking at content addressable storage for guix? <dongcarl>write your own package, it's pretty simple! <dongcarl>Marlin1113: I'd start by looking at `gnu/packages/linux.scm` <dongcarl>I believe you can just swap out the url and be good! <civodul>dongcarl: yes, "guix build pkg" builds the latest version of "pkg" <civodul>if "pkg" is ambiguous, you get a warning <dongcarl>civodul: Ah... so it's only in guile-land that we have `gcc` and `gcc-toolchain` as non-latest <Marlin1113>umm, where is gmu/packages/linux.scm located at? <nly>or you can do guix edit Linux-libre <b0f0>when you install a package and install it's plugin with 'guix install package' command. Do I have to do anything else like ocnfigure some config file. How does a package now that I installed a plugin for this package ? <b0f0>because my problem is that the package, when I run it, it reports that there is no such plugin. But the plugin is also a package and it is installed.