IRC channel logs

2020-03-24.log

back to list of logs

<mbakke>looking forward to a wave of libgdx games!
<NieDzejkob>hmm, I wrote a package definition with a transitive module dependency missing from #:imported-packages (instead of using %gnu-build-system-modules I manually specified utils, gnu-build-system and python-build-system and it couldn't import gremlin), and when I tried to build it a derivation for module-import-compiled failed. Now when I fixed the problem, I get a different error, In procedure symlink: File exists https://paste.debian.net/1136253/
<lfam>NieDzejkob: It means the filename of the symlink you are trying to create already exists
<NieDzejkob>Turns out that's what you get when there are duplicates in #:imported-modules and it's not, as I thought, a weird statefulness in the store
<vagrantc>aha!
<vagrantc>pinebook pro works with linux-libre-arm64-generic 5.4 + .dtb from patched 5.5 ...
<vagrantc>i thought last time i tried that it didn't work ...
*vagrantc wonders how hard it would be to add an option to use an out-of-tree device-tree
<roptat>ok, jarjar seems to be enough to build a similar jar, now let's see if that's enough for surefire to run properly
<roptat>aha! it worked, almost
<roptat>I now have a different error message :)
<KE0VVT>vagrantc: Do you know the FSF's position on the Pinebook?
<vagrantc>KE0VVT: no
<roptat>it's failing to find JUnit4Provider, which I haven't built, so let's do that now ^^'
<KE0VVT>vagrantc: I have considered the idea of having a powerful desktop computer and a tiny, durable laptop with good battery life for on the go.
<KE0VVT>vagrantc: Talos + Pinebook + Guix System :-)
<vagrantc>KE0VVT: the upgradable keyboard firmware has some binary blobs ... so my guess would be not real happy about it
<vagrantc>that's the pinebook pro, specifically
<vagrantc>the older pinebook is pretty good, other than the wifi which probably requires binary blobs and isn't even supported in linux, let alone linux-libre
<vagrantc>but the boot firmware for the original pinebook all the way down is in guix and debian, and i recently tested that it boots (using the same OS that boots on pinebook pro, just swapped out bootloader)
<lfam>What wifi chip isn't supported in linux at all?
<vagrantc>honestly, i haven't checked recently ... happy enough with my atk9k usb wifi :)
<KE0VVT>vagrantc: I thought the Pinebook was d̲e̲s̲i̲g̲n̲e̲d̲ for Linux. Why would they put such a card in it?
<lfam>Nvm I found it
<vagrantc>KE0VVT: it's very similar to existing ones, so probably wouldn't be hard to get fixed
<vagrantc>lfam: status may have changed ... i haven't looked in a year or so
<roptat>gah, it requires junit3 :/
<vagrantc>KE0VVT: and with these sorts of systems, they often come built-in with the SOC
<vagrantc>lfam: which one is it?
<lfam>Some realtek chip
<vagrantc>(RTL8723cs
<vagrantc>only mention in linux next-20200311 is in pinebook and pinetab device-trees
*lfam tests new Git
<roptat>hm, NullPointerException now :/
<nckx>lfam: As in test suite?
<lfam>nckx: As in tries to fix the 'install-credential-netrc' phase
<nckx>Same.
<lfam>How can I make Guile not abbreviate backtraces?
<lfam>Upstream commit 1c78c78d2513eaf22105c87484c65b4eecdf0bfc is responsible
<nckx>No point in us both investigating the same thing. I'm glad: bed time then. o/
<rain>noob question: is there a way to get tab autocomplete in the init rescue REPL? (if not, i can just look things up on this laptop, but it'd suck if this laptop wasn't here to look things up on)
<kkebreau>rain: Unless you can import the readline module, I don't think tab autocomplete will work.
<kkebreau>I don't remember it working for me last time I tried. Try "(use-modules (ice-9 readline))" at the prompt.
<rain>"no code for module"
<rain>it's not a big deal tbh
<rain>on the other hand, if i enter ,q, will it continue from the error?
<rain>(it was trying to symlink something)
<kkebreau>If you fixed the issue, it should continue just fine.
<kkebreau>If not, I think it leads to a kernel panic.
<rain>does it retry the symlink? or should i do that myself? ....i guess i can just find out by trying ,q....
<rain>yup, panic.
<kkebreau>I don't think I've ever accidently landed in that REPL and successfully continued booting.
<rain>dam. i was hoping the famous lisp error handling would shine in a situation like this.
<kkebreau>Maybe it does, but I'm not familiar with Guix System state early on in the boot process.
*kkebreau needs sleep
<rain>do a slep. slep is good.
<lfam>vagrantc: Can we remove the comment about the ASUS C201PA requiring a particular kernel from 'gnu/system/examples/asus-c201.tmpl'?
<vagrantc>lfam: i don't think it works with "plain" linux-libre ... but yeah, the comments need some updating
<kondor[m]>Is something wrong on my system, or the standard guix git does not have the submodule command?
<goldenshimmer>Hi! I've dived into writing some packages, and have run into a bit of a mystery: What's the right way to unpack multiple source tarballs that collectively serve as the source for a package? I tried this, but it says "Unbound variable: inputs" when it gets to the "(copy-file (assoc-ref inputs" bit: https://gitlab.com/ethus3h/ember-shared/-/blob/master/data/packages/dce.scm#L203 Thanks!
<brendyyn>goldenshimmer: you can specify an (origin ...)
<brendyyn>goldenshimmer: Above the define-public... of your package, create a regular (define foo-data (origin ....)
<lfam>kondor[m]: What did you try and what happened?
<kondor[m]>lfam: git submodule update --init --recursive
<brendyyn>goldenshimmer: in the phase you need #:key inputs #allow-other-keys in the lambda. there are many examples
<kondor[m]>lfam: output was git: 'submodule' is not a git command. See 'git --help'.
<lfam>Huh, it works for me kondor[m].
<lfam>What does `git --version` say kondor[m]?
<goldenshimmer>brendyyn: I'll pursue those, sounds like it will get me back on track. Thank you!
<kondor[m]>git version 2.25.0
<kondor[m]>... but now I'm thinking ... is there an environment variable that is necessary for this to work?
<kondor[m]>ooooh
<kondor[m]>GIT_EXEC_PATH is the culprit
<brendyyn>goldenshimmer: check out the adanaxis-mush package
<kondor[m]>I have git in a separate profile
<lfam>Yeah, it needs to be in the profile you are using
<kondor[m]>lfam: GIT_EXEC_PATH from one profile was overwritten by the default .guix-profile path
<lfam>It was in a profile besides the one you are currently using?
<kondor[m]>lfam: i have multiple profiles that i am using in the same time; it appears, something was misconfigured when i was sourcing each profiles etc/profile
<lfam>Huh, I'm not sure that using more than one profile at a time is supported
<lfam>If you can make it work, that's good
<kondor[m]>lfam: wasn't there a cookbook article about multiple profiles in simultaneous use
<kondor[m]>lfam: also this https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
<kondor[m]>is the information outdated?
<kondor[m]>i think the cookbook and the one linked were my starting points when developing multiple personality setup
<kondor[m]>but, can't remember :)
<kondor[m]>it's too late and nothing works today
<lfam>I don't think it's outdated, but as you found there can be conflicts between the profiles
<lfam>I hadn't read that blog post before
<kondor[m]>lfam: yes, that's precisely why I was avoiding profiles before ... but then the blogs + cookbook appeared and i thought, lets try it out. I was handling the conflicts manually though
<kondor[m]>lfam: so, yeah, in my experience multiple profiles together is a setup very prone to malfunction
<lfam>Presumably you only need Git in one of your profiles
<kondor[m]>lfam: presumably there is a thing in the other that depends on git
<kondor[m]>git gets pulled in
<kondor[m]>hence the environment var conflict
<vagrantc>ok, i have a booting pinebook pro kernel based off of 5.4 in guix now ... just need a single patch to add the device-tree
<vagrantc>it could potentially apply work for aarch64 linux-libre as well as linux-libre-arm64-generic (though i haven't tested with plain linux-libre aarch64)
<vagrantc>if i apply it to all packages, then linux-libre will be essentially needlessly rebuilt on all architectures
<vagrantc>i guess linux-libre-5.4-source could conditionally apply a patch on aarch64?
<vagrantc>any idea what i'm doing wrong to try and restrict this patch to aarch64 only? https://paste.debian.net/1136271/
<mwette>vagrant: take out the
*vagrantc awaits patiently :)
<mwette>vagrantc: try to take out the ,@ and replace the preceeding list with cons*
<vagrantc>mwette: thanks, will try it
<mwette>(cons* %boot... %linux... (if xxx '(,(search-patch..)) '()))
<vagrantc>do i need the empty '() ?
<mwette>need `(,(search-patch ...))
<mwette>yes: (cons* a b c '()) == (list a b c)
<vagrantc>thanks for helping this shameless cargo-culter :)
<vagrantc>i still was getting issues ... but it might be because i haven't updated the checkout in a long time
<guix-vits>Hi Guix.
<apteryx>hello!
<guix-vits>not a big trouble, but if someone have a time to kill: please try to install the nomad-git. i can run it from the git dir using `guix -L ./guix nomad-git` and `./autogen.sh && ./configure.sh && make run`, but not with `guix package -i nomad-git -L ./guix` and `nomad`. The software version is alpha.
<guix-vits>current "master" branch is feature-g-golf
<str1ngs>guix-vits: see #nomad-browser. you probably need to source ~/.guix-profile/etc/profile if your environment already does this. restart your environment.
<nagamalli>HI, Can anyone tell me where i can find which GUI are packacked?
<guix-vits>nagamalli: `guix search Desktop Environment |less`
<guix-vits>nagamalli: `guix search Window Manager |less`
<guix-vits>nagamalli: `guix search Wayland Compositor |less`
<guix-vits>though last one only shows a sway, in short.
<guix-vits>good, nomad-git installation works, i was need to restart the environment.
<usney>I can't install guix package manager
<usney>[1585027041.200]: [ FAIL ] Missing OpenPGP public key. Fetch it with this command:
<usney>I fetch it and doesn't work and even when I update the keys from a keyserver it still doesn't work
<usney>I will install it manually
<guix-vits>usney: script doesn't working, right?
<usney>yes the script seems to be broken
<usney>I am going to install it following the instructions
<usney>But just to let you developers of the script know it isn't working now because of the openpgp fail even after I get the key(s) and even after I upgrade them too.
<guix-vits>usney: in case of WorksForMe, can you provide the developers (i'm not one) with more info about your setup (OS, updates, exact order of commands being executed), please?
<usney>I am using pureos and I keep my machine updated with the latest software
<Kimapr>is there a way to `guix edit <package>` but with modules instead of packages?
<Kimapr>or something similar
<Kimapr>i tried to search module API reference (info about all modules in guix system and what do they do) but failed
<usney>it is working guix-vits I did a manual install following the instructions which I had to modify slightly
<Parra>Hi! I have tried to cross-compile changing the target triplet in guix pack but I found this: https://github.com/ecbrown/guix/blob/aaeb2b34cbebb12da326caed09d9d9625a8a2af1/guix/scripts/pack.scm#L631
<Parra>but it seems mingw is packaged: https://github.com/ecbrown/guix/blob/master/gnu/packages/mingw.scm
<Parra>any suggestions for it? how should I try to cross compile?
<Parra>It's sad because in the doc is full of places telling you this feature is available, but it isn't..
<Parra> https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/
<Parra>--target=i686-w64-mingw32
<guix-vits>Hi Parra.
<guix-vits>Parra: Why not https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pack.scm this pack?
<guix-vits>actually there is the same message on 655...
<Parra>hi guix-vits
<Parra>This is really problematic to me because I've spent time packaging my software with guix because I thought this feature was available.. and it isn't, it should be reflected in doc at least. If there is any alternative I would be glad to hear about it.
<guix-vits>Parra: i'm just `guix build --target=mips64el-linux-gnu hello` on my x86' and currently a download started.
<guix-vits>you mean with pack?
<Parra>well, if I can do it with build it doesn't matter, it's fine to me
<guix-vits>`guix pack hello --target=mips64el-linux-gnu` works too
<Parra>can you verify if the elf is in mips format? this can be done running file against the executable
<guix-vits>Parra: i'll, wait a sec; probably some arch not support the --target option; you're better catch an developer to know more :)
<usney>how long does guix pull last when you run it for the first time?
<Parra>I think darwin won't be at all, but at least mingw.. it would be great
<Parra>if mingw works, I would be interested implementing darwin
<guix-vits>usney: each `gull` is lives "forever", but old binary substitutes can be no longer available, so one may need to build them.
<guix-vits>if you about speed of command itself, then "it's depends" :)
<usney>is english your first language?
<usney>sorry I ask I hope I am not rude I am just making sure I am reading correctly
<guix-vits>usney: no, i'm not a Englishman
<usney>oh okay no problem
<usney>I still understand what you are saying though! :)
<guix-vits>"ай ам рашн джерк :)
<guix-vits>"
<usney>russian?
<guix-vits>yes
<usney>nice
<usney>I would have guessed either russian or related language
<usney>You are very brave to learn a whole new alphabet with entirely different letters
<guix-vits>Parra: λ file hello
<guix-vits>hello: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, interpreter /gnu/store/vhf3gdffx6k5zs32x7i9hgfa13c6xw66-glibc-cross-mips64el-linux-gnu-2.29/lib/ld.so.1, for GNU/Linux 2.6.32, not stripped
<Parra>ohhhh
<Parra>it worked man
<Parra>you made me happy
<usney>How is russia handling the corona guix-vits
<Parra>I will try mingw through build instead of pack later on
<Parra>if it works, I possibly implement darwin even if it's not libre, some people may benefit from it
<guix-vits>usney: i'm living in Kemerovo, in Western Siberia, and know not much about this; heard that people pass a temperature control before enter the factories, and seen a signs "quarantine /!\" in the Cardiology Hospital.
<guix-vits>though i'm doubt that the letters is so different (seen a persian at ask.fedora -- that is hardcore, i guess)
<usney>I am thinking about getting a pinebook pro. Since it seems there is no user friendly distro approved by GNU that supports the aarch64 arch. I am thinking about installing debian and installing the libre-linux-kernel then install guix for only free software. Is there anything else I can do to find out and remove non free software or make it more free?
<usney>perhaps there is already a guide somewhere I will have to search online for it.
<guix-vits>usney: https://www.joyofsource.com (not sure about freedom-related, but there is an success story)
<usney>for freeing debian
<usney>I think the gnu page for reasons why they don't recommend debian would be a good start
<usney>guix-vits I have ancestors who were slavic
<usney>the slavic peoples are from western europe and russia.
<usney>supposedly I may have a little russian dna so I have russian ancestors
<usney>what does guix pull do?
<guix-vits>provides freshest `guix` app, and the freshest package definitions.
<guix-vits>system profile then can be updated with `sudo [-E] guix system reconfigure <config.scm>`
<guix-vits>and user's profiles can be (independently from the each other) updated with a `guix package -u`
<guix-vits>each user have to `guix pull` separatedly (root user too)
<guix-vits>but sudoers can reuse their `guix pull` results with `sudo -E` (-E isn't needed on Guix System)
<usney>okay guix-vits thank you!
<bricewge>Hello Guix!
<bricewge>guix-vits: Wy does -E isn't needed on Guix System?
<Kimapr>i'm trying to edit a package to make it use local repository instead of remote repository but it says that there is no git repository there
<Kimapr>but there IS a git repo at the path i typed
<bricewge>Kimapr: Can you show the command you used?
<usney>I don't seem to be able to guix pull for root too. I did setup it to be able to be used by non-root users in the instructions.
<usney>guix-vits ^^
<usney>it says root doesn't own that folder
<usney>I am able to pull for my normal user though
<guix-vits>bricewge: i heard that -E is Guix System's default for `sudo`.
<guix-vits>*Hi bricewge
<usney>I am installing icecat
<usney>Will I be able to see the app in gnome or can I only launch it via terminal? I'll find out shortly after it is installed anyways though.
<usney>it keeps complaining that it cannot change to the locale for each language file how do I get rid of that warning?
<Kimapr>oh, seems like i messed up with versions. setting `version` back to 1.2 fixed the issue, but the reason i edited the file was to patch the latest version and install it
<guix-vits>usney: i'm not a developer; if you'd installed Guix as a package manager on top of an other GNU Linux system, then you need to `pull` as root by default. i'm totally have no experience outside of System installation.
<bricewge>usney: guix install glibc-locales
<Kimapr>from guix manual:Packages installed via Guix will not use the locale data of the host
<Kimapr>system. Instead, you must first install one of the locale packages
<Kimapr>available with Guix and then define the ‘GUIX_LOCPATH’ environment
<Kimapr>variable:
<Kimapr> $ guix install glibc-locales
<Kimapr> $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
<bricewge>guix-vits: Ho ok, I still have issue knowing which profile are used when guix pull.
<usney>thank you Kimapr
<Kimapr> https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Locales-1
<guix-vits>usney: change the "manual" to "manual-devel" above for a more recent version.
<Kimapr>you can also run `info guix` to get the manual in Guix System, i don't know if it's the same for standalone installation
<guix-vits>also the https://guix.gnu.org/manual/en/ has a "single-page" view (huge, but easy to search through).
<guix-vits>bricewge: idk about the profiles too. just that one user can have multiple profiles catched my eye in the manual.
<usney>is there any mirrors I can I use other than gnu? So I can have gnu save some bandwith?
<Kimapr> https://paste.debian.net/plain/1136283 where is the sha256 checksum coming from? how can i generate one for a different version myself?
<guix-vits>rekado_: ^^^ (Hi rekado_, usney asks)
<usney>who is rekado ?
<usney>I need to restart because I installed software that requires it
<usney>I will be back shortly after rebooting which should be fast
<guix-vits>Kimapr: you mean base32?
<Kimapr>isn't it sha256 encoded in base32?
<guix-vits>idk, but you may try `guix hash` and `guix download`
<Kimapr>the thing is that i don't know the file i want to get hash from
<usney>I am not able to see my guix installs anymore
<usney>I mean bash won't autocomplete my guix installed package icecat
<guix-vits>Kimapr: i'd did this: `git clone --single-branch --branch 1.2 git://github.com/swaywm/sway.git`
<guix-vits>`cd sway; guix hash -rx`
<guix-vits>got 0vch2zm5afc76ia78p3vg71zr2fyda67l9hd2h0x1jq3mnvfbxnd (as in your link)
<guix-vits>"7.4 Invoking guix hash" in manual
<guix-vits>usney: did you'd followed the manual's "2.4 Setting Up the Daemon"?
<guix-vits>Kimapr: but probably there is a better way (to downloaded things ended up in /gnu/store)
<usney>I'll try that guix-vits
<usney>thank you
<guix-vits>i'm personally was scarred by that part of manual, and simply installed the System. But the "on-top" way is considered a "first class citizen" by developers, afaik.
<civodul>Hello Guix!
<guix-vits>Hi civodul
<usney>sudo guix-daemon --build-users-group=guixbuild
<usney>sudo: guix-daemon: command not found
<Veera>Hi
<guix-vits>Hi Veera
<Veera>Running guix lint pkg says source not archived on Software heritage; What does it mean
<Veera>I am packaging qiv
<Veera>from spiegl.de/qiv/
<Veera>Yesterday I ran everuthing was okay
<civodul>Veera: it simply means the code is not archived at https://archive.softwareheritage.org/
<civodul>there's nothing you can do, though
<Veera>So i can't pkg qiv?
<Veera>Oh it is something else
<Veera>Also lint is complaining url returned suspiciously small file for homepage
<Veera>982 bytes
<Veera>When I open it in browser it is not that small
<guix-vits>usney: GUIX_PROFILE="`echo ~root`/.config/guix/current" ; source $GUIX_PROFILE/etc/profile
<guix-vits>?
<guix-vits>Veera: try to copy-paste the address from Web-browser to definition.scm, maybe there is a typo?
<Veera>No. I used wget and see that it is really 982 bytes and it uses html frames
<guix-vits>cool.
<bricewge>Veera: You can disregard the lint complains about Software heritage. Keep packaging!
<Veera>okay
<bricewge>civodul: Quick question: Is it normal that ssh-keygen (from openssh-activation) is run before urandom-seed?
<Kimapr>guix-vits: thanks
<usney>GUIX_PROFILE="`echo ~root`/.config/guix/current" ; source $GUIX_PROFILE/etc/profile
<usney>bash: /root/.config/guix/current/etc/profile: Permission denied
<usney>guix-vits,
<Kimapr>should there be a ` .` at the end of `guix hash -rx`? running `guix hash -rx` says `wrong number of arguments`
<guix-vits>Kimapr: yes `guix -rx .` inside of git-dir
<guix-vits>try it with 1.2 branch of sway to see if hash matches (worked for me)
<guix-vits>*guix hash
<guix-vits>Kimapr: sorry, i'd forget '.'
<andydarcyjewell>hi guix, i'm back at it again!
<andydarcyjewell>can anyone tell me what the exception "extraneous field initializers" means?
<guix-vits>Hi andydarcyjewell
<andydarcyjewell>Hey, guix-vits
<guix-vits>usney: idk, but if guix-daemon isn't found, then it's not in the calling user PATH variable. Probably you need to reread the section of manual that was used to install Guix (as it's worked before reboot).
<usney> https://bpaste.net/raw/RCRA guix-vits
<rekado_>hi Guix!
<guix-vits>Hi rekado_
***rekado_ is now known as rekado
<rekado>so, about Tensorflow: the best way forward (also for the future) seems to be to work off of Debian’s variant: https://salsa.debian.org/science-team/tensorflow/
<rekado>the reason is that they have written scripts to convert the Bazel output to Ninja.
<guix-vits>usney: idk, seriously. i'd never installed Guix on top of something.
<rekado>Now I wonder how to approach this. For Linux libre we take Linux sources and run the deblobber script to generate the clean sources.
<rekado>I suppose we can’t do the same for generating the build system for Tensorflow, because the tools needed to run the scripts are unpackageable.
<rekado>But the alternative does not sound very appealing either: to have a lone maintainer run Bazel locally to generate the build system files, and then either host these files somewhere or add them to Guix.
<guix-vits>civodul: usney have had a troubles with the installation script today.
<usney>hi
<usney>I am back
<usney>I am fixing my issues now
<usney>I have created my own installation script
<usney>it gives an error about keys even after I have imported them rekado
<lfam>bricewge: Can you make a bug report about the ssh-keygen thing?
<bricewge>Sure will do.
<bricewge>So it looks like a bug, right?
<rekado>usney: which user account imported the key and which is running the script?
<bricewge>lfam: BTW I managed to reproduce #36380 with your instructions.
<bricewge>I'm trying the fix suggested by Ludovic.
<andydarcyjewell>seems I've got past the "extraneous field initializers" error now, but now I need to add an argument to the "make" invocation. do I use #:make-flags for that, or is it only for things starting in "-" ?
<bricewge>That's when I noticed ssh-keygen doing it's business fine while the boot was still waiting for urandom-seed.
<andydarcyjewell>sorry, I meant "things starting *with*"
<rekado>andydarcyjewell: make-flags are what you should use in this case.
<usney>rekado I imported the key as normal user and the script can only be run as root as it complains about that.
<rekado>that’s why it doesn’t find the key
<rekado>the root user doesn’t know that some other user has the key.
<usney>oh okay cool
<usney>thank you rekado
<usney>I have already installed guix manually following the instructions rekado
<usney>will using that script to make sure I installed everything correctly cause any problems?
<rekado>the script will refuse to run when /gnu exists
<usney>okay
<andydarcyjewell>thanks, rekado
<usney>warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<usney>how do I fix that problem rekado ?
<usney>I tried installing the guix package it says to do in the locale documentation doesn't seem to work
<usney>I am upgrading the guix packages seeing if that helps
<guix-vits>rekado: http://logs.guix.gnu.org/guix/2020-03-23.log#201327 for usney?
<amartens[m]>jup usney you could try to set the locale to en_US.UTF-8 in your config.scm and reconfigure your system ... maybe it works
<civodul>rekado: good that Debian has a way out for Tensorflow
<usney>I found out how to do it guys
<usney>it is a bug that is fixed within the installation script amartens[m] guix-vits
<guix-vits>usney: the locale error? cool.
<usney>yes
<amartens[m]>nice work 👍
<Veera>yes setting locale to en_US.UTF-8 works. The default in config.scm en_US.utf8 did not worked for me either
<leoprikler>So, how do you get rid of locale warnings?
<guix-vits>leoprikler: http://logs.guix.gnu.org/guix/2020-03-23.log#201327
<leoprikler>ahh UTF-8 instead of utf8
<guix-vits>leoprikler: and this is "WTF", right %)
<leoprikler>pretty much
<leoprikler>Especially, because I already have (locale "de_DE.UTF-8")
<leoprikler>and still see the warning sometimes
<usney>it seems it only fixes the us_en locales for root and not for multi-users
<usney> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35671
<usney>the script does
<usney>nevermind I am getting the errors again with root too
<usney>I even checked the service daemons and they have it set to my systems locale hmm
<jonsger>there wont be a core-updates merging before release or?
<leoprikler>Merging core-updates before release and then waiting at least a week for problems to settle would be a wise decision.
<leoprikler>Having a major merge just after release sounds like a recipe for trouble.
<civodul>what branch for the xkbcomp update? https://issues.guix.gnu.org/issue/40204
<efraim>core-updates? Did you test it?
<civodul>i tested it on master
<civodul>it builds, so it probably works :-)
<jonsger>leoprikler: I would support that because MATE is heavily broken on master. I'm not so optimistic that my update on master branch will improve that situation a lot...
<andydarcyjewell>so, in my (inputs ...) section, I have to include a number of dependencies, such as libx11; assuming I need a #:use-module (gnu packages *whatever*) for each, how can I find out which package contains the library?
<leoprikler>either grep or just fire up the interpreter and let it tell you what module is missing
<NieDzejkob>or `guix show libx11` and look at the path
<NieDzejkob>gnu/packages/foo.scm -> (gnu packages foo)
<mbakke>NieDzejkob, andydarcyjewell: 'guix show libx11 | recsel -p location' even... or just 'guix edit libx11'.
<guix-vits>^recsel is in recutils package.
<jonsger>is there a tool to find the best path to update a package and it's dependencies while reducing rebuilds to a minimum? e.g. for gnome or mate
<Kimapr>how to install cow-store on Guix System?
<Kimapr>i want to install guix system on a flashdrive through Guix System installed on hdd
<Kimapr>and no, i won't flash installation image
<Kimapr>i tried to do `herd start cow-store /mnt` and got `herd: service 'cow-store' could not be found`
<NieDzejkob>my limited understanding of the installation process suggests you can skip that step
<NieDzejkob>AFAIK, cow-store is used to move the store out of the tmpfs in RMA
<NieDzejkob>RAM*
<guix-vits>Kimapr: cow-store needed for installation media which is read only, so during `guix system init` the items are downloaded and builded in RAM. As this can exhaust the RAM, cow-store copies things from RAM to target device and frees the RAM. NieDzejkob, correct?
<guix-vits>Kimapr: this service is defined in gnu/system/install.scm
<NieDzejkob>built*. cow-store doesn't exactly copy the things, it uses overlayfs to assign the target device as a "backing store", but the essence is there
<guix-vits>NieDzejkob: thanks.
<guix-vits>Kimapr: line 207
<civodul>"guix upgrade" often writes "1.0.0 -> 1.0.0"
<civodul>i think i'll change that to "(dependencies changed)"
<civodul>thoughts?
<rekado>good idea!
<civodul>that's less confusing
<civodul>good :-)
<Kimapr>root@DComp ~# guix system init /mnt/etc/config.scm /mnt
<Kimapr>Backtrace:
<Kimapr> 1 (primitive-load "/root/.config/guix/current/bin/guix")
<Kimapr>In guix/ui.scm:
<Kimapr> 1894:12 0 (run-guix-command _ . _)
<Kimapr>guix/ui.scm:1894:12: In procedure run-guix-command:
<Kimapr>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): (#<<file-system> device: "none" mount-point: "/dev/pts" type: "devpts" flags: () options: "gid=996,mode=620" mount?: #t needed-for-boot?: #f check?: #f create-mount-point?: #t dependencies: () location: ((line . 340) (column . 2) (filename . "gnu/system/file-systems.scm"))> #<<file-system> device: "tmpfs" mount-point: "/dev/shm" type: "tmpfs" flags: (no-suid no-dev) options:
<Kimapr>"size=50%" mount?: #t needed-for-boot?: #f check?: #f create-mount-point?: #t dependencies: () location: ((line . 351) (column . 2) (filename . "gnu/system/file-systems.scm"))> #<<file-system> device: "/gnu/store" mount-point: "/gnu/store" type: "none" flags: (read-only bind-mount no-atime) options: #f mount?: #t needed-for-boot?: #f check?: #f create-mount-point?: #f dependencies: () location: ((line . 364) (column . 2) (filename . "gnu/system/file-systems.sc
<Kimapr>m"))>)
<guix-vits>XD
<Kimapr>i'm confused
<Kimapr>and have no idea what that means
<guix-vits>Kimapr: probably some typo; can you post the config.scm?
<Kimapr> https://paste.debian.net/1136321/
<Kimapr>any clues?
<Kimapr>btw i'm installing guix system on mbr flashdrive from efi guix system
<usney>I got it working!
*raghavgururajan peeps in o/
<guix-vits>Hi raghavgururajan the "now press TAB after g, not v" :)
<rekado>Kimapr: the problem is that you do (append (list fs %base-file-systems)) instead of (append (list fs) %base-file-systems)
<usney>it was a pain tho I had to locate and remove all guix folders before I could use the installation script
<usney>now everything works as it should
<guix-vits>Kimapr: add ) after 'type "ext4))' and remove ) after '%base-file-systems)))'
<guix-vits>in other words
<guix-vits>usney: now try to reboot %)
<Kimapr>guix-vits: already done that
<Kimapr>oof, guix's template system config files have awful formatting
<Kimapr>too hard to track those brackets
<raghavgururajan>guix-vits pardon?
<usney>yes I rebooted already guix-vits
<guix-vits>Kimapr: try some editor with syntax highlighting.
<amartens[m]>Kimapr: what ? it's just Lisp lol
<rekado>Kimapr: the shared wisdom in Lisp land is that the formatting is fine; it’s your editor that should keep track of matching parentheses.
<Kimapr>well, my editor does have syntax highlighting and parentheses matching
<rekado>Kimapr: there are a bunch of editor extensions that take care of this, such as paredit or smartparens for Emacs
<usney>I am constantly getting this warning "guile: warning: failed to install locale"
<usney>when I run guix install packagename
<rekado>usney: how are you running the Guix daemon?
<usney>I used the installation script
*rekado builds bazel manually to generate a non-bazel build system for tensorflow
<guix-vits>raghavgururajan:
<guix-vits>was: raghav TAB gururajan
<guix-vits>now: raghavg TAB ururajan
<guix-vits>
<rekado>usney: what distribution do you use?
<usney>pureos
<rekado>how do you run services? Is this using systemd?
<usney>yes systemd
<rekado>could you please look at the service file for guix-daemon and check that the GUIX_LOCPATH environment variable is set?
<usney>okay rekado
<usney>does it matter from which folder?
<usney>the service is located in 3 folders
<usney>Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8
<usney>rekado ^^
<amartens[m]>usney try setting your locale to en_US.UTF-8 in your config.scm and reconfigure
<usney>which folder should I use for the config.scm?
<usney>when I updatedb and locate config.scm I get many files
<amartens[m]>mine is in /etc but I run Guix System
<guix-vits>Kimapr: one can use '(define' in the configs: http://paste.debian.net/1136323/
<rekado>amartens[m]: usney does not use Guix System, so there’s nothing to reconfigur
<rekado>usney: please change the value in the LC_ALL line to en_us.UTF-8 and restart the daemon
<rekado>ah, sorry: en_US.UTF-8
<amartens[m]>rekado: ah okay, I see.
<usney>I have done it rekado
<usney>thank you
<usney>is there anything I can do to speed up "guix pull"?
<usney>I am still getting the locale warning
<usney>I'll try rebooting
<rekado>rebooting probably won’t help
<rekado>is the guix-daemon process actually running with the correct variables?
<rekado>you can run “tr '\0' '\n' < /proc/PID/environ” where PID is the PID of the guix-daemon process
<rekado>(find it with pgrep -fa guix-daemon, or similar)
***mood_ is now known as mood
<civodul>rekado: "guix processes"!
<Kimapr>guix-vits: isn't `define` lisp/scheme/guile builtin function?
<guix-vits>Kimapr: our configs is a Scheme files. See, in my config i'd `(define (my-fs ....` and now my config is a little bit better organized.
<rekado>civodul: oh!
<rekado>neat!
<rekado>(good thing the GWL no longer provides the “process” sub-command)
<rekado>the bazel bootstrap uses “exec env -” in various places to clear the environment. This breaks gcc-toolchain.
<rekado>so I’m now trying a wrapper around env that strips off the “-”.
<civodul>rekado: oh, does GWL still have a (guix processes) module?
<civodul>if not, i'd happily reuse it :-)
*civodul didn't know "env -"
<rekado>no, I moved all modules to (gwl …), except for the script module providing the “workflow” command.
<rekado>bazel also tries to invoke /bin/bash … :-/
<civodul>cool
<civodul>bah
<janneke>amateurs
*janneke probably means: bah, professionals!
*str1ngs gasps!
*rekado links bash to /bin
<rekado>making progress
<alextee[m]>can guix have auto-completion when you do guix build -L ...
<alextee[m]>like find the targets and display them? like `make` does
***sneek_ is now known as sneek
<civodul>alextee[m]: there are completion files for Bash, Zsh, and Fish
<civodul>are you using them?
<civodul>they're not perfect, though
<apteryx>hello! I've written a Btrfs RAID system test, and so far I got this result: https://paste.debian.net/1136330/. Any idea?
<apteryx>ERROR: In procedure status:term-sig: Wrong type (expecting exact integer): #<eof>
<apteryx>from my study of our initrd, it should 'just work' ;-)
<alextee[m]>civodul: yeah i'm using them but i don't think they can detect custom packages on the fly
<alextee[m]>like i have some custom packages in a directory and i do guix build -L . mypackage
<alextee[m]>but probably not worth the effort implementing that
<civodul>alextee[m]: oh i see; detecting custom packages would be too slow, i think
<civodul>currently the Bash completion caches the output of "guix package -A"
<alextee[m]>ah i see. well, good enough i guess
<Parra>guix-vits: I've tried to build my software cross-compiling to mingw32, it started but perl failed... so yeah, it works, but not really
<apteryx>ah, this is because (again) seabios resets the term and was masking the useful output from system installation in QEMU. Trick: make system-test ... |& strings
<apteryx>perhaps we should always filter out the terminal reset control characters from QEMU's output
<Parra>does anyone know what happened?
<Parra> https://ibb.co/hsSvZ9Y
<apteryx>so, we get an EOF while copying the system to /mnt, which is the RAID 0 btrfs file system.
<mothacehe>Parra: This is a problem that I have solved on core-updates I think, you might want to use that branch instead :)
<Parra>ohhh, how can I use that branch?
<mothacehe>If you do not have Guix sources checkouted, you can run 'guix pull --branch=core-updates' I think.
<civodul>heya mothacehe
<mothacehe>hey civodul!
<civodul>how's everything? :-)
<mothacehe>everything is fine for now, thank you :) I fight boredom by generating huge Guix System disk-images :p
<civodul>heheh, good :-)
<efraim>do we want zlib support in nano? what would it even do?
<raghavgururajan>Folks! In cmake-build-system, what is the difference between "option" and "cmake_dependent_option"?
<guix-vits>mothacehe: -RR not helps, there was a bug?
<Parra>mothacehe: thank you so much, I will try it later
<apteryx>In (gnu tests install), what is installation-os bound to in `run-install'?
<raghavgururajan>For example, there is one "option" for sound support, with multiple "cmake_dependent_option" for different sound back-ends.
<rekado>raghavgururajan: I’m guessing that the dependent option is only considered if sound support is enabled.
<raghavgururajan>rekado Thanks!
<raghavgururajan>rekadoSO I have [1] option(ENABLE_VIDEO "Build mediastreamer2 with video support." YES). [2] cmake_dependent_option(ENABLE_FFMPEG "Build mediastreamer2 with ffmpeg video support." YES "ENABLE_VIDEO" NO). [3] cmake_dependent_option(ENABLE_SDL "Enable SDL support." NO "ENABLE_FFMPEG" NO).
<raghavgururajan>rekado ^
<raghavgururajan>rekado Why does ffmpeg option mentioned to set video option to NO?
<raghavgururajan>rekado Also, if I enable SDL, will it disable FFMPEG, eventhough I set FFMPEG to YES?
<rekado>see https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html
<raghavgururajan>rekado Thanks!
***sneek_ is now known as sneek
<mothacehe>apteryx: installation-os comes from (gnu system install)
<apteryx>mothacehe: thanks... for some reason Geiser doesn't make it available even after ,import (gnu system install)
<apteryx>it doesn't even show an error, so that's weird.
<apteryx>Perhaps it has to do with local-file that doesn't work at the REPL
<apteryx>oh, nevermind, I restarted Geiser and it now works...
<usney>how do I setup tor?
<apteryx>usney: there's a tor-service-type I think
<apteryx>and there must be a mention of it in the info manual
<hpfr[m]>hi, I'm new. does guix have an effort like nix flakes, to manage groups of guix expressions declaratively?
<hpfr[m]>and does it have something similar to home-manager, to manager user-scoped packages and configuration files (such as those in ~/.config)
<apteryx>hpfr[m]: there's guix-home, an external tool for now
<apteryx>about nix flakes, I'm not sure, but the system is managed declaratively using an operating-system record.
<hpfr[m]>they're intended to replace nix channels eventually, for easier rollbacking, pinning, etc
<civodul>hpfr[m]: do you have a pointer to Nix flakes?
<civodul>BTW, there's no such thing as a "Guix expression"
<civodul>instead there are package definitions, OS definitions, etc.
<rekado>bah, still can’t build bazel :-/
<rekado>clearing env vars is annoying
<hpfr[m]>civodul: RFC: https://github.com/NixOS/rfcs/pull/49 Discussion: https://news.ycombinator.com/item?id=20486462 Examples: https://gist.github.com/edolstra/40da6e3a4d4ee8fd019395365e0772e7 Video: https://www.youtube.com/watch?v=UeBX7Ide5a0
<hpfr[m]>apteryx: is it this? https://framagit.org/tyreunom/guix-home-manager
<guix-vits>roptat: tester detected ^^^
<Parra>@mothacehe pull from core-updates fails
<guix-vits>Parra: did you'd tried -RR flag for `pack`?
<NieDzejkob>Parra: find a commit ID that works on CI ( http://ci.guix.gnu.org/jobset/core-updates-core-updates ) and pass that to --commit
<civodul>hpfr[m]: thanks for the links!
<civodul>the initial bits sound similar to Guix channels (the ability to have dependencies, etc.)
<Parra>guix-vits: https://github.com/metacall/distributable/blob/5e2d34f7136f49329b3f78d58bf4f6655bd3911b/scripts/build.sh#L32
<Parra>NieDzejkob: for example --commit d19b14c ?
<Parra>does it need branch too?
<apteryx>hpfr[m]: about guix-home-manager, yes I believe so :-)
<Parra>NieDzejkob: it worked but now it throws an error on gmp
<raghavgururajan>Folks! What this error mean?
<raghavgururajan>ld: cannot find -lz
<raghavgururajan>collect2: error: ld returned 1 exit status
<bavier`>raghavgururajan: you need zlib
<raghavgururajan>bavier` as native-input?
<bavier`>raghavgururajan: probably input
<bavier`>zlib usually used at runtime
<raghavgururajan>bavier` Thanks!
<jsoo>how would i go about packaging sql mode for emacs? do i even need to?
<brendyyn>there are many emacs modes packages. you can look in the repo
<jsoo>right. sql mode is weird because i think it is part of the emacs tree but not installed by default
<brendyyn>So it's not in the output package?
<brendyyn>are you sure its not in some melpa repo or what ever its called too?
<jsoo>i think it's in melpa or elpa but i think the importer is broken?
<jsoo>guix import elpa x fails for all x afaict
<brendyyn>the importers are just a tool to for you to get started with. instead you shuld just study what similar packages look like
<jsoo>right i just don't know where the source of sql mode is
<jsoo>it might just be built in
<brendyyn>its there for me
<brendyyn>M-x sql-mode
<jsoo>yeah i think so
<jsoo>:+1:
<brendyyn>that was easy
<jsoo>I'm happy with that. I think the last remaining package i need to get rid of all package-installs now is proof-general for emacs 27 :)
<jsoo>ah, wait, i think cedille broke recently.
<roptat>hpfr[m], it's very alpha, and doesn't work well, but if you're interested, I'd be happy to help :)
<roptat>I think I need to fix the installation procedure though
<raghavgururajan>bavier` How about "ld: ../libbcunit_test.a(Util.c.o): in function `otherPrintf':" error?
<Veera>Hi guix
<raghavgururajan>ld: ../libbcunit_test.a(Util.c.o): in function `otherPrintf':
<raghavgururajan>/tmp/guix-build-bcunit-3.0.2.drv-0/source/BCUnit/Sources/Framework/Util.c:116: undefined reference to `CU_trace_handler'
<raghavgururajan>bavier` ^
<Veera>I need a help regarding qiv packaging; submitted a patch to guix-patches;
<Veera> https://issues.guix.gnu.org/issue/40209
<raghavgururajan>Veera o/
<Veera>DannyM commented in it
<Veera>Hi raghavgururajan
<Veera>He said indentation off
<Veera>In (string-append line ?
<Veera>Checked with guix lint it did not reported it
<Veera>Should I use emacs
<Veera>I used nano
<jsoo>if you like nano, you should use nano
<jsoo>there is an indentation script in etc (etc/indent-code.el)
<Veera>jsoo: yep
<Veera>Ok i will check the docs
<Veera>I just matched preexisting pkg scm's
<jsoo>Yeah there is a section in contributing under code style/formatting code to check out
<jsoo>if you do that, you should be fine
<Veera>Also in that he mentioned about why disable make tests
<jsoo>We generally try to always run tests. But there are many valid cases for disabling them
<Veera>Well the pkg does not has make check; make tests. instead runs the built executable qiv with jpg as argument in make install step itself
<jsoo>if some are failing for a valid reason (like the test tries to do network calls, or requires being attached to a tty), you can add a comment to that effect
<jsoo>also if there are no tests, that is fine too. just add a comment to that effect
<Veera>In that comment he said add it image-viewers.scm
<Veera>So should I add it to bottom of it.
<jsoo>ah, sure. the bottom is fine
<jsoo>styles vary across files. some are topologically sorted, some are alphabetically sorted
<jsoo>mostly they are topologically sorted. usually it is clear which sort is used
<Veera>If I add in image-viewers.scm then is there need to add to gnu/local.mk
<Veera>what is topological sort
<ngz>Sorting topologically is not so great, because it is hard to maintain. Alphabetic is straightforward.
<ngz>At least, I find it hard to maintain.
<Veera>but I see that in existing one it is just haphazard
<ngz>(e.g., try to sort topologically Emacs packages)
<Veera>perhaps new one got added to bottom
<bavier`>that's often the case
<jsoo>i think it makes sense to topo sort them since definitions can be order dependent. right?
<jsoo>i could be wrong
<jsoo>if you add it to image-viewers.scm there is no need to add it to local.mk
<Veera>jsoo: yep I saw that file; it's covers image-viewers
<jsoo>Veera: +1 excellent
<ngz>Then we need a git hook that would re-order automatically packages definitions topologically after changing a file :)
<jsoo>i'm not sure. i think not having a system is fine. when someone decides to reorder the file, i think they should feel free, though, usually.
<jsoo>any case i'm not particular about it. if you want to alphabetize it, go ahead :)
<jsoo>man i need to cut a release for idris-mode but i'm scared. i have never published any change personally
<rekado>bah, a whole day wasted on bazel :(
<roptat>rekado, :(
<rekado>enough for today
<rekado>what a nightmare
<roptat>too many dependencies, or is there something else?
<rekado>I’m just trying to build it from source on Guix System, without writing a Guix package definition.
<rekado>just in suitable Guix environment
<rekado>and this won’t work as bazel overwrites variables and breaks our GCC
<rekado>I passed options that led me to believe I could use to pass environment variables, but the build of some of the third party stuff (like zlib) fails
<rekado>the compile.sh script they provide also keeps rebuilding their Java stuff, so to reproduce the error takes a long time
<rekado>Since I only need to run bazel once to generate some output I think I’ll give up on trying to build it on my Guix System and instead install it on my office workstation running Fedora
<apteryx>rekado: if you just need to *use* bazel, you could use docker on your Guix System.
<brendyyn>apteryx: you can't just say that to a person.
<Veera>jsoo: thanks for ./etc/indent-code.el, it worked
<raghavgururajan>Woah! We don't have "opengl" ???
<apteryx>brendyyn: why? :-)
<apteryx>raghavgururajan: we have 'mesa', an implementation of it
<raghavgururajan>apteryx Phew!
<Veera>bye
<brendyyn>apteryx: he put so much effort in, and that is like saying give up
<rekado>nah, it’s a good point
<rekado>I don’t really want to work on this anyway
<apteryx>brendyyn: I was honestly suggesting an alternative path to 'run Bazel on a Fedora workstation'
<rekado>even when cheating (and not writing a proper Guix package definition) this is super messy
<rekado>my eyes glazed over when I looked at the nixpkgs expression
<rekado> https://github.com/NixOS/nixpkgs/blob/4d954e528d63be18831558183d40182aa4a285e2/pkgs/development/tools/build-managers/bazel/bazel-latest/default.nix
<rekado>and that’s ignoring all packaging problems
<apteryx>rekado: That package definition from Nix indeed looks... involved.
<mbakke>"Bazel checks whether the mtime of the install dir files is >9 years in the future, otherwise it extracts itself again [...] What the hell bazel."
<mbakke>You're doing heroic work here rekado! :-)
<jonsger>mbakke: is CI a bit behind with building core-updates?
<mbakke>jonsger: it has not even started yet
<mbakke>it's only building a tiny subset of packages
<mbakke>currently waiting for jannekes wip-hurd work
<civodul>mbakke: wip-hurd was set up to build all the packages...
<civodul>there are 18K failures currently, probably timeouts and such
<mbakke>oh
<civodul>i've changed it to build just the "core" subset
<mbakke>that should "kickstart" the branch when it gets merged, at least
<civodul>rekado: does https://github.com/NixOS/nixpkgs/blob/4d954e528d63be18831558183d40182aa4a285e2/pkgs/development/tools/build-managers/bazel/bazel-latest/default.nix actually build from source?
<civodul>it's quite intimidating, indeed
<rekado>civodul: only if you squint.
<rekado>civodul: it does what the Bazel website calls building from scratch.
<rekado>(i.e. building with those 100+ pre-built jars)
<rekado>it’s not the kind of thing we would want to do in Guix.
<leoprikler>pfft, those 100+ jars are nothing
<civodul>ah ah
<civodul>funny that even that takes so much effort
<leoprikler>bytecode is just as good as source code anyway ;)
<civodul>heheh
*jonsger wonders how other people develop on core-updates with even slower hardware...
<leoprikler>but do they?
<leoprikler>you can do some staging/c-u stuff on master as long as you know how to `git cherry-pick`
<apteryx>interesting, 'guix system init ...' on a RAID 0 Btrfs fs crashes QEMU
<apteryx>err, not exactly: qemu-system-x86_64: terminating on signal 15 from pid 369 (/gnu/store/qzkp1pa8h931fi7xsgc5zlh1f0jc70s3-earlyoom-1.3.1/bin/earlyoom)
<civodul>lfam: is Poetry ready? https://issues.guix.gnu.org/issue/39777
<efraim>civodul: the new updater text looks nice, but it's still a bit over eager to list packages to update: http://dpaste.com/26XNYVH
<civodul>apteryx: note that it's QEMU that's exiting, not the guest code
<civodul>efraim: paste.debian.net please :-)
<civodul>this one blocks Tor
<efraim>doh :/
<efraim> https://paste.debian.net/1136382/
<apteryx>civodul: seems it's just killed for using too much memory on my 4GiB laptop (by earlyoom)
<civodul>oh
<civodul>efraim: ah yes, to be continued...
<efraim>then again it's not actually a regression from what was listed before
<anadon>civodul: Thanks for fixing that!
<dongcarl>Going to add some patches for binutils from debian, they will allow us to produce reproducible mingw-w64 binaries... Will get to working on nightly releases after this!
<jonsger>dongcarl: nice :)
<raghavgururajan>I was trying to use the package "gsm", which is in "audio.scm". But I get 'unbound variable' error even-though I used (gnu packages audio).
<rekado>raghavgururajan: do you get more output?
<raghavgururajan>rekado Pardon?
<raghavgururajan>ice-9/eval.scm:223:20: In procedure proc:
<raghavgururajan>error: gsm: unbound variable
<raghavgururajan>hint: Did you forget a `use-modules' form?
<raghavgururajan>rekado ^
<dongcarl>civodul: When you wrote PACKAGE-WITH-PATCH in 1306b0b003a, was the intention for the procedure to ADD patches, or replace existing ones?
<dongcarl>I think the current behavior is to replace
<rekado>raghavgururajan: is this all or do you get more lines?
<raghavgururajan>rekado That is all.
<Rovanion>How do I write a shebang for bash on a Guix System?
<anadon>What do I need to do to re-open a bug ticket? It looks like `guix pack --format=squashfs ...` still fails in what appears to be the same way as before as after the patch to fix is was applied.
<anadon>civodul: ^
<rekado>raghavgururajan: please show us your diff.
<rekado>Rovanion: for example #!/run/current-system/profile/bin/bash
<rekado>you can’t really assume that /bin/bash exists; only /bin/sh is guaranteed.
<rekado>you can use a /bin/sh shebang and call bash from there if you expect the user to have bash in the environment
<Rovanion>Okey, second question: I've installed font-terminus and xfontsel, but terminus doesn't show up in xfontsel. Am I missing something?
<wheeler>New to guix packages here but hoping to learn how to do things the right way. I'm having a circular dependency issue while packaging audacious.
<wheeler>It has two parts: main program tarball, and a plugins tarball. All gnu-build-system compatible.
<wheeler>The issue I'm running into is that both depend on each other and need to be included in each others inputs.
<wheeler>Here's a link to the tree if anyone cares to take a look: https://git.mantlepro.com/josh/guix.git/tree/packages/audacious.scm
<wheeler>I'm new to guix packaging, so I'd appreciate all the critiques and suggestions I can get to improve my skills.
<bavier`>wheeler: is it possible to build one without the other?
<roptat>how is that possible? why does main require plugins, and plugins require main? how is that solved usually?
<bavier`>if so, one could be provided as a "bootstrap" package to get things going
<wheeler>The issue is that audacious-plugins installs to the audacious' libs directory
<roptat>can audacious find its plugins with another method?
<wheeler>Redefining plugindir in configure.ac resolves it for audacious-plugins (putting it in its own dir under /gnu/store)
<wheeler>But audacious can't find its plugins (and won't run).
<roptat>maybe an environment variable or something? You could also build main and plugins in the same package, which would remove the circular dependency
<wheeler>When modifying configure.ac for audacious to say, "use audacious-plugins" under /gnu/store, I get a circular dependency that causes my system to hang :-P
<wheeler>Any good example packages I can look at to build both in the same package? That would do the trick quite nicely I would think!
<wheeler>They don't necessarily need to be separated.
<bavier`>wheeler: if there's no flexible way to handle plugin install location, I'd say try to build the plugins as part of a single guix package
<lfam>Howdy
<bavier`>wheeler: add a phase to unpack the plugins tarball into the source tree, then patch Makefile to add it as a SUBDIR
<bavier`>s/Makefile/Makefile.am/
<wheeler>bavier`: Gotcha. I'll give it a try. Any packages you know off the top of your head that I can look to for an example?
<bavier`>not off the top
<wheeler>bavier` and roptat: Appreciate the help. Thanks for pointing me in the right direction.
<bavier`>good luck :)
<NieDzejkob>you could also have audacious-minimal, a package without plugins being used as the dependency for the plugin build, then `audacious' depending on the plugins
<NieDzejkob>maybe we could patch audacious to use an environment variable for the path
<NieDzejkob>huh. I'm putting @acronym{ROP, return oriented programming} in the description of a package and it gets silently skipped when rendering (in guix show)
<roptat>not all texinfo macros work
<bavier`>but @acronym is fairly widely used
<NieDzejkob>What should I patch to make it work? :)
<bavier`>NieDzejkob: what do you mean by 'silently skipped'?
<NieDzejkob>is it about texinfo's to-terminal renderer, or some part of the package printing logic?
<NieDzejkob>bavier`: Lorem ipsum @acronym{...} dolor sit amet -> Lorem ipsum dolor sit amet
<bavier`>NieDzejkob: hmm, I see it render to a parenthetical
<bavier`>e.g. '@acronym{FOO, Flexible Object Orchestrator}' -> "FOO (Flexible Object Orchestrator)"
<apfel>hi there, can i specifiy the version of an input? I tried (native-inputs `(("protobuf@3.6.1" ,protobuf))) guix does not complain but uses the most recent version anyway.
<lfam>NieDzejkob: I was thinking about the ROP package. I'm not so familiar with that kind of work so I'm wondering what the potential use cases are?
<mbakke>NieDzejkob: you're better off with @dfn, unless you want to hack on Guile's Texinfo support
<mbakke>apfel: you'll need to refer to the correct variable name, i.e. `(("protobuf" ,protobuf-3.6.1))
<apfel>mbakke: well, the problem is that the name is always protobuf, no matter what version
<mbakke>apfel: you can choose whatever name you want, `(("bananas" ,protobuf-3.6.1)) will work just as well :-)
<apfel>mbakke: sorry, to be more specific, no matter what version of protobuf you want, the package is always called protobuf, only the package definition contains the version not the name
<apfel>mbakke: ok sorry, yea, you are right, my bad
<mbakke>apfel: the name only matters if you need to refer to it in a build phase, i.e. (assoc-ref inputs "bananas")
<roptat>and a package has two "names": its variable name (the thing after the define or define-public) and its package name (the thing in the name field of the package definition)
<roptat>the cli uses the package name, but package definitions refer to packages by their variable name
<NieDzejkob>lfam: well, it's a domain specific tool. Do you want to know about the domain, or how the tool is useful within the domain?
<roptat>in inputs, you have ("some-arbitrary-name" ,some-variable-name)
<roptat>the right part of the inputs refers to the package, so it uses the variable name
<lfam>NieDzejkob: I guess I'm trying to tease out some insight about a sensitive question. Does the program have white-hat use cases?
<roptat>the left part is an identifier that can be used inside the package definition if you need to, but is usually skipped
<roptat>usually they are both the same in inputs, but the name on the left is a string, the name on the right is a variable reference
<NieDzejkob>lfam: it's not really sensitive, I'm just trying to understand your question well so that I don't type a lengthy explanation to a question you didn't ask :P
<apfel>roptat,mbakke: yea, sorry, i was confused. I somehow was working with the assumption that there where no protobuf packages with the correct version name. Package as in package definition, or symbol name.
<lfam>I've only heard about ROP chains in the context of what we might call bad behavior
<apfel>roptat,mbakke: but i think i was not explaining the problem very well
<lfam>But obviously it's important to learn these techniques and be able to discover exploits in order to fix them
<apfel>roptat,mbakke: but thanks
<NieDzejkob>lfam: exploit development does have white-hat usecases. The one I'm interested in is CTF competitions, but the skill is necessary to, for example, create a proof of concept that a bug is exploitable
<NieDzejkob>helps you judge impact
<roptat>I remember we rejected another package for the same reason in the past
<lfam>Yes but I think that case was quite egregious
<roptat>or maybe it was the same, I don't remember precisely
<NieDzejkob>you could argue all day with managers, or you could spend a (fun) while to actually make an exploit and point "look, I said so"
<NieDzejkob>in the age of bug bounties this becomes more important
<lfam>We should be careful to write the package synopsis and description to emphasize the "light side" of its utility
<mbakke>apfel: no worries, glad to help & clear some confusion :-)
<lfam>I think that previous case was purely an exploit in package form
<lfam>Not to mention that the most dangerous things we package are text editors and GCC ;)
<NieDzejkob>bavier`: are you using command-line `guix show' or some emacs thing? Also, I ran a grep and @acronym is quite commonly used in package descriptions, see, for example, fifengine
<NieDzejkob>roptat: I found the thread. https://lists.gnu.org/archive/html/guix-patches/2017-12/msg00075.html
<NieDzejkob>lfam: as for phrasing the description to emphasize the light side, I'm not sure there's a much better way of phrasing it than "Oh hey, by the way, if you're wondering if this has non-illegal usecases, [explanation]"
<lfam>No, you don't have phrase it like that. I don't think legality comes into it; it's more about ethics. But I think you can talk about it in terms of security research and educational tools
<lfam>The usual phrasing for this kind of thing
<lfam>Use your judgement
<jackhill>having the word security in there could help search also.
<jackhill>I didn't think of that with my comment on the issue before
<bavier`>NieDzejkob: using 'guix show'
<bavier`>right, @acronym is commonly used.
<NieDzejkob>huh, got to the bottom of the problem
<NieDzejkob>the guix package from (guix self) that's used when im in a `guix environment guix' skips @acronyms
<NieDzejkob>the latest commit that you get when you guix pull doesn't have that bug
<NieDzejkob>ah, no, I did a `./pre-inst-env guix environment --ad-hoc` to test a package and didn't exit
<NieDzejkob>and ~/guix/scripts got added to my PATH
<civodul>there was a Guile bug with @acronym that got fixed in 3.0.1/2.2.7
*lfam going through the poetry patches now
<civodul>thanks, lfam!
<civodul>hwloc@2 fails tests on aarch64
<rekado>oh… this… wow
<rekado>the Debian approach is the most elaborate way to say “I give up” since the invention of Docker.
<rekado>they run bazel build, which produces a 17MB log file
<rekado>then they run a script over the log file that extracts every command line
<drakonis>what is this over?
<rekado>and then they reassemble this in something like a makefile
<rekado>tensorflow
<lfam>😱
<civodul>!!
<drakonis>oh, tensroflow, how fun.
<bavier`>oh wow
<civodul>crazy stuff
<rekado>I need a drink
<civodul>IOW, it's not built from source
<lfam>I'd say this deserves a blog post but we shouldn't point out other distro's problems
<lfam>That's wild
<rekado>I fear that the reception of this hypothetical blog post would just be confusion all around
<civodul>it's interesting socially that this trick was enough to pass Debian's QA :-)
<drakonis>tensorflow has a package on debian?
<rekado>for us it would be confusing that this was considered a good idea
<civodul>rekado: it'd be good to get people to think about it, though
<lfam>Yeah, where is this in Debian? I'd like to check it out
<drakonis>i dont remember it ever having a package
<drakonis>it maybe briefly had one?
<rekado>for others it would be puzzling as to why people aren’t just using Bazel
<rekado>apparently it’s in the queue.
<rekado>it’s pretty new
<lfam>Right, there is a way to talk about it sensitively
<drakonis>its never going to be accepted
<rekado> https://salsa.debian.org/science-team/tensorflow/
<drakonis>that's not the queue though
<drakonis>it got dropped by mo zhou
<lfam>The latest commit: " I'm dropping this burden. "
<civodul>"rocket science team"
<drakonis>he already tried it before and the package was dropped from debian
<rekado>I read about this entering the queue on a mailing list
<drakonis>it existed for a brief amount of time in the archive
<civodul>lfam: fun :-)
<rekado>I see.
<rekado>this is fantastic
<drakonis>is it?
<lfam>It's a bit discouraging that even Debian can't make it work
<rekado>Guix *has* a tensorflow package FWIW
<rekado>we made it work
<rekado>but only once
<rekado>upgrading is virtually impossible
<rekado>so my next attempt will be to use bazelcmake
<rekado>*bazel-to-cmake
<rekado>and see how far we get
<drakonis>so, tensorflow will be unavailable if you can't get it to work?
<civodul>i'm surprised roptat still hasn't picked up on the idea of implementing Bazel on top of Guix
<drakonis>doesnt it also require nonfree software to drive the gpu for computations?
<drakonis>bazel is a massive beast
<civodul>yeah, GPUs are proprietary software ridden
<civodul>Guix provides a CPU-only version
<drakonis>the cpu only version is fairly slow
<lfam>What could it be doing that requires a GPU
<apteryx>Neat. I added a test for Btrfs RAID, and it passed without coding anything new :-)
<rekado>drakonis: depends on the problem
<roptat>civodul, :p
<rekado>drakonis: for some bioinfo things it doesn’t really matter whether the GPU is used or not.
<roptat>not interested (yet)
<civodul>:-)
<civodul>roptat: you're already after Maven though, right?
<rekado>some people just use very few parts of tensorflow
<roptat>yep, almost done
<civodul>woow
<civodul>that's something
<roptat>I can build and install packages with my maven-build-system
<roptat>but I have a NullPointerException when running tests
<lfam>This was considered "impossible" for us a few years ago
<lfam>It's very impressive roptat
<roptat>thanks :)
<civodul>NullPointerException is the #f of Java
<civodul>oops
<drakonis>impossible you say?
<lfam>No, "impossible"
<lfam>;)
<drakonis>do explain
<roptat>impossible n'est pas français ;)
<lfam>In English you can contradict yourself by putting the phrase in "quotation marks"
<lfam>So, I am saying that it was not actually impossible, although we thought that it was
<lfam>It's like saying that coronavirus is "not a big deal"
<drakonis>a bit of a weird choice but okay
<lfam>It's idiomatic
<civodul>:-)
<rekado>hmm, bazel-to-cmake is a dead-end.
<rekado>so, back to square one
<lfam>The idea is that you are quoting some other person who you think is incorrect
<civodul>if reimplementing Bazel is too hard, there's also the option of reimplementing TensorFlow
<civodul>with python-on-guile and all
<drakonis>hmm wow, okay, that's going to be a big problem
*civodul happy to share ideas
<rekado>civodul: we’d still need to build the library
<drakonis>the underlying c++ library is chunky
<rekado>the python bindings are generated during the build
<rekado>it’s confusing
<civodul>ah, let's give up on this one, then
<drakonis>python has a lot of scaffolding for generating bindings
<roptat>so, currently only surefire-plugin (the plugin that runs tests) is broken; it's supposed to fork itself and run the tests in the fork, using Junit4Provider. If there is not provider, it forks itself and the fork fails because it can't find the class. If it's present (and with the correct version), I get a NullPointerException in the main process, before the fork is created
<roptat>I'm pretty sure it has something to do with classpath handling, because the fork process will execute a generated jar that contains only a manifest with a specific classpath, so it can load junit and the junit provider
<rekado>with a lot of time we could probably untangle all the BUILD and *.bzl files in the tensorflow repository and write an equivalent build system.
<roptat>when their is no provider, the generation of the jar is incomplete, but it doesn't trigger the null pointer
<roptat>anyway, this is going to be more difficult than I thought...
<rekado>I suppose we could even parse all the BUILD files and implement a “bazel lite” that allows us to produce a build script
<rekado>…and this is where python-on-guile could come in handy again: the .bzl files look like a Python subset.
<rekado>but I gotta say that I don’t like the feeling of being tricked into engaging with a project that doesn’t care about conventions
<rekado>innovation is fine, of course, and it’s great that this is free software, but …
<lfam>I feel like it's always tough when Google makes a free clone of one of their internal tools. I've never heard that they are a joy to use
<drakonis>this is a second generation of their internal tools
<drakonis>much like kubernetes
<lfam>I guess that kubernetes had enough utility to take off
<drakonis>bazel might be useful to a variety of internal projects
<drakonis>kubernetes is uniquely useful to everyone
<lfam>They use blaze internally. Bazel is the thing they made open
<lfam>But it's not the same as Blaze
<drakonis>i did not say it was the same
<drakonis>bazel is the tool they designed with the lessons learned from blaze
***pkill9_ is now known as pkill9
<leoprikler>the first lesson is you can never have enough boostrap jars
<goldenshimmer>Have solved my question from last night by a change of mindset — even after getting past the unbound input variable, I couldn't do anything with it — seems that snippets don't have the build environment available, hence all my invokes failing; I have to stop thinking about the extra origin as part of this package, but as its own separate hidden one, to only be returned by guix build --sources=all (indeed, that is how
<goldenshimmer>works for adanaxisgpl). That resolves the mystery. Thanks again!