<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
<roelj>Woah, did ci.guix.gnu.org get a much faster uplink? :D <rekado>roelj: do you happen to connect from a research network? <rekado>roelj: we did remove one bug that made “guix publish” slow, but other than that we didn’t manage to fix any other problem <rekado>woah, RHEL deprecated GNU screen; it’s removed in RHEL 87 <rekado>“The screen utility has an old code base that is not easy to maintain and with little activity in the upstream community. The tmux package was viewed as having a better code base to maintain and build new features upon. Maintaining both within RHEL was becoming increasingly unfeasible when considering keeping up with CVE security errata, government security certifications, and similar requirements. For those concerned with DISA STIG <rekado>requirements, tmux satisfies the requirement as an alternative to screen.” <kmicu>Makes sense. Now they can also maintain less C by removing tmux too and recommending Emacs+TRAMP. 😺 <civodul>the same reasoning could apply to many (most?) C packages <civodul>and they make it sound like screen has CVEs every day, which is probably not the case either <civodul>"guix lint -c cve screen" returns nothing <mbakke>next they'll remove all C compilers other than clang because diversity is bad, I guess <civodul>well, RH is employing many of the GNU toolchain developers <rekado>it’s an odd move because tmux cannot connect to serial devices but screen can. <rekado>hardly a replacement, unless you only use it as a terminal multiplexer <ennoausberlin>I am trying to create my first package definition, but I failed. I want to import pyprof2calltree. The package definition looks good, but somehow the install fails <civodul>rekado: i guess it's the main use case <ennoausberlin>Is this the right way to do? guix package -f ./prof2calltree -i python-prof2calltree <ennoausberlin>./prof2calltree is the name of the edited package description file <civodul>ennoausberlin: the file passed to "guix package -f" must return a package object <civodul>if you wrote "(define ...)", the result is not a package object, it's the "unspecified" value <ennoausberlin>I get the following: guix package: error: python-prof2calltree: unknown package <civodul>also, you can't use -i in this case because "python-prof2calltree" is not known to Guix <roelj>civodul: rekado: I used to not be able to get more than ~3MB/s when downloading substitutes. This morning I noticed speeds up to 20MB/s. This is on a network with 1Gbit/s download. <kmicu>We have programs for serial connections, no need for a big C code base to perform a simple task. <ennoausberlin>civodul: Great. Without the extraneous -i argument it installs fine. <kmicu>(Though to be consistent RH should also deprecate Bash (which is ‘too big and too slow’ as stated in its manual) and many more outdated C tools ;) <roelj>rekado: 116.07M 18.5MB/s in 15s <roelj>rekado: I see it seems to start slow and increase gradually. So the longer your download the faster it gets. <ennoausberlin>civodul: Is it common practice to "publish/export" such an package definition? There was not much to do after guix import pypi, so even guix/scheme beginners like myself can do this. On the other hand it might be convenient to have this package publicly available <roelj>rekado: I'm happy to spend some more time to help debugging if that helps you in any way. :) <PurpleSym>mbakke: If you have not looked at the CVE for json-c, I’d take a shot, but it probably requires a version bump and soname change. <rekado>roelj: could you please send me tail of a traceroute? I’m curious to know how it differs from mine. <mbakke>PurpleSym: we have a new version of json-c on the 'staging' branch, I was hoping to merge it shortly but the CI has not made a lot of progress <mbakke>so maybe we should graft the fix meanwhile <PurpleSym>Ah, ok, my bad. I only looked at core-updates. <MSavoritias>so turns out the message I get from the Wifi adapter is [10681.700196] traps: telepathy-idle[18514] general protection fault ip:7f67241c8d22 sp:7fff4ee39ac0 error:0 in libgobject-2.0.so.0.6200.6[7f672419d000+33000] <rekado>roelj: you probably won’t get to the final node, because it doesn’t respond to pings <rekado>but the route would be interesting anyway <roelj>rekado: It looks like I get a response from the first 11 hops. After that (now at hop 45) I get the very interesting three stars. <roelj>rekado: So it seems to have reached the destination in 11 hops. <mbakke>PurpleSym: thanks for the info wrt json-c, very useful <mbakke>I will patch json-c on staging to include the security fixes and start porting the packages that are "stuck" on json-c 0.13 and 0.12 to 0.14 <bricewge>mbakke: staging-next is failing on make authenticate since I branched it out before your git magic on staging. What to do about it? <mbakke>bricewge: since it's just the one patch, let's rebase the branch on top of staging <mbakke>bricewge: it can wait until the branch gets promoted to 'staging' though <mbakke>unless you have other patches in the queue :) <civodul>ennoausberlin: yes, if you want to build a "channel", you have to provide that package in a file that defines a module and exports the variable <bricewge>mbakke: No other patches for it, I was just feeling bad about it's state <bricewge>So rewriting history is kinda ok for non official branches (master, staging and core-updates)? Or it's a special case? <civodul>bricewge: the convention is that branches named "wip-" may be rebased <civodul>other branches are normally not rebased <bricewge>Thanks, it makes sense; it's in the name <dutchie>am I misremembering, or is there a handy tool to help writing definitions for updated packages? <abralek>Hi, Does anybody knows what would be the simplest way to get gcc-3? it has libstdc++.so.5 which snx vpn requires? <rekado>it may predate even the first GCC packaged in Guix <abralek>haha, well but there is that Check Pint SNX vpn thingy which is also ancient. But it is still in used at work <abralek>according to ABI policty gcc 3.3.1 is the latest one which ships with libstdc++.so.5.0.5 <rekado>I hit an obstacle in reducing the pandoc closure size. <rekado>I’m now splitting static and shared libraries into different outputs <rekado>this helps but I would like to link the pandoc executable statically <rekado>just to see how much smaller that would be <rekado>pandoc support static linkage with “-fstatic”, but linking fails for some reason <rekado>I’m suspecting that GHC records the location of the libraries (in the “out” output) and doesn’t know how to find the static variants <butterypancake>the guix manual mentions trying to build your package on other platforms, but it doesn't mention trying to cross compile your package. Is that not important? How do I test cross compiling? <butterypancake>oh no, looks like I can't build my package using the arm qemu for some reason. It doesn't even start <civodul>butterypancake: in practice a lot of software packages cannot be cross-compiled <civodul>so we mostly focus on ensuring that "core" packages can be cross-compiled <civodul>cross compilation is made by using the '--target' option <butterypancake>I'm working on opendoas, which is going into admin.scm and is probably considered core <butterypancake>I don't get it. I try to run a build using qemu, and it trying to run the system native guile executable and then compains about "No such file or directory" <janneke>omg, the cross building c++ packages for mingw seems to have broken again (since the core-updates merge) *janneke needs to create a bug report <janneke>what if we just call c++ a failed language? <jonsger>janneke: maybe c++ on guile will help :P <janneke>now i'm looking for a real simple hello-c++ package <bricewge>Investigating while we can't build initrd for ARM since 57833803b446484b6f413fb883b2156933c38639 <bricewge>I have found that guile-static-stripped-3.0.2 timeout is 10 times lower compared to what is defined <lfam>bricewge: Cuirass doesn't honor those properties *lfam looks for reference <lfam>They should definitely be increased for armhf... or something <lfam>It's kind of a problematic platform <lfam>Quite slow and usually poorly built, and without much future now that 64-bit ARM machines are cheap and ubiquitous <bricewge>Oh well... So I have to build it myself and hope that it doesn't fail during the 20 hours build <jonsger>lfam: really powerful aarch64 machines aren't that common. I did a research recently <lfam>bricewge: The daemon should honor these values when you set them as options to `guix build` <lfam>jonsger: Yes, but even a Cortex A53 is faster than any armhf board, and the Cortex A72+ series is even faster <janneke>oh...master is fine: /gnu/store/1hmzj2z67la7qkj3msm2wgc168xm97c1-wxwidgets-mingw-3.0.5.1 <janneke>so, i'm goofing somewhere -- makes me very happy! <lfam>Maybe the Beagleboard X-15 compares, not sure. But the Novena, which was several hundred dollars, is slower than a $40 raspberry pi <jonsger>lfam: sure but I looked more on ARM server stuff "comparable" to x86, Marvell ThunderX and relevants... <lfam>I was comparing aarch64 it to 32-bit ARM (armhf). There weren't any workstation or server-class armhf machines at all, AFAIK <jonsger>I could set up a build server on my broken Nokia N900. 1 core 800MHz and 256 RAM :P <bricewge>lfam: I mean, since the build-farm won't build it because it doesn't honor the timeout properties, I have to build it on my own. <lfam>I wonder how long it would take to build Guile 😭 <reepca>"640K should be enough for anybody" <lfam>bricewge: Right. It's basically a bug that there is no substitute, however <lfam>It could be built "by hand" on the server <lfam>Like `guix build guile-static --timeout=1y` <civodul>lfam, bricewge: i actually did just that on berlin yesterday or so <civodul>on the upside Guile master has a master "baseline compiler" <civodul>i really hope we just won't have that problem in the future <lfam>I think it would be nice to know how many people are using the armhf port (based on how often substitutes are requested) <civodul>bricewge: there's a separate path in the compiler for -O0 <butterypancake>so I built a package using --target=aarch64-linux on an x86_64 machine. the build process spat out a path, and when I tried to run the executable I built at the end of that path, it worked. That means something is wrong right? I'm not sure how this could happen... <lfam>I figure it wouldn't do anything but I don't think that '--target=aarch64-linux' is valid <civodul>should be --target=aarch64-linux-gnu <bricewge>lfam: I guess very few people are using it otherwise they would have probably complained about it too <lfam>Sometimes people do complain. But it's hard to get a sense based onthat <bricewge>I was just trying to build Guix for a Beaglebone Black <butterypancake>also in the manual, section 14.6 number 5 has the system switch as aarch64-linux <lfam>Right, but that's for --system, not --target <lfam>Well, sounds like it worked anyways! <butterypancake>well yes. It works with --target=aarch64-linux but it fails with --target=aarch64-linux-gnu <bricewge>butterypancake: Then it's fine. What I understand is when executing a foreign binary, the kernel will check the magic number, then look under /proc/sys/fs/binfmt_misc/ for an appropriate interpreter and execute such binary with it (here qemu). <butterypancake>jesus. so guix is just magic. Thanks. didn't know it could do that <lfam>I guess it learned how to automagically guess what you mean *civodul finished 3h of video conf, ears bleeding, bah <lfam>Ugh, the rise of video chat is a minor disaster <lfam>I don't think anybody likes it <bricewge>lfam: Does Guix Data Service support that (number of download for a substitute) yet? <lfam>I don't know bricewge. Maybe cbaines knows :) <lfam>Wow, certain `guix package` operations are fast enough now that I thought it was broken <butterypancake>is there a good way to enter a guix environment with --target set? <lfam>What do you mean, "figure out the name"? <lfam>Like, what the /gnu/store directory would be? <jackhill>lfam: that said, it would be nice to have some of the videoconference stuff packaged in Guix, but some of the JavaScript, Kotlin, Java dependency graphs seem insurmountable. I ended up using automagic installation scripts on FHS comlient distros for my need, and it really made me appreciate Guix. <jackhill>I mean, I did already, but even more so. <lfam>Yeah, it's definitely a weak point for Guix these days <lfam>It's a weak point for free software in general <jackhill>but perhaps we can make it better in the future :) <cbaines>bricewge, lfam as for the Guix Data Service having data regarding substitutes being downloaded, it doesn't yet. <lfam>Especially since all the stuff under the hood (like codecs) is free software <cbaines>although it's some data that would be nice to have <butterypancake>so I think I know why --target=aarch64-linux would work but --target=aarch64-linux-gnu would not. It's becuase I set the compiler to be (string-append target "-gcc"). However, --target=aarch64-linux-gnu is actually running a c compiler, just one that can't acced glibc. --target=aarch64-linux is running a c compiler that can access glibc <roptat>speaking of Java, I'm still working on my wip-maven-build-system branch, it's taking longer than expected because I need to check I don't break too many things <roptat>I'm hopeful that this week-end I'll be able to push a first version of it <jackhill>roptat: +1. I appreciate that work! woo! <roptat>I had a hard time with junit, but in the end it turned out I shouldn't have updated it, then I spent most of my time rebuilding the java world... <bricewge>Does the offload feature support building via binfmt? <bricewge>When offloading does the client have to stay connected to the machine it offload to? <bricewge>roptat: Thanks, that what I was reading but it wasn't clear since the field 'build-machine-system' only take one entry <roptat>actually, it's not even offloading, binfmt is for building on your machine for another architecture <roptat>so set your own machine as an offload machine <civodul>binfmt support is completely separate from offloading <civodul>if you set it up on your machine, then you can run "guix build -s whatever" <civodul>no need to add a /etc/guix/machines.scm file <bricewge>Yeah but my laptop is really nosy so I wanted to make that build on a fanless one since the build may take 20 hours or so (guile-3.0-static for armhf) <civodul>bricewge: so my attempt to build it yesterday on berlin... timed out :-) <civodul>i had set a large --max-silent-time, but i had forgotten to change --timeout as well <civodul>building it through qemu would be terribly slow <bricewge>civodul: Such build don't register on CI, no? <roptat>it will, just offload to the machine that has binfmt <rekado>hmm, I think I’ll give up on statically linking the Haskell parts of pandoc. <rekado>a closure size reduction of 1G is enough for now. <butterypancake>Submitted my second patch :D How long does it usually take for people to review your patches? <bricewge>Hopefully berlin's will be ready before mine <str1ngs>hello, could someone check this diff for me? git show 9da87078417bb16ad82652a7d2efd72185c28220. seems to me the commit should have been v0.4.1-28-d459ca1 not v0.4.1-28-gd459ca1? or I'm miss understanding this change? <lfam>butterypancake: It depends <lfam>butterypancake: Is the 'libopenbsd' in the opendoas source code the same thing as libbsd? <janneke>civodul: "How does it fail exactly?"...well depending on what permutations of my additional hurd-specific patches and used command-line, i remember 3 failures <janneke>civodul: --no-grafts => meson build system does not support cross building <janneke>civodul: or sqlite3: error loading the .SO <janneke>civodul: or => it tries to build linux for the Hurd (or if i'm very much mistaken...the hurd for x86_64) <janneke>if there's a specific scenario that you want to look into (first) and need more details, i can help to provide <civodul>in a nutshell, you're saying it doesn't make a difference, right? :-) <civodul>but anyway, the image API can create raw disk images? <civodul>so we can always use "qemu-img convert" to turn that in qcow2 images <civodul>and then we no longer need all that stuff? <butterypancake>lfam: It's quite possible. I'll try building it using libbsd. Now libbsd most likely does things in a free bsd way as that's the more popular OS, and opendoas is written by an open bsd guy so it might not work. But I'll see <lfam>butterypancake: I don't think you need to try swapping out the code <lfam>It's also my impression that libbsd is more freebsd-oriented <rekado>that “warning: SQLite database is busy” on ci.guix.gnu.org is annoying *rekado tries to upgrade all build nodes <civodul>rekado: yes, did you see that discussion with reepca? <civodul>it seems to me that it's a recent regression <nckx>butterypancake: libopenbsd is what openssh uses (not sure about opensmtpd), I think it's supposed to be bundled. <rekado>civodul: yes, I saw your mails about this <rekado>civodul: but from what I understood reepca’s changes were unrelated <butterypancake>From what I can tell, the "openbsd-compat" that openssh uses looks different from the "libopenbsd" that opendoas uses. Is there actually a standard openbsd compat library? <nckx>str1ngs: Thanks. Yeah, 9da870784 is… broken in a weird way? It's not clear to me what was intended. mbakke? <nckx>bu: You've come to the place. <nckx>butterypancake: Possible, I haven't looked at doas yet (was looking at opensmtpd which uses libopenbsd-compat as well). <butterypancake>bu: You don't need to ask to ask. Just ask. Reduces chat volume a touch :P <bu>ihave installed guix 1.0.1 and now i would like to update the all system to the new version 1.1.0 without install everzting from the beginning <bricewge>rotty: It doesn't seems to offload anything to my binfmt node "guix build guile-static-stripped --system=armhf-linux" <nckx>lfam: Are you reviewing doas? <nckx>bu: Guix is a ‘rolling release’, so simply ‘guix pull’ and reconfigure. <butterypancake>bu: I'm not super knowledgeable put I'd think running `guix pull && sudo guix system reconfigure /etc/config.scm' and then rebooting should do the trick <lfam>nckx: I was taking a look at it. But, I don't really know how to judge the stuff around ./configure and cross-compilation <str1ngs>nckx: I have a fix for the guile2.2 issues. and I semi reverted the change to get the right git hash see http://paste.debian.net/1149414. as far as I know only nomad uses emacsy-minimal. but I forget how to check reverse depends. <roptat>bricewge, oh, I don't use offloading, but I think you're supposed to declare the architectures supported by a machine in machines.scm? <nckx>mbakke: Try --check --source. <bricewge>roptat: Lying about the system in 'build-system-system' seems to do the trick, it would be better if it would be a list instead of a string <roptat>you could put your system twice there <str1ngs>nckx: I think he just wanted to drop the v prefix. but inadvertently changed the hash. I'm not sure how (commit commit) works completely <mbakke>successfully built /gnu/store/qxzpn95il25ly8k0klq6n3z2b45nc46v-emacsy-minimal-0.4.1-28-gd459ca1-checkout.drv <str1ngs>guile-lib and guile-readline default to guile 3.0 now <str1ngs>which breaks the build depends on you guix describe I guess <nckx>mbakke: I get ‘fatal: no such ref blah blah’ and it died. I'm cloning the emacsy-minimal repository locally 😛 <janneke>civodul: if i add some well deserved nuance, i would say that it removes and/or cleans-up some more hacky stuff that i had...but yeah <janneke>civodul: and also: it doesn't break anything... <mbakke>nckx: I also get the "fatal" warning (!), but afterwards "Failed to do a shallow fetch; retrying a full fetch..." and then it succeeds <bu>butterypancake: thanks.. i ll try... <nckx>str1ngs: Where does he change the hash though? I don't see that. I just get a build failure. <str1ngs>nckx: mbakke the hash should be d459ca1d3d09e7624e662bc4cfc3596850796fc6. which nomad relies on and is current not updated in guix quite yet. <nckx>str1ngs: But that's the same hash… <nckx>(‘g’ just means ‘git’ here.) <janneke>civodul: i worked very hard on all this and tried a lot of things, so i'm grateful that you worked on it too and yeah, it's pretty tricksy <mbakke>nckx, str1ngs: the package already failed to build before my commit <nckx>mbakke: Hmm, cloning it manually fails with a network error. Pwarp pwarp. <nckx>mbakke: Sure, that I know. <bricewge>bu: Then the answer from butterypancake should work. <str1ngs>mbakke, nckx seems that change is right then. all that needs fixing is to use guile2.2-lib and guile2.2-readline then <nckx>I've tried to clone it three times, it fails every time, but I'm starting to thing I'm just cursed. <mbakke>str1ngs: great :-) -- FWIW that commit identifier was generated by "git describe --tags" <lispmacs[work]>hi, what is the command to download/print-path-to source code of a package? <lispmacs[work]>I used to be able to do this quite easily in Emacs guix, but yet another interface thing has broken on that >:( <str1ngs>mbakke: thank you. I was having trouble understanding that change. <mbakke>str1ngs: that would fail, because v0.4.1-29-gd459ca1 is not a valid commit identifier <civodul>janneke: i guess i'll leave it at it and we'll see what can be done with (gnu image) <civodul>janneke: i just don't feel comfortable adding things like disabling closure registration for the Hurd <str1ngs>mbakke: I had to bump the revision which might not be needed. also this assumes guile2.2. which is an okay assumptions as far as I know only nomad and maybe guixmax uses this. <civodul>lispmacs[work]: "guix build -S PACKAGE" <mbakke>str1ngs: bumping the revision is not necessary <str1ngs>mbakke: I might have locally built it already <str1ngs>experimental gui janneke was working on. <civodul>lispmacs[work]: but yeah, M-x guix-search-by-name seems to be broken :-/ <str1ngs>mbakke: is it safe that assume revision is git revision not guix package revision? <mbakke>str1ngs: yes, that revision is a git internal thing and represents the number of commits since the tag <nckx>lfam: The cross-gcc stuff is the current way to do this, although of course it should be abstracted away soon™. <str1ngs>mbakke: okay that's what I thought thanks. <str1ngs>mbakke: I'm going to test a little more with nomad make sure everything is okay. then I'll mail a patch off. thanks for the feedback. <str1ngs>how do I check what packages uses an input again? <lfam>There are a variety of ways, depending on your goal <nckx>mbakke: BTW, any particular reason for using ‘guix describe’ notation? <janneke>civodul: yeah -- it felt "kinda okay" just when trying to get it to build, on wip-hurd-vm...but now that we're looking towards merging...not so ;) <mbakke>nckx: mainly to make everyone confuse 'guix describe' and 'git describe' too :P <nckx>mbakke: You should see my .bash_history. <str1ngs>lfam: I just need to find what packages uses emacsy-minimal as an input. <nckx>We really need to fix ‘guix am’, it's been broken for ages. <janneke>civodul: i'm resetting wip-hurd-vm then to my current wip-hurd-disk content <mbakke>nckx: I've secretly started introducing 'git describe' versions mainly to avoid the IMO redundant (let ((commit ...) (revision ...))) bindings <janneke>and we can continue the proper review and merge \o/ <str1ngs>lfam: as far as I know just nomad, but I'll like to make sure I'm not breaking something that uses emacsy-minimal with guile 3.0 <mbakke>with the git describe format, we can often stuff it right into (version ...) and it will do the right thing <mbakke>especially for upstreams that do not use the "v" prefix on tags <nckx>I agree btw. I was just suprised that git-fetch supported it. <lfam>str1ngs: You could use `guix refresh --list-dependent emacsy-minimal` <str1ngs>mbakke: it's a nice change. makes it easier for me to commit bump. since I'm tracking two upstream projects <ryanprior>How's the progress going on peer-to-peer subtitutes and concensus around good build hashes? <lfam>You could also do this: `guix package --search=. | recsel -e 'dependencies ~ "emacsy-minimal"' -p name` but that's more for human use than for building things <nckx>ryanprior: I'm not aware of any. <nckx>Someone needs to work on it to make progress. <lfam>There isn't really a viable p2p protocol *rekado still waits for the database to become available <butterypancake>nckx: is there an alternative to %output? I'd like to use best practices. Just not sure what those are :P <nckx>butterypancake: There's the more generic but verbose ‘(assoc-ref %outputs "out")’, because packages can have multiple outputs. You can keep using %output as long as you want, I was just curious. <bu> butterypancake:i tryed but i got an error, a substitution error for a store...it tell me i should try --fallback to build from the source.... what i shoul do?? <lfam>bu: Did you try --fallback? <bu>not yet... should i go for it?? <butterypancake>--fallback means if you can't find someone who already compiled it, then do it yourself. So if your computer is really slow it might take a while because it has to compile something. But I don't think there is an alternative <butterypancake>nckx: I'll make sure to remeber that when I'm making a package with multiple outputs <nckx>Then you'll have no choice. <butterypancake>is there a page somewhere with all the variables I can use when packaging stuff? Like if there was a built in variable for what compiler executable to use, that would be really sweet <nckx>butterypancake: Not that I know of. %outputs is documented in (guix)Derivations (not %output, which made me wonder about its status) but that's not really intended for beginning packagers. <nckx>So sorry, I don't think so. <butterypancake>welp, I guess I'm an advanced packer then. I'll get around to learning scheme some day <bu>lfam:sorry i dont understand... i shoul give --fallback even if my aim is to update to the new version? <nckx>butterypancake: The (compiler …) approach is correct. I'm currently trying to figure out if passing target to configure is even needed then. <nckx>bu: --fallback just means ‘if a substitute download fails, build in from source instead of returning an error to the user’. <nckx>The end result is exactly the same. <butterypancake>ya, the configure script really doesn't do a damn thing with target. But in the future it might save someone some time. <ryanprior>Is there some way I can get the news between any two generations? Or any two commits? <nckx>butterypancake: That's useful info, thanks. <bu>nckx: thanks for the explaination! <butterypancake>nckx: btw, cross compiling works. But also not really. If I do --target=aarch64-linux it works, but if I do --target=aarch64-linux-gnu then the compiler can't find the glibc functions <nckx>--target takes triplets ☹ <nckx>I'm still building my aarch64 build environment so thanks for the vision of things to come. <butterypancake>I was debating trying to manually pass it the CROSS_C_LIBRARY enironment variables, but since I have a super standardized make phase it seemed like that's may or may not be an upstream bug <nckx>Sigh. And this was looking like such a nice straightforward package 🙂 <nckx>butterypancake: Hum, I pasted that example straight from my own system. What happened? <nckx>Well, 10-finger pasted. Perhaps I typoed. <ryanprior>I can't build guix from source right now. Following the instructions on "Building from Git" I ran `guix environment --pure guix` then `./bootstrap` then `./configure` but configure fails. <ryanprior>checking whether Guile-JSON is available and recent enough... no <butterypancake>It didn't like the struct or something. Also inspecting the object that made showed it was very different from the default setuid program objects. Even the g-expr copy pasted from the manual didn't work (I think you did have like 1 minor typo that I fixed). I ended up making the correct object in the exact same way the default setuid programs are made which was *one second* <butterypancake>so it works if you throw out g-expr and just use that. which makes sense because the default variable isn't made of g-expr, it's made of that syntax <butterypancake>oh ya, you put sbin instead of bin. That was how you differed from the manual <ryanprior>X.X okay well I guess I'll wait and see how things look tomorrow <ryanprior>Yes that's what failed with the complaint about Guile-JSON <butterypancake>so I'm actually one commit behind master and that commit mentions guile-jsonld <nckx>butterypancake: /sbin was just an example, doas seemed s-y, guess it's not. <butterypancake>nckx: bruh, you give me too much credit. Everything else was just bin so I rolled with it. I do not know my posix directory stuctures <nckx>Ugh, I need to submit patches sooner when mbakke's around. <mbakke>nckx: were you poking around in (guix utils) too? :P <nckx>(AND THEY'RE ALWAYS AROUND) *mbakke pretends to be AFK <butterypancake>wait, you guys where build a thing because I was complaining? I feel so happy and validated <nckx>mbakke: Indeed, but then I got distracted by something shiny, so it's good there's someone who isn't. Thank you. <nckx>butterypancake: No no, I've been mumbling about it for weeks (as have others I'm sure), your patch just ‘reminded’ me. <nckx>My patch is identical to Marius's so we know theirs is good code. <mbakke>nckx: heheh :-) did you use the same procedure name too? I am hoping for a good bikeshedding... <nckx>I used target->cc but I don't think it's better. <nckx>CC not being a ‘type’ & all. <nckx>butterypancake: To answer your earlier question (I thought I did y'day): fast patch reviews are not our strength. Getting one within a day is a magical experience. Savour it. Real ones are closer to a week, or more. Sometime much more ☹ We need help. <raghavgururajan>When I try to build 'clutter', it is also building 'inkscape'. Why is that? <nckx>…and this is how I find out that my ‘guix graph’ is broken. <lfam>raghavgururajan: You can try `guix graph --type=reverse-package inkscape | dot -Tsvg > ~/tmp/out.svg` and see what depends on inkscape <lfam>Inkscape is used to process SVG files by some Guix packages <lfam>You can also use the new --path option of `guix graph`: `guix graph --path clutter inkscape` <lfam>Indeed, looks like Inkscape is being used to build some docs somewhere <lfam>I don't quite understand why there isn't a libsvg and we instead have to use a GUI program but oh well <lfam>Maybe we could get an inkscape-minimal or something <nckx>--path should take seconds. Big graphs can take seconds to minutes to many, many minutes on older machines. <nckx>Although it's usually more a pain to render them than to generate them. <lfam>Yes, it's the dot step that takes a while. It took a few minutes for me <lfam>The --reverse-package graph is too big and complicated to be useful <nckx>butterypancake: I now understand why you were asking about execvpe y'day. Ick. <nckx>lfam: What do you use to view (really: navigate) them? <lfam>I just learned about that <lfam>`guix graph borg | xdot -` <nckx>Oh, I was missing the explicit -. <lfam>It's still kinda slow but at least easier to navigate <lfam>I mean, these graphs are pretty big <nckx>raghavgururajan: Which one? <lfam>I would cancel it and use --path <nckx>--path shows you exactly what you want, which dependency of which dependency of… pulls in inkscape. <nckx>But honestly --path is the way of the future, all ‘guix graph | dot’ is good for is to make shocking presentation slides on the state of dependency bloat on Linux change my mind. ***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 ;-))