IRC channel logs
back to list of logs
<roptat>butterypancake, usually we add "CC=gcc", or patch files that use cc to use gcc instead (with subsittute*) <roptat>butterypancake, there's an example of that in omake (in gnu/packages/ocaml.scm) <roptat>not sure why it's a phase instead of being part of the make-flags <alarat>samba has a --localstatedir config option, on other systems that points to /var. On guix currently it points to /gnu/store/...samba/var, which doesn't work as it's read-only, and samba tries to write lock files and log files. Where would the right place to put it be? <mbakke>alarat: if it's not possible to override those at run-time, it should probably be set to /var <butterypancake>which yacc should I use in a package recipe? Which one is the cononical one? <alarat>mbakke: it looks like they can be overridden at run time. so the compile time option should be kept pointing at the store? <mbakke>alarat: if you are writing a Guix service it does not matter much, but perhaps /var would be a better default for the general case. You tell me! :-) <nckx>I say /var no matter whether they can or can't be overwritten. A broken default is just that. <mbakke>agreed, "localstatedir" and "the store" don't really belong together :P <nckx>In practice it just means the packager didn't notice, or they were too lazy to fix ‘make install’. <butterypancake>what user owns the store? is it root? Can I just assume all files made in the store are owned by root? <alarat>nckx: yeah I add that --localstatedir=var and make install fails <nckx>alarat: You'll have to teach the build system manners. <alarat>my limited time in guix has certainly given me ample excuses to learn more <nckx>Sometimes Makefiles do a (silly and unnecessary) ‘mkdir $localstatedir’ for no reason, sometimes they do more and you can fool them by setting localstatedir to $out/share/doc-xxx/examples only during the install fase, etc. <nckx>In the first case a simple substitute* to replace, say, mkdir with true is fine.
***wxie1 is now known as wxie
<alarat>I can patch them out (looks like one directory was already patched out with substite*) but then when will they get created? The program creates some of them at runtime but errors out on others if they're missing. <alarat>Or is that an issue to push to samba <nckx>alarat: The service needs to create them if the programme doesn't. <nckx>Some daemons refuse to create /var/food/… for ‘security reasons’, whether that's a legitimate reason or not… <nckx>alarat: See cups for a simple example. <butterypancake>I'm having trouble finding documention on substitute*. I'm not sure where to look :/ <nckx>butterypancake: guix/build/utils.scm <nckx>(I don't just mean ‘read the fine code’, there's an actual docstring there too 🙂) <nckx>I think it says all there is to be said, really. <butterypancake>well now that I know what module it's in I can import it in the geiser repl and now the describe symbol at point thing works for it <butterypancake>but how am I supposed to know which modules to import? I feel like I've been contantly asking questions on this IRC but I still don't know where I'd go for answers without this IRC <nckx>I thought you'd given up on the geiser lyfe. <butterypancake>it's not to intrusive. Emacs stopped freezing. It's just there in the background <nckx>butterypancake: Hum, you… just know? I dunno, really. Build side things are in (guix build …), and the most common helpers are in its utils. <butterypancake>It seemed like such a general function I kept thrifting through scheme manuals trying to find it :P <nckx>‘Thrifting’. I picture sifting through dusty second-hand Scheme books. <nckx>I wish my local thrift shop had Scheme books ☹ <butterypancake>lol, same. I grew up taking speach thearapy because I said all the words funny but I also just tend to use the wrong ones. I honestly thought my inability to use the english language was limited to verbal communication until I started to use IRC. I think I'm just bad at english :P <nckx>Don't sweat it. Most English speakers are. <nckx>That's not ‘regexp’, just ‘Guile’. <nckx>You could type a literal tab " " which would produce the exact same string but isn't very nice. "\t" makes it obvious what's going on. <nckx>I forgot what it was but huzzah for it! <butterypancake>In my emacs config I'm pretty sure it's almost impossible to type a tab <butterypancake>probably not. So I did mspdebug early today which was my first patch, but this is doas, a sudo replacement <nckx>Right. I'm surprised that wasn't in Guix yet, glad it will be soon. <mroh>nothing is impossible in holy heaven <butterypancake>for mspdebug I installed it on my machine, but I don't know if that's how I should do it <nckx>butterypancake: You've chosen a harder than average package to test, because I'll bet it needs to be setuid, and store items can't be setuid. <nckx>butterypancake: Do you use Guix system? <butterypancake>and I just installed it using ./pre-inst-env guix install opendoas <nckx>OK, then you can add it to setuid-programs in your operating-system and reconfigure using sudo ./pre-inst-env guix. <nckx>Something like, roughly from memory: (setuid-programs (cons* #~(string-append #$doas "/sbin/doas") %setuid-programs)) <butterypancake>so I need to do a guix system reconfigure to set opendoas as a setuid-program? <nckx>This song & dance is necessary because setuid store items would be a security risk. <butterypancake>and I'm doing this reconfigure using my system guix, not the checked out guix <nckx>No, using ‘your’ ./pre-inst-enved guix. <nckx>To create a setuid copy of the doas binary in /run/setuid-programs. <butteryp`>that's a good sign, computer just restarted for no reason :P <nckx>(‘opendoas’ just sounds weird, like there's a proprietary Oracle version out there.) <butteryp`>I did a reconfigure like 3 hours ago, but never did the restart. Maybe it just really wanted that restart :P <butteryp`>or maybe a full day of running my crappy packages on it finally took its toll <nckx>butteryp`: butterypancake has quit (Read error: Connection reset by peer) <nckx>butterypancake: I don't want to IRCsplain but you're aware of /nick, right? <nckx>From here it looked like you quit just to get your nick back. <butterypancake>ya, but #guile didn't like that cuz I was "quieted or something" <butterypancake>bruh, I've been using IRC for like maybe a week. You can't IRCsplain to me. I don't know anything <nckx>That would be /close, at least on my client. <butterypancake>people do that thing where the line starts with a * to emote them doing something and I still don't know how to do that <nckx>butterypancake: Type: /me now knows how to do that. *butterypancake has learned a thing *nckx gets ready for bed time in ~15m. <butterypancake>ya, I've been doing this for too long. I really should quit. Like at least wait for someone to comment on your first package before finishing your second am I right? <nckx>butterypancake is about to learn harsh things about our patch review speed. No. Don't wait. Seriously. <nckx>butterypancake: Some people call them recipes. I call them packages, simply because I hate the word recipes. That's all there is to it. Call them what you like. (Packages!) <butterypancake>I mean, I kinda feel like they are a recipe as they don't actually include the ingredients (you gotta go download those) but also I think web dev people use the term recipe so I don't like that term <nckx>When forced to differentiate between the abstract concept of ‘the package’ and the actual Scheme code I say ‘package experession’. This happens roughly never. <nckx>butterypancake: I think it reminds me of cutesy 90s distros (there was one that called them ‘spells’ ffs) but honestly idk. <butterypancake>as an end user, it's a package. As a packager, maybe there is room for discussion. But things should probably be named for the consumer, not creator <nckx>This is Russell-level bikeshed epistemology. <butterypancake>I don't have emojis installed :P is that a sleepy one? You leaving? <butterypancake>sleep well! Thank you so much for all your help. You've saved me many hours <butterypancake>I added opendoas as a setuid program, and now I can use it to do root like thing!!! <ericonr>Hey there! Anyone here have experience with packaging Guix for a foreign distro which does cross compilation? I'm not sure how I can tell Guix to search for bindings such as gnutls without having them installed in the host system as well <ericonr>It fails with > configure: error: The Guile bindings of GnuTLS are missing; please install them. <xelxebar_>There's a commented out test with a comment "Broken" <xelxebar_>Would like to see if the tests run with that test enabled, so please un-comment it <wdkrnls>[FAIL] tests/tests-avx512pf/test-00001 <wdkrnls>[FAIL] tests/tests-avx512pf/test-00002 <wdkrnls>[FAIL] tests/tests-avx512pf/test-00003 <wdkrnls>I have an i5 processor from 2015, so maybe that's too early for avx512? <wdkrnls>builder for `/gnu/store/q2ry8ldrb10hlrsxf980nkpgg0dw3ab0-xed-11.2.0.drv' failed with exit code 1 <xelxebar_>wdkrnls: Thanks. Same tests failing on my machine too. <xelxebar_>The package shouldn't actually be using any avx instructions at all. It's just encoding/decoding opcodes and assembly mnemonics. <xelxebar_>Plus, the separate tests/tests-avx512 look to be passing just fine. <xelxebar_>The avx512pf ones are just for the group of prefetch instructions. <xelxebar_>Anyway, I'll just share the patch with the broken tests commented out. Thanks for the sanity check. <pkill9>it would be good if commands like `guix pull --news` that output lots of names of packages would output them in columns, like the ls command does <ryanprior>I agree, the news is quite hard to read at present. I've been pulling it into an Emacs buffer for reformatting but there's no reason it shouldn't be pleasant by default. <usney>Does the guix package manager check the software with a signature before installing either from binary or source? Like apt does with debian <mroh>maybe an idea for the 1.1.1 release: include our 2 rtl88*-linux-module in the initrd of the installer img. <usney>are you talking to me mroh ? <reepca>usney: substitutes are signed, and the signatures are indeed verified. <reepca>every package specifies a cryptographically-secure hash of the source used, and this is also verified <reepca>ultimately though, the hard work of verifying these things is on the packagers, in verifying that the source they hash to put in their package definitions was written by the people it claims to be written by <usney>Just making sure because my internet has been acting strangely disconnecting and reconnecting. Some sites I use regularly have reloaded unecrypted even though I use https everywhere. <usney>I am going to reinstall a different distro <usney>I am using a different distro, I used guix with a foreign distro. *raghavgururajan peeps-in. o/
***link2xt[nm] is now known as link2xt
***wxie1 is now known as wxie
***familia_ is now known as familia
<nckx>lfam: xdot search actually works (IceCat's didn't)! This changes everything. Thanks lfam. <lfam>Yeah, --path is a great feature <nckx>Is it very new? I wasn't aware of it. *nckx pinches its cheeks overjoyedly. <butterypancake>nckx: all I learned about execvpe was that it was added to glibc back in like 2.11 (our glibc has it). Basically, if the compiler can find glibc, you should be good. My problem with execvpe was actually that the configure script never checked for a compiler and was using cc. So the execvpe test was failing because it wasn't even using a compiler :/ now the aarch64-gcc should be able to see glibc I would think. However you'd h <butterypancake>check the environment variables. I think the aarch64 glibc is actually in an environment vaiable called like CROSS_C_LIBRARY or something. I'm not sure exactly why the CROSS environment variables exist, but they don't show up without a target <butterypancake>the silly thing is, I confirmed that the configure script is using the aarch64 compiler, and somehow is can indeed find execvpe. Now the flags in the configure script are quite different from in the makefile so you could look into that, but the configure script is so bad I'm not quite sure what the flags are <pkill9>i want a ranger-style browser for browsing guix graph output <nckx>pkill9: The lack of tooling (that I know of) for the dot format is rather disappointing. ‘Render it to a flat image, then drag that around the screen’ when it could be so much richer. *nckx must play around with xdot s'more. <raghavgururajan>Hmm. Is there a way for someone else to build inkscape for me? Like exporting from someone's store and importing into my store? <nckx>raghavgururajan: Which .drv? <nckx>Full /gnu/store/*-inkscape-*.drv file name. <nckx>guix.tobias.gr might have it, but it's backed up too. <nckx>It has /gnu/store/cnck9rzqjmssmk7mc6mmp6168gkhk8p2-inkscape-0.92.4.drv (/gnu/store/b6k81pq4sjzqj7lbng54rn8qc0c7wp0i-inkscape-0.92.4).
***sputny1 is now known as sputny
<nckx>‘Backed up’ being a colloquialism for ‘behind on work’, nothing to do with back-ups, sorry if that was confusing. <raghavgururajan>nckx: /gnu/store/wsxb8smh7yln0s6lpz0yknzkv43a15dq-inkscape-0.92.4.drv <cbaines>raghavgururajan, out of interest, how did you get that derivation? (what command did you run for example) <nckx>Oh, it's not an upstream inkscape? <raghavgururajan>I did not change inkscape, but I might have changed one of its deps. <lfam>I wonder if we can provide access to a faster computer <nckx>It would seem so, since an inkscape built from master is /gnu/store/cnck9…. <cbaines>OK, I was interested because data.guix.gnu.org didn't know about it <cbaines>but if you've got local changes that affect inkscape, that would explain it <nckx>raghavgururajan: OK, I'm building your patched inkscape. If the hashes match. <nckx>Long time (to me) dustyweb. <raghavgururajan>Hmm. Are substitutes built for all branches? May be current wip-desktop branch can be used to build a substitute for inkscape. <nckx>And hoping the same of you. <nckx>raghavgururajan: No, only branches that Cuirass is configured to build (either automatically or as a manual one-off evaluation). <lfam>So, core-updates-core-updates is the core-updates branch <lfam>guix-master is the master branch. guix-modular-master builds for `guix pull` <nckx>raghavgururajan: Simply pushing a new branch to Savannah doesn't change what's built on berlin (ci.guix). <nckx>That would slow down master substitutes, too. <cbaines>I'm hoping to hook that up to an instance of the Guix Build Coordinator that I've been working on recently to actually build things, as well as computing the derivations <nckx>Even just computing the derivations would be nice and relatively cheap. <cbaines>You can even fetch substitutes for the derivations <nckx>I see: I need to poke around the GDS more again 🙂 <lfam>How do you get around having to bake the substitutes nckx? <cbaines>Each row in the table represents a state of the repository, with the timestamp and commit <lfam>Is it just `guix publish`? <kmicu>A capital invests in Nix infra. Who invests in Guix tho? <nckx>lfam: Oh yeah, it's nothing fancy, it's guix publish + a caching proxy + some simple logic that populates the cache when the ‘CI’ system is idle. So users get a pre-cached hit or it's streamed straight from guix published (and cached), depending on load. Nothing fancy. *kmicu makes Guixix‑a cache for Guix devs. Invest your capital. <nckx>raghavgururajan: I just checked my terminal and it's building everything from gtk@2 up, not just inkscape, so I don't know how long it will take. <nckx>☝ That's basically what I do, but (ushers small children out of the room) in bash. <kmicu>‘Obsidian Systems is excited to bring IPFS support to Nix’ you see, a little bit of capital and Nix gets feature after feature. <kmicu>Guix+IPFS could use that IPFS Grants Platform money too. <cbaines>money is important, but peoples time is more important I feel <nckx>kmicu: Which IPFS grant? I am interest. *kmicu pasts [Why not both meme?] <mroh>kmicu: interesting, thanks for the link! *nckx wonders if a proposal for GPL3+ code would be accepted. <nckx>raghavgururajan: Inkscape's almost finished. However. I have pulled (guix d1fa24a + your ‘diff.diff’ patch). ‘guix build --dry-run inkscape’ returns /gnu/store/vzlyxgx8yascb5pay1s3giyxx1y5jiwn-inkscape-0.92.4.drv. That's not the same hash you posted above, so you won't get a substitute. <nckx>You've changed something else, or we're not working from the same base commit. <nckx> /gnu/store/a2l55bb1hwl4c10h0zz7ghbdav4yrpx7-inkscape-0.92.4 is ready. <nckx>raghavgururajan: I wonder what other patches are in your ‘git log --format=oneline origin/master..HEAD’. <nckx>lfam: I was wondering the same thing. I can't think of any security issues with regular user bayfront access. <lfam>We recently did something like that <lfam>I also don't have an idea of how busy bayfront is currently <lfam>But, it would be nice to have a decent server with a few seats for things like this <nckx>raghavgururajan: Alternatively, do you have your own git repository that you could just push to & I could pull from. <cbaines>disk space is the main issue, but I have some ideas about that *nckx rebases on wip-desktop… <raghavgururajan>nckx: Could you pull current wip-desktop and try `./pre-inst-env guix build clutter --dry-run`, to see the hash for inkscape? <nckx>Yeah, that's what I'm doing. <nckx>OK, so then diff.diff contains nothing new. Correct? <lfam>Would be nice to get a bigger disk on there
***Cairn[m] is now known as cairn
<raghavgururajan>nckx: Just a sec. The diff.diff has patches I sent to Danny. But he made some changes before he pushed to wip-desktop. <nckx>cbaines, lfam: Does bayfront have RAID. <bhartrihari>Hello, if I define a package using `define-public` in my config.scm before operating-system definition, is that enough to be able to list it in my packages list to have it installed? <cbaines>nckx, I believe so, two 4TB hard drives in RAID 1 <nckx>raghavgururajan: Ah. Well, I'm pulling (not pre-inst-enving because that's hardly faster on this machine) wip-desktop now. *lfam looks in maintenance.git <cbaines>lfam, there's a thread "Bayfront hardware" from a month ago which is somewhat related <nckx>Sorry, I was unclear, my real question was ‘could we just add more drives or do we need to replace the current ones wholesale?’. <cbaines>nckx, I believe there's plenty of connectivity, but probably only 2 bays for 3.5inch sized drives in the case, both of which are in use <cbaines>This is mostly me guessing though, I could be wrong <lfam>I'm not sure if it's exactly the same, but the specs on newegg show 6 SATA slots <nckx>Thanks 🙂 Andreas will know. <lfam>And the hardware manual is in maintenance.git <lfam>It seems the limiting factor is datacenter access during covid <nckx>I don't know the current situation in France (let alone which ‘half’ the data centre's in) but at least one country over that wouldn't be a problem now… 🤷 <nckx>Well, plus, the only opinion that matters is Andreas', whatever they're comfy with goes. <lfam>Well, that means we should buy hardware now so it's available when we have access again <cbaines>I've just removed the staging and core-updates specifications from Bayfront, so hopefully that'll reduce the disk space requirement <cbaines>although I'm not sure exactly when... I think Cuirass creates gc roots for things, and they expire after some time... <cbaines>anyway, it should be just building master now <nckx>cbaines: Is there a similar lopsided huge-ass-disk-image situation there? <nckx>IIRC changing the policy for those on berlin made a huge diff. <nckx>raghavgururajan: No grafts: /gnu/store/ms4jvikgjwa5fvngdamqi7l0yfdcbvs8-inkscape-0.92.4, grafts: /gnu/store/a2l55bb1hwl4c10h0zz7ghbdav4yrpx7-inkscape-0.92.4 <cbaines>I think the same scripts to handle disk images are in use on bayfront and berlin <nckx> And /gnu/store/a2l55bb1hwl4c10h0zz7ghbdav4yrpx7-inkscape-0.92.4 is available from my 'toots server. <guix-vits>bhartrihari: idk, but if you don't use this package outside of config.scm, probaly it's enough to simply '(define' (instead of -public)? <nckx>bhartrihari: Sorry, I totally missed your question. It's enough to use in (packages …), and as guix-vits righly notes you don't need -public. <civodul>bricewge: /gnu/store/skdy6z15p5y7xxs3a87d298bazwqnyrn-guile-static-3.0.2 is available from your favorite substitute provider <nckx>raghavgururajan: Remember to authorise my key and use --substitutes-urls= if you want to try it. <bhartrihari>nckx: I do get an error with both define-public and define: `unknown package`. I can install it when I define it in a separate file and install from the file. <nckx>bhartrihari: It won't be available on the command line if that's what you mean. <nckx>bhartrihari: Could you paste(.debian.net) your configuration & the error you get? <raghavgururajan>nckx: After refreshing my local wip-desktop branch, `./pre-inst-env guix build clutter --dry-run` gives /gnu/store/wsxb8smh7yln0s6lpz0yknzkv43a15dq-inkscape-0.92.4.drv and /gnu/store/shi094v95an5h7vm2yj9hakgml1l3xjy-gtk+-3.24.14.drv <nckx>I have the inkscape .drv but not the gtk+ one. <bhartrihari>nckx: do you want me to paste only the package definition or the whole config? <civodul>janneke: yay for the wip-hurd-vm reset! <nckx>bhartrihari: The more the better. <raghavgururajan>nckx: You have the /gnu/store/wsxb8smh7yln0s6lpz0yknzkv43a15dq-inkscape-0.92.4.drv??? <nckx>bhartrihari: A complete configuration is much easier for us to download and ‘guix system build’. <nckx>raghavgururajan: I do (I didn't track where it came from, sorry). It builds /gnu/store/ms4jvikgjwa5fvngdamqi7l0yfdcbvs8-inkscape-0.92.4 so that's also available as a substitute. <janneke>civodul: thanks for bearing with me...bit of a curvy roed <civodul>janneke: heh, i did my share to bend it a bit more :-) <raghavgururajan>nckx: How do I add your build farm inside my local wip-desktop branch or pre-inst-env? <nckx>raghavgururajan: Yes, it's a daemon property. <nckx>It will use whatever's defined in your system configuration, or the default (ci.guix) if that's nothing. <nckx>And if you haven't added the key it will (almost) silently ignore it. <bhartrihari>nckx: It worked. It seems that specification->package cannot handle strings naming file-local variable. <alextee[m]>nckx: isn't .gr for greece? how did you get that? <nckx>bhartrihari: Nope, it doesn't look in the local environment (TBH I don't know exactly where or how it does look.) <nckx>alextee[m]: a) Saw it was still available b) Didn't believe it c) Tried to register it anyway d) Mine. <nckx>.gr has no residency requirements, but there are relatively few registrars that offer it. <nckx>I thought it would be rather obvious that it's just for my initials but plenty of people think I'm Greek now. 🤷 <raghavgururajan>nckx: I was just reading about per-command technique in manual. Btw, guix archive is one-time thing? <cbaines>civodul, regarding packages being up-to-date, I'm not sure they're really conclusions, but my thoughts still center around patch review processes <alextee[m]>hehe, i'm used to .gr being greek sites. the owl looks pretty greek too <nckx>raghavgururajan: Yes, it modifies /etc/guix/acl. It's permanent until you remove my key from there. <cbaines>mostly because that will make it easier to open that up for people to push to, which could be an interesting prospect <cbaines>I also want to make another pass at building derivations from the data.guix-patches.cbaines.net Guix Data Service instance, but this time with the Guix Build Coordinator rather than Cuirass <nckx>raghavgururajan: Just saw you in my logs 🙂 Wonderful. <nckx>So would any kind of tagging system to remember which key is which a year on. *raghavgururajan Ctrl+X's inkscape's build. *nckx starts building gtk+ 😛 <nckx>cbaines: Thanks for complimenting my mad CSS skills by the way. Now I can legally go put ‘full stack’ on my CV. \o/ <nckx>raghavgururajan: gtk+ forces ‘make -j1’ :-/ But it's available now. If you get a 404 it's a cached one, so, er, wait a while longer then, I guess. <bricewge>civodul: Thanks but I'm actually looking for guile-static-stripped-3.0.2 and I don't know how to build skdy6z15p5y7xxs3a87d298bazwqnyrn-guile-static-3.0.2 <bricewge>When it find a package to update it try to build it (so the substitutes are cached), submit a patch and ping the maintainers of the package to review it <bricewge>“The nixpkgs-update mission is to make nixpkgs the most up-to-date repository of software in the world by the most ridiculous margin possible.” It looks like they are succeeding <TZander>... in the mean time there is a new release of Qt out. <civodul>bricewge: interesting! now we know what to do, we have pretty much all the pieces <civodul>(except EU funding and seemingly unbounded computing power) <mjw>Feels oddly familiar, but also a bit confusing, since instead of one data-structure/language to rule them all, it uses a mixture of tools and languages. *kmicu was very happy to see civodul mentioning Shake paper in a recent Guix post. <Kozo>Hey Guix, I need help understanding the difference between --system and --target. What is the diff between build and cross-build? Aren't they both making something for an arch that isn't the machine that's building it? <bricewge>Hey Kozo, I was wondering about it earlier in the day, so take it with a grain of salt. <bricewge>--system allow you to build for the specified architecture only, while --target will give you result working on both architecture (the host and the target) <Kozo>I am trying to build guix image for my arm device. I never seem to have much luck with --target and --sytem will actually finish a build but still working on the right u-boot loader <bricewge>Kozo: Doing the same thing for a Beaglebone Black ATM. <NieDzejkob>--system is basically indistinguishable from if you built on ARM itself <NieDzejkob>--target is classical cross compilation and all the frustration that comes with it :P <Kozo>NieDzejkob: I see, thank you. My arm device overheats before it ever finished a build. Which is why I'm trying to do it on my nice desktop =P <civodul>mjw: in the end, other than hashes, it's very different: OSTree is essentially a storage tool <civodul>but the idea of combining Ninja and OSTree is smart <civodul>(if i'm entitled to that assessment ;-))