IRC channel logs

2020-09-14.log

back to list of logs

<bdju>does `sxiv -a filename.gif` work for anyone? I can't seem to play gifs, but not sure if it's wayland weirdness or something else about my system
<bdju>my last two bugs aren't showing up on the mailing list and I haven't got any confirmation... I know new users need manual approval, but I've already filed bugs in the past
<bdju>the first of the two was sent over 3 hours ago
<nckx>sneek later tell raghavgururajan Reminder that the modern Web is broken beyond repair and must be abandoned: https://www.tobias.gr/burnitdown.png I suggest you send it to me in a simple /msg; it's relatively short.
<sneek>nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: Here is my ssh pub-key file, https://upload.disroot.org/r/LMCrUTuz#21daes1iqeCV7Vnkq0dGUWcHchewHBcriAkmr+aYoxc=
<sneek>Okay.
<nckx>Yeah, that's the link.
***stikonas_ is now known as stikonas
<bdju> http://ix.io/2xsZ waybar fails to build
<bdju>nice. got confirmation on my bug reports now
***sneek_ is now known as sneek
<ryanprior>bdju: I submitted a patch and got acknowledgement within about a minute. Dunno what's going on with the emails you sent.
<sneek>Welcome back ryanprior, you have 1 message!
<sneek>ryanprior, raghavgururajan says: I have just built ungoogled-chromium (84.0.4147.125-0.57244cd), as of a1a39ed5a46044161a71cbe6931c7e3006a82ecb, on Bayfront. You can get the substitute from there. :-)
<ryanprior>raghavgururajan: I was actually able to get ungoogled-chromium from ci.guix.org the other day, my lottery number does come up once in a blue moon =X
<guixy>Hi guix!
<guixy>I think I found a bug, but I don't know what to blame...
<PotentialUser-84>hello, which package if any provide gnat; the ada compiler; gcc's description isn't explicit that it contains an ada frontend from what I've read, correct me if I'm wrong on this
<guixy>It doesn't look like gnat is provided in guix...
<PotentialUser-84>how do you get contributors to add the package?
<guixy>Someone sees a need and adds it. It's actually very easy. You can do it if you want.
<apteryx>PotentialUser-84: you write a package definition, and submit a patch :-)
<apteryx>there's also a wishlist hosted on libreplanet
<guixy>There is?
<yanmaani>How come guix uses GCC and binutils as the base bootstrap set? Wouldn't it be much smaller to use say busybox + tcc?
<PotentialUser-84>apteryx: libreplanet link please
<guixy>users (from coreutils) might have a bug... or it might be xfce-desktop... or maybe sddm...
<guixy>What is UTMP_FILE?
<guixy>Which is expected to update the utmp file read by users: the display manager or the window manager?
<apteryx>sneek: later tell PotentialUser-84 https://libreplanet.org/wiki/Group:Guix/Wishlist
<sneek>Okay.
<yanmaani>I found this: https://busybox.net/~landley/firmware/design.html
<raghavgururajan>sneek, later ask apteryx: Are you interested in telegram-desktop? 🙃
<sneek>raghavgururajan, you have 1 message!
<sneek>raghavgururajan, nckx says: Reminder that the modern Web is broken beyond repair and must be abandoned: https://www.tobias.gr/burnitdown.png I suggest you send it to me in a simple /msg; it's relatively short.
<sneek>Will do.
<raghavgururajan>sneek, later tell nckx: 😲 😐 😑 😶 . https://paste.debian.net/plain/1163691
<sneek>Will do.
<apteryx>raghavgururajan: I don't use telegram, no but I'm happy if you're working on it :-)
<sneek>apteryx, you have 1 message!
<sneek>apteryx, raghavgururajan says: Are you interested in telegram-desktop? 🙃
<jackhill>yanmaani: you might be interested in this blog post: https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
<jackhill>yanmaani: long story short is it is being worked on. The #bootstrappable is another place people who care about that sort of thing interact.
<raghavgururajan>apteryx: Cool! I wanted to add one more option for guixers, for IM+VoIP solutions.
<raghavgururajan>apteryx: I was wondering if we could team-up in the same way as we did for linphone. WDYT?
<apteryx>I don't use telegram (and don't have an interest in using it), so I think someone else is probably fitter than I am for this one
<apteryx>I'll be happy to review patches anyways, of course, it's just I wouldn't be able to test it the way I did for linphone
<raghavgururajan>apteryx: I understand. No worries!
<str1ngs>HappyEnt[m]: thanks for this link https://xff.cz/kernels/5.9/README. do you know if he plains to get these into the mainline?
<str1ngs>plans*
<milkman[bot]>Search
<raghavgururajan>Hey it is here
<raghavgururajan>I welcome MilkMan bot into #guix
<str1ngs>jackhill: this is the first I heard of gash-utils. that's pretty cool
<raghavgururajan>milkman[bot], the rules
<milkman[bot]>0. A robot may not harm humanity, or, by inaction, allow humanity to come to harm.
<milkman[bot]>1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
<milkman[bot]>2. A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.
<milkman[bot]>3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
<raghavgururajan>milkman[bot], thanks
<milkman[bot]>it’s nothing
<str1ngs>3 laws of robotics :P
<raghavgururajan>sneek: later tell nckx: The bot has been added, under the nick milkman[bot]
<sneek>Got it.
<str1ngs>raghavgururajan: this is a Issac Asimov reference
<raghavgururajan>str1ngs, I see
<raghavgururajan>No more spammers tricking us into clicking porn links.
<raghavgururajan>Test: https://guix.gnu.org
<str1ngs>raghavgururajan: if you have not read the foundation series it's really great. up there with Dune
<milkman[bot]>GNU's advanced distro and transactional package manager — GNU Guix
<str1ngs>can milkman[bot] evaluate scheme?
<str1ngs>milkman[bot]: ,(+ 1 1)
<raghavgururajan>str1ngs, Nah, its is a HuBot.
<str1ngs>not an "enlightened" robot I see :P
<raghavgururajan> https://hubot.github.com/
<milkman[bot]>HUBOT | Hubot is your friendly robot sidekick. Install him in your company to dramatically improve employee efficiency.
<raghavgururajan>The bot is hosted at bot.disroot.org, connected to #guix, via XMPP-IRC gateway at irc.disroot.org
<raghavgururajan>sneek, later tell nckx: Could temporarily add a line on ChanServ message about this new bot and to use `help` command to see options? Thanks!
<sneek>Got it.
<raghavgururajan>milkman[bot] magic-8 Do you think you can manage sneek
<milkman[bot]>You may rely on it
<raghavgururajan>Hmm.
<xelxebar>Anyone have a disk image for the beaglebone black laying around?
<xelxebar>str1ngs: Would you be able/willing to build such?
<xelxebar>Trying to libreboot my laptop.
<str1ngs>xelxebar: I don't have a beaglebone myself.
<str1ngs>I can sorta give you instructions that I used for rockpro64 but I don't know how much that carries
<str1ngs>over.
<str1ngs>xelxebar: but the way in the guix source there is ./gnu/system/examples/beaglebone-black.tmpl
<str1ngs>so that should be pretty easy starting point.
<str1ngs>by the way*
<xelxebar>Yeah, there's a beaglebone-black-installation-os operating-system declaration in gnu/system/install.scm
<xelxebar>So I figured I could just do this: guix system disk-image --target=armhf-linux-gnu -s armhf-linux -e "(@ (gnu system install) beaglebone-black-installation-os)"
<str1ngs>ah nice is that part of the guix installer. I've only ever used system init
<xelxebar>Yeah. Super nice.
<str1ngs>have you tried that? or the template?
<xelxebar>For some reason, though, I'm having trouble with the cross-compilation. When I tried the above command a few days ago it bailed out on me.
<str1ngs>ahh you are building on another machine?
<str1ngs>cross compilation is kinda hit or miss. it's probably better to user --system= with qemu then --target
<str1ngs>use*
<xelxebar>Yeah, don't have anything on the bbb at the moment.
<str1ngs>can it boot off of a scdcard. I find it easier to build everything on my workstation. then init the sdcard. then boot the device with an sdcard.
<xelxebar>Oh! Nice idea. I didn't think about using a qemu vm to bootstrap an image.
<str1ngs>xelxebar: you don't even need qemu vm. you can just use guix.
<xelxebar>Even though the bbb is armhf and I'm on x86?
<str1ngs>if you say do guix build --system=armhf-linux bash. it will build armfh bash. but you need to have qemu binfmt service
<str1ngs>what distro do you use on you main main machine. the more processing power the better.
<str1ngs>xelxebar: also x86 you mean x86_64?
<xelxebar>On a foreign distro at the moment (Void Linux), but this project is an attempt at transitioning over to a full guix system.
<xelxebar>On an ~8 yo machine. Yeah, x86_64.
<str1ngs>xelxebar: as long as void linux has a qemu binfmt service you are find. you can even install the files your self.
<str1ngs>also I use qemu static user
<str1ngs>the main thing is if you call a armhf elf binary qemu user transparently interop it.
<xelxebar>What is qemu binfmt?
<str1ngs>binfmt is kernel mechanics that can run foreign binaries transparently
<xelxebar>What?? I had no idea this was a thing...
<str1ngs>say you have a window PE file. you can have binfmt call say wine. in this case if you have a armhf elf file it will call qemu-arm-static
<str1ngs>xelxebar: here's a example for armhf https://paste.debian.net/1163695
<str1ngs>there is a registration process I don't think you can just drop the file in there.
<xelxebar>Oh. The thing where you can register "magic" byte sequences with the kernel and it will pass files with those sequences off to userland process. I've messed with that in the past. Didn't put 2-and-2 together.
<str1ngs>xelxebar: right
<str1ngs>xelxebar: main point is if you have that working properly . then you can just have guix build natively with --system=armhf-linxu
<str1ngs>of course spell linux right.
<xelxebar>That's a really cool solution.
*xelxebar uses GUN/Linxu
<str1ngs>are you fun Texas?!
<str1ngs>from*
<xelxebar>How memory heavy should I expect this to be?
<xelxebar>Have 4gb on this machine.
<xelxebar>str1ngs: Why do you ask?
<str1ngs>it's not its really about raw processing power.
<str1ngs>xelxebar: it was a joke on GUN..Linxu
<xelxebar>Oh. Whoosh. lol
<str1ngs>of course don't expect to build chromium or icecat :P
<efraim>I have an aarch64 board I can use to build a beaglebone-black image for if you give me a command :)
<str1ngs>xelxebar: also I offload to the main build machine from the arm machines.. this helps prevent fires.
<str1ngs>xelxebar: yeah as efraim metioned if you have an expression you need help with. people can build for you
<xelxebar>efraim: Do you always just descend into conversations like that, helpfully?
<xelxebar>efraim: This is what I'm trying to do: guix system disk-image -s armhf-linux -e "(@ (gnu system install) beaglebone-black-installation-os)"
<efraim>sometimes
<efraim>oooh, looks like it'll be building linux-libre
<efraim>i'll see if there's a substitute for 5.4
<efraim>no substitute for 5.4 either. looks like i'll be building 5.8.7
<xelxebar>Odd. Did the build servers stop serving linux-libre for some archs?
<efraim>it's been behind on building the kernels for some reason
<xelxebar>Thanks, efraim!
<xelxebar>str1ngs: Looking at the binfmt_misc example you gave me. It looks to be using a static build of qemu-arm for the interpreter. Is there any specific reason for that?
<str1ngs>xelxebar: the static build variant is not dependant on system libraries so it can survive chroots or unshares.
<str1ngs>it might not be required. but I use it for other things.
<str1ngs>in the context of guix i mean.
<xelxebar>Hrm. How does binfmt work with mount namespaces? I would guess that you have to re-register the interpreter?
<xelxebar>If you're in a chroot, which hierarchy does the interpreter come from?
<efraim>IIRC the root of the chroot
*efraim has played with debootstrap some on the past
<xelxebar>Oh, wait, reading Documentation/admin-guide/binfmt-misc.txt in the kernel tree explains the flags. The F flag loads the binary upon registration, thus it sort of circumvents namespaces and chroots. Nifty.
<str1ngs>xelxebar: so I don't need qemu static then?
<str1ngs>I wonder which is more performant.
<xelxebar>str1ngs: I believe that's what it means.
<str1ngs>I noticed it just worked with guix. but I assumed it seems it's not guix voodoo magic :P
<xelxebar>My hypothesis is that the F flag would give a bit of initial performance boost, since the interpreter is pre-loaded, instead of loaded at execution time.
<xelxebar>Maybe Guix should apply for religious tax exemption.
<str1ngs>amen
<xelxebar>Also, Guix needs a mascot so we can make a voodoo doll for it.
<str1ngs>well it works for the church of Scientology soo..
<xelxebar>Seems legit to me. Please send me 50 gnus and we will expedite your open source enlightement transformation.
***MightyJoe is now known as cyraxjoe
<str1ngs>100 gnu and you are indoctrinated into the hold order of geeks
<str1ngs>holy*
<leoprikler>I'm getting weird "Church of Emacs" vibes from y'all
<OriansJ`>leoprikler: M-x dunnet
<peanutbutterandc>Hey there
<peanutbutterandc>I'm trying to cook up a package that has 'harfbuzz' as it's dependency
<peanutbutterandc>But during configure phase, it's saying something contradictory: 'using platform harfbuzz' (so it detects harfbuzz) but then goes on to say "No library found for -lharfbuzz". How should I go about fixing this?
<efraim>the first part could be based on configure flags
<efraim>do you have pkg-config in native-inputs?
<peanutbutterandc>efraim, Oh.... no... I'll fix that up right away then! Thank you!
<peanutbutterandc>I thought pkg-config was available in the build system itself
<peanutbutterandc>This is strange... still says the same thing.... now library found for -lharfbuzz
<peanutbutterandc>also there are warnings during patch-source-shebangs phase about no binary interpreter for PYTHON found in PATH, even when I use python as a native input....
<peanutbutterandc>this is a perl-build system
<civodul>Hello Guix!
<xelxebar>leoprikler: I am actually a vim heretic, but please don't tell anyone.
<peanutbutterandc>Hello Mr. Courtes
<necrophcodr>I've been implementing some Perl packages, but during their test phases they fail with "sh: perl: command not found", and various other 127s. I've added perl as an input for all 3 input types, yet it remains unable to find these executables. How can i troubleshoot this?
<xelxebar>necrophcodr: Dumb question, but did you include perl as a native-input instead of just a plain input?
<necrophcodr>xelxebar, i added perl in all of them. native-inputs, inputs, and propagated-inputs.
<xelxebar>peanutbutterandc: Hrm. Regarding python, I vaguely remember having to futz with python-2 vs python-3 in the native inputs before.
<rekado_>necrophcodr: does the build system reset PATH? How does it call perl?
<peanutbutterandc>xelxebar, (native-inputs)
<peanutbutterandc>also, thanks! I'll try that
<necrophcodr>rekado_, i'll admit i have no idea. i'll take a walk through the guix codebase again.
<xelxebar>necrophcodr: I believe rekado_ is asking about the build system of the package as opposed to how guix calls it.
<peanutbutterandc>xelxebar, Um.... using python2 as an input throws 'unbound variable' error
<necrophcodr>xelxebar, i dont actually know either way. i would assume not, since that may break the tests as they depend on these variables, but i dont know.
<peanutbutterandc>even though I am using (gnu packages python)
<xelxebar>peanutbutterandc: Try python-2. Need the hyphen.
<peanutbutterandc>xelxebar, Ooooh! Wow! The warnings suddenly disappeared!
<peanutbutterandc>Thanks!
<peanutbutterandc>Also, why the hyphen in the name when `guix show python2` shows it named python2? o.O seems kinda' confusing
<peanutbutterandc>but there's still the warning of not finding the library -lharfbuzz.... do I have to include anything else?
<iyzsong-w>2 kind of name, 'python-2' is the scheme variable name for the package, and 'python2' is the package 'name'. the later is used in CLI/UI, while the scheme one is used in scheme code...
<peanutbutterandc>iyzsong-w, I understand. But I think the common convention was to have the same scheme variable name and package name. Also, hello!
<peanutbutterandc>Anyways, any ideas regarding -lharfbuzz not being found? I do have pkg-config in my native input
<peanutbutterandc>and harfbuzz in my input
<iyzsong-w>for '-lharfbuzz', first check where is the harfbuzz library (in harfbuzz package's store path "lib" or other directories). then check how the package search libraries (via LIBRARY_PATH or pkg-config, or hardcoded...)
<peanutbutterandc>...inputs
<xelxebar>peanutbutterandc: What's the build system. Perhaps it's mangling CFLAGS or LDFLAGS?
<peanutbutterandc>xelxebar, It's the perl-build-system
<necrophcodr>rekado_, xelxebar , it doesnt appear to be the case, no. regarding resetting path or other env.
<xelxebar>peanutbutterandc: Yeah, it's probably legacy cruft? There's also a python2-minimal package.
<iyzsong-w>LIBRARY_PATH only works when libharfbuzz.so in "lib", pkg-config generally works, and hardcoded paths need to be patched
<peanutbutterandc>I'm actually trying to fix up the package definition of `guix import cpan Harfbuzz::Shaper`
<Librecat>hi
<peanutbutterandc>hello
<Librecat>how can i install iceweasel-uxp
<Librecat>i tried putting UXP into the platform folder of iceweasel-uxp
<Librecat>but it didnt build
<Librecat>also i am on guixsd right now
<peanutbutterandc>iyzsong-w, How can I figure out how the package searches for libraries? it's a perl-build-system.... also, the harfbuzz library is in lib (of the /gnu/store/_-harfbuzz
<janneke>hello Guix!
<peanutbutterandc>Hey there, Mr. janneke!
<iyzsong-w>peanutbutterandc: not the perl-build-system, you can search where the warning 'not finding -lharfbuzz' is output, and in that file, how it check for '-lharfbuzz'
<iyzsong-w>maybe Makefile.PL, or some script in the source files
<peanutbutterandc>I just added perl-extutils-pkgconfig to the output too and that didn't work either.... just an update
<peanutbutterandc>iyzsong-w, Hmmmm.... I will do just that thank you.
<iyzsong-w>good luck :)
<peanutbutterandc>Also, wasn't there some command line argument in guix to download the source or something?
<peanutbutterandc>I'd like to use that please - instead of wget-ing the source tar ball manually
<peanutbutterandc>what was it?
<xelxebar>guix download?
<xelxebar>Oh, guix build -S
<iyzsong-w>guix build -S <package-name>
<peanutbutterandc>Ooooh... that just might be it. Thank you very much
<peanutbutterandc>iyzsong-w, Also, what's with the -w suffix? I thought you went by just iyzsong before. (I remember you helping me out with one of my very first package definitions too)
<iyzsong-w>peanutbutterandc: um, i'm on my working computer. the real one is living at home..
<peanutbutterandc>iyzsong-w, Ah... I see. Well, it's good to meet you here again!
<iyzsong-w>peanutbutterandc: glad to meet you too!
<peanutbutterandc>(:
<xelxebar>iyzsong-w: Heh. Getting paid to #guix. Where do you work?
<peanutbutterandc>Ooooh.... guix build -S downloads to /gnu/store and not the current working directory...
<peanutbutterandc>I guess that makes sense, too
<iyzsong-w>xelxebar: in China, current doing some testing, python, jenkins, CI, etc.
<peanutbutterandc>If someone here wants to hire me, I raise my hand. I need a job. :[
*xelxebar is in the same boat: (pretty) please see wilsonb.com/cv.pdf
<peanutbutterandc>xelxebar, That is one of the cleanest cvs I've seen. Super neat. What did you use to make it? Also, my situation is super worse: it's just https://github.com/peanutbutterandcrackers/ :P
<milkman[bot]>peanutbutterandcrackers · GitHub
<peanutbutterandc>wow we have a new bot now?
<xelxebar>peanutbutterandc: Oh, thank's for looking at it! It's just plain TeX.
<peanutbutterandc>xelxebar, That's quite aesthetic. And I'm sure you'll get a great position somewhere. (:
<xelxebar>Guessing you're not quite a billionaire yet? :p Looks like you've poked around with several things.
<peanutbutterandc>xelxebar, Oh that's a joke. lol. I'm just a n00b of everything. "Jack of all, hireworthy at none" it seems. Just a random high-school drop-out poking around with stuffs in his free time.
<xelxebar>peanutbutterandc: Cheers, mate! If you need help getting a cv together, feel free hitting me up. Might try converting you to the plain TeX side!
<peanutbutterandc>xelxebar, I've been meaning to learn TeXinfo. But sure! I will remember to ask for you if I decide to learn TeX. Thank you very much. (:
<jlicht>hey guix!
<jonsger>hi
<Librecat>totem video player complains about aac decoder
<peanutbutterandc>iyzsong-w, Um.... I couldn't really find any good leads in the source.... this is the Makefile.PL: https://termbin.com/rda2a Any ideas?
<Librecat>can you load firmware on intel graphics
<Kimapr[m]>тттттттттттткпщыдуз
<xelxebar>peanutbutterandc: Where is the chec_lib procedure defined?
<Kimapr[m]>oops, sorry for that
<Kimapr[m]>i was meant to minimize everything but had wrong keyboard layout
<peanutbutterandc>xelxebar, I'm sorry I don't really know. Not a perl hacker. :( just trying to package something that I use that uses this module.... would you like to see the whole package?
<xelxebar>peanutbutterandc: Nevermind, you mentioned that "Using platform harfbuzz library" prints out, right?
<xelxebar>peanutbutterandc: Sure, I'll take a crack at it.
<iyzsong-w>i don't have much ideas too, if 'check_lib' passed, we see "Using platform harfbuzz library", but there is no "No library found for -lharfbuzz" in this Makefile.PL..
<peanutbutterandc>xelxebar, This is the revision history of the package: https://github.com/peanutbutterandcrackers/guix-packages/blob/master/chordpro.scm
<milkman[bot]>guix-packages/chordpro.scm at master · peanutbutterandcrackers/guix-packages · GitHub
<xelxebar>iyzsong-w: pretty sure that -lharfbuzz error is coming from the final compilation
<peanutbutterandc>xelxebar, and this is the current changes: https://termbin.com/5cov
<peanutbutterandc>chordpro works just fine... it's chordpro-next that is problematic (and depends on perl-harfbuzz-shaper)
<peanutbutterandc>so currently I've been stuck at:
<Librecat>does general protection faults mean hardware failure
<xelxebar>iyzsong-w: What do you think the CCCDLFLAGS is?
<peanutbutterandc>`guix build -L . --verbosity=2 -e '(@@ (chordpro) perl-harfbuzz-shaper)'` # because perl-harfbuzz-shaper isn't public
<xelxebar>peanutbutterandc: What about adding CXXFLAGS and LDFLAGS to the cxx call at the bottom of that makefile?
<peanutbutterandc>xelxebar, Um.... I'm sorry how do I access the build directory? o.O
<peanutbutterandc>from outside...?
<peanutbutterandc>okay --keep-failed passed
<peanutbutterandc>the main error is actually the test failure but we're still getting there
<Librecat> http://paste.debian.net/1163707 does this mean hardware failure
<milkman[bot]>debian Pastezone
<xelxebar>peanutbutterandc: How comfortable are you with writing guix package defs?
<peanutbutterandc>xelxebar, Pretty comfortable these days (I did send in a few patches too) (:
<xelxebar>I might try creating a pre-build phase that sets the CCCDLFLAGS environment variable.
<peanutbutterandc>Hmmm..... (setenv ?
<xelxebar>Yeah.
<civodul>Nix on content-addressability: https://www.tweag.io/blog/2020-09-10-nix-cas/
<milkman[bot]>Tweag - Towards a content-addressed model for Nix
<peanutbutterandc>xelxebar, What should I set it to?
<xelxebar>Oh, right. Try adding CXXFLAGS to it?
<jonsger>Librecat: does it work or not?
<peanutbutterandc>xelxebar, (setenv "CCCDLFLAGS" (getenv "CXXFLAGS")) ?
<xelxebar>peanutbutterandc: This is just me poking at the problem. I don't really understand how this perl makefile works, but my guess is that the compiler invocation at the end is missing some flags that guix needs.
<xelxebar>peanutbutterandc: Maybe try appending CXXFLAGS?
<peanutbutterandc>xelxebar, I did report it over at GitHub and here: https://github.com/sciurius/perl-HarfBuzz-Shaper/issues/8
<milkman[bot]>Build Failure · Issue #8 · sciurius/perl-HarfBuzz-Shaper · GitHub
<xelxebar>peanutbutterandc: Something like (setenv "CCCDLFLAGS" (string-append (getenv "CCCDLFSAGS") " " (getenv "CXXFLAGS"))
<peanutbutterandc>xelxebar, Okay. I will. Thank you very much. Also, that is a space and not a ":" ? o.O
<peanutbutterandc>I'm sorry I'm not familiar with this level of CCCDLFLAGS setting
<xelxebar>There might be a nice guile procedure or guix helper for appending to envars, but that should work.
<xelxebar>peanutbutterandc: Yeah, CXXFLAGS is just a space-separated list of flags inserted into the compiler call. I'm guessing that CCCDLFLAGS is something related.
<peanutbutterandc>xelxebar, Okay I will then. Thank you very much.
<peanutbutterandc>I'm just glad that I've got the working version of chordpro already packaged up. This is just so that I can follow and contribute (bug reports, etc. and not patches, yet, sadly) to the upstream repository...
<xelxebar>I find myself using guix packages similarly. It's a nice way of robustly documenting the build process.
<peanutbutterandc>There's also time machine, if anything goes wrong. :D
<xelxebar>Anyway, if that doesn't work, you could try adding CXXFLAGS and LDFLAGS to that line in the makefile.
<Librecat>it sometimes crashes with kernels newer than 5.4.59
<Librecat>jonsger, it didnt crash with the centos 8 kernel
<peanutbutterandc>xelxebar, I will do that then. Thank you for your help
<jonsger>Librecat: guix provides older kernels then 5.4
<xelxebar>peanutbutterandc: In the off chance you need to munge that file, the substitute* macro from (guix build utils) is effectively sed.
<Librecat>i will try 4.19
<Librecat>jonsger, how do i install older packages
<peanutbutterandc>xelxebar, Oh... okay. (I am not very good at regex golfing, sadly, but I'll try that too)
<peanutbutterandc>Librecat, You can use guix time-machine
<jonsger>Librecat: you run Guix system or guix as package manager on foreign distro?
<Librecat>jonsger, i use guix system
<jonsger>Librecat: so you need to change your system config
<Librecat>i dont see a line with "linux"
<Librecat>and i am not good with elisp
<Librecat>i used the graphical install to install this guix system
<jonsger>Librecat: you need to add it: (kernel linux-libre-4.9)
<Librecat>where
<Librecat>jonsger, where
<jonsger>(operating-system (locale ...) (kernel ...))
<Librecat>ok i added it after locale
<xelxebar>Librecat: Coming in late here, but general protection faults are typically driver problems. I wouldn't suspect hardware yet.
<Librecat>that explains me not having these errors on the centos8 kernel
<Librecat>its a heavily patched 4.18
<jlicht>civodul: doesn't the upstream nix daemon also support deduplication?
<civodul>jlicht: yes, it does
<xelxebar>efraim: Any ETA on that build? I might be closing down for the night pretty soon.
<civodul>but here it's a different thing: the famous "extensional model"
<xelxebar>efraim: No rush really. Could you just PM me when it finishes?
<jlicht>"It costs both time, and money (in cpu power, and storage space)." <- shouldn't that only be cpu power, provided deduplication is enabled?
<rekado_>this is the proposal: https://github.com/tweag/rfcs/blob/cas-rfc/rfcs/0062-content-addressed-paths.md
<milkman[bot]>rfcs/0062-content-addressed-paths.md at cas-rfc · tweag/rfcs · GitHub
<Librecat>jonsger, it didnt work
<jonsger>?
<Librecat>unbound variable
<rekado_>you may need to import (gnu packages linux) first
<jonsger>yeah
<Librecat> do i add it to the use-modules at the very top
<Librecat>jonsger rekado_ changing (use-modules (gnu)) to (use-modules (gnu packages linux))
<rekado_>don’t change. Add.
<Librecat>ok
<Librecat>rekado_, jonsger it worked thanks
<jonsger>:)
<Librecat>btw guile is a genius idea instead of editing a bunch of config files one by one we just edit a single elisp fiie
<jlicht>has anyone here been playing with the guix-home-manager?
<efraim>xelxebar: it's still building linux-libre
<xelxebar>efraim: Cheers. I'm running through znc, so ping me whenever.
<efraim>xelxebar: ok
<Librecat>4.9 is too old for my hardware :(
<Librecat>the graphics drivers dont load
<Librecat>jonsger, ^
<jonsger>and 5.4 and 5.8 don't work?
<Librecat>they do but i get general protection faults
<Librecat>and segfaults
<Librecat>jonsger, ^
<jonsger>so you should report a bug.
<raghavgururajan>error: search-patches: unbound variable
<raghavgururajan>????
<raghavgururajan>Am I missing a module?
<Librecat>i've never reported a bug before
<Librecat>can i use a custom kernel on guix
<Librecat>i will try some linux-libre kernels
<rekado_>Librecat: yes, you can, but you’ll need to build your own kernel package first.
<rekado_>Librecat: the cookbook has an article on how to do that.
<rekado_> https://guix.gnu.org/cookbook/en/html_node/Customizing-the-Kernel.html
<milkman[bot]>Customizing the Kernel (GNU Guix Cookbook)
<Librecat>rekado_ thank you ! :)
<rekado_>Librecat: to report a bug in Guix is easy: you just send an email with a description of your problem (and ideally with a recipe how to reproduce the problem) to bug-guix@gnu.org
<rekado_>if this is your first time it will take a little while before the email is accepted
<Librecat>my bios is kinda out of date since the manifacturer *cut off* support for my motherboard. This is why we use free software , to be independent of the manifacturer
<Librecat>i will reboot 10 times and compare the output of dmesg to see if it is reproducible
<Librecat>it shows the same errors i sent via paste.debian.net
<Librecat>i will try 5.4 libre kernel
<Librecat>unrelated to my problems but why cant i use the hurd kernel , are the drivers non existent
<desmes>Is there a way to find out the recommended packages (additional dependencies?) of a package? E.g. something like hunspell for Emacs or some fonts for Icecat, etc. I'm looking at the GUIX PACKAGE documentation but I'm not finding it.
<seeg123>hello, I'm trying to run `guix pull` however this is what I'm getting:
<seeg123>downloading from http://download.icu-project.org/files/icu4c/64.2/icu4c-64_2-src.tgz...
<seeg123>\sha256 hash mismatch for /gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz:
<seeg123> expected hash: 0v0xsf14xwlj125y9fd8lrhsaych4d8liv8gr746zng6g225szb2
<seeg123> actual hash: 08a82bkvvdkfx0kh7ri682prmrm7hvzbpdhw07m3nmgarj5h7pi3
<seeg123>hash mismatch for store item '/gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz'
<seeg123>build of /gnu/store/4582v7day5c4v9qaidlkwmd6kllks2y4-icu4c-64_2-src.tgz.drv failed
<milkman[bot]>Downloading ICU - ICU - International Components for Unicode
<seeg123>View build log at '/var/log/guix/drvs/45/82v7day5c4v9qaidlkwmd6kllks2y4-icu4c-64_2-src.tgz.drv.bz2'.
<seeg123>cannot build derivation `/gnu/store/534ngj9snq1l15wnb54a4ag7blpaj1jx-icu4c-64_2-src.tar.xz.drv': 1 dependencies couldn't be built
<seeg123>cannot build derivation `/gnu/store/xam27asppwc5ivyp6p77gjvflrg4fmdk-icu4c-64.2.drv': 1 dependencies couldn't be built
<seeg123>guix pull: error: build of `/gnu/store/xam27asppwc5ivyp6p77gjvflrg4fmdk-icu4c-64.2.drv' failed
<efraim>seeg123: run 'guix download https://flashner.co.il/~efraim/42c09n402s5nxy6blr6vnw437bbw7cfc-icu4c-58_2-src.tgz' if it has the correct hash it'll just work™ when you run '
<efraim>when you run guix pull next
<civodul>oh, do we have a disappared tarball?
<seeg123>efraim, thanks, what's this magic link?
<civodul>(actually guix download the URL above won't work because the file name will be incorrect)
<efraim>I put a couple of the missing tarballs on my site
<seeg123>it did run correctly
<efraim>civodul: good point
<seeg123>i still get hash mismatch
<seeg123>\sha256 hash mismatch for /gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz:
<seeg123> expected hash: 0v0xsf14xwlj125y9fd8lrhsaych4d8liv8gr746zng6g225szb2
<seeg123> actual hash: 15555k3q758m3d08v2p1iinj9qc0nqgicxk5j76hrpky7n83r4l3
<efraim>oh, wait, I have 58_2, not 64_2
<efraim>i'll grab it from bayfront
<efraim>seeg123: https://flashner.co.il/~efraim/missing-tarballs/icu4c-64_2-src.tgz
<seeg123>efraim thanks, what is 'bayfront' in case I happen to have similar problems in the future?
<efraim>it's our secondary build machine with a large cache of older tarballs.
<seeg123>ah ok
<efraim>there's a content addressed mirroring system that serves substitutes and tarballs based on their hash but with icu4c's redirection on their older source tarballs it doesn't always get asked
<seeg123>seems to have worked
*jonsger wonders if someone tried to build a nss >= 3.53. It fails with
<jonsger>blapit.h:11:10: fatal error: seccomon.h: No such file or directory
<seeg123>i am just starting out with guix, wanted to build a simple vm image :)
<efraim>lxqt-config takes longer to build than I would've thought
<civodul>efraim: when you stumble upon missing tarballs, could you give a heads-up?
<efraim>civodul: sure
<civodul>just to see if we're doing things right
<civodul>normally we should have them on berlni
<civodul>*berlin
<efraim>although I'm not looking for too many old ones, the ones I came across was from trying to bring back the mips port
<efraim>it was still pointing at hydra so I just ran it with --no-substitutes
<efraim>the docker service should probably add docker-cli to the profile service thingy
<civodul>yeah, makes sense
<efraim>Found a mistake in the documentation with the docker service, I'll get that too
<civodul>yay!
<civodul>continuously improving :-)
<efraim>trying to export my guix system container to a docker container is frustrating
<apteryx>civodul: where would a patch adding a 'delayed' property of the origin snippet field go? Would master be OK? I'm asking now to know on which branch to base such change.
<apteryx>to the*
*mothacehe Added a new page at https://ci.guix.gnu.org/metrics.
<efraim>ISTM that if you add it and it tries to rebuild the world then it would need to go to core-updates
<mothacehe>apteryx: I think civodul advised against such a change for performance reasons in the past.
<apteryx>yes, we're discussing it in the 'Dependency cycle issues when using a Gexp-based snippet' thread on guix-devel. He suggested a way to benchmark the performance to see the effect such a change would have.
<apteryx>efraim: good observation, I'll just try it on master and see.
<civodul>mothacehe: it would seem the performance issue doesn't quite exist
<civodul>apteryx: master would be fine
<civodul>mothacehe: oh! https://ci.guix.gnu.org/metrics is beautiful!
<civodul>maybe evaluation time could be shown as a graph too?
<civodul>also it would be nice to see the "builds per day" line overlaid with a "new derivations per day" line
<civodul>to see if they match
<civodul>and a pony, too
<civodul>:-)
<mothacehe>civodul: thanks! Oh good idea, I'll add it!
<mothacehe>(the new derivations per day line :p)
<g_bor[m]>Hello gux,
<g_bor[m]>so far I have one new Outreachy proposal, about improving guix time machine.
<rekado_>mothacehe: very nice!
<g_bor[m]>Did you have an opportunity to have a look at that?
<mothacehe>thanks rekado_ :)
<rekado_>4500+ seconds per evaluation seems … really long
<mothacehe>yes plus it seems to trigger memory allocation issues with guile + libgc@8
<civodul>hey g_bor[m]!
<civodul>g_bor[m]: i haven't see it, no
<civodul>*seen
<civodul>one has to log in on outreachy.org?
<apteryx>is something broken on master? I get In procedure append: Wrong type argument in position 2 (expecting empty list): #<procedure %final-inputs ()>
<apteryx>just running ./pre-inst-env guix build hello
<seeg123>is there a way to use some build caches? I try to build a bare guix os system image but it takes ages, currently it builds guile for about an hour now and my PC is quite powerful :)
<rekado_>civodul: I think this is about <CAJ3okZ1-WujYOpA=72tMBG+_+oSONq3+SpqH0ckU9cBrBZ95bw@mail.gmail.com>
<rekado_>seeg123: are you not using binary substitutes on purpose?
<seeg123>no
<rekado_>how did you install Guix?
<seeg123> https://guix.gnu.org/manual/en/html_node/Binary-Installation.html#Binary-Installation basically
<milkman[bot]>Binary Installation (GNU Guix Reference Manual)
<seeg123>I use archlinux but the package here seems to be broken so I just used the above guide
<rekado_>the installer script (linked at the top of the URL above) will ask you if you want to use binary substitutes.
<seeg123>hm ok
<rekado_>see also point 7 in the guide
<seeg123>ah it's called "substitutes", i was skimming for the docs looking for "cache" but haven't found it :)
<seeg123>ah ok seems to download now and it's faster
<seeg123>thanks
*rekado_ wants to generate a new GPG key and store it on the Yubikey
<rekado_> https://github.com/drduh/YubiKey-Guide#nixos
<milkman[bot]>GitHub - drduh/YubiKey-Guide: Guide to using YubiKey for GPG and SSH
<rekado_>someone™ should add a Guix section :)
<wehlutyk>Hello guix!
<wehlutyk>I'm trying to get the Zotero flatpak to work properly on guixsd, and running into a portal problem. Would anyone here be willing to help troubleshoot?
<civodul>rekado_: definitely! :-)
<wehlutyk>(my problem is not specific to Zotero)
<civodul>seeg123: out of curiosity, why did you look for "cache"? a former Nix user maybe?
<seeg123>We do use nix as it makes things simpler, just trying out guix
<seeg123>i was thinking of "build cache" or smth like that
<rekado_>civodul: I might actually write that Guix section — and a cookbook entry
<civodul>yay! :-)
<civodul>seeg123: ok; Nix uses the term "binary cache" these days i think, others just say "pre-built binaries" or similar
<wehlutyk>In short, neither xdg-desktop-portal nor xdg-desktop-portal-gtk seem to export the `org.freedesktop.portal.OpenURI` interface, meaning that I can't open files/URIs from inside Zotero. I had stumbled on that using the firefox flatpak also
<zimoun>rekado_ mothacehe: the average 4500+ sec per evaluation should not be representative, statistically speaking. For example, ungoogled-chromium kill this stat.
<zimoun>civodul: well I am proposing something about “guix git log” to more easily find old packages. I guess that what g_bor[m] refers to: https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00108.html
<milkman[bot]>[OUTREACHY] toward a proposal?
<mothacehe> zimoun: This 4500s evaluation represents the required time to go through every possible package derivation (~50K) and check if a build is needed. The time should be relatively constant on master.
<mothacehe>But I agree with your email and this average thing is not that interesting. I'll consider adding a plot as ludo suggested or some other statistic as you suggested.
<zimoun>mothacehe: thanks for explaining.
<civodul>zimoun: oh, nice!
<efraim>has anyone had success logging into a guix docker-image? I'm trying 'docker run --privileged ... /run/current-system/profile/bin/bash --login' and i'm not getting a prompt
<apteryx>efraim: you need to use docker exec to have /run/current-system
<apteryx>the manual examples uses that
<apteryx>otherwise you can bind your profile/etc to /etc and your bins to /opt/gnu/bin or something then use /opt/gnu/bin/bash --login, I think.
<apteryx>(to use with docker run)
<apteryx>it's been a while
<apteryx>I have a bunch of scripts somewhere that may provide more clues if you need more help
<efraim>ah, I had the manual open to the docker service section
<raghavgururajan>wehlutyk: That is a flatpak-wide issue. Due to how it works (containerised manner). I am not aware of any work around for that in guix. Anyway, we have nix-service-type, where you can nix's zotero.
<efraim>looks like i need to take my container, run it, and then exec into it
<efraim>success! thanks apteryx
<apteryx>yay!
<efraim>Definately writing that down for later
<wehlutyk>raghavgururajan: you mean it's an issue with flatpak on guix? or an issue with flatpak generally? Other users of zotero on flatpak don't seem to have that issue, and my understanding is that portals are exactly for that use-case
<raghavgururajan>wehlutyk, flatpak on guix
<raghavgururajan>Something to do with FHS.
<wehlutyk>oh, ok
<peanutbutterandc>Hey there,
<peanutbutterandc>is there a way to trigger a build from scratch even though it's already been built successfully?
<apteryx>--check --no-grafts
<peanutbutterandc>apteryx, Oh wow. Cool. Thank you! Could you please explain why the --no-grafts?
<apteryx>by defaults, guix build will honor grafts, but this has the often undesirable effect that your --check will only repeat the grafting part, which is probably not what you're after.
<peanutbutterandc>Hmmm... thank you very much. (I just realized that I need to read about what grafts are, exactly. But I shan't bother you with that)
<apteryx>no worries. I should read more about grafts too ;-)
<peanutbutterandc>xelxebar, Hey there! So the issue was fixed by setting 'LIBS=-L/absolute/path/to/harfbuz/lib -lharfbuzz' in the #:make-maker-flags. (:
<peanutbutterandc>apteryx, (:
<raghavgururajan>To use /gnu/store/... path as file-URL, should it be `file:////gnu/store/... ` or `file:///gnu/store/...`?
<wehlutyk>Thanks raghavgururajan , I try to file a bug when I have the time then
<bdju>in the linux-libre source browsable online somewhere or do I have to download a tarball to look through it?
<reepca>civodul: regarding 42023, just to double-check, after applying the troublesome patch 'canonicalize-with-link' looks like this, right? http://paste.debian.net/1163765
<bdju>s/in the/is the
<milkman[bot]>debian Pastezone
*reepca is very puzzled by that strace output
<reepca>the only potential explanation that comes to me so far is that somehow the target (/gnu/store/.links/0k63r0n3681r2gqd00blq4z5xd7cw1knv0x049p99f0pq31brhrk) exists but is a dangling symbolic link (didn't know that 'file-exists?' uses stat and not lstat), but I have no idea why that would be there
<apteryx>civodul: I don't get it, but on current master, making the origin snippet field thunked or delayed, nothing can be built anymore (cycles are introduced?). It wasn't like this the last time I tested this.
<civodul>apteryx: did you miss a recompilation?
<civodul>reepca: i have to go but i'm happy to discuss it in a couple of hours :-)
<civodul>(or by email)
<bdju>I'm researching USB WLAN devices that work with free software and I'm finding that the REALTEK RTL8812BU chipset is very common and there are options readily available that use it. The driver for this is free, but it's not in the kernel, and it's not yet packaged on Guix.
<bdju>I have a device that uses this driver and so I was hoping to find something with a chipset already in the kernel to recommend a friend, but I'm increasingly thinking it would be easiest to get this driver packaged
<bdju> https://github.com/cilynx/rtl88x2bu driver here
<milkman[bot]>GitHub - cilynx/rtl88x2bu: rtl88x2bu driver updated for current kernels.
<bdju>if anyone has experienced packaging drivers, it would be pretty useful to have this packaged
<bdju> https://waifupaste.moe/raw/jtd here's a screenshot of three models with the chipset I found on US Amazon
<bdju>the exact one I bought a couple months ago isn't being sold anymore but it looks like the top or bottom one pretty much
<pancak3>bdju: Guix is pretty good at abstracting things so they just work. I managed to successfully package a linux kernel module and I still don't know how those work. It's probably not as hard as you think.
<apteryx>sneek: later tell civodul I did run make clean-go and recompiled, so that should have covered it
<sneek>Got it.
<bdju>pancak3: I'll give it some thought, but I find it to be rather intimidating and I'm not sure I'd get anywhere with it.
<pancak3>bdju: what I usually do is just pop onto this IRC and say: I'm packaging a kernel module that does blank. What are some similar packages I can look at for inspiration. It's never failed me
<bdju>pancak3: thanks for the idea
<apteryx>Guix is approaching 15000 packages (currently at 14800) :-)
<jonsger>CI web frontend seems down
<rekado_>jonsger: yes, just noticed. Odd
*rekado_ kicks it
<rekado_>it’s back
<raghavgururajan>apteryx: I can do +10 by this month. 🙃
<raghavgururajan>What's the number on debian?
<apteryx>probably around 45 k or so
<raghavgururajan>😮 😯 😐 😶
<apteryx>ah, perhaps I'm exaggerating; this suggests ~ 32k: https://repology.org/repository/debian_unstable
<milkman[bot]>Debian Unstable repository information - Repology
<apteryx>nixpkgs unstable has an impressive ~52 k packages
<raghavgururajan>Oh, they split a package into multiple one, like foo-bin and foo-dev etc. We do outputs.
<raghavgururajan>Oh wow
*jonsger focuses more on quality then on quantity. There just to many broken/not perfect packages...
<raghavgururajan>jonsger, +1
<raghavgururajan>Does using nix-service-type on top of guix system, cause any conflicts or issues?
<rekado_>apteryx: they also claim to have all R packages from CRAN, but many many of them won’t build
<rekado_>that’s because they automate that stuff, but don’t seem to care enough to make it build.
<apteryx>rekado_: I see! I guess jonsger has a point :-). I also value quality above quantity.
<rekado_>I’m probably biased but I wouldn’t use any other distro but Guix for R work.
<rekado_>*probably* biased.
<fnstudio>hi! i have this mcron script that i launch with `mcron` (or `mcron --daemon`) as a user; the config file is `~/.config/cron/main.guile`
<fnstudio>the file used to work but now i'm having some issues with a change i made and i'm wondering if there's any way to debug that?
*raghavgururajan wouldn’t use any other distro but Guix for anything 🤣
<fnstudio>i know i get an error code when mcron quits but sadly that's not v helpful
<fnstudio>not sure this mcron question really belongs here... (it's not about shepherd or anything really guix specific) but i thought there might be someone knowledgeable of guile/mcron
<jonsger>fnstudio: I found it pretty hard to debug mcron stuff on guix and I can't really help you :(
<apteryx>fnstudio: if the error happens in a job, you can run the job code by itself
<fnstudio>jonsger: oh well, that's very helpful indeed, at least i know i'm not alone :)
<fnstudio>apteryx: right, but well, no, the error seems to be due to my (wrong) use of `with-mail-out`
<fnstudio>apteryx: so i'd need to debug the config file in itself, as a mcron (or guile?) file, i suppose
<fnstudio>i was surprised in not finding a lot of examples around that
<fnstudio>just this, as far as i can tell, https://lists.gnu.org/archive/html/help-mcron/2016-03/msg00000.html
<milkman[bot]>[Help-mcron] How to use with-mail-out in mcron guile file?
<fnstudio>lol, stupid me i wasn't importing it properly! ("it" being the `with-mail-out` command)
<fnstudio>so, in case someone stumbles into this, this fixed it for me: `(use-modules (mcron redirect))`
<fnstudio>as explained here https://www.gnu.org/software/mcron/manual/mcron.html#The-redirect-module
<milkman[bot]>mcron 1.1.1
<apteryx>fnstudio: good to know!
<fnstudio>:)
<raghavgururajan>milkman[bot], weather toronto
<milkman[bot]>It is currently 16.06 °C in Toronto.
<raghavgururajan>milkman[bot], thanks
<milkman[bot]>it’s nothing
<peanutbutterandc>Question: I understand this: `(1 2 3 ,(+ 2 2)) but what is `(1 2 3 ,@(+2 2))`? (in guix packages that (inherit) from other packages)?
<peanutbutterandc>...as in `guix edit zile-on-guile`?
<peanutbutterandc> (inputs
<peanutbutterandc> `(("guile" ,guile-2.0)
<peanutbutterandc> ,@(package-inputs zile)))
<apteryx>it's the syntax to splice (i.e., insert in place) a list into another list (at the same level).
<apteryx>e.g., `(1 2 ,@'(3 4)) == (append '(1 2) '(3 4))
<apteryx>in your example, it's adding the "guile" input on top of all the usual inputs of the zile package.
<peanutbutterandc>Ah! That makes a lot of sense. Thank you very much.
<apteryx>you can eval the code at the REPL to see what list produces
<peanutbutterandc>Is there any way I could remove multiple entries in an assoc-ref in one go? (assoc-remove!) only removes 1
<peanutbutterandc>I want to simplify the input list of a package that inherits from another. This means removing only a couple of inputs from the inherited one, and then adding a few
<apteryx>a grep suggests: (fold alist-delete (%final-inputs) '("libc" "gcc"))
<apteryx>so, (fold alist-delete your-original-inputs '(inputs to remove))
<peanutbutterandc>wow you are really good at regex-golfing. I need to get my grep-game up. Thank you very much
<apteryx>eh, I had the luck of knowing it'd involve alist-delete, which made it easy :-)
<jonsger>is there any reasoning why backtraces of guix have those super short line width, so that no one can read the store paths further then /gnu/store/abzwefwef...
<apteryx>the reasoning is "trimming long lines of output" is the reasonable default. Unfortunately the way to change this is not well documented/convenient. It involves setting the COLUMNS environment variable to the number of chars you want to preserve (per line).
<apteryx>There's a bug about this in the Guile debbugs tracker.
<pancak3>how come when you inherit another package, the version variable remains the original packages version and not the new version?
<peanutbutterandc>pancak3, Hey there! Inheritance seems to cascade. So if the parent has (version "1") but child has (version "2") child's one over-writes the parents one...
<pancak3>27.1 > 28.0.50 ???
<peanutbutterandc>May I see the package definition please?
<pancak3>emacs vs emacs-next
<apteryx>pancak3: it's a limitation in teh way the bindings for the record fields are created
<pancak3>is there an easy way to get the version I want? Like some (package-version self) kinda deal?
<apteryx>you should be able to use (package-version inherited-package)
<pancak3>oh see I actually want it the other way around I think
<peanutbutterandc>emacs and emacs-next seem to be doing what I expect of inherited packages to me...
<pancak3>(define-public emacs ... ... (copy-file (string-append "emacs/" version "/lisp")))
<pancak3>I want emacs-next to override the version in emacs so I copies the right folder
<pancak3>this is part of fixing bug 43277 btw
<peanutbutterandc>but if a child inherits from parent, won't the parent just stay as they are? Like in classes and objects?
*raghavgururajan *yarns*
<pancak3>well that's what happening but I don't want to copy past everything from the parent into the child :/
<peanutbutterandc>well I don't know much about this, anyways. I just chimed in because I was just fixing up an inheritance in a package definition.
<pancak3>So I'd want something like (package-version self) that I'd put into the emacs definition. I also have no clue how any of this works so maybe that's not possible
<apteryx>pancak3: have you seen the last message of that thread? The package "seq" shouldn't appear in your profile anymore since it comes with Emacs.
<apteryx>If something propagates it, it's a bug.
<peanutbutterandc>pancak3, there's this-package
<peanutbutterandc>perhaps (package-version this-package) is what you're looking for
<peanutbutterandc>It's there at the very end of 'package reference' section in the guix manual
<pancak3>apteryx: that's not the bug. I packages emacs-next and I never tested it cuz I'm an idiot. It breaks when nothing else is installed because I'm a dummy who didn't do the environment variables right
<pancak3>peanutbutterandc: Yah!
<pancak3>peanutbutterandc: lemme try
<apteryx>pancak3: eh, don't be so hard on yourself, we all make gaffes ;-)
<pancak3>apteryx: ya but this was less a mistake and more carelessness. I really should've noticed this
<peanutbutterandc>pancak3, sounds like me. But (a lot) smarter. lol.
<pancak3>ugh, it won't let me use this-package. It doesn't look like it does what I want :/
<apteryx>seems you could simply use the 'emacs-version' binding, no?
<pancak3>ok, so the fix to the bug is to copy the native-search-paths section from emacs to emacs-next because the path depends on the version
<jlicht>pancak3: that would only work for thunked record fields, sadly. So afaik, you have to copy all of these 'boring' things :/
<pancak3>however, if I managed to get emacs to take emacs-next version, then I wouldn't need to copy the native-search-paths and I could also delete the arguments section from emacs-next
<apteryx>ah, this search-path keeps causing issues, I ressuscitate a previous attempt at getting rid of the versioned component.
<pancak3>am I allowed to resort to regex :P
<apteryx>I should*
<apteryx>Emacs supports adding ':' to EMACSLOADPATH which does the same thing and is version agnostic, but our search-path machinery can't express this yet.
<pancak3>what do you mean adding ':'? like EMACSPATH=/profile/lisp::
***bran is now known as Bran
<apteryx>or just "EMACSLOADPATH=/profile/lisp:", IIRC.
<apteryx>a trailing sep
<apteryx>but the position doesn't matter
<apteryx>could be at the front
<jonsger>apteryx: it's at least 15 or 20 chars shorter then usual output of guix, so it's not a reasonable default...
<pancak3>you're right. The problem goes away by pre-pending a colon
<pancak3>I like this solution. I will pursue
<apteryx>jonsger: guix ui seems to rely on (terminal-columns) to determine the width of the terminal. You are right that there's a mismatch. Another reason to fix: bugs.gnu.org/36677
<jonsger>the upstream issue of guile is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36677, but it doesn't seem that there is any recent activity
<milkman[bot]>#36677 - [PATCH] Don't truncate backtraces - GNU bug report logs
<jonsger>ah thats the same :P
<apteryx>you are welcome to cause this to change :-)
<apteryx>some different opinions came out on that thread, IIRC what stood out was that it should be easy to tweak (a parameter seems like a good fit).
<pancak3>do you think I should just prepend the ':' to EMACSLOADPATH in the emacs-build-system?
<pancak3>it'd be the easiest thing to do
<apteryx>pancak3: no, you'd have to make this fix in a couple places in the code base (build system, guix environment, ...), which would be unwieldy.
<civodul>hey reepca!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: I did run make clean-go and recompiled, so that should have covered it
<leoprikler>I haven't read all of this, but what is the context here anyway?
<leoprikler>[w.r.t EMACSLOADPATH]
<civodul>apteryx: did you figure out what was wrong?
<reepca>o/
<pancak3>leoprikler: if EMACSLOADPATH=/profilelisp: everything good. if EMACSLOADPATH=/profilelisp:/systemlisp everything good. if EMACSLOADPATH=/profilelisp everything bad
<pancak3>everything is bad for emacs-next right now
<pancak3>systemlisp is like the /gnu/store/...emacs-.../share/version/lisp
<pancak3>we could fix emacs-next by adding the system lisp dir to the emacs-next definition but it would mean some redundant code. If emacs-next could override the version variable in emacs, everything would be pretty great. If we could append a ":" to the end of EMACSLOADPATH then that would be ideal
<pancak3>That's probably a bad explanation but that's the current situation
<leoprikler>ehm, as a quick solution, you could use something wrap-program esque to add ":" ass a suffix to EMACSLOADPATH
<leoprikler>but just to be sure, this is specifically an emacs-next problem atm, right?
<pancak3>yep
<leoprikler>could there be some pollution from emacs 27 stuff spilling into your EMACSLOADPATH?
<leoprikler>e.g. you have emacs 27 installed and try to get emacs-next running in a `guix environment` without --pure?
<pancak3>ya. emacs-next works with emacs lisp. If you don't do --pure and you have emacs, then it appears like everything works
<pancak3>but if you do --pure, than you realize we don't have the emacs-next lisp
<leoprikler>hmm, sounds like the emacs-next search-path is borked, you should probably try to get the version part right
<pancak3>I'm probably not making a lot of sense here. I feel like all the words I'm saying have like 3 meanings
<pancak3>I don't think we're on the same page
<leoprikler>and make sure, that the search-path set by `guix environment --ad-hoc emacs-next` does contain a valid directory
<pancak3>emacs sets EMACSLOADPATH to profilelisp:systemlisp
<pancak3> emacs-next currently sets EMACSLOADPATH to profilelisp
<leoprikler>p sure that "profilelisp:systemlisp" is not an actual string
<pancak3>ya, that's what I'm calling it. That's not the actuall values
<leoprikler>also p sure that it's only profilelisp unless installed system-wide (which I don't)
<pancak3>I didn't understand that last statement
<leoprikler>my current EMACSLOADPATH is $GUIX_PROFILE/share/emacs/site-lisp:$GUIX_PROFILE/share/emacs/27.1/lisp
<pancak3>yep. that's what I was calling profilelisp and systemlisp
<pancak3>maybe not good names. but that's what you should have
<leoprikler>if the latter is missing with emacs-next, that's because the version part (here 27.1) does not match the file being installed
<pancak3>yes exactly
<apteryx>pancak3: if repeating code for the emacs-search-path abhores you (which I kind of understand), you could factor it out as a procedure, and call it with the a version arg.
<leoprikler>IIRC emacs-search-path already refers to version, but that may be broken for emacs-next currently
<jlicht>civodul: to prevent the ML from being spammed with "Not me", my sad old T400 with 8GB ram has no issues /w Emacs 27.1 session running for about 4 days now.
<pancak3>the version variable in the emacs definition is always 27.1 even when called from emacs-next. the emacs-next version doesn't override the emacs version
<pancak3>If I could make the emacs definition run with the emacs-next version, there wouldn't be any problem at all
<reepca>civodul: that cycle of ENOENT -> EEXIST -> ENOENT... is very odd. The only way a canonical link should be getting deleted is if the gc is run, and that shouldn't cause any more than a few retries. But stat() is consistently returning ENOENT for a prolonged period of time. After looking at the stat man page, the only explanation I have for that is that either a dangling symlink has somehow been placed where the canonical link should go
<reepca>or we've managed to end up with different versions of guix/store/deduplication.scm
<jlicht>and I have 107 emacs packages installed, so we could do some debugging with the disjoint set of our packages ;-)
<jlicht>s/disjoint/relative complement/ ...
<pancak3>maybe I'm wrong. I noticed an error in my tests. I'm trying again now, but of course building stuff takes forever
<civodul>jlicht: good to know, thanks :-)
<civodul>reepca: hmm!
<civodul>yeah dunno, i didn't try to investigate
<civodul>it happened while retrieving a store item after build completion
<efraim>my pine64 seems to have locked up a second time while building guile-static
<apteryx>pancak3: I think some copy paste is OK as a quick fix, and I'll propose a patch to make it possible to #:append-separator? #t when defining a search-path.
<apteryx>but that patch can only be applied to core-updates, so it'll take some time before it finds its way on master
<str1ngs>efraim: hello, I offload my rockpro64 builds more powerful machine. with qemu binfmt
<str1ngs>to a more*
<efraim>Mine isn't necessarily faster when emulated, just more stable
<str1ngs>understandable, also heat dissipation helps
<str1ngs>also factoring in RAM
<jonsger>apteryx: COLUMNS doesn't work for all backtraces. I just use it as COLUMNS=300 ./pre-inst-env guix build nss
<jonsger>that's frustrating
<apteryx>in Guix the matter is made more complicated for backtraces because some Guile scripts are evaluated in the environment of the daemon.
<jonsger>I still don't know which file can't be deleted because of non existin
<apteryx>so you need to set an extra environment variable for your guix-daemon
<jonsger>apteryx: how can I do that?
<str1ngs>maybe, but so far offloading has worked well for my rockpro64 and pinephone
<apteryx>are you on Guix System, or another distro?
<jonsger>guixsd
<jlicht>is there any idiomatic way to concatenate the contents of G-Expressions?
<civodul>jlicht: what d'you mean by "concatenate"?
<jlicht>literally, `cat <file1> <file2>`
<apteryx>jonsger: hmm, I'm trying to find out if it's possible to set an extra environment variable for the guix-service-type
<civodul>jlicht: but gexps contain code, not arbitrary byte strings
<civodul>for a sequence, you can write #~(begin #$exp1 #$exp2)
<civodul>then if you know EXP1 and EXP2 are string-valued, you can write #~(string-append #$exp1 #$exp2)
<civodul>so it really depends on the context
<jlicht>hmm, I'm trying to write s-expressions (elisp) to the store, and I would prefer if I don't have to immediately 'drop down' to representing everything as strings that I then feed to mixed-text-file
<civodul>ah yes, definitely
<civodul>you can maybe use 'scheme-file' for that
<civodul>as in (scheme-file "foo.el" #~(this is actually (elisp)))
<jlicht>I am, but running into some reader troubles there ;-)
<jlicht>I end up with about 50 tiny 'scheme-file's that I'd like to concatenate now, so I can dump them in some form of init.el
<civodul>oh, i see
<civodul>i guess you could use a computed-file that depends on all these scheme-file and concatenates them
<civodul>but you have to explicitly write the code that does that
<jlicht>oh wow, that was exactly what I was looking for
<apteryx>jonsger: hmm, I can't find how to do this at the level of guix-service-type. It'd be good to add a backtrace-max-width field to the guix-configuration record and have it setenv the COLUMNS environment variable in the guix-shepherd-service procedure.
<jlicht>civodul: are 'normal' scheme types also "ungexp"-able?
<jonsger>apteryx: hm oke, so it seems the icedove update has to wait some more days :P
<apteryx>I think it used to work to set COLUMNS in the /root/.bash_profile file but Shepherd no longer defaults to use environment variables from its environment so that probably doesn't help anymore.
<apteryx>eh, sorry about that!
<civodul>jlicht: yes!
<civodul>as in #$123
<jlicht>amazing :-).
<reepca>so it turns out that currently 'deduplicate' will simply try canonicalizing anything that isn't explicitly a directory
<reepca>this includes symlinks
<reepca>the behavior of link() when given a symlink as oldpath is implementation-defined, and we use the preprocessor macro CAN_LINK_SYMLINK in optimise-store.cc to determine it
<reepca>but the main problem is that I didn't consider that symlinks might be deduplicated (they can be on linux), nor did I consider that 'file-exists?' would use stat instead of lstat.