IRC channel logs

2021-03-04.log

back to list of logs

<dftxbs3e>so I should push to core-updates every change I can't apply on master? Right now, I oftentimes gave up making these changes because they wouldnt fit on master
<dftxbs3e>I was focused on shipping code to actual users
<lfam>In what way do these changes not fit on master?
<dftxbs3e>e.g. I would patch master package without updating core-updates with the pristine version potentially breaking dependents
<dftxbs3e>lfam, cause too many rebuilds
<dftxbs3e>on security issues specially]
<lfam>Yeah, if it's over 1800 rebuilds, it goes to core-updates: https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
<lfam>For security issues, we can usually use grafts to deploy the changes quickly
<dftxbs3e>lfam, yes but graft can't be incompatible?
<lfam>Right, it's tricky
<lfam>It's why patches from upstream are still useful
<dftxbs3e>lfam, how many rebuilds mandate a graft for security issues?
<dftxbs3e>if it rebuilds 80 packages, the security patch, is that OK?
<lfam>The guidelines are in that manual chapter I keep linking to
<lfam>For more than 300 rebuilds, we need to use a graft
<dftxbs3e>lfam, I don't think it's there, it doesnt speak of security updates or grafts AFAICT
<lfam>Please read section 8
<lfam>I mean, it's useful info and committers should have read the entire thing
<dftxbs3e>I had already read it like since months, okay so 80 packages is fine
<lfam>Yeah
<lfam>So, for security issues, if the change causes more 300 rebuilds, we need to try using a graft
<lfam>It's not always possible, and then we have to decide what to do
<lfam>If necessary, I think we could rebuild the world in a few days, at least for x86_64
<lfam>But, I can't remember the last time we did that. It's been a few years, at least, if we ever did
<dftxbs3e>lfam, look: https://ci.guix.gnu.org/eval/133270
<lfam>What do you think about it?
<dftxbs3e>lfam, well it rebuilds lots of stuff, I still pushed it to master, it was less than 300 but still quite big
<lfam>Yeah, it was the right choice, in my opinion
<dftxbs3e>OK great!
<dftxbs3e>The information about failing packages introduced by specific commits is still unclear in ci.guix.gnu.org
<lfam>We use the number of rebuilds to make these judgements. It's not perfect. It could rebuild 299 Go packages, which are really cheap to build. Or it could rebuild 299 gigantic C++ packages, which might take a week. But either way, we say it's okay.
<rekado>dftxbs3e: we don’t know if the change caused the failure or if the package was broken before
<dftxbs3e>The information is there but you need to go through many pages to actually check, it could highly the ones that newly failed?
<lfam>You could also push 10 commits that each rebuild 299 different packages, and that would still be considered okay
<rekado>that would be good info to keep track of
<dftxbs3e>rekado, well it does know now, it has icons
<lfam>It's not perfect, but it's the guidelines that we have, and they work fine in practice
<rekado>dftxbs3e: ah, that’s what the red dot means, eh?
<lfam>I should say, those are the guidelines we have, not "it's the guidelines we have"
<dftxbs3e>rekado, upward green arrow means it newly builds, upward red arrow means it newly fails, circles mean nothing changed
<dftxbs3e>rekado, yes!
<rekado>good good
<dftxbs3e>rekado, I wish the important information was available more clearly, like all new success and fails should be all available in line of sight when visiting each evaluation
<rekado>here a graph view would also be nice
<lfam>Yes, that would be great dftxbs3e
<rekado>I don’t understand the failure for imp
<lfam>I recommend suggesting it to mothacehe. They are working on ci.guix.gnu.org these days
<rekado>here’s the log: https://ci.guix.gnu.org/build/366192/log/raw
<lfam>And the graph, too
<dftxbs3e>lfam, they arent here but will email
<lfam>Yeah, the logs are kind of confusing these days rekado. It's like they show all the output of `guix build foo` instead of just the log for building foo
<rekado>ah, the build for vtk failed
<lfam>I think this logging issue has been discussed but it would be good to bring it up again
<lfam>VTK is totally broken, and no fix in sight :/
<lfam>Let me find the references
<rekado>(the pagination is also confusing, always has been)
<lfam> https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00292.html
<dftxbs3e>actually I think we would be better off without pagination
<rekado>click “next” until nothing changes any more, then hit “last” and you’ll get something else entirely
<lfam>It's actually fallout from a broken graft :/
<dftxbs3e>pagination on individual evaluations I think we could get rid of
<lfam>And then, the work being done to fix VTK: <https://bugs.gnu.org/46724>
<rekado>oh, yeah, that sounds messy :-/
<lfam>We need to do some unbundling, and more than one person has said it's ahrd
<lfam>hard
<lfam>It's really a shame. We had just gotten FreeCAD working, and now this has broken it
<dftxbs3e>lfam, rekado: actually do subscribe to rss feeds, they provide that information, very useful!
<dftxbs3e>(what was fixed and what broke)
<lfam>I agree it's useful but I'm already overwhelmed by information. Personally I can't take any more :)
<rekado>nah, I’m good ;)
<rekado>I don’t even read all email
*rekado eyes the 50k unread email counter
<dftxbs3e>well I can read RSS feeds whenever I like
<dftxbs3e>I packaged quiterss, it's quite good to manage LOTS of feeds
<lfam>It's healthy to declare email bankruptcy once in a while rekado. Just mark all messages as read
<dftxbs3e>and have all info in an eye-sight
<lfam>Just like a debt jubilee, we must have email jubilees
*rekado insert “This is fine” meme here
<lfam>And they may be the only type available to us
<rekado>hmm: failed to deploy hydra-guix-128: aborting reconfiguration because commit 2cc169f8f91dd76ec86317e8c868b9183c19b2d9 of channel 'guix' is not a descendant of 14c3c3eec2cdd9359964a0bd5e77654ec10bcc98
*rekado –> zzz
<lfam>For the logs: That 14c3c3ee commit is not part of guix.git
<lfam>So, I suppose that system diverged from Guix, with some local changes. One will need to use --allow-downgrades to get back on track
<dftxbs3e>RSS feeds also tells us with new system tests fail
<dftxbs3e>it's just amazing!!
<dftxbs3e>lots of system tests are currently broken
<dftxbs3e>tor, unattended-upgrade, .. broken
<bdju>ripgrep build failed earlier. http://ix.io/2RAR
<lfam>The systems tests need love
<lfam>They use a lot of resources so people don't run them routinely
<lfam>I do use them but I have to use a powerful server
<lfam>I'm wondering, is there an unattended-upgrades system test?
<dftxbs3e>lfam, updates-services ?
<lfam>I'm having trouble finding it
<dftxbs3e>upgrade-services *
<lfam>Ah
<dftxbs3e>lfam, maybe it's unrelated
<dftxbs3e>I may have taken this for unattended-upgrade by mistake
<lfam>I think it could be considered a feature of unattended-upgrades
<dftxbs3e>also I think Cuirass should as much as possible provide a command to reproduce results of things
<dftxbs3e>with time-machine now it should be easy
<lfam>I notice a new computer based on Cortex-A17 CPUs. That is the fastest armhf CPU available. If we wanted to build armhf natively we could try running a dozen of them
<lfam> https://www.cnx-software.com/2021/03/03/geniatech-xpi-3288-raspberry-pi-lookalike-features-rockchip-rk3288-soc/
<vagrantc>i've got a few rk3288 systems ... they're ... kind of not too slow :)
<lfam>Heh
<lfam>armhf only gets so fast
<vagrantc>but none of them have any real i/o interfaces
<lfam>Yeah :/
<vagrantc>some have 4GB of ram ... which isn't a lot, but also isn't nothing
<lfam>There *are* good SD cards that can be used the way we need them to be used. They are really expensive
<lfam>One needs to look for cards that are used to shoot 4K video
<dftxbs3e>how do we re-run this exactly? https://ci.guix.gnu.org/build/365743/details
<dftxbs3e>Cuirass could tell
<vagrantc>lfam: only 2GB of ram on those you linked to ... i wouldn't recommend it
<lfam>Basically, an administrator needs to run it again
<lfam>vagrantc: Yeah, good point. 4 GB should be the minimum
<vagrantc>lfam: the firefly-rk3288 had a 4GB model... not sure if they're still available
<vagrantc>i used one with USB->sata adapters
<vagrantc>lfam: it's even supported in guix already ... although been a long time since i tested it
<lfam>It's in stock in their shop
<lfam>They also have a "reloaded" version. I guess they refined some things
<lfam>I still think it would be best to have one very powerful computer than a bunch of these little things. It's always been difficult for us to coordinate access to them and keep them running smoothly
<vagrantc>indeed
<vagrantc>speaking from experience maintaining a farm of ~20 arm boards ... and having those all in one place ... still a pain
*vagrantc eyes up the honeycomb lx2 ...
<lfam>They just announced this: https://www.solid-run.com/articles/honeycomb-lx2-server/
<vagrantc>yeah, but apparently it's really just a case for two boards :)
<lfam>Well yeah :)
<lfam>And I'm not sure we are going to be able to rackmount any ARM hardware
<vagrantc>better off with a taller machine with more room for a better fan
<pkill9>I just thought, would using guix deploy to a raspberry pi be computationally quicker than reconfiguring on the device itself?
<vagrantc>interesting question :)
<pkill9>yea, cos my guess is it practically just sends all the builds over
<pkill9>and the machine doing the deploying does all the computing
<pkill9>i would hope
<lfam>It sort of depends, I'd guess
<lfam>The pi4 is a quad-core A72, so not extremely slow
<lfam>But you'd want a fan on it if you were going to use it to build
<lfam>Emulated aarch64 on x86_64 is really slow on our build farm, and we have some very powerful servers there
<lfam>Maybe there is a faster way to do the emulation
<vagrantc>yay. i can remove the 'skip-dex-test-with-missing-procyon phase from the next diffoscope upload... pushed the fix upstream.
<lfam>I am getting "Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'show-type-column'" again, from Audacity
<dftxbs3e>nckx, you were right it doesnt scrap from upstream, would be nice though, but also Debian's uscan watch infrastructure already does this
*RaghavGururajan[ whistles
<RaghavGururajan[>Hello Guix!
<RaghavGururajan[> * Hello Guix!!
<raghavgururajan>Hey
***RaghavGururajan[ is now known as Gururajan[m]
<Gururajan[m]>?
<lfam>Gah this audacity issue is too annoying
<dftxbs3e>raghavgururajan, o_O was that you or
<nckx>Apparently not.
***nckx sets mode: +q *!club.cyber@*
<nckx>That's not what I typed, Freenode.
***nckx sets mode: +q *!club.*@*
***nckx sets mode: -q *!club.cyber@*
<lfam>Hmph
<nckx>Weird, it dropped the ‘a* both times’.
<raghavgururajan>dftxbs3e: Unfortunately no.
<lfam>There are a lot packages that cherry-pick the glib-or-gtk-wrap phase
<lfam>I wonder if it should be its own thing
*nckx was literally headed for bed, so... hold the fort kidz.
<raghavgururajan>Night nckx o/
<dftxbs3e>Good night! :-D
<nckx>Don't let mister-farts-in-the-blanket-fort in! o/
<raghavgururajan>What if someone had same name as me and tried to join #guix, without any ill intention?
<dftxbs3e>raghavgururajan, could be but quite unlikely
<raghavgururajan>Hmm. I still see RaghavGururajan[ and Gururajan[m] in the participants list.
<raghavgururajan>Ah gone now.
***aidalgol_ is now known as aidalgol
<kozo[m]>Hello, are there any common lispers around? I would like some help figuring out workflow
<kozo[m]>I see in guix that there are packages for what also is a (ql:quickload) call for me when I'm writing lisp. For instance, I installed cl-csv as a system package for guix but I was not able to access it in my emacs + slime buffers
<gnutec>Hey there! Ubuntu has no more net-tools installed in the system. It's only iproute2 and Network Manager. https://www.xmodulo.com/linux-tcpip-networking-net-tools-iproute2.html
<gnutec>kozo, I don't got it. Are you trying to writing in lisp? There is a emacs lisp.
<gnutec>kozo[m], I don't got it. Are you trying to writing in lisp? There is a
<gnutec> emacs lisp.
<kozo[m]>I'm wondering why someone built a system package for different common lisp libraries if once installed, can not be accessed.
<kozo[m]>It's obviously I don't know how to access them
<gnutec>kozo[m], Ha! Do you mean use something like (use-modules) of foreign library?
<kozo[m]>Similar. Normally when I write common lisp, I use (ql:quickload :cl-csv) to bring a library into my buffers. I see the same library exists at a system package. It would be neat if I could just have them installed and not have to quickload them all the time.
<kozo[m]> * Similar. Normally when I write common lisp, I use (ql:quickload :cl-csv) to bring a library into my buffers. I see the same library exists as a system package. It would be neat if I could just have them installed and not have to quickload them all the time.
<gnutec>kozo[m], I don't know. :-(
<aidalgol>Following the cookbook's 'virtualenv' analogy, what would be the guix equivalent of the 'requirements.txt' file?
<dftxbs3e>aidalgol, all *inputs fields?
<dftxbs3e>and the package definitions they point to, and so on
<aidalgol>What would I actually check into my project's source control? An exported manifest file?
<dftxbs3e>aidalgol, ohh, yes, you could start with that, then write a package definition for your own package
<dftxbs3e>aidalgol, look at this for example: https://github.com/freebayes/freebayes/blob/master/guix.scm
<bavier[m]>oh no, I'm in a rabbit-hole while upgrading our `onionshare` package, and have arrived at a dependency on "python-certifi", which is a python package bundling the Mozilla CA certs. That seems shaky to me.
<dftxbs3e>bavier[m], onionshare doesnt require it directly correct?
<dftxbs3e>bavier[m], it's python-requests
<bavier[m]>probably best to do like debian here: https://packages.debian.org/buster/python3-certifi
<dftxbs3e>bavier[m], but we actually do not have any "GNU Guix CA"
<dftxbs3e>GNU Guix CA certificates bundle *
<bavier[m]>dftxbs3e: right, it's a downstream dependency.
<dftxbs3e>bavier[m], I'm not sure we should do anything here, create a post on guix-devel though
<dftxbs3e>or open a bug
<aidalgol>dftxbs3e: Sounds like 'guix environment' is what I want.
<dftxbs3e>aidalgol, sorry not sure what you were asking
<bavier[m]>dftxbs3e: right, no Guix CA, but I think we can at least make it respect system and env vars like in the manual's "X.509 Certificates" section.
<bavier[m]>but yes, this is the sort of thing that would definitely prompt me to send to guix-patches
<aidalgol>dftxbs3e: I'm trying to figure out how to use guix to create a reproducible, isolated environment for my software development, instead of hacks with docker containers.
<dftxbs3e>aidalgol, yes that is a very good idea! What's not clear to you yet?
<aidalgol>dftxbs3e: How to declare my project's dependencies in a file for others to use (or for myself to rebuild the environment).
<ryanprior>aidalgol: here's an example of how I'm doing it in one of my projects: https://github.com/ryanprior/authasaurus/blob/master/requirements.scm
<ryanprior>I'm also working on migrating dev environments from Docker to Guix.
<ryanprior>You can enter an isolated container with that project's source code and its dependencies using `guix environment -C -m requirements.scm` in the project root directory
<aidalgol>Awesome!
<aidalgol>Don't you want to specify an exact version, though?
<aidalgol>If one of the packages in my requirements.scm file is a daemon that is normally run as a system service, like postgres, where do its files go?
<ryanprior>At some point I may want to lock those down to a specific version. You can do that with a matching channels.scm file.
<ryanprior>If you need a daemon, then you'll need more than just a manifest of packages. You'll also need a system definition with a service for the daemon. I'm still a newbie at setting those up, I've been slowly reading and seeing how other people do it.
<ryanprior>That's an area with a large increase in complexity though. It's felt sometimes like death by a thousand embedded DSLs.
<muradm>installing openjdk11 does not expose javac, why? for example (packages->manifest (list openjdk11))
<muradm>then which javac: not found
<muradm>currently workaround it by finding openjdk11-jdk in store and putting it to $PATH
<muradm>in gnu/packages/java.scm i something like ("openjdk11:jdk" ,openjdk11 "jdk") in native inputs to openjdk12
<rekado_>turns out that “guix deploy” doesn’t like it when the target system was built with a more recent Guix than the host system.
<rekado_>that commit was in fact a commit in guix.git, but the host system running “guix deploy” had a slightly older Guix
<aidalgol>ryanprior: Seems less fraught than docker, though.
<civodul>Hello Guix!
<mothacehe>hey civodul!
<aidalgol>How do you run services within a profile (as a normal user)?
<civodul>aidalgol: hi! currently there's nothing like "user systemd", but what you can do is install and run shepherd as a normal user
<civodul>howdy mothacehe!
<civodul>how's that FFI crash quest? :-)
<mothacehe>hehe on hold for now, I already spent an unreasonable amount of time on it :p But I'll resume it :)
<aidalgol>civodul: I suppose I should have s/services/daemons/ in my last message. :P
<civodul>yup
<civodul>mothacehe: heh, i know that feeling!
***apteryx_ is now known as apteryx
<aidalgol>I have a software project that uses docker to run postgresql isolated form the host system like this <https://paste.debian.net/1187783/>, and I am trying to migrate to guix, because it's intended purpose is closer to my needs than docker.
<rekado_>sneek: later tell muradm Do “guix install openjdk:jdk” to install the “jdk” output of the “openjdk” package.
<sneek>Okay.
<aidalgol>But it sounds like guix does only half of this (reproducible installation of packages).
<rekado_>aidalgol: you can build system containers with Guix, but without a system you won’t be able to run system services.
<aidalgol>rekado_: Is that even what I want here, though?
<rekado_>I don’t know
<rekado_>you can of course run postgresql manually, but why bother?
<aidalgol>Also, what's a system container, in this context?
***amfl_ is now known as amfl
<aidalgol>Uh, I should also mention that I am running guix on a foreign distro (Debian).
<rekado_>“guix system container”
<rekado_>(that’s a command)
<rekado_>it’s okay to use Guix on Debian; you can still use most of the “guix system” commands
<civodul>there's also "guix system docker-image"
<davidl>a word of warning here: I used that on a Debian machine, and execed into the container and ran guix pull and it broke my host system.
<cybersyn>hiya guix
<civodul>davidl: oh, interesting; how did it break?
<civodul>maybe there's a bug report?
<davidl>civodul: I wrote a bug report about it. let me check.
<davidl>yes
<civodul>at first sight i don't see how running "guix pull" in the container could break the host
<cybersyn>sorry i haven't got around to the UX/Community Experience research yet as discussed at guix day, after the lunar new year I got hired for a last minute job thats had my hands full, but i'll be getting shooting the mailing list a little presentation at the end of next week
<aidalgol>Do I understand this correctly? 'guix system' lets you run an instance of GuixOS inside a container/vm/other?
<civodul>cybersyn: great, thanks for the update!
<civodul>aidalgol: it's the entry point for "all things system": https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html
<aidalgol>I'm reading that info node now. :P
<civodul>cool :-)
<davidl>civodul: #45599
<aidalgol>I don't fully understand it, unfortunately...
<aidalgol>rekado_: Were you suggesting I run everything for my project in a system container?
<rekado_>I don’t know your project well enough to suggest that. But if you want to run postgresql separately from your host system I’d suggest using “guix system” for that, so that you can use the existing service definitions.
<aidalgol>The project is a Phoenix web application, if that helps, but that sounds like what I want.
***Lightsword_ is now known as Lightsword
***bkv is now known as bqv
<aidalgol>How do I go about writing an "'operating-system' declaration?"
<rekado_>aidalgol: perhaps it’s best to start from an example.
<mdevos>aidalgol: I would look at the examples in gnu/system/examples/*.tmpl
<mdevos>alternatively, there probably are exampels in the manual
<rekado_>yes, in the cookbook
<aidalgol>Where is that "gnu" directory located?
<aidalgol>Once I get this working for me, I think I will have a recipe to contribute to the cookbook.
<mdevos>aidalgol: in the source code: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples?h=wip-digests&id=e43958af2764d56de4cd883134a6889b9b61a8f2
<aidalgol>Ah, I just did a binary install.
<aidalgol>How does guix "run" a docker container? It does not appear to be using docker itself.
<mdevos>Could you run "EDITOR=echo guix edit hello"? At least if you ran "guix pull" at least once, I think you will see a copy of guix source code
<aidalgol>I have run 'guix pull', and that command gives me /gnu/store/930411vbppz046kfgh1zbcc02wa7axp1-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm
<mdevos>Trim off "packages/bases.scm", and you have the location of the gnu dircetory
<aidalgol>Excellent!
<aidalgol>Hmm... there's no "system" or "examples" directory in there
<mdevos>On my system, I have /gnu/store/grkrnr7vlrk8xabjphhkl35c2d0la6kz-guix-module-union/share/guile/site/3.0/gnu/system/examples/vm-image.tmpl?
<aidalgol>OK, I am dumb... I was viewing it in dired, and because they're symlinks, my wetware filtered them out as regular files...
<rekado_>aidalgol: if you use “guix system docker-image” it will generate a Docker image that you can load up with Docker to run it. The other container method uses the kernel interface directly.
<civodul>davidl: oh thanks, looking into the bug
<aidalgol>rekado_: Ah, got it
***nckx sets mode: -q *!club.*@*
***ChanServ sets mode: +q *!club.*@*
<rekado_>I see this on one of the build nodes: [ 14.207710] shepherd[541]: segfault at 7f4d9d5c3b48 ip 00007f3d9dba3044 sp 00007f3d9ad7ad18 error 6 in libgc.so.1.4.3[7f3d9dba2000+1b000]
<rekado_>shepherd segfault right after booting
<rekado_>(and then kernel panic, of course)
<rekado_>does this sound familiar at all?
<rekado_>this is with linux 5.9.14-gnu
<rekado_>(old kernel because this node was offline for a long time)
<rekado_>5.4.102 is the long term kernel
<rekado_>according to kernel.org
<rekado_>oh, sorry, wrong window
<cybersyn>just saw the news about bootstrapped OCaml, great work!
<fnstudio>hi, i've created an ad-hoc env containing python-numpy, then i started a org-mode/org-babel file in emacs; the file contains a numpy snippet but if i C-c C-c it, it fails to import numpy
<fnstudio>it throws a "ModuleNotFoundError: No module named 'numpy'"
<fnstudio>i eval'ed this "(setq org-babel-python-command "~/.guix-profile/bin/python")" but it didn't help
<fnstudio>this may belong to emacs or emacs-org more than it does here
<fnstudio>* #emacs or #org-mode, i meant
<rekado_>booted an older kernel (5.4.55-gnu), and got a different kernel oops, again related to memory (BUG: unable to handle page fault for address: 0000000fa2774528); I’m suspecting a hardware problem.
<rekado_>fnstudio: you need not just the python command but also environment variables.
<fnstudio>rekado_: oh... i see
<rekado_>I don’t know enough about babel, but I think you can add a snippet that’s evaluated before others, containing this:
<rekado_>GUIX_PROFILE=$HOME/.guix-profile
<rekado_>source $GUIX_PROFILE/etc/profile
<rekado_>then you’d have all env vars you need for the remaining snippets
<fnstudio>as a bash snippet i suppose
<fnstudio>rekado_: thanks so much, let me try that straightaway!
<rekado_>yes, a bash snippet
<rekado_>I don’t know how to tell babel to eval the snippets in the same context so that the variables are set throughout
<fnstudio>yes, i'm experimenting, i'm sure this has put me on the right track already
<fnstudio>brilliant
<divansantana>how can I go about installing an older emacs like 26.3 on guix system? I'm trying guix time-machine --commit=f0e810110bf44b6c5c61bf0cdcadc836a7fd459d -- package -i emacs but it's failing
<divansantana>And various other commits pre 27.1 are failing with diff errors.
<fnstudio>rekado_: ok, simply sourcing ls -lhG --time-style long-iso
<fnstudio>rekado_: ooops sorry
<fnstudio>i was saying, simply sourcing $GUIX_PROFILE/etc/profile won't set the PYTHONPATH as it is in the guix environment
<fnstudio>but that made me think that i could start the guix environment from within emacs, in the same bash snippet in addition (or simply alternative?) to sourcing the profile
<fnstudio>hm... that does seem to set the env variable correctly within emacs, but it still doesn't work
<fnstudio>"echo PYTHONPATH" in a shell block returns what you'd expect
<fnstudio>*echo $PYTHONPATH :)
<fnstudio>but "import some-library" in a python block still returns a module-not-found error...
<fnstudio>of course some-library is in the guix env and things work fine from outside emacs / org-babel
<fnstudio>but the idea of launching guix env as part of org-babel seems legit
<rekado_>fnstudio: I was thinking you could use “:session” or “:prologue” for that, but it seems that these are only for source blocks of the same language type
<rekado_>sourcing the etc/profile file *should* set PYTHONPATH as long as you have python itself in the profile
<rekado_>when in doubt: check the contents of the file.
<rekado_>(oh, I should have read on…)
<rekado_>yeah, so the problem appears to be that the Python process is spawned from outside of the shell environment where PYTHONPATH is set
<rekado_>here’s a silly idea: Guile has “guile --listen”, which spawns a REPL that I can connect to over the network
<rekado_>does Python allow you to launch its REPL and connect to it?
<rekado_>because then you could do the shell setup in one snippet (source’ing etc/profile *and* launching a Python process inside that new environment) and have the other Python snippets *connect* to that Python process
<rekado_>maybe I’m over or under-thinking things…
<fnstudio>rekado_: no no, that's absolutely useful, i'll do some experiments and revert :) thanks for now
***roptat is now known as roptat_
<civodul>it should be possible to spawn guix env from org-mode and use :session so that subsequent snippets run in that environment, no?
***roptat_ is now known as roptat
<fnstudio>civodul: let me try with :session
<fnstudio>civodul: thanks! that did something, i think i'm past the initial problem now
<fnstudio>i still have some minor issues apparently, i'm sorting out a minimum (non-)working example to see where the problem is
<fnstudio>but yeah i should have found :session by looking at the docs
<civodul>cool!
<fnstudio>i must have messed something up... outside emacs, in my terminal, if i run "guix environment --ad-hoc python-requests" and then launch a python repl and then import requests, i get a module not found error
<fnstudio>(just checking: i suppose it's fine to have multiple guix environments launched in different terminals, isn't it?)
<nckx>Morning Guix.
<nckx>fnstudio: Yes.
<nckx>guix environment --ad-hoc python-requests python-wrapper -- python -c 'import requests' works here
<fnstudio>nckx: yes, it did here too but i'm not sure what's happening now (i'm on a foreign distro though and was experimenting with emacs and org-babel...)
<edgarvincent>Hi all!
<nckx>Oy, ‘did’, that's not good.
<fnstudio>or maybe it's the python-wrapper bit that i was omitting?
*fnstudio investigating
<nckx>I was just going to ask: make sure that you're using python3.
<fnstudio>(but i'm totally in love with the power of guix + org-babel, it feels so exciting!)
<nckx>(Python-wrapper == python3 + ‘python’ compatibility link, in case you didn't already know.)
<edgarvincent>I'm trying to install the guix system. After files have been copied to /mnt, the installer fails with the following error: "/remove" "Device or ressource busy". Is there anything I can do?
<nckx>Hi edgarvincent.
<nckx>(I can only welcome you, not be of help with the installer.)
<nckx>edgarvincent: Are you using the graphical installer? Is it really an error, with no way to continue?
<edgarvincent>nckx: That's fine. Thanks for welcoming me :)
<edgarvincent>I'm using the graphical installer. I can't select "OK" at the end of the error dialog but I can access a TTY.
<nckx>And the error is literally "/remove" "Device or ressource busy"? I'm just puzzled 'bout where that ‘/remove’ is coming from...
<nckx>I don't even know if the installer logs more info to a file. It might log to tty12 or so.
<fnstudio>edgarvincent: maybe the working dir of one of the TTYs is in the removable media?
<nckx>edgarvincent: Did you do anything in a tty while the installation was running?
<edgar-vincent2>[still me from the TTY, with the wrong keyboard layout...]
<edgar-vincent2>I was simply reading the docs [C-M-F2]
<nckx>Hm, that's obviously fine. (Mine's basically the same question as fnstudio's: if you chdir'd into /mnt while the installation was running, it won't be able to be unmounted.)
<edgar-vincent2>Definitely not. I hadn't realised I could open a console before the error occurred.
<nckx>Is it possible to share a screenshot of the error message?
<nckx>A literal (legible) photo is fine too
*nckx feels stupid for adding legible but it's happened...
<edgarvincent>Sure.
<fnstudio>here's a minimum non-working example of my emacs + org-babel + guix attempt https://paste.debian.net/1187844/
<rekado_>divansantana: this works for me: guix time-machine --commit=7ab5c4e0e861cfe979591e1ffab9c6e9f26caa6b -- build emacs-minimal
<edgarvincent> https://lutim.lagout.org/zXmENQbr/OH3buPiG.jpg
<edgarvincent> https://lutim.lagout.org/37aiLhNV/xZI6wnEL.jpg
<edgar-vincent2>Could it be caused by the EFI?
<nckx> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/install.scm#n265
<nckx>edgar-vincent2: I don't see how it could be.
<nckx>Could you run ‘sudo lsof | grep /remove’ in a TTY?
<nckx>‘guix install lsof’ first if it's not included by default.
<edgarvincent>No output.
<nckx>Meh.
<nckx>edgarvincent: I'm not able to debug a past installer error remotely I'm afraid.
<nckx>But this is the clean-up path failing, and your installed system should be complete.
<nckx>Reboot & see.
<edgarvincent>I have logs in TTY12
<edgarvincent>Hmm, /remove is not mounted.
<edgarvincent>I'll do as you say and reboot
<nckx>Can you rmdir /remove?
<edgarvincent>Whoops, too late, sorry.
<nckx>No problem, it was poking at a dead body.
<edgarvincent>It's asked my LUKS passphrase, so some of it is working.
<nckx>edgarvincent: Are those image URLs stable? I'd like to forward them to bug-guix@.
<edgarvincent>Only for 30 days I think :(
<edgarvincent>I should have saved the logs.
<divansantana>rekado_: thanks, it's working now.
<edgarvincent>Well it's not booting, so I'll reinstall the whole thing anyway.
<edgarvincent>Meanwhile, thanks for your help!
<nckx>edgarvincent: What does it say?
<edgarvincent>I enter my passphrase and then nothing happens.
<edgarvincent>I know it's the right one (although the keymap is wrong) because it fails when it isn't.
<nckx>:(
<edgarvincent>I'll try again.
<nckx>edgarvincent: Would you have time to report the /remove bug to bug-guix@? That way you'll receive replies. I've hosted the screenshots at https://www.tobias.gr/removebug/ if you don't want to do so yourself.
<edgarvincent>Sure! Thanks.
<edgarvincent>Also, the installer ignore the layout I set with F1.
<edgarvincent>Ignores*
<nckx>How can I test the installer? ‘qemu-system-x86_64 -M q35 -accel kvm -cpu host -cdrom /tmp/guix.iso’ boots GRUB fine but the kernel panics (/initrd.image: incomplete write).
<nckx>guix.iso being http://guix.gnu.org/en/download/latest/.
<civodul>nckx: i think you need "-m 1024" or so
<nckx>Ha.
<civodul>the default is 128M of RAM or something
<civodul>(which "should be enough for everyone", but hey)
*nckx gives it 4G.
<nckx>128M isn't that much for a crazy initrd with Guile!
<nckx>Yep, that worked, thank you civperson.
<civodul>yw!
<edgarvincent>I'm surprised HPLIP is available in guix.
<edgarvincent>(and that my Thunderbolt dock works without blobs)
<nckx>Our hplip package is freedom-okidokey.
<nckx>We remove/omit some blobs.
***efraim_ is now known as efraim
<edgarvincent>OK :)
<nckx>edgarvincent: I can't reproduce the keymap bug; I select Belgian and can type ‘azerty’ with amazing speed. I didn't use ‘F1’ though...
<edgarvincent>Do you also disable hp-plugin?
<edgarvincent>Oh, so you just selected the keymap from the installer dialog?
<nckx>From its ‘natural’ order in the wizard, but even if I go back (pressing F1 at the hostname dialogue) and select something crazy like German it works.
<edgarvincent>hahaha
<nckx>edgarvincent: Isn't that shipped separately from hplip? We do disable the ImageProcessor.
<edgarvincent>OK, weird. That's the 1.2.0 right?
*mdevos wonders if someone has a working Guix System + CUPS + HP printer setup, but must be leaving now
<edgarvincent>Not on other, nonfree distros.
<nckx>mdevos: ...yes? (Why is that even a question?)
<edgarvincent>I'll check if I ever get a working laptop again.
<edgarvincent>(And since printers is where it all started from, it's a delicate matter ^^)
<nckx>edgarvincent: ‘The 1.2.0’? Our hplip is 3.20.11, but you're probably referring to something else.
<mdevos>(correction, Brother printer)
<nckx>Oh, Guix has versions.
<nckx>Riiigth.
<edgarvincent>Sorry I meant the installer :)
<nckx>mdevos: I've also used a Brother printer, once or so, it wasn't mine.
<nckx>edgarvincent: It's http://guix.gnu.org/en/download/latest/ (at or close to current master), I'll try 1.2.0.
<nckx>Personally, I don't recommend using the ‘stable’ release unless latest gives you trouble.
<edgarvincent>Yeah, I'll use latest. Thanks for the pointer
<nckx>edgarvincent: Yes, printers are still Satan's representation on earth.
<edgarvincent>They are.
<nckx>My arrow keys stopped working the the 1.2.0 VM :-/
<nckx>...and now they magically do. Still no bug: I select programmer Dvorak, fill in some stuff, at the first partitioning window press F1, go back to keyboard layout selection, choose German, type ‘qwertz’ at the hostname prompt.
<nckx>However, from listening to past reports (like yours earlier) there are plenty of installer bugs that query the state of the moon, so I believe you.
<apteryx>Autoconf's manual defines a system type as 'CPU-COMPANY-SYSTEM', where system can be either 'os' or 'kernel-os'. In practice it seems we use 'arch-kernel-os', no?
<edgarvincent>hahaha
<edgarvincent>We'll see if I can reproduce the bug with the development version. Downloading right now.
<nckx>apteryx: The vendor (‘unknown’ in our case) field is optional, yes.
<nckx>edgarvincent: If you could note the exact point at which you go back to the layout selection a second time, I'll try it again.
<edgarvincent>I did it after typing a few characters in the 'hostname' field.
<roptat>apteryx, maybe read the note here: http://linuxfromscratch.org/lfs/view/stable/partintro/toolchaintechnotes.html#lfs-cross :)
<edgarvincent>(I use a French USB keyboard BTW)
<civodul>apteryx: yeah the vendor part has become useless
<civodul>it could make sense when compiling a kernel for an ARM board, say, but it's not actually used that way
<nckx>edgarvincent: And it's only the ‘go back with F1’ functionality that's broken?
<nckx>Or layouts in general?
<edgarvincent>Layouts in general.
<nckx>Let me French.
<edgarvincent>Whether I select "French" with F1 or from the wizard, the layout remains Qwerty.
<edgarvincent>I used French/French
<apteryx>civodul: ah, the definitive answer to my question as pointed by the Autoconf manual lies is config.sub ($(guix build config)/bin/config.sub) -> it does some heuristic below the comment "Ambiguous whether COMPANY is present, or skipped and KERNEL-OS is two parts"
<apteryx>civodul: thanks
<civodul>oh i see
<rekado_>sneek: later tell mdevos I’m using a Brother laser printer and it works well with my Guix Systems.
<sneek>Will do.
<rekado_>sneek: botsnack!
<sneek>:)
<edgarvincent>Same problem with the latest installer.
*nckx ne peut pas se reproduire.
<roptat>nckx, sorry to hear that ^^'
<edgarvincent>Se reproduire ? Haha
<roptat>in case you didn't know, "se reproduire" means "procreate"
<nckx>I've selected francais both as language and as layout (francais/francais) and it works.
<nckx>I know :)
<edgarvincent>I'm using EN_UK for the language, forgot to mention it.
<nckx>I don't see how it would matter, but might as well test again.
<roptat>how does the installer change keyboard layout, does that leave a trace in logs somewhere?
<nckx>edgarvincent: Interesting choice (I assume you mean en_GB, en_UK, if it existed, would be Ukranian English).
<edgarvincent>Ah! It works when my dock and external keyboard are disconnected
<nckx>😃
<nckx>Interesting.
<edgarvincent>Yes sry GB obviously haha
<roptat>so you had two keyboards connected?
<nckx>(Life hack: en_IE is en_GB with sensible units.)
<edgarvincent>So the Northern Irish are presumed to speak Irish English.
<edgarvincent>roptat: yes
<nckx>edgarvincent: Does changing the layout with the USB keyboard connected still change the layout for the built-in/AT keyboard, assuming there is one?
<nckx>s/all that/the other keyboard/.
<edgarvincent>No
<nckx>edgarvincent: <So the Northern> Not sure if joke but that is actually the case.
<nckx>Uh, huh, weird.
<edgarvincent>It's partly a joke. It's just that I know people from Northern Ireland who would never say they speak Irish English.
<nckx>edgarvincent: With the USB keyboard connected and switched to a TTY, does ‘loadkeys fr’ work and/or print anything?
<nckx>edgarvincent: Locales are... complicated. They touch on language, culture, political geography, and identity -- how could they not be. The ‘_IE’ is not just a sexy accent.
<edgarvincent>It works with loadkeys fr
<edgarvincent><nckx "edgar.vincent: Locales are... co"> Oh I very well know...
<nckx>edgarvincent: Could you (you're on fire today!) file another bug?
<edgarvincent>Sure
<edgarvincent>Let me see if the /remove bug appears with latest.
<nckx>WTF, there's an en_BE locale.
<nckx> https://icu4c-demos.unicode.org/icu-bin/locexp?d_=en&_=en_BE
<edgarvincent>Oh wow
<nckx>It's just en_IE but ‘teached’ is a word.
<edgarvincent>Should I include other logs than /var/log/debug?
*nckx AFK.
<roptat>edgarvincent, could you check the value of $KEYMAP_UPDATE?
<roptat>I think you should have one or more /tmp/kmscon-%d-keymap-update, maybe check their content too
<roptat>but I don't have the installer running, so I don't really know what I'm looking for and if whatever you see is normal or not
<mdevos>sneek: later tell rekado: could you share your guix operating-system configuration? CUPS gives me ‘No such file or directory’ errors
<sneek>mdevos, you have 2 messages!
<sneek>mdevos, nckx says: I've also used a Brother printer, once or so, it wasn't mine. (<-- with my Guix System laptop, it worked, but it was over IP[P])
<sneek>mdevos, rekado_ says: I’m using a Brother laser printer and it works well with my Guix Systems.
<sneek>Got it.
*mdevos afk
<edgarvincent>roptat: $KEYMAP_UPDATE is empty.
<roptat>actually that might be normal outside the installer screen
<roptat>forget about it, others will be better at helping you
<edgarvincent>There's a /tmp/kmscon-258-keymap-update file, but cat hangs when I try to display its content.
<edgarvincent>Np, thanks for trying :)
<roptat>oh yeah, that's a fifo
<edgarvincent><edgarvincent "There's a /tmp/kmscon-258-keymap"> Its size is 0.
<roptat>not a regular file, so that's expected
<edgarvincent>Ah ok
<roptat>sorry ^^'
<edgarvincent>Np
<rekado_>mdevos: it’s just this service: https://elephly.net/paste/1614875656.scm.html
<sneek>Welcome back rekado_, you have 1 message!
<sneek>rekado_, mdevos says: could you share your guix operating-system configuration? CUPS gives me ‘No such file or directory’ errors
<rekado_>nothing else in my config relates to CUPS.
<edgarvincent>OK, the problem is not the external keyboard, it's the dock.
<apteryx>on master, this fails: "guix build --target='armhf-linux-gnu' binutils" Is it expected? checking target system type... Invalid configuration `armhf-linux-gnu': machine `armhf-unknown' not recognized
<apteryx>looking at the logs; arm-linux-gnueabihf seems like the valid triplet to use
<civodul>apteryx: yes, arm-linux-gnueabihf is the "standard" thing
<civodul>here it's ARCH-KERNEL-OS-ABI :-)
<apteryx>eh, that's not even documented as 'something' valid ;-)
<apteryx>(in the config.sub script I pointed at earlier, which is used by Autoconf)
<nojr>I have a question: if you're using guix on a foreign distro should I be sudo -i guix pull as well as guix pull?
<roptat>nojr, it would update root's guix, which you probably don't use apart from the daemon
<nojr>roptat: guix pull suffices?
<nojr>just to clarify
<roptat>yes, it updates your user's guix
<roptat>with new packages, and new tools
<roptat>running guix pull as root would only update the daemon, but it won't affect the set of available packages or commands
<pkill9>i don't think it would update the daemon
<pkill9>that gets updated on guix system reconfigure
<nojr>I belive the manual says to use sudo -i guix pull in a foreign distro
<pkill9>oh wait
<pkill9>nvm
<nojr>but before I was just using guix pull
<pkill9>I was thinking on guix system
<civodul>apteryx: it's just that people have learn to piggyback useful info on triplets
<civodul>mips and armv7 support multiple ABIs and that has to appear somewhere
<apteryx>and this information is not useful in emulated situations? (e.g., guix build --system)
<civodul>in that case you're building natively
<civodul>and which ABI is used is determined in other ways
<civodul>via GCC configure flags, typically
<civodul>it's kind of a mess
<apteryx>I see! Thank you for the insights :-)
<apteryx>cbaines: hi! I'm testing your cross-compilation patch for guile-lib, and was expecting that 'guix build --target='arm-linux-gnueabihf' guile-lib' would fail, but it seems to build fine; any idea of how to trigger the problem the patch is designed to solve?
<cbaines>apteryx, the package doesn't fail to build, it fails to cross-compile without that patch
<cbaines>specifically, Guile for the target architecture won't like the .go files
<apteryx>OK, so perhaps if I use 'file' on one of the compiled .go files I'd see if everything is OK
*apteryx checks
<apteryx>it's strange, shouldn't byte compiled code such as Guile's .go be the same on any achitecture?
<apteryx>apparently it can optimize for a system; the help of guild compile says about the --target option you used '-T, --target=TRIPLET produce bytecode for host TRIPLET'
<cbaines>I don't know, but it seems that the .go files are architecture specific
<cbaines>I also see things like "ELF 64-bit" in the file output, so I wonder if that changes depending on whether you're targeting a 32 or 64 bit architecture
<edgarvincent>Can't reproduce the /remove bug on latest, which is good :)
<bdju>trying to update everything but the failing ripgrep is not working. other related stuff like emacs-rg and emacs-magit keeps erroring now
<bdju>maybe my command syntax is wrong
<bdju>`guix package --upgrade . --do-not-upgrade ripgrep emacs-rg emacs-evil-magit emacs-guix emacs-magit`
<leoprikler>rip grep :(
***achow101_ is now known as achow101
<apteryx>is it possible to spawn 'guix environment' in a way to make cross-compiling possible?
<apteryx>seems like no
<pinoaffe>apteryx: there seem to be a couple of cross-compiling toolchains packaged, you should be able to use those in a guix environment
<pinoaffe>(can't say I've tried tho)
<pinoaffe>but there's no generic way to get a crosscompiling environment for a given architecture afaik
<apteryx>I'm a bit confused; I'm trying to cross-compile guile-lib, looking at this patch: https://issues.guix.gnu.org/46725
<apteryx>so at build time it needs the native Guile of the build machine; but for running the test suite for example it needs the Guile of the target machine
<apteryx>there's still useful comment in (guix build gnu-build-system): "When cross building, $PATH must refer only to native (host) inputs since target inputs are not executable."
<apteryx>the only other thing guix would do differently when cross-compiling that package would be to pass --host=$target to the configure script. Hence, I should be able to do 'guix environment --ad-hoc $native-inputs-of-package' then ./configure --target=$target and it should work the same for this case
<shcv>bdju: I did another pull and upgrade today, and ripgrep seems to be working now
<apteryx>unrip'd!
<edgarvincent>I'm curious: why does one need to install sddm to use GNOME Wayland?
<pkill9>cos it supports wayland, otherwise idk
<bdju>shcv: oh, sweet. you're right. thanks
<edgarvincent>GDM doesn't?
<apteryx>ah, there's another subtlety to cross-compiling; native-inputs wouldn't find their way in the search paths defined
<divansantana>How does one boot into say single user mode? Or some sort of rescue mode
<divansantana>Suppose i could boot an iso and try chroot in
<shcv>the grub menu for GuixSD has alternative boot options to load any of your previous system configurations
<shcv>so you can just go back to the last one that worked
<divansantana>Ive got k autologin setup and mistake in xinitrc is causing it to crash loop quickly. X
<divansantana>shcv: that wont work because my xinitrc config is in git, not guix unfortunately
<shcv>if the problem is after login, you can just use Ctrl+Alt+F{1-6} to go to a console
<shcv>I recommend F2-F6, because 1 has all of the boot logs and service event streams
<divansantana>No because when x starts up in switches to the display. And its very quick. Not enough time to switch to tty and type
<divansantana>it*
<divansantana>Fast x crash loop. Quite a mess.
<shcv>so the problem happens immediately upon loading your session manager? Or do you not use one?
<divansantana>I think i use slim with autologin. Which reads my .xinitrc so on boot it goes into a fast x loop where switching out of it is impossible
<divansantana>If only a key binding would kill X for good
<divansantana>Or init=/bin/bash on another linux would help
<shcv>you could see if there's a recovery boot option, though I don't remember one. There's also a message during boot about an early-boot guile repl or something, maybe you could catch it at that phase of boot
<shcv>or just boot a live usb and then mount + edit; chroot shouldn't be necessary
<divansantana>Mount plus edit minus chroot. True. Let me flash an iso. Thanks!
<divansantana>I dont know much about boot repl etc. Seems would be useful
<divansantana>I guess must be a way to boot a rescue mode of sorts with shepherd
<shcv>I haven't tried it myself; I've always had old systems that worked which I could fall back on
<divansantana>Some rescue mode from the boot menu would be very welcome. Im guessing there is a way to achieve a init=/bin/bash like functionality
<nckx>Not reaaally.
<nckx>There's a rescue REPL but you have to be pretty damn familiar with Guix and desperate to use it. It's not even Spartan.
<nckx>It's theoretically not impossible to mount your root fs from it, then spawn a shell, and tediously hobble your way to rescue.
<apteryx>civodul: about the qemu:static output and binfmt change; does my last reply justifies keeping it the way it is, or would you rather do what I suggested there (hard-code the F flag and revert to plain srfi-9 records?)
<dftxbs3e>civodul, I've been looking at cpe suggest code
<dftxbs3e>civodul, I rebased the patch on master, just some copyright lines issue, somehow now it doesnt suggest anything at all, trying to find out why
<dftxbs3e>civodul, It would be great to end up with an Emacs "data entry" UI that can somehow limit the work to human choices "accept (or modify before accept) or skip" and iterate on all packages that way
<paulj>nckx: update on changing my hash_alg to tea yesterday. It worked for the first file download, but I had the same error when downloading the sig file. Seems both hash algorithms will fail. I then turned off dir_index, but this caused all end of issues. I had to reboot into a sysrescue image and run fsck to fix everthing. After this, guix is working normally again. Therefore I suggest the recommendation in the handbook should be to turn
<paulj>this feature off at the start, or to use a different format (btrfs).
<dftxbs3e>civodul, so we can easily get up to speed with cpe tagging, on all packages in GNU Guix
<nckx>Ouchies.
<nckx>paulj: ‘all end of issues’ - could you elaborate?
<nckx>I have not heard this before.
<dftxbs3e>I have a question, how do you actually verify tarball authenticity corresponds to upstream with GNU Guix? Considering GNU Guix hash format is different it's a bit troublesome at times..
<paulj>nckx: basically the system was not finding anything. Even guix pull wouldn't work. I rebooted, then had page after page of errors saying that (I'm paraphrasing...) the inodes have an index flag set, but the file system isn't a indexed. It tried to fix each one, then finally gave up and gave me the rescue repl. I tried to see if I could run fsck from here (with (system "fsck -D /dev/nvme0n1p3") ), but without success. I had a recent
<paulj>sysrescue installation on a memory stick, so I booted that, and then ran the fsck command from there. After it fixed everything, I could reboot giux again with every thing running normally.
<PotentialUser-21>Hi all, I'm really thinking about distrohopping from Gentoo to Guix, but I have a few questions first ...
<dftxbs3e>PotentialUser-21, hello!
<paulj>PotentialUser-21: I am on that journey at the moment!
<PotentialUser-21>Good to hear! I've read the docs a bit and watched a few talks. Although I still barely know anything about Guile, so that will be interresting to learn
<civodul>dftxbs3e: what CPE suggest code? that's what we need but... is it already written?
<paulj>I have a "spare" laptop which I am using while I learn the ropes. I also installed a VM with guix - another good way to find your way in.
<fnstudio>another minimum (non-)working example of my emacs+org-mode+guix problem: https://paste.debian.net/1187899/
<dftxbs3e>civodul, you sent me this: https://issues.guix.gnu.org/42299
<PotentialUser-21>My first question was about Shepard, there doesn't seems to be a lot of documentations and I found : https://www.quora.com/What-advantages-does-systemd-have-over-GNU-dmd
<PotentialUser-21>Is this info still true ?
<dftxbs3e>civodul, I actually didnt know we had cpe properties for some packages already (never seen it before in GNU Guix packages), I am glad it is already the case!
<PotentialUser-21>The other thing that is holding me back is software availability ...
<PotentialUser-21>Is there a channel for security tools somewhere ?
<roptat>PotentialUser-21, you can install guix on top of your distro if you want to check software
<paulj>That was written 4 years ago. My personal experience is very limited, but I see no issues with shepherd. It is managing the system services on my laptop, and I have also used it for some user services.
<pkill9>idk if the shepherd has parallel startup, but it is fast
<PotentialUser-21>LIke Zap, Metasploit, Scapy, CME, etc
<roptat>the shepherd is quite limited, but tightly integrated with guix, so all the missing features are actually not really necessary
<paulj>Nice article from Efraim here: https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
<PotentialUser-21>I see ...
<PotentialUser-21>Also, how do you manage network inside of Guix ?
<civodul>dftxbs3e: nice, i had forgotten it came with a patch :-)
<civodul>dftxbs3e: but still, the thing is that we need to parse the CPE stuff
<roptat>it's all managed from the os declaration
<PotentialUser-21>Got it, I'll check it out, but there's a few packages that are missing from the repos that I need for my job
<paulj>I use networkmanager - managed in the os declaration as roptat states.
<roptat>PotentialUser-21, well, you could help package them :)
<PotentialUser-21>True, but as I said, I know nothing about guile right now :P
<nckx>paulj: So fsck did ‘fix’ it? (Not that I'd ever recommend something that scary as safe; just curious.)
<dftxbs3e>civodul, I am investigating yes.. do we have an XML parser in GNU Guile?
<PotentialUser-21>I doubt that the first thing I'll do is starting wrtiing packages in Guile ^^'
<PotentialUser-21>I could give it a shot I guess
<paulj>nckx: It did. I watched the output, and was wondering whether it would work again, but everything seems to be OK.
<dftxbs3e>PotentialUser-21, it's actually really easy! Also you can write GNU Guix packages in JSON (most times..)
<roptat>dftxbs3e, (sxml simple)
<dftxbs3e>roptat, okay! cool!
<civodul>dftxbs3e: yes; if you look at the history of (guix cve), there was an SSAX-based parser of the CVE database from when it was XML
<nckx>paulj: Phew, at least.
<PotentialUser-21>JSON isn't a language though ...?
<roptat>dftxbs3e, you should have a look at (guix cve) too
<dftxbs3e>PotentialUser-21, it's not :-)
<nckx>I mean, I know you have tiered off-site back-ups like everyone does, of course, but still.
<PotentialUser-21>It's going to be a learning experience, I know a bit about ebuilds so i could write them in Gentoo ...
<dftxbs3e>civodul, oh the cpe database isnt available in json format?
<dftxbs3e>civodul, but cve database is?
<paulj>I wasn't overly worried, as I would have taken the opportunity to test how easy I can reload the system from scratch! ;)
<civodul>dftxbs3e: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/cve.scm?id=8a928aa729f31d3409cee8371894fd9a50e9fe8f#n123
<civodul>dftxbs3e: yeah, the bug report above mentions that CPE is still XML
<civodul>surely they'll switch to JSON once we're done implementing it ;-)
<roptat>PotentialUser-21, most of the time, packages are fairly easy, we just lack people to help package and maintain the software they use
<roptat>PotentialUser-21, but sometimes you find some difficult ones and that can become messy ^^'
<PotentialUser-21>I see.. That seems to be a problem with Gentoo as well too :(
<dftxbs3e>civodul, I see.. bruh..
<paulj>PotentialUser-21: If you know your way around gentoo ebuilds, I suspect you will have no problems with guile.
<roptat>in general, you don't really need to know much about guile to create a package, so that's good
<roptat>just be sure to close your parenthesis ^^
<paulj>paredit is your friend... (you use emacs, don't you...?!!)
<PotentialUser-21>I don't :(
<nckx>PotentialUser-21: Packaging requires different skills than ‘programming in Guile’. There's some overlap but less than people think. We don't use (or encourage) clever complex things in package definitions, they are generally simple and readable, almost markup-like.
<roptat>(I don't either)
<paulj>If not, I am sure there is a vim/nvim equivalent!
<paulj>... or which ever other editor is your favorite tool
<roptat>PotentialUser-21, but if I were you, I'd start by installing guix on top of gentoo, just to get a feel of how it works from a user perspective, and I'd look into replacing my software with guix versions step by step, packaging stuff along the way if needed
<PotentialUser-21>I see, also, could I define stuff close to useflag in package definition ?
<PotentialUser-21>I mean the way I package a package and someone else is going to package it might be different
<roptat>no, we usually enable most of the options and that's it
<paulj>You can inherit the system package definition, and then add your own additions. useflags are not a thing in guix like they are in gentoo
<roptat>although there's a project to add parameterized packages, which is close to gentoo's useflugs
<roptat>it's not in guix yet though
<PotentialUser-21>Is there any roadmap on the future of guix ?
<PotentialUser-21>Also, how are decisions taken ?
<roptat>but you can always customize your packages, as paulj said, you can inherit or use various build options (like --with-branch, --with-git-url, etc)
<PotentialUser-21>Is there a "gentoo council" version of guix ?
<roptat>there's a collective of maintainers and committers. We usually collectively decide what we want during events like fosdem
<roptat>but in general, we simply do whatever we want to do
<PotentialUser-21>lol
<roptat>it kinda works though :)
<roptat>I know there's a roadmap, but the file I find in guix repo is still about roadmap to 1.0
<roptat>pretty sure we have something more recent than that
<roptat>mh... I see https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/ROADMAP.org
<roptat>civodul, I think we need to have the roadmap in a single place...
<pkill9>couldn't socket activation itself be a service?
<pkill9>and just make it required by whatever other services require it
<pkill9>which would then activate the socket when they are activated
<pkill9>s/they are activated/the services are activated
<roptat>pkill9, I think it's the other way around?
<pkill9>oh ok
<roptat>when the socket is used, the service is spawned
<pkill9>oh i see
<ryanprior>When you run `guix package -A somename` does Guix evaluate every package expression at that time? Or does it use a cache from previous evaluations?
<roptat>systemd for instance creates the socket and listens on it, then activates the service when it hears something, and pass it the socket with its content
<roptat>something like that, though I have no idea how it's done in practice
<roptat>ryanprior, I think it uses a cache created at guix pull time
<pkill9>roptat: couldn't that itself be a service?
<pkill9>or would it just be convoluted?
<roptat>pkill9, I suppose you could wrap the service around some socket activation code
<pkill9>roptat: i was thinking more like, you give it the service to start, so the socket activation code is separate from the service that will have the socket be activated
<mrprofessor>Hello people!
<PotentialUser-21>The installer should be less focus on getting a DE and more focus on setting up your machine IMO
<roptat>pkill9, maybe. again, I don't really know how it works in practice
<mrprofessor>New to GUIX. Wondering about package manager.
<roptat>PotentialUser-21, like what?
<ryanprior>hello mrprofessor! Write your questions here & we'll answer best as we can :)
<PotentialUser-21>Set up network, Set up your disks, maybe even giving you the option of the non-libre kernel
<ryanprior>PotentialUser-21: I appreciate that feedback! Have you written it up in more detail somewhere?
<roptat>not that last one ^^
<mrprofessor>I can install packages using `guix install neovim`, But I was also assuming that I could add packages in the config file too `/etc/config.scm`.
<PotentialUser-21>No, but I could if you want ryanprior
<PotentialUser-21>I'm more in a learning process as of now ^^'
<PotentialUser-21>I might boot a VM tonight, and actually trying it out
<pkill9>mrprofessor: if they're in config.scm, then they will be available system-wide
<roptat>PotentialUser-21, I believe we already have a process to do all that? are you having any trouble with it, or anything missing?
<ryanprior>You can of course create your own installers, but the official Guix installer will not suggest any non-free components (like the upstream Linux kernel) because we keep to the high standard of the Free System Definition Guidelines
<pkill9>to all users i mean
***lukedashjr is now known as luke-jr
<ryanprior>PotentialUser-21: if you can write out the parts of the installation that you found confusing and/or unhelpful, that would be helpful to us.
<mrprofessor>@pkill9 understood. Can I have a per user config too?
<roptat>mrprofessor, yes, that's called a manifest, but it is limited to packages, not configuration
<pkill9>mrprofessor: yes, using manifests
<ryanprior>mrprofessor: you have exactly one system-wide config, and then each user can zero or more configs.
<pkill9>what roptat said
<paulj>fnstudio: I am not an expert, but shouldn't the last line be (scm->json #(0 1 2))? Then it works here
<paulj>(in emacs)
<ryanprior>roptat: I think you can have user configs and services by using guix system container?
<mrprofessor>Gotcha! @rotpat @pkill9 @ryanprior. So how do I install packages after adding them to the config.scm? `sudo guix system reconfigure /etc/config.scm` ??
<roptat>mrprofessor, yes, you reconfigure, guix instantiates the new OS, and you have your packages available in it
<roptat>though I can never remember if you need sudo -E for that one or not
<fnstudio>paulj: hey, thanks for checking! i think i get a complain about guile-json not being available before it gets to (# 1 2 3), but let me try (and thanks for spotting that out)
<roptat>the manual seems to say it's indeed "sudo guix system reconfigure ...", no -E, sorry for the confusion!
<mrprofessor>Makes sense. @roptat. Where can I find the guide for maintaining per user packages?
<roptat>mrprofessor, https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#profile_002dmanifest
<paulj>Strange. I pasted your code into emacs, and then C-c C-c. First of all it didn't work, but then it did after I fixed the above mistake. I haven't installed guile-json explicitly in my system. I understand the guix environment should take care of that.
<roptat>mrprofessor, also https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#export_002dmanifest
<ison>mrprofessor: The installation guide recommends "sudo -i guix"
<paulj>If you run the guix environment command in a shell, does it give you any ideas as to what is happening?
<mrprofessor>Ahh the manual is great. But I wish there were more blogs/guides.
<roptat>ison, mrprofessor " To explicitly run root’s guix, type sudo -i guix" but you probably don't want to do that as you pull as your user, not root
<fnstudio>paulj: yeah, it's all fine if done in a shell
<nckx>mrprofessor: You probably want sudo -E, not sudo -i.
<paulj>Strange... Unfortunately you have passed the boundary of my current knowledge on this!
<nckx>Then you only have to ‘guix pull’, not ‘guix pull && sudo -i guix pull’.
<roptat>mrprofessor, like https://guix.gnu.org/en/blog/2019/guix-profiles-in-practice/
<roptat>mrprofessor, and maybe more recent: https://guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html#Guix-Profiles-in-Practice
<roptat>:)
<mrprofessor>=sudo guix system reconfigure /etc/config.scm= worked for me.
<roptat>right, this uses your user's guix, which should be the latest version if you ran guix pull, whereas root's guix might be slightly outdated
<leoprikler>can someone explain #46923 to me?
<mrprofessor>@roptat no it installed packages mentioned in `/etc/config.scm`.
<nckx>leoprikler: ...wat.
<roptat>mrprofessor, indeed, but using versions from your user's guix, and not the system's guix
<fnstudio>paulj: hey, don't worry, contrarily it was very kind for you to look into it
<leoprikler>idk either
<nckx>I assume it's related to 865728dd52600c7aa29a87bf18cb02ddf453cdfc but I'm still confused.
<roptat>mrprofessor, which is fine, that's exactly what you want :)
<leoprikler>well, at least I'm not alone
*nckx replied.
<leoprikler>Oh, you mean confused about my question?
<nckx>No no.
<nckx>As fun as it would be to play along.
<shcv>I'm working on a python package, and it doesn't seem to be copying data files even though I have include_package_data = True in my setup.cfg; any ideas?
<raghavgururajan>Hello Guix!
<roptat>gah, the videos of the guix day in november are still not on audio-video, are they?
<nckx>Hi raghavgururajan.
<nckx>roptat: Is there a reason we can't host them ourselves, if only until they are?
<nckx>It wouldn't be a PHP security update without a new failing test.
<fnstudio>paulj: i tested it in a new environment and on that system things seem to work as expected
<fnstudio>"environment" as in "on a new machine"
<fnstudio>both machines are guix over a foreign distro, i'm thinking of what the difference can be
<fnstudio>it might be because i'm using emacs in daemon-client mode on one of the machines
<PotentialUser-21>So what would be the advantage of using Guix over gentoo ?
<PotentialUser-21>I mean, security wise
<fnstudio>but i guess this is getting closer to the point where i should move this to #emacs :)
<PotentialUser-21>I understand that the package manager has nothing to do with portage
<shcv>main advantages of Guix over Gentoo are: binary substitutions, and guaranteed reproducible builds
<shcv>verified in both cases, which helps for security too
<PotentialUser-21>I'm not familiar with "reproducible builds", why would I need a package to be reproducible if my system built it ?
<PotentialUser-21>Sorry, that's a very noobish question :(
<shcv>also Guix has a very strict channel authentication scheme, so that all commits have to be signed
<PotentialUser-21>Same with Gentoo though
<PotentialUser-21>Well the main overlay
<shcv>yeah, all channels work that way for Guix, though you still have to trust them
<nckx>PotentialUser-21: I don't know. It's rather a leading question. I don't think Guix advertises itself as more secure than <X>. That would be a risky strategy.
<PotentialUser-21>Never said, Guix advertises itself as more secure ^^
<shcv>reproducibility helps because you can verify you got the same result as someone else, and thus that there was no tampering in between
<PotentialUser-21>It's just something very important for me, as I expose a few servers to the scary interwebs
<shcv>it also helps for solving bugs, because anyone who builds it gets the same result
<shcv>so patches and fixes happen much faster
<shcv>or could, anyway
<PotentialUser-21>Haa gotcha
<nckx>‘We're so weird, most PHP bash script injections won't run on Guix’ is as good a reason as any.
<shcv>lol
<pkill9>also you're less likely to misconfigure services maybe
<shcv>and also pure free software! no malicious proprietary blobs!
<shcv>:P
<pkill9>instead of having many files in /etc you need to remember which you modified, you have it all in one file written in the same language
<PotentialUser-21>You could boot gentoo with pure libre software too
<pkill9>idk if that's a concern really
<shcv>the configuration can admittedly be a challenge until you get used to it
<PotentialUser-21>I'd also argue that Useflag is a huge security + for gentoo
<PotentialUser-21>So if X package is vulnerable that doesn't mean that yours is
<PotentialUser-21>Because feature Y might not be compile on your system
<shcv>I do think it would be nice if packages offered a standard "customization" interface, but it's really not that hard to modify the package to remove a feature
<PotentialUser-21>I'd have to look this up shcv
<shcv>it's not as easy as useflags though
<nckx>shcv: That's what parameterised packages would be, but designing such an interface is hard.
<PotentialUser-21>I'm also confused as how does guix decide to pull a binary or compile the package from source ?
<nckx>If we're not careful we'll end up with use flags again.
<shcv>but coming from Gentoo myself, I will say that the reproducible builds and atomic system management are a huge benefit for the security of my own machines
<PotentialUser-21>What's wrong with useflags ? :(
<shcv>also the fact that substitutes are avaiable
<civodul>roptat: yeah maybe we can start by removing this ROADMAP file or something
<PotentialUser-21>True, shcv, those are some great features!
<civodul>roptat: but we should definitely keep track of the big long-term directions at least
<shcv>together, it means that I update my systems regularly, and don't have to spend a day or two fixing dependency conflicts if I waited too long
<PotentialUser-21>What are substitutes ?
<shcv>binaries
<shcv>that "substitute" for building it yourself
<PotentialUser-21>Gotcha
<PotentialUser-21>How does guix decide to pull a substitue or fetch the sources ?
<shcv>if substitute available, fetch; else: build from source
<pkill9>there was work on adding an equivalent to use-flags
<civodul>see also https://guix.gnu.org/manual/en/html_node/Substitutes.html
<shcv>you can ask it to build if you want to, but reproducibility makes that kinda pointless
<PotentialUser-21>Will do
<shcv>maybe you could do something with multi-valued packages, and tags to prioritize the selection
<PotentialUser-21>Guix looks really nice on paper, I'm just afraid it won't be as mature as Gentoo, and of course I understand that guix is not likke 25 yo either
<shcv>PotentialUser-21: I switched a month ago, and have been very happy so far
<PotentialUser-21>Any packages that you can't find ?
<shcv>the only thing that was really a pain was the lacking ZFS support, since I use that for my server
<PotentialUser-21>Oof, really ?
<PotentialUser-21>Yeah, that might be a turn off for me to then ...
<jonsger>there is ongoing work on the ZFS front...
<shcv>I was able to get it to work, but not with a ZFS root yet
<PotentialUser-21>Any thread that talks about it ?
<PotentialUser-21>zfs on root was definitely something I would be interested in
<shcv>there are things that don't have packages yet, but packaging things is actually pretty easy; I'll admit it was a bit hard to get started though
<PotentialUser-21>Then I'll have to teach myself guile :P
<shcv>one of the ZFS threads: https://issues.guix.gnu.org/45692
<PotentialUser-21>Wow, "raid5atemyhomework" that guy is a memer
<PotentialUser-21>Also, without systemd, does that mean no udev ? How does ZFS work without udev ?
<dftxbs3e>PotentialUser-21, there's eudev
<PotentialUser-21>Ohh, nice!
<PotentialUser-21>I find it hard to explore the package part, where you only can click on the first letter ...
<PotentialUser-21>package page *
<dftxbs3e>PotentialUser-21, agreed but just install GNU Guix..
<dftxbs3e>PotentialUser-21, on top of your current distro
<nckx>roptat: I think you're more familiar with the sausage factory that is PHP than I am; does ‘random number generator:RAND_load_file:Cannot open file’ ring a bell?
<PotentialUser-21>I don't see the benefits of installing it on top of portage tbh, other than learning it
<dftxbs3e>PotentialUser-21, reproducible dev envs, but yes do install to explore :-)
<PotentialUser-21>I'll probably make a VM ^^'
<rekado_>PotentialUser-21: see also https://hpc.guix.info/browse
<rekado_>PotentialUser-21: you can use Guix on your distro and then use the “guix system vm” command to build VMs
<rekado_>it’s much nicer than being locked in a VM, inside of which “guix system” doesn’t make much sense.
<PotentialUser-21>I'lll have to read up more about this command, that definitely seems interesting
<avalenn>I just read this and found it interesting for guix guys : https://blog.yossarian.net/2021/02/28/Weird-architectures-werent-supported-to-begin-with
<roptat>nckx, no, but maybe it's having trouble finding /dev/rand or something?
<roptat>random*
<roptat>"cannot open file", I'd look at what strace tells you
<nckx>It's during the test suite during the build.
<nckx>That's going to be at least 3 funpoints to instrument.
<nckx>I only have about 1-2 left before bed time.
<roptat>nckx, if you have kept the build directory in /tmp, you can use php from there
<nckx>I've visually verified that the test ‘passes’ (it outputs the expected error message being tested for; it just outputs 2 more) so I'm tempted to disable it ‘for now’ and push the update... of course, ‘for now’ is risky.
<roptat>mh... sure, we've done that for other tests
<roptat>the test should have a name like .../*.phpt, and there's a similar-named *.php in the same location that you can run
<nckx>It's ext/openssl/tests/bug80747.phpt.
<nckx>I didn't know about the .php file though.
<roptat>then you should have a /tmp/guix-build-php-*/ext/openssl/tests/bug80747.php
<nckx>I'd only found a (generated-looking) shell script.
<roptat>mh.. add a /php-*/ in there
<nckx>roptat: ...yes. That's the failing test I'm looking at.
<roptat>oh, maybe I'm wrong? I think it generates the php file from the phpt one
<roptat>but maybe it's not in the same directory after all?
<nckx>No no, it works!
<nckx>Wow.
<nckx>I mean, I can run it with and it actually prints the same stuff, not a whole different mess because it's missing some env magic ☺
<nckx>This is great.
<nckx>Thanks roptat.
<nckx>*with php
<nckx>*with sapi/cli/php
<roptat>\o/
<roptat>hope it can help you understand what's going on :)
<roptat>civodul, maybe we should merge that roadmap with the one in the guix repo, and keep only one of them?
<nckx>Hum, the error message doesn't appear in strace (even with -f[f]), I'm still doin' it wrong.
<nckx>But it does print it, so...
<rekado_>has any here attempted to package kubernetes or parts of it?
<rekado_>*anyone
<roptat>civodul, we also have a TODO file in the guix repo ^^'
<civodul>avalenn: interesting
<shcv>any idea why a data file in this python package isn't being copied in the 'install' phase? It's there after the unpack phase, and the setup.cfg file has 'include_package_data = True'
<shcv>I can manually copy it, but that doesn't seem right
<shcv>(as in, add the copy step explicitly to the guix package)
<civodul>roptat: yeah i'm not sure what the best way forward is; perhaps a "vision" page on the web site, with highlights of the grand long-term goals (like free software, R-B + bootstrapping, tight integration through Guile, etc.)
*nckx → zzz, will continue wrasslin' PHP tomorrow.
<nckx>civodul: Cool!
<civodul>avalenn: the author at the end mentions "corporate platforms", but HPPA/m68k/Alpha today are more hobbyist/zero-waste platforms than "corporate"
<roptat>civodul, that would be nice, but it wouldn't be enough, unless you want to put more details, like "shepherd and fibers" and stuff we have in our ROADMAP and TODO files
<civodul>yes, we need at least two different levels
<civodul>for actual milestones, it would be nice to have appropriate tooling tho
<civodul>like on those code hosting sites you know, or Phabricator, Trac, etc.
<dftxbs3e>civodul, phabricator is really great
<leoprikler>Also Rust intermediate dependencies are unironically a huge number of barely maintained packages.
<leoprikler>And whenever you do minor version bump any of them (in Guix or elsewhere), prepare for trouble and make it double.
<lispmacs[work]>did Guix ever work out the problems with building firefox on 32 bit Guix? it was a problem a few years ago I recall
<lispmacs[work]>was going to install guix on a 32 bit machine
<lispmacs[work]>x86
<leoprikler>lispmacs[work]: do you mean http://issues.guix.gnu.org/35519?
<Whyvn>I am trying to add emacs --daemon to a shepherd service, but it does not seem to want to start. Is this the correct formatting? http://paste.debian.net/1187926/
<leoprikler>make-forkexec-constructor is not actually implemented in terms of system* IIRC
<leoprikler>or wait
<leoprikler>(list "emacs" (format #f "--fg-daemon=~a" socket-name))
<leoprikler>you don't want emacs to background itself (similar to how systemd wants to hold the process itself)
<Whyvn>ok thank you, is the output of the service supposed to show up in the log-file? to verify the output when it starts to be sure its working correctly