IRC channel logs

2020-05-28.log

back to list of logs

<butterypancake>is there a good way to alias gcc to cc in a package definition
<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
<roptat>there's also ocaml-ocb-stubblr
<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?
<butterypancake>guix search yacc
<butterypancake>oops
<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?
<nckx>butterypancake: bison.
<butterypancake>Thanks so much!
<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’.
<nckx>I can attest to both.
<butterypancake>what user owns the store? is it root? Can I just assume all files made in the store are owned by root?
<nckx>butterypancake: Yes
<alarat>nckx: yeah I add that --localstatedir=var and make install fails
<butterypancake>thanks! time to figure out substitute*
<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.
<alarat>ok
<butterypancake>I'm having trouble finding documention on substitute*. I'm not sure where to look :/
<nckx>butterypancake: guix/build/utils.scm
<butterypancake>:D
<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.
<butterypancake>would you know how to throw a tab into a regexp?
<nckx>Use "\t".
<nckx>That's not ‘regexp’, just ‘Guile’.
<butterypancake>IT BUILT SUCCESSFULLY!!!!
<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>Yay!
<nckx>I forgot what it was but huzzah for it!
<nckx>Now… does it run?
<butterypancake>In my emacs config I'm pretty sure it's almost impossible to type a tab
<nckx>C-q tab?
<butterypancake>probably not. So I did mspdebug early today which was my first patch, but this is doas, a sudo replacement
<nckx>Are you evil?
<butterypancake>I am evil
<nckx>Right. I'm surprised that wasn't in Guix yet, glad it will be soon.
<mroh>nothing is impossible in holy heaven
<butterypancake>oh, i can enter a tab. C-q tab was it
<butterypancake>is there a good way to test it now that I built it?
<butterypancake>for mspdebug I installed it on my machine, but I don't know if that's how I should do it
<butterypancake> doas: not installed setuid
<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>Right.
<nckx>butterypancake: Do you use Guix system?
<butterypancake>yep
<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.
<nckx>Correct.
<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>The one with doas.
<nckx>To create a setuid copy of the doas binary in /run/setuid-programs.
<nckx>That one should work.
<butterypancake>aight
<butteryp`>that's a good sign, computer just restarted for no reason :P
<butteryp`>oh, I don't have my proper username
<nckx>(‘opendoas’ just sounds weird, like there's a proprietary Oracle version out there.)
<nckx>butteryp`: Erk :-/
<nckx>That's a new one.
<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
<butteryp`>oh, looks like my username is free now
<nckx>butteryp`: butterypancake has quit (Read error: Connection reset by peer)
<butterypancake>jesus, IRC is too weird
<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>then i tried /exit to exit #guile but it exited everything
<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>Et voila.
<butterypancake>thanks :P
<butterypancake>aight, time to make opendoas a setuid 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?
<butterypancake>are they packages? recipes? what am I even making?
<nckx>butterypancake is about to learn harsh things about our patch review speed. No. Don't wait. Seriously.
<butterypancake>oh dear :P
<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>Expression, even.
<butterypancake>that's fair
<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.
*nckx → 😴 Good luck!
<butterypancake>I don't have emojis installed :P is that a sleepy one? You leaving?
<nckx>Oh, yes.
<butterypancake>sleep well! Thank you so much for all your help. You've saved me many hours
<nckx>My pleasure.
<butterypancake>nckx: it works!!!!
<butterypancake>it freaking works!!!
<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_>Could someone try building this package I threw together? https://paste.debian.net/1149276/
<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>[TESTED] 613
<wdkrnls>[ERRORS] 3
<wdkrnls>[PASS_PCT] 99.5106%
<wdkrnls>[FAIL] tests/tests-avx512pf/test-00001
<wdkrnls>[FAIL] tests/tests-avx512pf/test-00002
<wdkrnls>[FAIL] tests/tests-avx512pf/test-00003
<wdkrnls>
<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.
<usney>nice
<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/
<civodul>Hello Guix!
<reepca>o/
<efraim>hi!
***link2xt[nm] is now known as link2xt
<kmicu>( ^_^)/
<janneke>\(^_^ )
<janneke>he regtur!
<civodul>interesting post on Nix Flakes: https://www.tweag.io/posts/2020-05-25-flakes.html
***wxie1 is now known as wxie
<roelj>Woah, did ci.guix.gnu.org get a much faster uplink? :D
<civodul>hi roelj!
<civodul>what makes you say so?
<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>*s
<rekado>any of the other problems
<rekado>woah, RHEL deprecated GNU screen; it’s removed in RHEL 87
<rekado>*8
<rekado>I totally missed this
<rekado> https://access.redhat.com/solutions/4136481
<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.”
<mbakke>uh
<kmicu>Makes sense. Now they can also maintain less C by removing tmux too and recommending Emacs+TRAMP. 😺
<civodul>rekado: it's weird
<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
<ennoausberlin>Hello
<civodul>well, RH is employing many of the GNU toolchain developers
<rekado>and https://git.savannah.gnu.org/cgit/screen.git/log/ shows activity in 2020, 2019, 2018…
<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
<civodul>yes
<civodul>see the example for -f at https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html
<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.
<civodul>great
<bricewge>Hello Guix
<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 ;)
<rekado>roelj: could you please tell us what speed you get with wget -O /dev/null http://141.80.181.40/nar/lzip/72dncmg5a2jx0lqbjhx0vml2jc45qyn6-libreoffice-6.4.2.2
<rekado>for me it stays at around 2MB/s
<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.
<bricewge>Does guile-static still doesn't build on armhf? http://ci.guix.gnu.org/build/2694317/details
<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]
<roelj>rekado: Running now.
<MSavoritias>and that is with sudo dmesg
<MSavoritias>could it be a guix problem?
<PurpleSym>mbakke: Unfortunately the security patch from Gentoo (https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-libs/json-c/files/json-c-0.14-security-fix.patch) does not for for 0.13.1 and .deb-based distros have not patched it yet, as far as I see.
<PurpleSym>s/for/work/
<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: https://paste.debian.net/1149324/
<roelj>rekado: So it seems to have reached the destination in 11 hops.
<bricewge>Ho, ok looks like https://issues.guix.info/41350#36 should fix building disk-image for arm
<PurpleSym>rekado: 116,07M 5,74MB/s in 20s, traceroute: https://paste.debian.net/1149326/
<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
<mbakke>hopefully this weekend!
<PurpleSym>Great! There’s also a seconds patch that seems to be important, otherwise applications fail at runtime: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/json-c/files/json-c-0.14-object-limitation.patch
<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>PurpleSym: oh my, thanks :)
<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
<civodul>the "staging" situation was special
<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?
<dutchie>along the lines of `guix import`
<reepca>dutchie: 'guix refresh'?
<rekado>guix refresh -u the-package
<dutchie>ah yeah that's the one! thanks
<abralek>Hi, Does anybody knows what would be the simplest way to get gcc-3? it has libstdc++.so.5 which snx vpn requires?
<abralek>guix time-machine? )
<rekado>GCC 3 is ancient
<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>I packed it in docker for now
<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"
<butterypancake>I'm trying to build using --target now. Thanks civodul :D
<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?
<reepca>c++ deprecated; migrate to bash
<janneke>checking for iostream... no
<janneke>wtf?
<janneke>;)
<jonsger>janneke: maybe c++ on guile will help :P
<janneke>mesc++
<leoprikler>instead of cxx we have cyy
<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
<bricewge>The log said it timed out at 3600 while it's set to 36000 in Guix http://ci.guix.gnu.org/log/skdy6z15p5y7xxs3a87d298bazwqnyrn-guile-static-3.0.2
<bricewge> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm?id=57833803b446484b6f413fb883b2156933c38639#n257
<lfam>bricewge: Cuirass doesn't honor those properties
*lfam looks for reference
<lfam> https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html
<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
<lfam>No!
<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>okay, I get your point :P
<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
<bricewge>I'll report it
<bricewge>I don't see how it could be fixed without honoring the properties. It never has been build on cuirass: http://ci.guix.gnu.org/search?query=guile-static-stripped%20system:armhf-linux
<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>but yeah, it's annoying
<lfam>Aha!
<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
<bricewge>civodul: WDY by “baseline compiler”?
<lfam>I think it would be nice to know how many people are using the armhf port (based on how often substitutes are requested)
<bricewge>s/WDY/WDYM/
<civodul>bricewge: there's a separate path in the compiler for -O0
<civodul>it's much less resource hungry
<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>butterypancake: binfmt ;)
<bricewge>Try "file" on the binary
<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>I ran file on the binary and it says it's aarch64
<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!
<lfam>Weird
<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?
<butterypancake>so I can figure out the name for the aarch64 gcc?
<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>:(
<jackhill>but perhaps we can make it better in the future :)
<lfam>Yes!
<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?
<roptat>yes for the first
<roptat>no idea for the second question
<roptat>see https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#Transparent-Emulation-with-QEMU
<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>i'll try again
<civodul>building it through qemu would be terribly slow
<bricewge>civodul: Such build don't register on CI, no?
<bricewge>Do you have the log of it failling?
<bricewge>The timeout is of 20 hours on this one
<bricewge>So offloading won't work with binfmt?
<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>I just can’t get it to work.
<rekado>a closure size reduction of 1G is enough for now.
<bricewge>roptat: Thank you for specifying it
<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>janneke: ok, thanks!
<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
<nckx>Good late morning Guix.
<rekado>that “warning: SQLite database is busy” on ci.guix.gnu.org is annoying
*rekado tries to upgrade all build nodes
<butterypancake>yo, what up nckx! I send in my opendoas patch
<civodul>rekado: yes, did you see that discussion with reepca?
<civodul>it seems to me that it's a recent regression
<civodul>Goeden Dag, nckx!
<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
<nckx>civodul: Bonjour 😊
<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?
<lfam>Probably not
<lfam>Well I think it's fine
<bu>hello!!
<bu>i need some help...
<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"
<bricewge>Too bad
<nckx>lfam: Are you reviewing doas?
<mbakke>nckx: how is it broken?
<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
<bricewge>rotty: Oups it was meant to roptat
<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.
<nckx>mbakke: There's no such thing as ‘0.4.1-28-gd459ca1’ in https://git.savannah.gnu.org/git/emacsy.git.
<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
<mbakke>nckx: it works for me
<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
<bricewge>rotty: Oh no, it faill actually
<mbakke>successfully built /gnu/store/qxzpn95il25ly8k0klq6n3z2b45nc46v-emacsy-minimal-0.4.1-28-gd459ca1-checkout.drv
<roptat>oh :/
<roptat>that's still roptat :p
<str1ngs>mbakke: see my diff http://paste.debian.net/1149414
<str1ngs>guile-lib and guile-readline default to guile 3.0 now
<str1ngs>which breaks the build depends on you guix describe I guess
<janneke>civodul: yes, sort of
<bricewge>bu: Are you using Guix System?
<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
<bu>bricewge: Yes!!!
<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"
<nckx>5. I give up.
<lispmacs[work]>hi, what is the command to download/print-path-to source code of a package?
<str1ngs>mbakke: nckx this diff should build http://paste.debian.net/1149416
<lispmacs[work]>I used to be able to do this quite easily in Emacs guix, but yet another interface thing has broken on that >:(
<civodul>janneke: heh ok :-)
<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
<mbakke>what is 'guixmax'?
<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: should I mail this patch?
<mbakke>str1ngs: that would be great :)
<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.
<mbakke>excellent :)
<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
<mbakke>everyone else*
<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.
<nckx>Happily so.
<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
<str1ngs>lfam: great that's what I neeed.
<str1ngs>needed*
<nckx>Is %output deprecated?
<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??
<lfam>Of course
<lfam>I mean, yes
<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
<lfam>Right
<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>Or shouldn't be.
<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
<lfam>Just like that!
<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.
<nckx>The time taken is not.
<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!
<nckx>(I suspected as much.)
<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>Eh, that's not good.
<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 🙂
<butterypancake>also, using g-expr for the setuid programs didn't work for me
<butterypancake>just cuz I'm spilling all the nasties I found :P
<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>(file-append opendoas "/bin/doas")
<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
<butterypancake>ryanprior: you're lucky. I can't get past bootstrap right now
<ryanprior>X.X okay well I guess I'll wait and see how things look tomorrow
<butterypancake>ryanprior: wait, I rebooted and now it works
<butterypancake>idk, maybe we got different issues
<butterypancake>did you do ./configure --localstatedir=/var ??
<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
<butterypancake>just back it up 1 and it should work
<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
<lfam>Lol
<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.
<nckx>*awkward silence*
<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.
<nckx>Anyway, sent.
<raghavgururajan>Hello Guix!
<raghavgururajan>When I try to build 'clutter', it is also building 'inkscape'. Why is that?
<raghavgururajan>clutter does not have inkscape as input
<raghavgururajan>The inkscape build consuming too much time.
<nckx>…and this is how I find out that my ‘guix graph’ is broken.
<nckx> https://paste.debian.net/plain/1149427
<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
<raghavgururajan>lfam: Thanks!
<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
<guix-vits>Hi raghav-gururajan. Thanks lfam.
<raghavgururajan>guix-vits o/
<raghavgururajan>I suspect gtk-doc or gdk-pixbuf
<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
<raghavgururajan>How long the guix graph command takes?
<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>--path is the way to go
<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>Did you get anywhere?
<nckx>lfam: What do you use to view (really: navigate) them?
<lfam>Firefox
<lfam>No, use xdot!
<lfam>I just learned about that
<lfam>I had forgotten
<lfam>`guix graph borg | xdot -`
<lfam>For example
<nckx>Oh, I was missing the explicit -.
<nckx>Thanks!
<lfam>It's still kinda slow but at least easier to navigate
<lfam>I mean, these graphs are pretty big
<raghavgururajan>command is still running....
<nckx>raghavgururajan: Which one?
<lfam>I would cancel it and use --path
<nckx>
<raghavgururajan>Oh its done
<nckx>--path shows you exactly what you want, which dependency of which dependency of… pulls in inkscape.
<raghavgururajan>Uh oh, how do I open svg files.
<raghavgururajan>image viewer?
<nckx>…Inkscape 😛
<lfam>I use a web browser
<nckx>(Most browsers too.)
<raghavgururajan>Icecat it is.
<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 GNU/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.
<lfam>Just a couple weeks old
*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>Looks like I cannot go-around inkscape dependency.
<raghavgururajan>I am letting it build.
<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?
<raghavgururajan>nckx: Yoy mean hash?
<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: Just a sec
<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)
<raghavgururajan>Here is the diff, with which my inkscape is trying to build.
<raghavgururajan> https://disroot.org/upload/FNZQOj7ixeTaz_w2/diff.diff
<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….
<raghavgururajan>cbaines: I ran `./pre-inst-env guix build clutter --dry-run`
<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
<raghavgururajan>My clutter's definition is https://bin.disroot.org/?180be61f7ad961ca#5EVDTUuJxS7dnGWgn5CMzDzWsrMZiEzMS5ypaT6quGWs
<raghavgururajan>I see.
<raghavgururajan>Yeah, my local changes are included in that diff.
<raghavgururajan>It's been an hour and just reached 15%.
<nckx>raghavgururajan: OK, I'm building your patched inkscape. If the hashes match.
<raghavgururajan>nckx: Thanks so much.
<dustyweb>hello #guix!
<nckx>o/
<nckx>Long time (to me) dustyweb.
<dustyweb>hi nckx, how are ya
<nckx>Healthy af.
<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.
<lfam>raghavgururajan: I think they are only built for the things listed on this page: http://ci.guix.gnu.org/
<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`
<lfam>And etc
<raghavgururajan>I see.
<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>The instance of the Guix Data Service I've got for "patches" does at least look at branches though https://data.guix-patches.cbaines.net/repository/2/branch/wip-desktop
<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.
<nckx>Guix Drv Service.
<cbaines>Well, that already happens :)
<cbaines>You can even fetch substitutes for the derivations
<nckx>I see: I need to poke around the GDS more again 🙂
<cbaines>nckx, I'm really liking the look of https://guix.tobias.gr/about/ :D
<raghavgururajan>cbaines: I am not able understand what is mentioned in that link.
<cbaines>So this page https://data.guix-patches.cbaines.net/repository/2/branch/wip-desktop shows information about the wip-desktop-branch for the main Guix git repository
<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`?
<cbaines>raghavgururajan, does that help?
<raghavgururajan>cbaines: Ah I see. Thanks!
<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.
<cbaines>What's A capital kmicu ?
*kmicu makes Guixix‑a cache for Guix devs. Invest your capital.
<kmicu>cbaines: business money https://earnestcapital.com/earnest-capital-invests-in-cachix/ 😺
<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.
<cbaines>lfam, the way I've addressed baking the substitutes in the Guix Build Coordinator is just doing it after the build: https://git.cbaines.net/guix/build-coordinator/tree/guix-build-coordinator/hooks.scm#n51 It's really not that much code.
<raghavgururajan>nckx: Fantastic! xD
<nckx>☝ That's basically what I do, but (ushers small children out of the room) in bash.
<cbaines>kmicu, interesting, thanks :)
<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?]
<kmicu>nckx: https://github.com/ipfs/devgrants/pull/43
<nckx>kmicu: Thanks.
<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
<raghavgururajan>nckx, https://bin.disroot.org/?ae6a83be3e57b808#GzbBAxDgyhL1p9uugibpiTthDtHVqvaA3Qkrgutb8t3n
<cbaines>lfam, I setup some monitoring for Bayfront http://mago.cbaines.net:3000/d/rYdddlPWk/node-exporter-full?orgId=1
<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.
<raghavgururajan>Ah Cool!
<nckx>OK, so then diff.diff contains nothing new. Correct?
<lfam>Would be nice to get a bigger disk on there
<cbaines>are you on guix-sysadmin lfam ?
***Cairn[m] is now known as cairn
<lfam>Yes
<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.
<raghavgururajan>Let me update my wip-desktop and retest the hash for inkscape.
*lfam looks in maintenance.git
<lfam>Yes
<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?’.
<nckx>Heh, ‘just’.
<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
<nckx>Oh sweet.
<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… 🤷
<lfam>It's in Bordeaux
<nckx>Well, plus, the only opinion that matters is Andreas', whatever they're comfy with goes.
<lfam>Yup
<lfam>Well, that means we should buy hardware now so it's available when we have access again
<lfam>Therefore!
<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.
<bhartrihari>No
<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.
<civodul>cbaines: what were your conclusions regarding Nix being more up-to-date at https://repology.org/ ?
<civodul>i'm jealous
<janneke>civodul: thanks for bearing with me...bit of a curvy roed
<raghavgururajan>nckx, Cool! Thank you!
<civodul>janneke: heh, i did my share to bend it a bit more :-)
<janneke>*lol*
<raghavgururajan>nckx: How do I add your build farm inside my local wip-desktop branch or pre-inst-env?
<raghavgururajan>Or even pre-inst-env uses config from host system?
<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.
<raghavgururajan>Cool!
<nckx>But you can override it per-command with ‘--substitute-urls="https://guix.tobias.gr"’.
<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.)
<bhartrihari>I see.
<nckx>alextee[m]: a) Saw it was still available b) Didn't believe it c) Tried to register it anyway d) Mine.
<alextee[m]>cool!
<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>civodul, I spent some time moving the patches Git repository I've been playing with to it's own Gitolite instance recently https://git.guix-patches.cbaines.net/
<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
<raghavgururajan>nckx: It's working.. Thanks so much!
<nckx>raghavgururajan: Just saw you in my logs 🙂 Wonderful.
<raghavgururajan>`guix archive --revoke` would be handy.
<raghavgururajan>Phew!
<nckx>So would any kind of tagging system to remember which key is which a year on.
*raghavgururajan Ctrl+X's inkscape's build.
<raghavgururajan>Oh boy, gtk+ now builds.
<raghavgururajan>Hope it is not as heavy as inkscape.
*nckx starts building gtk+ 😛
<raghavgururajan>nckx: Thanks so much!
<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.
<raghavgururajan>nckx: Cool!
<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>civodul: Nix has really up todate package because of their bot r-ryantm https://github.com/ryantm/nixpkgs-update
<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>mbakke: heya, regarding https://issues.guix.gnu.org/40791 (Qt upgrade) Which branch did this go to? Its not on core-updates AFAICT. Well, basically any idea when this will be able to go to master?
<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)
<TZander>ah, found branch 'staging-next'
<mjw>Merkle trees and build systems: https://lwn.net/SubscriberLink/821367/4ec5cb10052d4d9a/
<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>bricewge: Thank you
<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>uses QEMU
<NieDzejkob>--target is classical cross compilation and all the frustration that comes with it :P
<civodul>mjw: thanks for the link!
<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 ;-))