IRC channel logs

2020-12-17.log

back to list of logs

<mbakke>yet it's still far from complete! :)
<dftxbs3e>cbaines, is there a way to trust substitutes just for your agent?
<cbaines>dftxbs3e, I don't believe so
<dftxbs3e>cbaines, OK! Thanks.
<dftxbs3e>cbaines, aa... a packed GNU Guix doesnt have a view of the actual /gnu/store from the host
<dftxbs3e>big bummer
<dftxbs3e>so can't build anything
<cbaines>Hmm, so the powerpc machine has the guix-daemon right? How was that built?
<dftxbs3e>cbaines, my host has Fedora 33 and it's easier there package-wise so I did it
<dftxbs3e>ppc64le that host is
<dftxbs3e>I just want it inside the VM because security isolation and resource management
<dftxbs3e>the guix-daemon basically can't modify the /gnu/store from the pack
<dftxbs3e>somehow
<dftxbs3e>it gets permission denied
<cbaines>So the guix-daemon is installed through a fedora package, I guess that includes the Guile parts of Guix?
<dftxbs3e>cbaines, no, it's compiled manually and make install'd
<dftxbs3e>that's for my host, not the VM I am trying to install it to
<dftxbs3e>It would be nice to be able to "pack" an environment
<dftxbs3e>cbaines, if only I could rebuild guix-binary
<dftxbs3e>ah I found how!
<dftxbs3e>cbaines, ./pre-inst-env guix pack -C xz --fallback -s powerpc64le-linux --localstatedir --profile-name=current-guix --with-git-url=guix=https://gitlab.com/lle-bout/guix --with-branch=guix=wip-lle-bout-le1 --without-tests=guix guix
<dftxbs3e>heh
<cbaines>interesting!
<dftxbs3e>(I also modified the GNU Guix package definition with --with-courage
<dftxbs3e>The Makefile can also do it under normal circumstances with: $ make guix-binary.blah.tar.xz
<dftxbs3e>good to know
<dftxbs3e>cbaines, yay it worked! modified install shell script a bit to use custom tarball..
<cbaines>dftxbs3e, great, hopefully I'll be able to produce some powerpc64le-linux derivations to built soonish
<dftxbs3e>cbaines, it needs to build first world now.. so will take some time
<dftxbs3e>I'll see if I can copy part of the store from my host
***sneek_ is now known as sneek
***flor_ is now known as flor
<ryanprior>Y'all know which package has pgrep?
<ryanprior>Found my answer: it's procps
<kozo[m]>How did you figure out what package contained it?
<xelxebar>kozo[m]: For now, you just have to slum it by searching around. Debian package search lets you search for files: https://www.debian.org/distrib/packages
<kozo[m]>Thank you xelxebar
<xelxebar>There is a file-to-package search command in the works right now. Last I looked at the thread in the mailing list, it seems like it'll land soon.
<ryanprior>I looked it up in Debian kozo and that gave me the clue
<ryanprior>I will make regular use of the Guix file-to-package search as soon as it's available :)
<kozo[m]>ryanprior: Thank you =]
***regtur_ is now known as regtur
<rekado>hmm, savannah seems to be unresponsive
<Parra2>Good morning!
<Parra2>Hi, recently I've seen this post about Guix ( https://hpc.guix.info/blog/2019/10/towards-reproducible-jupyter-notebooks/ ). I think it's a really cool tooling. In fact I'm developing MetaCall ( https://github.com/metacall/core ) which is a multi-runtime polyglot. MetaCall already uses Guix for CD/CI and shipping / distribution. I think we could benefit each other with this kind of applications. What do you think?
<pinoaffe>hi folks, my emacs segfaults when I launch it as exwm window manager or from within a graphical session but works when I launch it in a TTY, anything I could look into?
<xelxebar>pinoaffe: When logs are unhelpful, the next tool I go for is strace.
<mfg>hi guix! long time no see :(
<mfg>i was wondering why guix (and i guess nix too) uses symlinks and not some unionfs like thing? is there a reason for this or did it work well enough and was easier?
<pinoaffe>xelxebar: thanks, I figured it out, something was wrong with my font cache and running `fc-cache -fv` did the trick
<xelxebar>Hrm. A segfault sounds like a bug. If you have any idea where in the stack this occured, it might be nice to report upstream.
<rekado>savannah appears to be back
<civodul>Hello Guix!
<janneke>hello civodul!
<civodul>hey janneke :-)
<rekado>hello, hello!
<rekado>This looks nice: https://github.com/rougier/nano-emacs
<rekado>I’ve been feeling a little sad about neglecting “Guile Studio” for so long; nano-emacs gives me some motivation to work on it again
<civodul>rekado: it looks nice indeed!
<civodul>re Guile-Studio, we should consider promoting it
<civodul>having a blog post on the Guile web site, a Debian package, etc.
<civodul>Parra: you have networking problems!
<civodul>should we kick Parra until they've fixed the problem?
<jonsger>please :)
<rekado>(I hide joins and parts, so I didn’t notice)
<PurpleSym>civodul: It looks like your most recent patch series broke `guix system build`, see https://paste.debian.net/1177114/
<rekado>civodul: I’ll try to work on this next week. I also want it to offer some templates and a splash screen where templates can be instantiated.
<rekado>once I’m happy with it I’d be happy to build a pack and write an introductory blog post.
<jonsger>rekado: I used to, but thunderbird removed that feature :(
<rekado>I’m using this for on-the-fly importing and building from within R: https://issues.guix.gnu.org/issue/45288
<rekado>yay or nay?
<janneke>rekado: as a big divergence, what happened to the eww-compatible issues web, didn't you have that ready?
<rekado>janneke: I had a CSS fix but Mark didn’t like it IIRC
<rekado>so I guess as I got overwhelmed by the discussion I didn’t pursue it any further and didn’t apply it
<rekado>I should follow up on this at some point
<janneke>rekado: ah, too bad
<janneke>i detached when i thought to see: ah, it's getting better, great!
<rekado>I don’t have any good strategies for writing and maintaining CSS, so I tire quickly and feel very unsuccessful whenever I mess with it.
<rekado>that’s a big hurdle for me to overcome
<rekado>I have a few “important” things to do today, but I’ll see if I can deploy a quick fix later.
<janneke>yeah, i feel the same -- but that would be awesome and much appreciated
<procra>Hi guix!
<dftxbs3e>mbakke, finally ran the build!
<efraim>I used ip commands to connect my pine64 to the network, how do I get it to resolve domain names?
<procra>I have been trying to use a virtual machine with network however I am not very sure if I should do it in some specific way or not and in case there is one which is it?
<dftxbs3e>efraim, echo "nameserver 80.67.169.12" >> /etc/resolv.conf ?
<dftxbs3e>That's fdn.fr's DNS
<dftxbs3e>procra, With QEMU? There should be command line parameters to provide some simple no-fuss networking to the guest
<dftxbs3e>cbaines, this morning the x86 VM was idle, I restarted guix-build-coordinator-agent service and it started picking up jobs again.
<dftxbs3e>cbaines, last log line: 2020-12-17 11:18:19 (INFO ): 3fdb677b-c8ba-4273-9d80-aa232de41fe6: finished submitting outputs, reporting build success
<efraim>dftxbs3e: thanks. I used 192.168.1.1 for my local router.
<dftxbs3e>cbaines, ah.. disk space ran out
<cbaines>dftxbs3e, ah, with doing lots of parallel builds, you'll probably need to increase the guix gc frequency
<dftxbs3e>cbaines, will make it hourly
<civodul>PurpleSym: wasn't it fixed by d88ff09ea3138fc85c1463b0b345bd6ba71ca568 ?
***ChanServ sets mode: +o civodul
<procra>dftxbs3e: sorry i got an network problem
<PurpleSym>civodul: Hm, still an issue here with `guix time-machine -C channels.scm -- system build -e '…'`. channels.scm just contains an extra channel.
<PurpleSym>`… -- describe` reports commit 17235ec28ceee1243bca2f6910c602c4460ae02a.
<procra>dftxbs3e: with virt-manager which use QEMU, it show me a way to conctme bot it is macvtap and it haven't work. algo I am really new
<dftxbs3e>procra, if you're new, try GNOME Boxes, it's easier to use!
<civodul>PurpleSym: can you reproduce it with a simple config or share the one you have?
<dftxbs3e>procra, with virt-manager over here I have a NAT network configured and that's what it uses.
<dftxbs3e>There's a default one usually, called 'default'
<dftxbs3e>You can otherwise create one with Edit->Connection Details->Virtual Networks
<procra>dftxbs3e: thank you <3. I haven't a default NAT an searching why I find that ip4 forward was not enable and after enable it I really dont't know what to do.
<cbaines>I might actually have time tomorrow to do patch review stuff, I should probably send out an email or something
<civodul>cbaines: for a joint session where we all roll up our sleeves and bite the bullet?
<cbaines>civodul, well, trying to collaborate over IRC doing some patch review, whatever that turns out to mean
<civodul>yeah, cool :-)
<cbaines>setting out some time regularly might help to get more people involved
<cbaines>it also might help iterate on the processes/tooling, getting more input from others, rather than me just flip flopping between reviewing patches then working on tooling
*jonsger will joins this party :)
<mbakke>whoops, the Perl upgrade on 'core-updates' broke 'po4a' (a prerequisite for 'guix'), I did not notice because I was working on texlive (a prerequisite of po4a), and the other perl stuff I tested was fine
<civodul>heh
<kisaja[m]>when is gtk4 going to be in guix, its already stable btw
<civodul>kisaja[m]: hi! "when you package it" is one possible answer :-)
***Parra was kicked by civodul (Kicked by civodul)
<dftxbs3e>cbaines, guix-build-coordinator requires mariadb somehow and that doesnt build on powerpc64le-linux yet
<cbaines>dftxbs3e, ah, that could be because of the sqitch dependency
<cbaines>which isn't actually used by the agent
<cbaines>I'm excluding those inputs for the hurd already https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/package-management.scm#n1083
<cbaines>Maybe it would help to have a more minimal package definition with just enough stuff for the agent though
<fdddd>Would it be possible to install Guix "headlessly" (e.g. over SSH)? I have a machine which I will use as a server, but I don't think graphics can be displayed for the installation on this machine with the Linux Libre kernel. Alternatively, is it possible to get the TTY display to work without graphical drivers? The machine has an AMD Ryzen 2200G APU with integrated graphics so the firmware blobs necessary for AMDGPU are missing afaik.
<jonsger>fdddd: I think basic 2D graphics should work even without the non-free firmware. Maybe you need to fiddle a bit with cmdline (nomodeset)...
<fdddd>Right I will give nomodeset from grub a try. Wasn't sure if this still required firmware etc.
<jonsger>good luck
<fdddd>Thank you!
<PurpleSym>civodul: Building gnu/system/examples/vm-image.tmpl works fine, but I don’t see why it does not with a different configuration :/
<rekado>fdddd: you can use “guix deploy” to install Guix System remotely
<zimoun>hi
<jonsger>PurpleSym: do you use channels?
<PurpleSym>jonsger: Yes.
<efraim>looks like giac depends on glpk<5
<fdddd>rekado: I guess this would require the machine already running some OS/live CD and be reachable by SSH?
<jonsger>PurpleSym: me as well and that seems to trigger that bug
<jonsger>hm, savannah sees to have problems
<zimoun>rekado: what is “style” specification? patch #45288 about import/cran
<leoprikler>Is there a way to get a specific package from the propagated input some package in #:inputs
<civodul>PurpleSym: could you paste all the "guix system build" output?
<jonsger>civodul: I have an example here https://issues.guix.gnu.org/44760#22
<civodul>jonsger: that error is from "guix pull"?
<civodul>i really need to see the command and full output :-)
*civodul tries "guix time-machine --commit=6a060ff27ff68384d7c90076baa36c349fff689d -- pull -p /tmp/test"
<jonsger>civodul: no guix pull succeds its from module-import-compiled
<jonsger>.drv
<jonsger> /gnu/store/f3512776j33cmlg6k42m4ndpi3by3j1v-module-import-compiled.drv and the log does not contain more then I posted to the bug
<civodul>jonsger: to put it differently, how can i reproduce?
<civodul>the time-machine+pull above works for me
<PurpleSym>civodul: The pull part of time-machine succeeds. My config+channel are not public yet and quite big, unfortunately.
<jonsger>civodul: I think its triggerd if you use additional channels
<raghavgururajan>Hello Guix!
<dftxbs3e>mbakke, hello! it failed with this: objcopy --dump-section=.gnu.attributes=/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.bin.tmp /tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.o
<dftxbs3e>objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.o'
<dftxbs3e>I am thinking binutils (objcopy) isnt up to date enough?
<dftxbs3e>cbaines, will try offloading
<abcdw>jgart[m], dftxbs3e Fixed yesterday quirk. It were few problems in different places (I had bunch of temporary scm files without namespaces and proper imports declarations in the load-path), but the interpreter complained about unbound varible for some reason.
<civodul>jonsger: i've tried with additional channels as well
<civodul>so i don't know
<civodul>maybe it's an issue with a specific channel?
<dftxbs3e>abcdw, well okay!
<jonsger>maybe, I need to dig deeper as I don't see something obvious triggering the error
<abcdw>bob@antelope ~/work/rde$ sudo guix system -L . build rde/system/desktop.scm
<abcdw>bob@antelope ~/work/rde$ sudo guix system -L . reconfigure rde/system/desktop.scm
<abcdw>receiving objects 4% [####
<abcdw>What kind of object does it recieve?
<rekado>zimoun: when --style=specification is selected the generated package definition uses (specification->package "foo") instead of ,foo.
<abcdw>I built it before reconfiguring, it should do nothing, just switch to new configuration. Isn't it?
<rekado>this is useful for on-the-fly installations as with guix.install() in R.
<rekado>it is useful because the user module imports don’t need to be updated to import the variables that are referenced by the new package definitions.
<rekado>instead they are found by specification->package
<rekado>it also makes user modules (the file that guix.install() appends to) future proof as the package definitions therein are robust against changes to the location of package variables.
<civodul>abcdw: Git objects
<abcdw>civodul, why it's doing it during reconfigure?
<civodul>abcdw: for downgrade detection, see https://guix.gnu.org/en/blog/2020/securing-updates/
<abcdw>Can I path to reconfigure just /gnu/store/kk4l1qdrs5ksp825gpdamaqi0r4m5kpn-system ?
<abcdw>civodul, ok, thank you, will take a look.
<civodul>now there's a slight bug, which is that when you use sudo it updates ~root/.cache
<civodul>even if it already has an up-to-date checkout in ~user/.cache
<dftxbs3e>re patch review meeting: I would also be willing to help. I don't have commit access yet.. trying to upstream some things to obtain it. (I have some patches pending already)
<abcdw>civodul, copying .cache to /root helped, thank you.
<abcdw>Idk why checkout was sooooo slow
<mbakke>dftxbs3e: what are you running to get that error? I'll try to reproduce.
<civodul>abcdw: if it's the initial clone, it takes time, there are quite a few MiBs to fetch :-)
<civodul>i've filed a bug for this
<Franciman>Hi, is there some form of iteroperability between nix packages and guix packages?
<dftxbs3e>mbakke, ./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-tarballs
<dftxbs3e>mbakke, note this doesnt need special hardware at all, it runs on x86_64-linux
<mbakke>dftxbs3e: did you patch anything, other than the GCC 10 change?
<rekado>Franciman: at what level?
<rekado>Franciman: generally, the answer is “no”
<dftxbs3e>mbakke, ugh I think I didnt and I should've been, sorry doing many things in parallel I think it's a mistake now
<dftxbs3e>mbakke, if you havent made it default, then gcc-10 should be made default..
<mbakke>dftxbs3e: you mean in make-bootstrap.scm, right?
<dftxbs3e>mbakke, yes or.. gcc.scm, I vaguely remember it not being easy to replace gcc just for that part but I may be wrong
<mbakke>Right, I also remember complications in that area. I've queued builds with that change now, we'll see.
<Franciman>rekado, at the most basic level, i.e. take a nix package description and convert it in guix
<Franciman>I guess the inner working would the different?
<rekado>Franciman: there is a nix package importer, but I’ve never used it and I hear it’s no longer fully functional (no pun intended)
<Franciman>lol
<Franciman>ok thanks
<Franciman>also why generlly the answer is no? It's because packages are dealt with differently?
<Franciman>What I'm asking is: what would be a difficulty in translating a set of packages from nix to guix?
<civodul>Franciman: Nix packages are written in Nix language + Bash
<civodul>whereas Guix packages are written in Scheme
<Franciman>oh ok, I thought that'd be easy
<Franciman>ok thanks
<dftxbs3e>cbaines, miredo wasnt working out of the box on GNU Guix System, so I sent a patch, you can have IPv6 easily after that :-) - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45296
<librecat[m]>what is not fsdg on other distros i only know kernel some codecs i dont know and browsers
<leoprikler>librecat[m]: basically anything coming from "nonfree" on Debian, as well as many other contrib stuff, for example
<leoprikler>(not sure if debian contrib, but other distros have nonfree stuff in their contrib)
<librecat[m]>i wanna make a fsdg gentoo or lfs so thats why i am asking
<librecat[m]>what are the compile flags on ffmpeg
<librecat[m]>sorry for asking ^ i will read the package
<zimoun>rekado: thanks
<guix-vits>librecat: gentoo has LICENSES option. aren't it is fsdg?
<guix-vits>*enough
<stikonas>guix-vits: LICENSES option is quite good (and defaults to free only) but sometimes LICENSES field is inaccurate
<stikonas>e.g. www-client/chromium is non-free but LICENSE says BSD
<guix-vits>ah, yes that was in wiki. thank you
<stikonas>so instead I use ungoogled-chromium from some overlay... Also need to deblob kernel (gentoo-sources)
<librecat[m]><stikonas "so instead I use ungoogled-chrom"> do you know any overlay with libre-sources
<librecat[m]>stikonas: i can replace the kernel tarball url with the libre tarball by modifying vanilla-sources
<zimoun>civodul: about #44760, well #45294 reports the same, IIUC.
<zimoun>even if “guix time-machine” is also working for me.
<torque`> https://paste.debian.net/1177283
<stikonas>librecat[m]: no, I do deblobing in an ebuild hook
<zimoun>torque`: hum, maybe Savannah is down.
<stikonas>librecat[m]: something like https://paste.debian.net/1177285/
<guix-vits>torque`: try again? it opens for me (slowly).
<librecat[m]>stikonas: i will try that thanks
<librecat[m]>will it work on zen-sources
<stikonas>probably...
<stikonas>it just runs general deblobing scripts...
<stikonas>you need to put that in /etc/portage/env/sys-kernel
<stikonas>and also disable network sandbox
<librecat[m]>wow gentoo is so configurable like lfs
<civodul>mbakke: 46% substitutes on 'ungrafting'
<mbakke>slow but steady.. :)
<stikonas>librecat[m]: yeah, with gentoo you can do quite a lot of tricks... I was able to replicate openjdk/rust bootstrap that guix does
<mbakke>why not just use Guix instead at that point? :-)
*mbakke unequips troll hat
<librecat[m]>stikonas: how can i install icecat/iceweasel on gentoo maybe makeicecat + firefox ebuild
<stikonas>librecat[m]: I haven't tried it. There is some overlay https://gpo.zugaina.org/www-client/icecat although that's old icecat...
<librecat[m]>stikonas: the icecat maintainers might be able to make a new stable release with 78 esr
<librecat[m]>the last was 60 esr
<torque`>Savannah seems better now.
<bandali>re savannah: there were a bunch of lingering git processes hogging the git server. killed them, and things should be good again now :-)
<bandali>that server could generally use a bit more memory imho
<dftxbs3e>cbaines, ZFS deduplication on my hypervisor host is taking up lots of RAM. So many things are OOM'ing right now because the hypervisor host is under serious memory pressure.
<cbaines>dftxbs3e, maybe drop the number of parallel builds, 16 is quite a lot
<HappyEnt[m]>Hello! Anybody know how to solve guix in pre-inst-env not finding (gcrypt hash)? The module is definitely in my load-path and I can load it perfectly fine from a repl inside the pre-inst-env. I also tried a pure environment using guile from the source build (In contrast to what I had in my environment)
<ngz>HappyEnt[m]: I don't know, but I would try to ./configure and compile guix again in your case.
<ngz>This is my recipe when ./pre-inst-env starts acting funny.
<HappyEnt[m]>ngz: I tried that, but maybe make clean leaves something over. Now that I think about it I think that was my problem last time I had this same problem. I will try a clean clone! Thank you :)
<dftxbs3e>cbaines, the problem is elsewhere, the VM only has 3GB of RAM allocated currently :P
<dftxbs3e>cbaines, are OOMs going to disturb the system? Or is your code able to detect OOMs and ignore build results?
<cbaines>dftxbs3e, there's not a mechanism currently to spot when builds fail because of resource issues, but don't worry about it, failures will be retried a couple of times
<ngz>Is it fine to update openblas in core-updates?
<dftxbs3e>cbaines, okay, many builds probably failed many times there so I hope it didnt mess everything up
<dftxbs3e>cbaines, I lowered it to 8 parallel-builds as well
<mbakke>ngz: should be fine
<mbakke>civodul, janneke: cross-compiling glibc to GNU/Hurd fails on 'core-updates'
<civodul>ngz: yup; i think it's too much for 'staging'
<civodul>mbakke: ah ha!
<civodul>i'll try
<roptat>hi guix!
<mbakke>hm, savannah seems to have gone down mid-push for me
<janneke>mbakke: bah...2x
<torque`>mbakke: you are not alone. :(
<mbakke>it eventually succeeded :)
<jmarciano>Hello, I would like to install Leo editor by using Guix package manager on foreign OS (Hyperbola). https://leoeditor.com/
<sneek>Welcome back jmarciano, you have 1 message!
<sneek>jmarciano, leoprikler says: Guix (the package manager/OS) deletes files [upon gc] using rm, so nothing is trashed. Applications on Guix, e.g. GNOME, may or may not honor XDG trash, as they do in other distros.
<jmarciano>How do I go installing that by using Guix?
<jmarciano>for example pip is not in Guix, I cannot just run pip
<jmarciano>leoprikler: thanks
<mbakke>dftxbs3e: I get the same error with a GCC 10 bootstrap
<mbakke>objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.o'
<dftxbs3e>mbakke, yep! I ldbl means long double often
<dftxbs3e>s/I //
<mbakke>jmarciano: I think pip is available as 'python-pip'
<mbakke>jmarciano: ...although the best approach is to create a proper package
<mbakke>jmarciano: since 'leo' is distributed as a regular PyPI archive, a good starting point for a proper package is to run 'guix import pypi -r leo'
<dftxbs3e>how would you quickly setup a service that starts a single command?
<dftxbs3e>mbakke, I have this thing about this error: https://sourceware.org/pipermail/glibc-cvs/2020q2/069281.html
<dftxbs3e>I remember looking it up before
<dftxbs3e>mbakke, the way they are handling this long double format switch is such a mess, it even breaks configurations that don't opt-in to it! (Like ours)
<ngz>cbaines: OOC, what is your availability tomorrow, for the patch review session?
<cbaines>ngz, I'm in the UK (UTC+0), I plan to be around most of the day
<dftxbs3e>mbakke, maybe try reverting this: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=4a914de930a8317cab5bc11bdb608e3a3da3d1ad
<dftxbs3e>GCC-10 may not need it
<ngz>cbaines: OK, thanks.
<jmarciano>mbakke: aha thank you for pointer
<mbakke>dftxbs3e: testing now
<dftxbs3e>mbakke, beginning to use worktrees so I don't have to recompile GNU Guix from scratch every time I switch from master to core-updates
<dftxbs3e>I had to delete the patched tree with your patches earlier.. making a new one
<mbakke>dftxbs3e: worktrees are indispensable when working on multiple branches. Do you still have the GCC patch?
<dftxbs3e>mbakke, yes I still have it
<mbakke>dftxbs3e: I got the same failure after reverting the GCC long-double patch
<mbakke>dftxbs3e: actually, the long-double argument to GCC was not effective for 'gcc-cross-sans-libc', which is the compiler that is used when it fails, testing with it now
<mbakke>...it did not make a difference
<zimoun>cbaines: cool initiative the patch review. It could be cool to join with the (old) bugs squashing. https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00001.html :-) Especially, do some triage with patches older than 40000. For instance #35045 submitted 1.5years then reassigned today.
<cbaines>zimoun, thanks, and yeah, there's definately some old patches that are still relelvant
<cbaines>I've been going through patchwork.cbaines.net in reverse date order https://patchwork.cbaines.net/project/guix-patches/list/?state=1&order=date
<cbaines>although I don't think Patchwork is missing some older patches probably
<zimoun>cbaines: do you mean Patchworkk is missing older patches? as #33899; the well-known IPFS WIP PoC :-)
<cbaines>ah, yeah, wrong way around, patchwork.cbaines.net won't list patches that were sent before I set it up
<aecepoglu[m]>what are the files in guix/gnu/packages/patches for?
<zimoun>it is already nice to have. Where is the legend for A/R/T and S/W/F?
<dftxbs3e>mbakke, well..
<zimoun>aecepoglu[m]: applies patches to some packages.
<aecepoglu[m]>So, they are optional patches people have submitted for certain packages
<cbaines>zimoun, I think the oldest patch in patchwork is from 2018-10-21. It does actually have #33899 but it's incorrectly marked as accepted https://patchwork.cbaines.net/project/guix-patches/list/?series=&submitter=&state=*&q=33899&archive=both&delegate=
<aecepoglu[m]>Thanks zimoun
<cbaines>I think to reduce the number of patches, I just marked everything as accepted at some point it the past
<cbaines>zimoun, as for the A/R/T and S/W/F bits, you might see information if you hover your mouse over those bits
<ngz>cbaines: I have a silly question: can patchwork let me know if a patch actually builds?
<cbaines>zimoun, I see Acked by/Reviewed by/Tested by and Success/Warning/Fail
<aecepoglu[m]>I have written a package for an addon for a text editor (Kakoune, which exists in guix) . The plugin itself is a CLI application written in Rust. Should in go in gnu/packages/rust.scm or rust-apps.scm ?
<zimoun>cbaines: thanks.
<zimoun>cbaines: does Success means “apply success“ or “build success” as ngz asks?
<cbaines>ngz, so Patchwork provides a web interface, and helps with processing the patches. Then there's some stuff that I'm using the Guix Data Service and Guix Build Coordinator to do
<vagrantc>sortring by oldest first has the downside of looking at a v2 patch series before a v3 patch series
<vagrantc>there's a way to mark a series as superceded?
<cbaines>ngz, taking this patch as an example https://patchwork.cbaines.net/project/guix-patches/patch/20201217114619.18199-1-mail@cbaines.net/ if you click through to the Guix Data Service via the "View comparison" link, you'll see the relevant revisions for the comparision have been processed correctly, and some builds for affected packages have been scheduled, but I don't think they've completed yet
<vagrantc>oh, ipxe is really confusing ... v2 -> v3 -> mislabeled as v2 :/
<cbaines>vagrantc, you can mark patches as superseded, you'll need to register and sign in to do that
<mbakke>dftxbs3e: there are quite a few powerpc related fixes added shortly after binutils 2.35.1: https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_35-branch;pg=1
<cbaines>the possible states are customisible as well
<ngz>cbaines: When I'm here <https://data.guix-patches.cbaines.net/compare?base_commit=17235ec28ceee1243bca2f6910c602c4460ae02a&target_commit=adf427ca7a27ddfbdddda6fce194573d2c4906ef>, where should I go next?
<cbaines>ngz, click "Compare package derivations", below the blue "Update results" button
<dftxbs3e>mbakke, ah! I'll take a look!
<cbaines>ngz, you'll then probably want to remove the default for Limit results, tick the "All results" checkbox and press "Update results"
<cbaines>I recently added the "Build change" filter to that page, which means the Guix Data Service can show just the packages that are broken by applying a patch, or merging a branch for example
<profmakx>hi peeps. is there an easy way to bootstrap a guix-sd onto a flash drive that is booted via uboot? (in this case, if it matters, for a rockpro64)
<dustyweb>any mu(4e) users here try running mu-guile?
<dustyweb>I'm trying to run (use-modules (mu)) but with no avail, even though mu is installed in my profile
<dustyweb>based on the package definition, it does look like the mu library should maybe be loaded...
<ngz>cbaines: OK. so what should I look after in this page, with full results? The red squares on the right?
<dustyweb>oh
<dustyweb>actually, I think I see
<dustyweb>mu-guile is for guile-2.2...
<cbaines>ngz, yeah, the coloured squares relate to builds, and red means the build failed. Unfortunately lots of the builds are just yet to happen.
<cbaines>I did find a good example of the Guix Data Service detecting new lint warnings https://patchwork.cbaines.net/project/guix-patches/patch/20201211201833.22529-8-dftxbs3e@free.fr/
<cbaines>and here's an example where the builds have actually happened https://patchwork.cbaines.net/project/guix-patches/list/?series=5816
<cbaines>vagrantc, on the sorting and versions of patches, yeah, it's often confusing. I often end up searching by the Debbugs ID, then trying to work out what's the latest patches
<cbaines>Patchwork also has a tendency to detect peoples replies to patches as new patches
<vagrantc>like any tool, it's imperfect, but still useful :)
<dftxbs3e>mbakke, can't say anything there is related, tried using binutils at HEAD?
<lfam>profmakx: What do you mean by "bootstrap onto a flash drive"?
<cbaines>On the subject of patchwork.cbaines.net, I've re-enabled the registration page https://patchwork.cbaines.net/register/ so if you want an account to be able to change the states of patches, now is a good time
<dftxbs3e>I get errors like this when trying to 'save' a modified config with the interactive nmcli (nmcli connection edit <connection_name>) - https://pic.infini.fr/ZHFEFc1Z/sTOU9FM3.png
<cbaines>I disabled the registraion page recently, because bots were filling it in for some reason
<dftxbs3e>cbaines, registered!
<profmakx>lfam: I want to install guix-sd aarch64 onto the medium from my laptop
<lfam>profmakx: It sounds like you could use `guix system disk-image` to generate the a disk image. I'm not sure exactly how to go from (assuming) x86_64 to aarch64 but I think it must be possible
<profmakx>(might be as easy as guix system --system=aarch64?)
<lfam>I think you might have to cross-compile with --target, rather than --system, but I don't know for sure
<lfam>You could try it and find out
<lfam>I'm sure there are people here who know what to do, or who have talked about it on the mailing lists
<profmakx>looks that the usual way is to install another system and then using guix init
<aecepoglu[m]>Is it acceptable to send patches that place scheme functions that dynamically create packages?
<lfam>aecepoglu[m]: That sounds like a package importer, of which we have several
<aecepoglu[m]>not a package importer... There are multiple packages that are identical except with different "version" fields and different public names.
<lfam>For that, we usually create one of the packages in the normal way and then use package inheritance to create the rest
<lfam>If you search in 'gnu/packages' for "(inherit" you should find examples
<lfam>Maybe if there is really a huge number of these, they should be created programatically
<lfam>It really depends
<aecepoglu[m]>I do. OK. OK. True. Makes sense
<aecepoglu[m]>In 8.3 Defining Package Variants they also mentioned creating functions to return packages, so I thought it was also an acceptable way of doing the same thing
<pinoaffe>aecepoglu[m]: you can take a look in gnu/packages/bootloaders.scm at the function make-u-boot-package as an example of a function used to create packages
<pinoaffe>but as lfam said, "inherit" is used more frequently
<lfam>aecepoglu[m]: It is acceptable, but there is a trade-off between cleverness and accessibility
<lfam>We generate the kernel packages (linux-libre) in this way, and I think it has significantly reduced the number of people willing to help maintain the kernel packages
<lfam>Even when I wanted to help with the kernel, it put me off getting involved for a long time, and I only got involved when there was literally nobody else
<aecepoglu[m]>I see. Inherit it is then
<lfam>On the other hand, "copy and paste" is slow, tedious, and uninteresting, but really easy for anyone to understand :)
<lfam>Ultimately, the person who will maintain the packages gets to decide :)
<aecepoglu[m]>copy-paste is also difficult to maintain, because instead of 1 we need to change many places
<lfam>Yes, there are trade-offs in both directions
<lfam>Inheritance can be seriously confusing when there is more than one layer
<lfam>But, it sounds like the only thing that would be changed in the packages you are suggesting is the version and source hash, right?
<aecepoglu[m]>oh in my case inheritance really does satisfy
<aecepoglu[m]>And it makes it so I don't create a diff for the original package
<aecepoglu[m]>The inherit method should be the one I use. I had forgotten about it.
<joshuaBPMan>Hello you lovely people!
<lfam>Howdy
<morgansmith>is it just me or is the guix git repo currently down?
<librecat[m]>lol gnome updated their screenshot at last the icons seem to be from gnome 3.40 https://gnome.org
<Gooberpatrol66>I cannot figure this out
<Gooberpatrol66>(define nanorc
<Gooberpatrol66> (local-file "/root/guix-configs/nano/nanorc"))
<Gooberpatrol66> (simple-service 'nanorc etc-service-type
<Gooberpatrol66> (list `("nanorc", nanorc)))
<Gooberpatrol66>In procedure append: Wrong type argument in position 2 (expecting empty list): #<<service> type: #<service-type nanorc 7f440be275c0> value: (("nanorc" #<<local-file> file: "/root/guix-configs/nano/nanorc" absolute: #<promise #<procedure 7f4400509600 at /root/guix-configs/guixrig/config-guixrig.scm:17:4 ()>> name: "nanorc" recursive?: #f select?: #<procedure true (file stat)>>))>
<Gooberpatrol66>I copy pasted it from a working config file. What could be different?
<morgansmith>your comma spacing is odd. is that just an artifact of copying it into IRC?
<morgansmith>, nanorc vs ,nanorc
<Gooberpatrol66>It seems not to matter where it is
<morgansmith>huh, the more you know
<efraim>Gooberpatrol66: change it from (list `("nanorc", nanorc))) to `(("nanorc" ,nanorc)))
<Gooberpatrol66>efraim: In procedure append: Wrong type argument in position 2 (expecting empty list): #<<service> type: #<service-type nanorc 7f3fd1148b00> value: (("nanorc" #<<local-file> file: "/root/guix-configs/nano/nanorc" absolute: #<promise #<procedure 7f3fc478f600 at /root/guix-configs/guixrig/config-guixrig.scm:17:4 ()>> name: "nanorc" recursive?: #f select?: #<procedure true (file stat)>>))>
<profmakx>gezas, this is slow
<lfam>morgansmith: It's not just you, the Git repo host is offline. The admins are working on it
<civodul>mbakke, janneke: i've pushed a fix and "guix build coreutils --target=i586-pc-gnu" now works on core-updates!
<mbakke>civodul: yay, thank you!
<morgansmith>lfam: It's working now :)
<lfam>Great :)
<Gooberpatrol66>Sigh...I had an extra paren up above
<lfam>I suspect it might go down again... apparently usage has spiked
<janneke>civodul: \o/ great
<mbakke>what are some good packages to excercise 'texlive-union' and friends?
<civodul>mbakke: packages that already use it? :-)
<civodul>maybe mit-scheme and numpy
<civodul>(off the top of my head)
<civodul>there's also Octave but then you'd have to build OpenBLAS first
<janneke>hmm, why is the "arm-unknown-linux-gnueabihf-gcc" cross-compiler on aarch called "arm-linux-gnueabihf-gcc"?
<janneke>*aarch64
<lfam>While linting this package <https://paste.debian.net/1177403/>, I got this message: "warning: TLS warning alert received: unrecognized-name"
<lfam>That's the only output of the lint command
<lfam>Anybody know what that means?
<mbakke>civodul: there are other problems getting to Octave with GCC 10, but thanks for the tips :-)
<mbakke>I was hoping to find some that build PDFs or similar
<mbakke>but manuals seem fine
<civodul>oh you're testing GCC 10?
<mbakke>yes, most of my recent patches on core-updates have been for GCC 10 :-) including a soon-to-be-pushed TeX Live upgrade
<bandali>lfam, does the linter use gnutls somewhere in the stack?
<lfam>Surely, bandali
<lfam>It does remote lookups and so it will do TLS, and Guix uses gnutls
<bandali>right
<bandali>lfam, quite the long shot, but maaaaaybe it might be related to https://gitlab.com/gnutls/gnutls/-/issues/1131
<bandali>it just jumped to mind, since it's something i came across the other
<bandali>day
<bandali>could be completely unrelated :-)
<lfam>I don't believe it's failing. I think it's just a warning
<lfam>At least, I'd hope it would fail hard
<bandali>oh okay
<lfam>I wouldn't be too surprised if cinecert.com was misconfigured somehow...
<civodul>yeah
<civodul>"wget -O /dev/null https://www.cinecert.com/asdcplib/" should the same warning
<civodul>(it uses GnuTLS as well tho)
<lfam>Yes, although the warning doesn't say which URL has the problem, it doesn't complain when I replace cinecert.com with github.com
<lfam>Yes, I can reproduce it that way civodul
<lfam>"GnuTLS: received alert [112]: The server name sent was not recognized"
<mbakke>ooh, mit-scheme fails with 'mktexpk: Cannot find mktex.opt; check your installation.'
<civodul>ouch
<civodul>now we need to find someone who actually understands the stuff
<civodul>mbakke: BTW, do you know whether gconf really needs to depend on orbit2 (CORBA implementation)?
<ngz>font-iosevka-* packages all inherit from `font-iosevka'. Yet they all use (version (package-version font-iosevka)). This shouldn't be needed, right?
<mbakke>civodul: don't know, but I doubt it. I think orbit2 has been deprecated for ages.
<civodul>mbakke: that's what i thought; i'll try removing it on core-updates
<civodul>ngz: correct!
<GewaltDisney>i know you guys have people coming in here all the time to just say how deep and beautiful a project like guix is, but i just had to stop in and remind everyone
<lfam>Thank you GewaltDisney :)
<mbakke>civodul: I don't think 'gconf' is actually used still either: https://en.wikipedia.org/wiki/GConf
<mbakke>locally I've also made 'intltool' purposefully fail to build, and will remove it from packages as I go (GNOME no longer uses it) :-)
<mbakke>as well as 'python2', but that is more complicated (rust and ghc tests)
<GewaltDisney>lfam, you're welcome. the way it exemplifies what i would call a "politics of demonstration", not only speaking about the ethics of free software but demonstrating its necessetity in practice, if we want to keep to the standards science has set itself; while also demonstrating what becomes possible when workers are treated as owners of their means of production. i dont think i've encountered any technology that had such profound
<GewaltDisney>implications, both in the realm of ideas as well as the social
<lfam>Not much to say except, I agree!
<GewaltDisney>hugs
<civodul>mbakke: oh it's a whole bunch of stuff we could get rid of
<ride>With guix on a foreign distro, can you still use a config.scm file? If so, is there a command other than 'guix system reconfigure' for it or does that still apply?
<apteryx>ride: no
<apteryx>you can still generate system disk images, vms, etc. but you don't get to configure the current system via a Guix operating system configuration on foreign distros.
<apteryx>experimenting with the following manifest while test driving changes to the emacs-build-system, I notice quite some times is spent before anything gets done, with CPU and disk usage low: https://paste.debian.net/1177415/.
<apteryx>Any idea what this could be due to?
<apteryx>oh, forget the essential part: the slow start is only when using: 'GUIX_DAEMON_SOCKET=ssh://my-remote-offload-host' ./pre-inst-env guix build -m the-above-manifest.scm
<apteryx>mbakke: are you planing to entirely remove python2 from core-updates?
<mbakke>sneek: later tell apteryx I don't think removing python2 is feasible, but I am trying to remove all non-essential uses
<sneek>Got it.
<mbakke>In related news, all 'llvm' variants use python2, but AFAICT they all work with Python 3. Not sure what the comment is about.
<mbakke>some fail with GCC 10 though, but that's another issue
<mbakke>in unrelated news, 'guix size guix' is 446.5 MiB on "core-updates", but 542.2 MiB on "master"?
<mbakke>'guix size guix guile-avahi' is 484.3 MiB
<mbakke>oh, there's an extra 'guile' in the closure on 'master' :-)