IRC channel logs


back to list of logs

<jlicht>and perhaps have a look at bashrc/bash_profile files, comparing the git and not-git user's version of it
<yewscion>That seems to have fixed it! Interesting.
<yewscion>I don't understand why, but it seems that a program needs to be part of the operating-system declaration to be accessible as an argument to ssh.
<yewscion>Thank You for Your help, jlicht and M6piz7wk[m]!
<jlicht>yw, glad it works now :-)
<florhizome[m]>why does meson/pkgconfig not find libmutter here?
<florhizome[m]>(i tried adding it as any input and the according directories definitely are in the exported env vars
<florhizome[m]><drakonis> "but most of the work has been..." <- I guess this would help resolve stuff like user installed DE plugins not being found by the DE (xfce)...
<florhizome[m]>What is mentioned in terms of modprobe seems to be related to my frustrations to get thinkfan working (I recognized that guix handles this stuff very different but didn’t find how – basically I can place a file via service in etc/modprobe.d that should allow external fan control but it won’t)
<florhizome[m]>the git/ssh example above seems to apply, too.
<florhizome[m]>if this can all be addressed better, not saying „fixed“, it’s not trivial and I’m happily awaiting it ;)
<drakonis>it kinda exists afaik
<drakonis>you can declare environment variables per package
<nckx>florhizome[m]: <should allow external fan control but it won’t> How so?
<florhizome[m]>I remember some examples altering search–paths, do you mean that?
<florhizome[m]>moving to an (imho) better default is still preferable though
<florhizome[m]>nckx: normally you would place a file in modprobe.d called thinkfan.conf that says thinkpad_acpi fan_control=1 and then it becomes possible.
<florhizome[m]>on guix it didn‘t change anything for me.
<florhizome[m]>for now I’m doing it with kernel arguments which seems a bit overdosed^^
<excalamus>good evening, Guix
<nckx>But thanks for the answer. :)
<nckx>Evening excalamus; 'night Guix o/
<florhizome[m]>(and then I still have to manage to write to the right file, there is a lot of confusing stuff already)
<florhizome[m]>night nckx , evening excalamus (:
<excalamus>I saw that Google Summer of Code was opening up to non-students. I know someone did that in 2019. Is that something the Guix project is still interested in?
<excalamus>I wish I had time to do that, mainly for having a dedicated mentor. But I don't think I'll have time.
<excalamus>I'm curious what the Guix project might prioritize
<florhizome[m]>* actually fell asleep and is going to bed, too ^^
<jgart>Can this package go in music?
<jgart>It's a common lisp package
<jgart>It's a library for typesetting sheet music with lisp
<roptat>sounds like a good fit
<jgart>Another oddity about this package is that it doesn't have any releases or is under any version control.
<jgart>What should I call the version?
<jgart>It is just distributed as a tarball
<jgart>cmn is a dependency of slippery-chicken:
<roptat>jgart, uh, does upstream provide updates at all?
<roptat>I'd use "0" as the version, or maybe "0-0", then "0-1", etc if you think the source can change without upstream calling it a release or giving a version number
<jgart>I'm pretty sure they do but they're just releasing a new tarball everytime without a version bump
<jgart>I'll ask on their mailing list:
<zamfofex>I think the problem is that there is no good way to differ the URL between versions.
<jgart>Here's a wikipedia article on CMN
<jgart>And its' manual
<jgart>Bill Schottstaedt might be the sole author of CMN (longtime professor at Stanford)
<jgart>CMN was written in the early 90s
<jgart>It's still used today by slippery-chicken project which is active
<jgart>on github
<dissent>hey guix, from time to time i get errors saying conflicting entries, in the present case emacs-md4rd and emacs-tldr. should i report this?
<zamfofex>dissent: Maybe the issue you’re running into has to do with propagated inputs.
<zamfofex>When do you get those error messages? When installing a package? When updating?
<dissent>zamfofex: when installing
<zamfofex>I think your issue is that two packages you are trying to install have a package with the same name and different versions as propagated inputs.
<zamfofex>Try doing as it says. First run ‘guix pull && guix package -u’ to update the packages, then try installing again. If you have already done that, you could try to change the propagated input with a transformation option.
<dissent>will do. thanks.
<podiki[m]>anyone know of any relevant guix visuals? besides the logo?
<podiki[m]>I also found a diagram on how profiles are contructed from a fosdem talk, but curious what else is out there
<acrow>The manual seem to say that the use of GUIX_PACKAGE_PATH preempts the default path. Can I just add the default path to get all the good things together, eg.. GUIX_PACKAGE_PATH="${HOME}/.config/guix/current:${HOME}/.config/guix/local-packages/"?
<acrow>Maybe if I make it "${HOME}/.config/guix/current/share/guile/site/3.0:..."
<podiki[m]>I think it was more for before channels took over, but you can have it point to a directory where you have package files instead of having a full channel; if I remember correctly
<kittyblam>Yesterday I finally got my first real package working, Yafaray core/xml, its a dependency for Yafaray GUI, with my yafaray.scm obviously not yet being on any channel, how do I go about adding the dependency as an input? perhaps I will find it eventually reading more of the guix manual tho
<acrow>podiki, thanks. I tried to get channels to work using a subdirectory but failed. Channels seem to require the use of git and a local url which I'm not sure how to write. This is strictly for local experimentation.
<podiki[m]>I use a local only channel (been meaning to publish publicly at some point)
<podiki[m]>just needs to be a git repository and use (url "file:///path/to/gitrepo")
<podiki[m]>in the channels def
<podiki[m]>but package path can be easier/quicker
<acrow>I'm having success without sussing out the default directory, just the single local directory is joined with the default so, GUIX_PACKAGE_PATH=<my-local-path> guix package --show=<my-local-package>, succeeds. I'm going to try to simply manually edit the GUIX_PACKAGE_PATH into my ${GUIX_PROFILE}/bin/profile, and then source it to create the new default.
<acrow>Err, it's etc/profile.
<acrow>podiki, thanks again. Your comments were helpful.
<acrow>I'm rethinking that modification to ${GUIX_PROFILE}/etc/profile. The write protection made me think twice before making the change. I think I'll sleep on that.
<podiki[m]>happy to pass on the bits I've picked up, and if a simple example should be in the manual or cookbook (if not already), do file a report
<podiki[m]>acrow: yes, don't touch that manually. you'll want to add that to your .profile (or similar for whatever shell)
<podiki[m]>acrow: this will be helpful
<acrow>podiki, ah, the cookbook. Didn't look there. Thank you. The channels portion of the manual seems to offer support for a simple subdirectory through modifications of channels.scm as well as adding that .guix-channel meta-file but it wasn't trivial enough for me. And a git repository seems like overkill in my situation.
<podiki[m]>yeah, maybe something to be improved then
<jgart>When installing clikan, a python app, it triggers a ton of haskell deps to build. How is this possible?
<jgart>I don't see any haskell deps in clikan
<podiki[m]>my random guess is a pandoc dependency somewhere?
<podiki[m]>I'm also confused sometimes at those deep dependencies
<jgart>hmmm yea, I was thinking of that too as posibility
<jgart>I'll have to check the deps
<jgart>s/transitive deps
<jgart>podiki[m], do you happen to remember the command of the top of your head to check those transitive deps?
<jgart>totally forgot now ha
*jgart browses the docs
<podiki[m]>... guix graph?
<jgart>is there a way to show transitive deps as a ascii list?
<jgart>or just a plain list?
<podiki[m]>not sure, maybe parse guix graph output?
<podiki[m]>it is just text for a graph basically
<podiki[m]>grep on label for the names
<podiki[m]>this exhausts my knowledge, but guix graph clikan | grep pandoc does show pandoc in there
<jgart>oh yeah I see that to
<lilyp>you might want to do BFS still, so that you can announce some levels
<lilyp>e.g. L5 dependency: gcc
<xelxebar>jgart: guix gc --requisites not what you're looking for?
<efraim>hello guix!
<xelxebar>I'm trying to install guix to a domu and don't want to install grub, but *do* want to populate /boot/grub/grub.cfg.
<xelxebar>--no-bootloader skips both. Is a way to achieve just the latter?
<wehlutyk[m]>Ahoy guix o/
<wehlutyk[m]>I'm trying out `guix shell -D guix help2man git strace which less coreutils bash --pure --check -- bash`, and the checking part uses my parent SHELL value, which is fish. So it checks my PATH as generated by fish, not by bash. Is there a way to pass a new SHELL variable to `guix shell ... --check` so that it reflects the bash from inside the environment?
<wehlutyk[m]>The converse question would be, what would be the equivalent of separating .bashrc and .bash_profile in fish, so any PATH modifications can be left aside when using fish inside a guix shell?
<florhizome[m]>> <> why does meson/pkgconfig not find libmutter here?
<florhizome[m]>> (i tried adding it as any input and the according directories definitely are in the exported env vars
<florhizome[m]>still looking for tips w/ this
<jgart>florhizome[m], Could you share the package definition
<jgart>what version of mutter does gala need?
<jgart>It might be that the mutter in guix is too old:
<jgart>That's what would trigger that message:
<jgart>if mutter_dep.length() == 0
<jgart> error ('No supported mutter library found!')
<jpoiret>xelxebar: I don't think there's a way to do something this fine yet
<jpoiret>however i'm in the process (procrastinating though) of writing a mail about making some changes to operating-system and `guix system` so that they become more modular
<ns12>How do I keep the directory of a successful build? `guix build --keep-failed ...` keeps the directory of failed builds. Is there an equivalent for successful builds?
<jpoiret>one thing i'd like is to make the "linux loader" separate, so that we could easily have something akin to package transformations but to rather have system be adapted to run in Xen, containers, etc... easily
<jgart>xelxebar, thanks! that shows it too
<jgart>Ryan Prior shared this with me today:
<jgart>what guix needs
*jgart adds it to the wish list
<xelxebar>jpoiret: Okay. So this is sorta WIP. By separate "linux loader", do you essentially mean adding handles to control grub's linux and initrd lines?
<florhizome[m]><jgart> "florhizome, Could you share..." <- 40.05 / libmutter8 ... Should be fine.
<florhizome[m]>Current Mutter on master wouldn't bei enough, so i built that specifically for this case^^
<florhizome[m]>In the paste i added an ls into that folder
<jpoiret>more like: "here's how you're supposed to get loaded, either via some bootloader (grub, u-boot, etc), directly via efistub, via container, etc..."
<jpoiret>and you could define a loader that would be basically grub but without bootloader, for cases like yours
<xelxebar>Oh, even better. So a general loader "frontend", per se, with "backends" for the various loading mechanisms.
<jpoiret>yes, exactly (although this isn't even WIP, it's a very minimal draft i have in my head)
<jpoiret>ideally, we could make those loaders more easily customizable too. Personally, I was thinking of using grub-install with --removable so that it did not update the efi vars, making it so that `guix system init` could be used to install directly on vm disks.
<florhizome[m]><jgart> "if mutter_dep.length() == 0" <- What does it mean, could it be triggered although a Else fitting Mutter ist found?
<jpoiret>(since right now `system vm` only loads kernel and initrd directly and bind mounts the store instead, and does not create a whole vm image)
<jpoiret>i know there's `guix system image` as well but it doesn't let you have for example luks2 formatted partitions on there, since you need to still do the install process
<jgart>florhizome[m], I'm not sure what your patch set looks like so it's hard to contextualize everything that might/could be wrong. Sometimes error msg's are not enough to tell. I think we need a `guix paste gala -r` subcommand that pastes to online pastebins :) -r is for recursive
<M6piz7wk[m]>How long does it take for someone to take a look at my amazing patch~
*M6piz7wk[m] doesn't understand why are all the crates-io.scm in one 65K lines long file as the rebuilding is expensive
<vivien>Hello guix! Regarding the progress of core-updates-frozen, I have 2 issues remaining: 51916 (can’t reconfigure the system with GNOME) and 51890 (vigra fails, so no libreoffice).
<xelxebar>jpoiret: I'm definitely interested in hearing your thoughts. Please ping me when you end up posting that email!
<ss2>hello! Is invoke part of Guix, or Guile? I'm looking for its documentation.
<ss2>guix build utils.
<ns12>M6piz7wk[m] It looks like you accidentally changed the indentation for many of the existing lines in crates-io.scm.
<jgart>ss2, I think it is part of guix iirc
<M6piz7wk[m]><ns12> "6piz7wk It looks like you..." <- aaAaAaAaAaAaA
<M6piz7wk[m]>howddya fix that? the manual said to do ./etcs/indent-thing.el
<M6piz7wk[m]>the damned manual tricked me again!
<xelxebar>ss2: It's defined in (guix build utils)
***wielaard is now known as mjw
<ss2>found it there.
<ss2>Was hoping to find more documentation, think I figured it anyway, and don't need invoke.
<ns12>M6piz7wk[m] Also, each new package (rust-ci-info, rust-cargo-metadata, rust-cargo-make, etc.) should be in an individual git commit, and you should produce a series of patches using `git format-patch`. This will make your patch series easier to review.
*M6piz7wk[m] has to go AFK now will fix the patch after
<ns12>M6piz7wk[m] Note that I am not affiliated with the project. I am just giving some general suggestions. It is a bit difficult to review a 15,401 line patch where the main content apparently starts at line 14,849.
<rekado>ss2: nobody really *needs* INVOKE, but it’s useful in the context of build phases. We generally want to abort a build when a program cannot be run.
*M6piz7wk[m] was suspicious when nckx said that it's this easy
<rekado>INVOKE is just SYSTEM* that raises an exception on failure.
<jgart>M6piz7wk[m], yup, it'll be hard to get someone to review a patch set like that. Were you able to run `guix lint` on it? You should do that too to catch common package errors also
<ss2>ah, and I just wrapped this command inside SYSTEM*. I'm hacking on mcron scripts at the moment. The manual has an example I more or less played around with:
<ss2>Is there an easy way to create a link to refer to from within info in Emacs?
<M6piz7wk[m]><jgart> "6piz7wk, yup, it'll be hard to..." <- nope though that only the elisp script is sufficient u.u
<ns12>M6piz7wk[m] There are many examples of patches in the guix-patches mailing list ( ). Here is an example of a patch series that adds 7 Rust packages:
<ns12>Documentation about submitting patches:
<florhizome[m]><jgart> "florhizome, I'm not sure what..." <- my problem is only that my passwords lie in my nextcloud and I haven’t come around finding a solutions to automounting it (doubt automounting via system declaration works for davfs (?)), so I need to do that manually and most of the time I’m too lazy so I just write into matrix from iPad/mobile phone and not from emacs.
<florhizome[m]>but yeah paste will come in a sec...
<jgart>florhizome[m], have you tried wgetpaste?
<jgart>guix edit wgetpaste
<florhizome[m]>does it paste to matrix automatically:o
<florhizome[m]>The “problem” i described is logging into matrix.
<jgart>hmmm don't think so
<jgart>maybe one of the python cli matrix clients do something like that
<florhizome[m]>which I need my keepassxc db for. which is on my nextcloud. which I would like to auto mount via davfs but haven’t come around to^^
<ns12>Question: Can I install Guix services such as Apache or Nginx if I am using Guix as a package manager in Debian? Or are the Guix services usable only in the standalone Guix System OS?
<jonsger>phodina[m]: nice that you get the phosh patches back to live :)
<florhizome[m]>here you are (;
<florhizome[m]>for the record, i basically got the dependency package definitions as i saw fit from c-u-f.
<M6piz7wk[m]><ns12> "Documentation about submitting..." <- is this really the way? It seems like something that is automated
<rekado>ns12: yes, the services are only usable on Guix System.
<rekado>ns12: there may be a way to cheat and run them inside a Guix System container, but I don’t think this has been tested.
<rekado>M6piz7wk[m]: what do you mean? It’s best for contributors to do some initial quality checks before making other people point out quality issues during the review.
<ns12>rekado: I am thinking of using Guix on the cloud (e.g. on Digital Ocean or Linode). What are my options if I want to run Guix services?
*M6piz7wk[m] already wrote script for that
<rekado>ns12: I don’t know. I’ve used Guix on AWS, but without services.
<rekado>the cloud providers have features that are most conveniently used through Docker images. You can build a Guix System docker thing, which may be the most convenient (albeit crude) way to get Guix System services in the cloud.
<ns12>rekado: Guix System on AWS, or Guix as a package manager?
<rekado>just Guix-built packages and Guix itself as an environment manager.
<rekado>M6piz7wk[m]: “Verify that your patch contains only one set of related changes” — your script does that?
<jlicht>I can confirm that the openssh service works in a container, with binary guix on raspbian
<rekado>or “Take a look at the profile reported by guix size (see Invoking guix size). This will allow you to notice references to other packages unwillingly retained”?
<rekado>these are manual steps
<rekado>jlicht: is there a convenient way to configure a faux system on top of another distro, system services included?
<ns12>rekado: jlicht: Does "container" refer to this ?
<vdv> maybe interesting
<vdv>25x faster than unzip, 10 faster than tar at reading files
<rekado>ns12: I was thinking of “guix system docker-image”, actually
<rekado>I’ma gonna push this new texlive importer
<ns12>rekado: How do I update the docker image? For example, to install new software? Do I have to produce a new image again using "guix system docker-image"?
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>why is this happening on alpine linux?
<M6piz7wk[m]>... when bootstrapping guix
*M6piz7wk[m] is trying to build guix on alpine linux docker to get cached build to speed up the crate2guix thing
<M6piz7wk[m]>... bcs none yet submitted guix to docker u.u
<M6piz7wk[m]>nwm figured it out
*M6piz7wk[m] used his broken docker with guix
<vivien>M6piz7wk[m], are you still trying to get guix to build things inside a docker container?
<M6piz7wk[m]>wrote a script and trying to integrate it in docker's caching to avoid long waiting for the initial build
<M6piz7wk[m]>bcs docker caches steps
<rekado>ns12: that’s what I’d do, yes.
<rekado>I always treat VMs and container images as disposable artifacts of a higher-level build process.
<ns12>rekado: Is there an alternative to building new images every time the system configuration changes?
<ns12>Perhaps a way to update an existing Guix OS running in a docker container?
<rekado>I don’t know.
<rekado>I’m sure we’d be happy to grow a feature like this.
<rekado>all of this image and container stuff is demand-driven, so if we can clearly specify how this should work I’m sure we could extend “guix deploy” or something like that.
<M6piz7wk[m]>aaaaa it's so painful to get a working docker with guix u.u
<florhizome[m]><rekado> "ns12: yes, the services are only..." <- Except home services ...
<rekado>I built docker images with Guix a lot; I would not call this painful.
<rekado>what exactly causes pain here?
<M6piz7wk[m]>is there a tarball for guix repo?
<M6piz7wk[m]>it doesn't meeeh
*M6piz7wk[m] set up gitea mirror
<ns12>rekado: There's no "guix system reconfigure ..." when running in a Docker image? Why must the Docker image be rebuilt whenever I want to install a package?
<M6piz7wk[m]>hmm so guix doesn't have docker bcs it doesn't have deamonless deployment?
<M6piz7wk[m]>meeeh i do it without docker then u.u
<rekado>M6piz7wk[m]: ? Guix does have docker.
<M6piz7wk[m]>rekado: where?
<rekado>and it’s impossible to address your comments when you don’t respond to requests of clarification
<rekado>guix show docker
<M6piz7wk[m]>the only one that has a somewhat working guix command is the one from metacell
<M6piz7wk[m]>rekado: i meant docker image that can be used for devopsing thing
<vivien>What about guix pack -f docker guix?
<vivien>(you may want to add -Sbin=/bin
<vivien> (
<efraim>vigra builds with numpy-1.19.5 and not 1.20.3, so that's where the breakage is
<M6piz7wk[m]>meh i need to figure out my management can't even script send-mail
<ns12>Does Guix accept packages that are not bit-reproducible?
<rekado>(did I break “guix pull”…?)
<rekado>efraim: interesting!
<vivien>ns12, can’t you make it bit-reproducible?
<rekado>efraim: vigra is not propagating numpy; does it install a Python module and actually *should* propagate it?
<ns12>vivien: There are some software that require binaries for bootstrap (e.g. self-hosting compilers), and the output of the binaries may not be bit-reproducible.
<rekado>in any case: we can’t just downgrade numpy, nor can we use a different version of numpy when vigra provides a Python module.
<rekado>ns12: we generally try to bootstrap compilers without requiring binaries
<rekado>this isn’t always possible, but we go to almost extreme lengths to try.
<ns12>rekado: I see. So the packaging of compilers in Guix is best left for the experts.
<rekado>guix pull is broken: nettle-3.5-check-_pkcs1_sec_decrypt-msg-len.patch is not found
<efraim>rekado: I have no idea, I'm just trying to get libreoffice to build
<efraim>i'll compare it against master
<rekado>efraim: yes, I understand :)
<rekado>efraim: looks like it *does* install a Python lib, but into the default output.
<rekado>maybe we could split it off and then worry about the Python stuff (vigranumpy) later
<gbrlwck>rekado: did you break `guix pull`? i get a "patch not found" for nettle-3.5-check-_pkcs1_sec_decrypt-msg-len.patch
<efraim>saga@7.9.0 guile-cv@0.2.1 vigra-c@0.0.0-1.66ff4fa libreoffice@ hugin@2020.0.0 enblend-enfuse@4.2 are the packages which use it directly
<rekado>I get the same
<rekado>wasn’t me this time
<rekado>the patch seems to exist, and it’s listed in gnu/ as well
<qzdlns[m]>hi guix o/
<qzdlns[m]>is anyone running GIMP >=2.99.6 or tracking dev builds?
<rekado>I’m guessing that maybe the patch name is too long
<rekado>but I don’t know how to run guix lint on this package
<rekado>./pre-inst-env guix lint -e '(@ (gnu packages nettle) nettle-3.5/fixed)' doesn’t work
<rekado>I can’t look at this now; someone else please fix it :)
<rekado>to test: make as-derivation
<M6piz7wk[m]>aaaa why does guix have such an outdated rust
<vivien>M6piz7wk[m], join us at core-updates-frozen
<qzdlns[m]>6piz7wk: i imagine because toolchain :^^)
<M6piz7wk[m]>where's core-updates-frozen
<vivien>guix pull --branch=core-updates-frozen
<ss2>how does it work to pass on packages in an (with-extensions ..)? The manual says I can pass on “full-blown” packages. Is it enough to state (gnu package PACKAGE) inside with-extensions?
<M6piz7wk[m]>what's that? do i submit patches to it?
<vivien>M6piz7wk[m], you can
*M6piz7wk[m] goes to try to package things to it then
<jpoiret>ehm, i'd rather have you try `guix time-machine --branch=core-updates-frozen` rather than `guix pull`
<jpoiret>but both will work
<jpoiret>just that one will move your current guix to core-updates-frozen, and `guix time-machine` will only use it for specific commands
<jpoiret>ie guix time-machine is the guix shell of guix itself
<jpoiret>i use time-machine to test things on master when my system is running c-u-f
<PurpleSym>civodul: GHC has not been built by the CI for core-updates-frozen. That’ll be a very painful sprint tomorrow 😢
<ns12>How does Guix keep track of upstream package updates when there is no specific maintainer for each package?
<brendyyn>ns12, embrace chaos and madness
<emacsen_>ns12, it's a snarky answer but the truth is that a maintainer does not in itself guarantee updates when an upstream event occurs
<ss2>And you are always free to submit a patch for an upgrade.
<emacsen_>I do think it's more of an issue when it comes to backports though, and it's a very fair concern
<abrenon>hello guix
<singpolyma>It would be possible to have a service that scans all known upstreams, and even tries to auto-update
<vivien>See guix refresh
<yewscion>Good Morning, Guix!
<singpolyma>vivien: nice, that's even better than I expected
<ekaitz>hi, I have problems doing guix pull atm
<ekaitz>the guix-extra derivation fails
<ekaitz>did anyone had the same issue recently?
<ekaitz>it looks like an error on the package `nettle` related with a patch that is missing
<ns12>ekaitz: I am currently experiencing the same issue.
<M6piz7wk[m]>i just spent 5 min wondering why guix can't build my package when i didn't realize that i didn't build the repo -w-
<M6piz7wk[m]>is there a way to configure guix to only use rust* packages from a specified channel?
*M6piz7wk[m] wants to experiment~
<ekaitz>ns12: ugh, let me review the package...
<ekaitz>what's the branch that guix uses by default for the packages? master?
<M6piz7wk[m]>ekaitz: afaik master
<civodul>rekado: nice stuff regarding the texlive importer! tests/texlive.scm needs an update tho :-)
<civodul>ekaitz: ouch, looking into it...
<ekaitz>civodul: there seems to be a problem with gnu/packages/patches/nettle-3.5-check-_pkcs1_sec_decrypt-msg-len.patch
<ekaitz>but it is where it's supposed to be... (i think)
<rekado>civodul: ah, right, the tests…
<civodul>ekaitz: fixed in 21357224bc1f450931fb3a64fe6d06f9d1137b67!
<civodul>on behalf of Guix Inc., apologies for the inconvenience
<vivien>Does Guix Inc. stand for Guix Inconveniences?
<civodul>could be!
<civodul>hear hear, i'm looking for fearless testers of static-networking-service-type:
<ekaitz>civodul: how was this related to texlive? omg
<civodul>ekaitz: twas related to the texlive importer, which is not supposed to pull in (gnu packages ...) modules
<civodul>those modules got pulled in in guix-extra.drv, but without the patches
*jonsger will test the static network when its merged :)
*vivien too
<ekaitz>oh! thanks for elaborating
<civodul>i gather merging is the best way to get testers :-)
<civodul>sneek: seen iskarian
<vivien>At least putting it on a branch, so I can reconfigure my system
<civodul>ah, that i can do
<jonsger>civodul: as long as it won't break to much on existing use cases...
<jpoiret>anyone would be happy with a patches field for channels + guix pull transformer --with-patches?
<jpoiret>that's where i'm looking right now
<jlicht>rekado: I used guix system container, back in the day, and put the resulting script in a systemd unit file that was booted on (raspbian) boot. Seemed to work fine, once I got my operating system declaration set up
<rekado>arf, so it was me after all!
<rekado>my apologies!
<jpoiret>after i test out iso9660 installer with my patch (damn, I didn't even know this was a different filesystem altogether!)
<jlicht>ns12: It _technically_ does, but I never used guix container; I simply used guix system container to do what I needed
<rekado>I’m trying to compile Guix from a “master” checkout on my core-updates-frozen system and I get this error:
<rekado>ld: /gnu/store/5d7m9lawhw0i1i3wah86b6as3mjizgri-sqlite-3.36.0/lib/ undefined reference to `stat64@GLIBC_2.33'
<rekado>I’m doing this inside of a “guix environment --pure guix”
<rekado>upon exiting the environment I get: guix environment: error: /gnu/store/9z5rmnv7yiyrzhi5qcg7hdg97k80g61v-bash-5.1.8/bin/bash: command not found
*rekado runs ./configure again
<yewscion>Wrong window, please disregard.
<jpoiret>rekado: is that error on make? if so at which point?
<jpoiret>master has GLIBC_2.31 i think, whereas core-updates has 2.33, which is annoying when things leak into the environment
<zimoun>rekado, I think 3b1a12c5bff5a0c108284d19a6982bdf663bbceb breaks “guix pull”
*M6piz7wk[m] sent a console code block:
<M6piz7wk[m]>why is it unable to build the package?
<rekado>zimoun: civodul unbroke it already
<rekado>M6piz7wk[m]: because the package name is rust-shell2batch
<zimoun>rekado, thanks civodul for quick fix :-)
<rekado>python-numcodecs seems to be built with march=native or something like that
<M6piz7wk[m]>oh right
<rekado>I get “Illegal Instruction” on our cluster
<M6piz7wk[m]>kreyren@leonid ~/.local/share/crate2guix/guix [env]$ ./pre-inst-env guix build rust-shell2batch
<M6piz7wk[m]>guix build: error: rust-shell2batch: unknown package
<vivien>civodul, my system configuration is ready for the leap of faith, I’ll see which is more likely: the static networking service is broken, or my understanding of the network is terrible. But maybe everything will work out of the box? Who knows.
<efraim>rekado: dropping python-numpy only breaks transfig (needed for embled-enfuse and hugin), and it has a newer version upstream
<vivien>Now I’m waiting for the name of the branch to pull :)
<efraim>no, there's a newer xfig and fig2dev
<civodul>vivien: if you're already using the static 'static-networking' procedure, it should work without changing anything
<M6piz7wk[m]>did i somehow broke guix or something >.>
<civodul>you'll just get a deprecation warning
<M6piz7wk[m]>the definition seems sane
<M6piz7wk[m]>it just doesn't see it u.u
<M6piz7wk[m]>generated using:
<M6piz7wk[m]>kreyren@leonid ~/Repositories/crate2guix [env]$ cat | curl -F 'f:1=<-'
<M6piz7wk[m]>seems to be broken since the change on frozen-whatever
<vivien>civodul, ahem, right now I’m using DHCP and I tweaked the DHCP server so that it gives me a static address
<vivien>So I don’t know if things will work without making a request to the DHCP server, to be honest ^^
<civodul>vivien: if you don't use static-networking, you're not part of the target audience :-)
<vivien>I’m kind of using static networking, I add myself a static IPv6 on top of the dynamic networking
*M6piz7wk[m] continues to be in agony with guix packaging
<mahmooz>am i still able to use gcc -lSDL on guix or do i have to write a package to be able to compile?
<mahmooz>eh apparently it doesnt work but how can i get it to work
<vivien>To be clear, I’m not using static networking (and doing weird DHCP stuff) because I can’t assign myself a static IPv6. If the new static-networking service works, I’ll use it.
<mahmooz>anyone plz gotta compile this homework c program 🤣
*M6piz7wk[m] ragequits and goes to play games then w-w
<mahmooz>ye im about ragequit and reinstall arch rn lmao
<M6piz7wk[m]>mahmooz: eh? whats your issue
<M6piz7wk[m]>compiling C program?
<abrenon>mahmooz: what have you tried ? what doesn't work and why ? you should be able to open an environment with both GCC and lib SDL
<M6piz7wk[m]>`guix shell gcc -- gcc path/to/file.c` $head
<mahmooz>tried using gcc program.c -lSDL2
<mahmooz>or -lSDL
<abrenon>but what environment are you working in ?
<apteryx>mahmooz: try from an environment launched with: guix shell gcc-toolchain sdl
<mahmooz>what do you call the default system environment?
<apteryx>or run 'guix install gcc-toolchain sdl'
<mahmooz>im using that
<mahmooz>already installed both tho
<apteryx>can you paste the failure at
<apteryx>to give us some more context; perhaps the minimal source you're working with so we can try it
<mahmooz>ld just cant find the sdl lib
<mahmooz>[3dcube]$ gcc -lSDL2
<mahmooz>ld: cannot find -lSDL2
<mahmooz>collect2: error: ld returned 1 exit status
<apteryx>here's sdl2
<apteryx>in guix
<apteryx>so swap sdl for sdl2 in the above 'guix shell' command
<rekado>M6piz7wk[m]: having just added your package definition to the end of my crates-io.scm I cannot reproduce your problem.
<rekado>this is on the “master” branch.
<mahmooz>ok imma try that
<mahmooz>oh it works lol
<apteryx>neat, we avoided one ragequit instance ;-)
<mahmooz>wait so to write a package for that program i just include sdl2 in the build inputs?
<mahmooz>and which build system should i use lol
<mahmooz>i should probably learn cmake
<abrenon>it's a general pattern: when you want to learn on a project written in a given language using a given set of libraries, you open environment (either temporary or by installing them in your profile like you did) where they both the compiler/interpreter and set of libraries are installed, and work from there
<apteryx>meson if you want to hang out with the cool kids; autotools if you want something solid and well documented
<abrenon>mahmooz: if you follow typical ./configure make make install, gnu-build-system seems appropriate
<mahmooz>ight makes sense
<mahmooz>thanks alot guys
<rekado>sdl2 is a bit special: you’ll need to use sdl-union with the list of sdl2 components you want to use
<apteryx>oh; they already left
<apteryx>they may be back soon ;-)
<rekado>in a package definition this looks like this: ("sdl2-union" ,(sdl-union (list sdl2 sdl2-mixer sdl2-image)))
<apteryx>looks like it's missing a search path specification?
<abrenon>rekado: interesting ! why is that ?
<abrenon>do other libraries share this particularity ?
<M6piz7wk[m]><rekado> "this is on the “master” branch." <- Seems to be reproducible only on `core-updates-frozen`
<M6piz7wk[m]><apteryx> "neat, we avoided one ragequit..." <- now avoid mine :P
<rekado>I would suggest to avoid core-updates* as a beginner.
<rekado>it’s known to be slighhtly broken and is being fixed
<jpoiret>just saw the email about tomorrow's sprint… is starting a guix pull && guix system reconfigure overnight cheating? :)
<rekado>it’s only cheating if it works!
<jackhill>what's the difference between the texlive-latex-* packages and the texlive-* packages?
*M6piz7wk[m] is rebuilding back to master
<rekado>jackhill: the texlive-*-* packages are old
<rekado>texlive-* is the new good stuff.
<M6piz7wk[m]>i am just going to bump rust version AND YOU ALL BE HAPPY ABOUT IT
<jpoiret>i'm not so sure that's worth your time and effort
<rekado>you can bump but you can’t push ¯\_(ツ)_/¯
<M6piz7wk[m]>rekado: Why not!
<rekado>jackhill: the texlive-* stuff also generally has been checked against texlive.tlpdb
<M6piz7wk[m]>M6piz7wk[m]: none uses rust 1.48.X anymore! that was like stoneage ago
<jackhill>rekado: cool. So anything in texlive-latex-* is a candidate for migrating over?
<rekado>jackhill: pretty much, yes.
<rekado>but I also found recently that simple-texlive-package has its own set of flaws
<rekado>it installs the current working directory to the texmf-dist prefix and that’s generally pretty awful
<rekado>M6piz7wk[m]: complaining isn’t going to change it.
<rekado>also: rust-1.52 is the latest available version on the master branch
<jackhill>rekado: I see, it's still great to have a starting point. I've finally become motivated to move away from the monolithic texlive
<rekado>don’t know why you’re so hung up about 1.48
<rekado>jackhill: whee!
<rekado>there are a dozen things I’d like to change about how simple-texlive-package works — or even how the texlive-build-system works
<rekado>it’s a bit of a mess as I was figuring things out as we were getting bug reports
<rekado>BDD – bug driven development
<M6piz7wk[m]>rekado: why!
<M6piz7wk[m]>rekado: java does that since the 20s
<rekado>jackhill: you’ll see that even when simple-texlive-package is used a lot of things need to be overridden. That’s just no fun and really should be handled a level lower: in the texlive-build-system
<rekado>M6piz7wk[m]: I’m not following; I don’t know what “that” is, but frankly I also don’t really care about Java and rust and what they are doing.
<jackhill>rekado: I see, thanks for sharing your knowledge and all the work in that area. Understanding the context when reading the package definitions is really helpful
<M6piz7wk[m]>rekado: Bug driven.. whatever you ruined it -w-
<civodul>rekado: i wasn't sure about texlive-* vs. texlive-*-*
<rekado>civodul: the new ones are named “texlive-” followed by the name in tlpdb.
<rekado>the old ones were really just SVN tree subsets where the second component corresponds to the directory from whence the files were taken.
<rekado>so we’d have “-latex-”, “-generic-”, “-tex-”, etc
<rekado>but then it turned out that a package a) actually has a definition in tlpdb and thus b) can install files into various directories of the texmf-dist prefix.
<rekado>so naming things by the “component name” no longer made any sense
<civodul>for the two packages i added yesterday, i did a mixture of that
<civodul>i thought i had inferred the rule, but i hadn't :-)
<rekado>I deprecated the old names of only those packages that I have checked against the tlpdb
*apteryx throws the towel on the mutter test suite (see:
<ekaitz>yesterday I saw someone here saying their system spent hours in 100% compilation of ghc and I laughed
<ekaitz>now my sistem is in that state for 15 minutes and... -__-
<podiki[m]>apteryx: wow, and a year old issue
<civodul>ekaitz: guess what: i've been doing exactly that while reviewing a trivial patch
<apteryx>the gnome #mutter channel being completely silent doesn't help
<civodul>#muter? :-)
<apteryx>podiki[m]: it passes their CI, which uses Fedora 34
<yewscion>ekaitz and civodul: I am doing the same, haha.
<apteryx>civodul: ah!
<civodul>jpoiret: i like !
<podiki[m]>guess they have a magic machine, wonder if they tested on anything else successfully
<podiki[m]>yes, hooray for better error reporting!
<podiki[m]>apteryx: do you have to disable all the tests or can it complete with some of them consistently?
<rekado>civodul, ekaitz we should set up a shared system that compiles these things once; we could then download the result. Some sort of substitution for a local build.
<rekado>(in preparation of tomorrow’s hack we should maybe just build these things manually on…)
<apteryx>podiki[m]: I just tried with [...] meson test --suite core -v and I saw: glamor: No eglstream capable devices found
<apteryx>it then falls back to sw; xorg later prits: (EE) failed to read Wayland events: Broken pipe
<civodul>rekado: yes, but not that ghc-8.10.7 is currently missing for master
<civodul>so who's in for tomorrow's hack session?
<civodul>i'll merge master into core-updates later today in preparation...
<apteryx>civodul: what's this (hack session) ?
<apteryx>should I read my mails
<civodul>apteryx: it's about getting things done together!
<jackhill>I might be able to squeeze in one hour around 16:00 UTC.
<apteryx>sounds good
<civodul>jackhill: every minute counts! :-)
<jackhill>I think I'll "cheat" too and start builds going overnight :)
<ekaitz>btw rekado and civodul why does it get that much time? (and also, why does it stay in 100%?)
<civodul>jackhill: heh, the organization accepts that :-)
<civodul>ekaitz: no idea; the "100%" is probably because ghc's build process emits things that are wrongfully interpreted as progress indicators by (guix status)
<ekaitz>it's still running
<vivien>civodul, I’m not sure I understand the static-networking-service situation. Do you plan to push it to a branch, so that I can test it?
<vivien>(a wip branch)
<civodul>vivien: ah yes, i planned to do that but got distracted; lemme see
<civodul>vivien: pushed as wip-networking-netlink, so you should be able to time-machine that
<vivien>Thank you :)
<apteryx>is there no way to have a search path for glib schemas? searching share/glib-2.0/schemas
<apteryx>ah, already supposed to find them through XDG_DATA_DIRS
<apteryx>we have a search path for that on glib
<podiki[m]>civodul: I'm in! already tried yesterday, but waiting on that mutter bug
<podiki[m]>so my system is on core-updates-frozen from a few weeks ago
<podiki[m]>I saw some low hanging package fixes I can do (meson version change)
<awb99_>how can I configure guix to give a user permission to expose port 80 ?
<M6piz7wk[m]><awb99_> "how can I configure guix to give..." <- is that even possible on linux
<lilyp>not sure, lower 1024 are usually protected
<awb99_>it is possible.
<awb99_>I am doing it for other distros.
<awb99_>but not sure how to do it in guix.
<roptat>I guess we've never heard of it, so it's not very probably there's something ready-made for it. How do you do it on other distros? then maybe we can replicate that in guix
<awb99_>setcap 'cap_net_bind_service=+ep' /usr/bin/node
<awb99_>this is how I do it on debian
<awb99_>this allows node to listen on port 80
<roptat>I see. I don't think we can set capabilities in guix
<roptat>the closest we have are... setuid-programs I guess
<lilyp>I think you can do so on symlinks you yourself generate like setuid-programs
<lilyp>you just need to code up the gexp yourself
<roptat>er, I don't think you want to give capabilities to anything in the store
<awb99_>with setuid
<awb99_>how does it work?
<awb99_>I want to avoid runniing my app as root.
<awb99_>Because if there is some kind of exploit or error, running as root is the worst I can do.
<lilyp>ahh, they're manually copied to /run/setuid-programs and then have their setuid bit set
<lilyp>in an activation script i believe
<awb99_>what does the setuid do?
<awb99_>does it run a programm with full root permissions?
<jonsger>civodul: what do I need to delete from %desktop-services in order to get static-networking working? I remove network-manager-service-type but that seems not enough...
<jonsger>the error message is a bit non-saying to me:
<roptat>jonsger, did you cons with a non-list?
<roptat>asking because of (expecting empty list)
<jonsger>its inside a cons*
<roptat>can you share your services declaration?
<roptat>this (append #<<static-networking> addresses: (#<<network-a…> …) in the backtrace looks suspicious
<roptat>the fact that the first argument to append is not a list...
<M6piz7wk[m]>Does guix have any way to maintain stable vs unstable channel?
<M6piz7wk[m]>like in guile?
<M6piz7wk[m]>something like `(channel 'stable)`
<jonsger> ignore the to much ) at the end
<roptat>M6piz7wk[m], no we don't have the human resource for that
<M6piz7wk[m]>hm O.o
<roptat>jonsger, looks correct. I wonder, is it normal to use static-networking instead of static-networking-configuration?
<roptat>M6piz7wk[m], unless you mean 'stable as in unmaintained, of course
<M6piz7wk[m]>What would be the theory of integrating something alike? Just `(define-public thing)` that returns a package?
<jonsger>roptat: I've wrote it like Ludos example on the bug tracker ^^
<M6piz7wk[m]>roptat: rather something i can devops the hell out of automatically :p
<M6piz7wk[m]>so that it only flicks if the package passed QA
*M6piz7wk[m] is experimenting with exherbo linux-like packaging hierarchy for guix
<roptat>M6piz7wk[m], mh, I think I don't understand what you mean then. How is stable vs unstable "like in guile"?
<M6piz7wk[m]>I want to define a channel per package e.g. `(define-public (rust version) ... (channel 'stable))` and i want the package to be visible in guix for installation only when the end-user selected the stable channel
<M6piz7wk[m]>simplified.. i want to define it per architecture and stuff
<roptat>I don't understand
<M6piz7wk[m]>how do i parse a variable with a value from `config.scm`
<M6piz7wk[m]>wait that won't work
*M6piz7wk[m] goes back to drawing board
*vagrantc has often wondered about one package per .scm
<M6piz7wk[m]>i basically need guix to only build packages definitions that were selected
<vagrantc>i guess the module dependencies would get pretty ugly pretty fast
<sneek>vagrantc, you have 1 message!
<sneek>vagrantc, civodul says: i think you inadvertently recreated the core-updates-frozen-batched-changes branch; could you delete it and use core-updates-frozen instead? :-)
<vagrantc>civodul: i did the latter already :)
<M6piz7wk[m]>vagrantc: not if you define a function that returns a package definition from used version that is taken from a file name
<M6piz7wk[m]>so in theory defining modules only once and then expanding function~
<roptat>jonsger, I don't see what's wrong, maybe the problem is with the patches?
*M6piz7wk[m] is thinking about one file that defines logic for all versions and then files just call the function to define whether the package is compatible with the architecture
<roptat>M6piz7wk[m], I think this is way too complex compared to what guix is doing
<roptat>are you trying to programmatically define new packages? to create a dependency graph?
<roptat>a variable can only hold a single value, so when a package depends on another one, it can only be that one
<M6piz7wk[m]>more like defining a function which logic is influenced by the package version that can be called from a package e.g. `rust-1.54.scm` that uses the file name for the version definition, checksum and compatibility
<jonsger>roptat: found the problem. There is an (list ) around static-networking missing. He forgot it in the example, in the docu patch its correct :)
<roptat>jonsger, oh ok
<M6piz7wk[m]>let me show you how exherbo ppl are doing it with paludis
<M6piz7wk[m]>1. One repo per programming language
<M6piz7wk[m]>2. All packages have a separate library that tells the package manager how the package is packaged ( **THEN** each version has a separate file where **the file name** is used for version declaration and the **file content** for compatibility declaration
<M6piz7wk[m]>So you can define continuous delivery by just doing check for new version and automatically build + bump
<M6piz7wk[m]>~~which they don't do bcs they don't understand kloeri's genius, but still it works that way~~
<M6piz7wk[m]>So basically each `rust-version.exheres-0` is just defining metadata for the library to generate packages
<M6piz7wk[m]>which should be much more maintainable, automatible and efficient method case gentoo packaging vs exherbo packaging (gentoo taking like 5x storage space and does way less)
<rekado>efraim: thanks for fixing vigra!
<cybersyn>hiya guix, I'm packaging notcurses and want to make ffmpeg optional as a second output, bcs it is 8x the size of the package. it uses CMAKE and offers the configure flag "-DUSE_MULTIMEDIA=ffmpeg", but I haven't been able that uses different configure flags based on outputs (perhaps there is a better way -- it's my first multi-output package)
<efraim>rekado: I would've liked to create a patch to add support for later versions of numpy but it didn't look like anything needed it
<efraim>and I was short on time :)
<vivien>civodul, when I’m assigning a static ipv6 with your static networking service, the address digits are reversed!!!
<vivien>I’ve assigned 2a00:5881:4008:2810::309/64, and I get 903::1028:840:8158:2a/64
<vivien>That’s funny ^^
<roptat>M6piz7wk[m], you're basically saying guix needs to compute dependencies and solve version constraints, instead of using a static graph?
<roptat>M6piz7wk[m], the lack of a solver in guix is kind of a strength in my opinion
<M6piz7wk[m]>roptat: Not really as packages rarely change dependencies and are influenced by version change for packaging, the static graph is preserved just different method of defining inputs
<M6piz7wk[m]>What i want to experiment with is defining dependencies with which the package is known to build and i don't want to handle it through guix, but during CI so that guix just has all the info needed to complete the packaging request without figuring out what to do with the package
<roptat>I'm even more lost
<M6piz7wk[m]>ok imagine a function that returns a package definition
<vagrantc>guix has a lot of those
<M6piz7wk[m]>you are parsing version input to that function that changes the output of the function
<M6piz7wk[m]>that's it
<roptat>yeah, we have that for linux-libre for instance, or maybe even better, the package-with-python2, or package-with-explicit-ocaml family
<M6piz7wk[m]>... and checksum
<M6piz7wk[m]>roptat: yes, but it's not very automatible i want to parse this version from a file called `rust-1.2.3.scm` where the `1.2.3` is used for the version definition
<M6piz7wk[m]>so that CI can just create a file and trigger on file change
<M6piz7wk[m]>+ the `rust.1.2.3.scm` containing compatibility metadata -> The version should only show up to the user if it's known to be compatible with their arch
<roptat>it's already the case, package are not installable if they're known not to work on the user's arch
<roptat>(or one of its dependencies)
<M6piz7wk[m]>How do you integrate an auto-bumps for it on the current setup?
<M6piz7wk[m]>and environment that is designed for production systems
<M6piz7wk[m]>roptat: yes so that i can have CI that checks each X amount of seconds and bumps the package if upstream released a new version
<cybersyn>any recommendations for a multi-output package definition to reference that isn't just "out" and "doc"?
<roptat>I feel we live in a very different world...
<cybersyn>theres rust/cargo, but thats a bit more complex of reference than i need
<roptat>oh, there are updaters, but we don't do version bumps automatically
<lilyp>cybersyn: "out" "bin", "out", "lib"
<roptat>M6piz7wk[m], try "guix refresh" :)
<roptat>(or even "guix refresh -u" to write the changes to file)
<roptat>which reminds me I sould run that for ocaml...
<cybersyn>lilyp: thanks, I'm wondering if there is a specific definition that might be helpful for my case, re: having ffpmeg as an output?
<roptat>but, I have a paper to write, and it won't write itself...
<roptat>see you!
<M6piz7wk[m]>... ehh oke
*M6piz7wk[m] didn't know that guix has updaters which makes the work significantly easier
<M6piz7wk[m]>still not automated and without control for production 🤔
<cybersyn>I'm trying to understand how a different output could be based on building with a different set of #:configure-flags
<roptat>I like QA on production :p
<M6piz7wk[m]>roptat: yes, but not a great idea for QA on production to hotfix all packages for production x.x
<M6piz7wk[m]>better to make QA on production to work on tests for the upstream that are taken by the distro
<M6piz7wk[m]>since guix is not doing any customization for that to matter in packaging definition
<ss2>could someone maybe explain this to me? I've written an mcron task that is now part of my declaration. It written all in Guile that basically downloads a file to a directory. I've noticed now that the output of file is written in ASCII, while if I call this function in my REPL the output is in UTF8.
<ss2>Something somewhere is telling me that this process is called in ASCII? Would I have to declare $LOCALE?
<lilyp>ss2: call (setlocale) at the start of your script
<civodul>vivien: re reversed IPv6 digits, you sure? you're looking at the output of "ip a"?
<vivien>ip -6 address
<civodul>roptat: could it be that something in guile-netlink reverses digits?
<civodul>inet-pton presumably does things right
<civodul>but then, could it be that the netlink protocol expects big-endian (network order?) integers, and guile-netlink sends them using native endianness?
<vagrantc>civodul: so, how does one delete a remote branch in git? haven't done that before ...
<civodul>vivien: can you do "herd stop networking", then "strace -f -o log -s 500 -p1" and "herd start networking"?
<civodul>vagrantc: i always forget the right incantation but i can do it for you (Magit knows how to do it :-))
<vivien>Let me reboot first
<roptat>vagrantc, git push :foo to delete foo
<civodul>ah right
<roptat>ah I really shouldn't be on IRC :/
<civodul>i've removed core-updates-frozen-batched-changes
<ss2>lilyp: thx!
<vagrantc>wow, that's unintuitive
<vagrantc>civodul: thanks, sorry for the confusion ... i guess i needed to prune my remote branches or something
<efraim>`git fetch --prune`
<jackhill>vagrantc: there's also now a --delete option to git push
<vagrantc>jackhill: that seems more intuitive
<jackhill>vagrantc: yeah, I think it's been a few years now, but I remember when it got added because of that. I think the mnemonic for the other way is pushing nothing to the remote branch label removes it, which makes … some kind of sense :)
<vivien>civodul, huh, I’m not sure I can, in fact. The graphics card is weirdly supported, so the screen is frozen, and I usually operate via SSH. Could you design a script that I would run in GNU screen without interaction?
<vivien>Stupid me, I just have to run the commands
<vagrantc>still having issues building guix on Debian i386 ... looks suspiciously similar to the guile libgc issues
<apteryx>oh, I'm guessing the mutter test suite fails due to ES2 being dynamically loaded (needing patching) in mesa
<apteryx>I enabled that recently, probably overlooked that bit
<mahmooz>i think the fact that the default iso doesnt contain necessary wifi drivers for most machines is gatekeeping alot of people
<mahmooz>i myself tried to install it a few months ago and i got so frustrated with it and eventually gave up
<vivien>Huh, if I do herd stop networking, I can still access the network.
<mahmooz>until recently i installed it in a vm and generated an iso with wifi drivers to be able to install it
<vivien>(sorry I should ping the people)
<vivien>civodul, if I do herd stop networking, I can still access the network, and I still have my IP addresses
<vagrantc>... hrm ... mmap(PROT_NONE) failed
<vivien>Does that count as a bug?
<civodul>vivien: hmm did you apply v2? v1 indeed had that bug
<vivien>I applied whatever you put in the wip-networking-netlink branch :)
<jonsger>I applied that from the branch, but I rebooted the system as stoping the networking service failed...
<apteryx>mahmooz: as in free software wifi drivers? guix as a gnu project is committed to free software; so unless the drivers are free software, it's not something that we want to do.
<jackhill>civodul: after reconfiguring from the wip-networking-netlink branch still using my legacy operating system definition, the networking service doesn't seem happy:
<jackhill>(I did not reboot)
<vivien>jackhill, I had the same, but if you reboot it works
<jackhill>vivien, jonsger: ah cool
*jackhill mutters about the evils of state :)
<vivien>jackhill, jonsger, did you configure an IPv6 address?
<jonsger>vivien: nope
<jonsger>but I have one ^^
<roptat>jonsger, it's probably just a link-local address, starts with fe80::
<jonsger>yeah, and another one from my ISP
<jackhill>vivien: not yet, but I will later
*vivien infers that jonsger lives in a civilized place
<jonsger>starting with 20a1:c22
*jonsger is not so happy with its ISP. As DSL training doesn't work with Turris Omnia :(
<vivien>civodul, from the dates, it looks like wip-networking-netlink hosts your v2
***mark__ is now known as mjw
<roptat>vivien, can you check if guile-netlink does the right thing?
<vivien>How would I do that?
<vivien>I guess the first step would be guix time-machine -- shell guile guile-netlink -- guile
<roptat>mh, ,use (ip addr) (addr-add "eno1" "20a1:c22::1/56" #:ipv6? #t)
<roptat>yes, maybe strace that so we can see exactly what message is being set
<vivien>I don’t know how to use strace
<vivien>How should I call it?
<vivien>Invoke it rather
<roptat>strace -f guile?
<roptat>not sure about the options you'd use
<roptat>strace -f -o trace.log guile
<roptat>(oh in the command above, replace eno1 with the name of your device)
<rekado>there’s a chance of getting new hardware for
<vivien>That’s eno1
<vivien>Who’s paying for the electricity?
<vivien>For the CI
<rekado>Madalin and I were thinking about replacing the head node with two new servers. They would be replicates of one another, each with locally attached storage (instead of this external storage array).
<rekado>vivien: the MDC
<rekado>(and thus the German tax payer, I guess)
<vivien>I don’t know what the MDC is
<vivien>I guess D and C is for Data Center
<roptat>almost :)
<vivien>Did you consider running crypto mining?
<rekado>no, we use the HPC cluster for that.
<roptat>we need to create our own crypto, with proof of packaging
<vivien>Distributed consensus based on bootstrapping each Rust commit
<vagrantc>yeah, create a package with a derivation hash with a certain number of leading zeros, profit! what could possibly go wrong.
<rekado>anyway, the plan is to get two servers with 40 * 16TB disks each; and then use the external storage array for things other than /gnu/store and the substitute cache.
<rekado>one thing I’m not sure of is software RAID and multipath support.
<lilyp>I do like the idea of a cryptocoin that can be challenged by a timestamp in some build :)
<vivien>roptat, strace: decode_nlattr: [xlat 0x4e1940, dflt "AF_???", decoders 0x7fff0109db18] size is zero (going to pass nla_type as decoder argument), but opaque data (0x7fff0109dbb0) is not - will be ignored
<vivien>strace: decode_nlattr: [xlat 0x4e1940, dflt "AF_???", decoders 0x7fff0109db18] size is zero (going to pass nla_type as decoder argument), but opaque data (0x7fff0109dbb0) is not - will be ignored
<vivien>$1 = #t
<rekado>is multipath + mdadm known to work in the early boot?
<vivien>And the ip address is reversed
<roptat>vivien, I'll need trace.log
<roptat>vivien, fun (:
<vivien>Have fun :)
<roptat>sendto(16, {{len=64, type=RTM_NEWADDR, flags=NLM_F_REQUEST|NLM_F_ACK|NLM_F_EXCL|NLM_F_CREATE, seq=50621, pid=0}, {ifa_family=AF_INET6, ifa_prefixlen=56, ifa_flags=0, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eno1")}, [{{nla_len=20, nla_type=IFA_LOCAL}, inet_pton(AF_INET6, "100::220c:a120")}, {{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "100::220c:a120")}]}, 64, 0, NULL, 0) = 64
<roptat>looks like I reversed everything
<vivien>You were hiding in my computer all along!
<roptat>vivien, just to be sure, which architecture are you on? (not that it should matter)
<vivien>lscpu says little endian
<lilyp>as one would expect from x86 :)
<roptat>ok, I guess this reverse is the culprit:
<roptat>what happened when I wrote that? :)
<awb99>I am trying to run certbot in guix, and get the error: Permission denied: '/var/lib/letsencrypt'
<civodul>jackhill: does "herd stop networking" (making sure the interfaces are down) followed by "herd start networking" work better?
<lilyp>have you tried certbot-service-type? :)
<civodul>(errno 17 is EEXIST, which means the address/route is already there)
<civodul>roptat: heh, indeed, plain reverse :-)
<civodul>rekado: oh, new hardware, sweet!
<civodul>we'll need to pay the German taxpayer a beer one of these days
<civodul>(or other beverage of their choice)
<rekado>I should note that we’re still in the process of bidding, competing with other departments. But we should know soon whether we can go ahead.
<rekado>most important for us is to know whether we will be able to use Guix System like this, i.e. all disks local, access via mdadm and multipath.
<civodul>right, you did a great job getting that set up back then, but the road was bumpy
<rekado>and it still isn’t nice. We have to be much too careful when rebooting the thing, so I’d much rather have something simpler with local storage.
<rekado>(and two of these machines so we can take one down for maintenance without making everyone sad)
<civodul>yeah, that'd be better
<civodul>"guix size ghc" -> 1.6GiB?!
*apteryx discovers the gles2_libname mutter build option
<apteryx>getting close
<podiki[m]>just in time for tomorrow's c-u-f push!
<vivien>c-u-f starts to look good, I could finally reconfigure my home :) Thank you! Now the only obstacle is issue 51916.
<rekado>I’m still building libreoffice
<rekado>and I’ll probably build ungoogled-chromium until tomorrow.
<awb99>lilyp - I do not want to use certbot as a service. I want to use it standalone for testing. Do you think adding the service mitght beimportant to make the package work?
<vivien>roptat, will you make a new guile-netlink release?
<zimoun`>rekado: that’s cool!
<roptat>vivien, well, I guess ^^'
<vivien>Don’t forget to sleep too, depending on your location
<vivien>(well, depending on your location, sleeping should happen at different times ^^)
<roptat>thanks :)
<roptat>I'll probably write some tests to check the various functions, with different parameters etc
<roptat>I don't want to publish a new version just to be embarrassed by another bug :p
<rekado>awb99: do you have permissions to read from / write to /var/lib/letsencrypt? Does the directory exist?
<roptat>should familiarize myself a bit more with srfi-64 (iirc)
<vivien>That’s in my to-do list too, for now I have (exit 1) as my test suite
<mbakke>ooh, wip-networking-netlink looks really nice
<vivien>mbakke, there’s a known problem with IPv6 addresses, and you will need to reboot if you want to apply it properly :)
<awb99>rekad - the thing is that /var/lib/letsencrypt does not exist!
<mbakke>vivien: thanks for the heads-up. Reboot is OK, at least as long as reconfigure does not break the running network configuration (on remote nodes).
<mbakke>I guess I can just put in the IPv6 address in reverse order for now :P
<vivien>Or you put both :)
<drakonis>any reason linux 5.15 hasn't been included yet?
<drakonis>civodul: so, how do i participate on the sprint :V?
<mbakke>rekado: perhaps it could work to run ci.guix as a big VM on the two nodes? with DRBD disk mirroring?
<civodul>drakonis: get yourself ready with a core-updates-frozen checkout; then rekado highlighted a couple of important issues, but otherwise you can just look for other issues yourself, for instance by upgrading your user profile or system
<drakonis>the checkout is ready
<civodul>ready to go!
<drakonis>just figuring out how to switch to it
<civodul>you can try things like "./pre-inst-env guix upgrade -n" to get a feel
<drakonis>hm, i see
<vivien>What’s the sprint? Is it a race to fix issues?
<drakonis>i wanted to build my system with it
<civodul>vivien: yes, tomorrow
<podiki[m]>i'm excited about the sprint, ready to get c-u-f done
<drakonis>i was going to set it up as a channel
<civodul>you could also "guix time-machine --branch=core-updates-frozen", but you'll need a checkout anyway
<vivien>Too bad vigra has been fixed already :)
<drakonis>that doesnt work for system reconfigure, does it?
<podiki[m]>or just straight guix pull --branch=core-update-frozen (or change your channels.scm like I did)
<podiki[m]>but currently can't reconfigure due to the mutter test suite (being worked on by better minds than me)
<drakonis>gnome, heh.
<podiki[m]>(even though I don't use gnome, but some deps, or via gdm?)
<podiki[m]>this is why I don't gnome, I guess I've backslid in guix
<drakonis>gnome 41 is good though
<drakonis>glad its finally here and in a timely manner!
<drakonis>was asking how to do it because i wasnt sure if my hacky channels setup where i copied the guix channel definition was the way to go
<civodul>i think it's GNOME 40, not 41
<civodul>still a significant improvement though :-)
<drakonis>no i think it got bumped to 41 now
<civodul>oh really?
<civodul>this branch is just wild
<civodul>we won't recognize our systems when we finally merge it :-)
<zimoun`>civodul, for tomorrow, “guix time-machine --branch=core-updates-frozen -- weather“ reports a lot of missings. Is it expected?
<drakonis>it was sneaked into it the branch earlier this week
<zimoun`>for instance, a lot of R packages.
<civodul>zimoun`: what do you think? :-)
<drakonis> lots of 41.0 packages here
<zimoun`>hehe! :-) Are they broken or Cuirass does not build them?
<drakonis>mutter is still 40 apparently?
<apteryx>working on it
<drakonis>so not everything got bumped
<civodul>zimoun`: dunno, i suppose we'll have to investigate
<drakonis>a work in progress, it seems.
<civodul>besides i'm reconfiguring berlin so it has the new daemon and spends less time "removing unused links"
<apteryx>thanks for working on a fix for that
<drakonis>civodul: i guess its mainly 40, no complete 41 yet
<podiki[m]>the CI has been suffering a bit it seems
<podiki[m]>a big evaluation from last week was restarted yesterday, but is still slowly going through aarch64
<podiki[m]>(I think that set is where a lot of i686 died when low level deps failed with space running out)
<podiki[m]>also, makes checking why things failed difficult (impossible)
<apteryx>drakonis: nice thing is that it doesn't seem to matter, according to raghavgururajan; (40 vs 41), so we can continue upgrading to 41 at our pace if it already works on 40.
<drakonis>that's great to hear.
<zimoun`>civodul, hum… so tomorrow my carbon footprint will be done. ;-)
<drakonis>also, just so y'alls know, we've opened #guix-chat a while back
<drakonis>wrong one
<drakonis>its #guix-offtopic you want
<civodul>neat, didn't know
<drakonis>i have something i want to test now
<drakonis>the older gnome release on the master branch has some issues with wine, i want to find out if these are still around if i'm on a fresher gnome release
*civodul attemps master -> core-updates-frozen merge
<nckx>drakonis: Made me do a double take there for a moment.
<drakonis>welp, there is a lot of things that have to be compiled right now in cuf
<drakonis>nckx: hehhhhhh
<drakonis>somehow, firefox isnt getting mass rebuilt
<nckx>Opposite day.
<podiki[m]>I haven't been able to use wine on c-u-f in forever (gtk+-3 was failing on i686 maybe?)
<podiki[m]>related to the pixbuf changes, but haven't tried recently (waiting for other things to get fixed/built)
<drakonis>i sure hope mesa and libglvnd finally get the touchups they need
<nckx>detrout: Hello and welcome to #guix! also explain yourself.
<drakonis>after 1.4.0 releases
<daviid>rekado: fwiw, i forgot to mention that vigra is also used by hugin, which
<daviid>is in guix as well ...
<vagrantc>so, if we did switch make dist to use a different tar format, we could ignore the silly file-length-in-tarballs issues and remove the guix lint warning about it ... but ... that requires fighting with autotools/automake/auto* and convincing it to pass another argument to tar
<mbakke>drakonis: do you know if anyone is working on libglvnd?
<drakonis>i don't think anyone's currently working on it
<rekado>no worries, I know that vigra is used by a bunch of things (guix refresh -l vigra). I just mention libreoffice because it’s big and popular.
<vagrantc>and ... maybe there are bootstrapability contraints to consider, using a tar format more recent than the late 80s ?
<drakonis>there was some movement a while back
<drakonis>getting libglvnd to function should make guix a viable option for foreign distributions
<drakonis>mbakke: why do you ask?
<rekado>mbakke: re drbd: maybe! But I dread having to maintain the host OS (if that’s not also Guix System).
<mbakke>drakonis: no particular reason, I looked into it a while back and did a naive experiment without success
<mbakke>I don't have any foreign libGL to test with, though
<mbakke>Guix already works fine on foreign systems that are supported by Guix's Mesa, no?
<drakonis>the first step is to get applications linked with libglvnd to run first
<jackhill>civodul: herd stop networking doesn't seem to actually bring the interfaces down
<drakonis>i don't think so, but then, i don't have hardware that likes mesa
<drakonis>i think i'm going to do an experiment to check it out
<drakonis><- nvidia gpu
<civodul>jackhill: are you testing with IPv4 or v6?
<mbakke>rekado: I think I can write a system service for such a setup
<mbakke>'herd migrate guix-ci' sounds fun :)
<drakonis>libglvnd is supposed to prevent issues arising from having multiple libgls on the same system
<drakonis>and to let those libgls read from each
<drakonis>also, if i remember correctly
<drakonis>anyhow, it needs work
***janneke_ is now known as janneke
<rekado>mbakke: :) that would be great!
<jackhill>civodul: just v4 for now in the service. This network as slaac though, so a v6 address is being set
*jackhill -> dinner
***xgqtd is now known as xgqt
<podiki[m]>we had a patch for mesa updated with libglvnd and some discussion on modifying packages that hardcode libgl
<podiki[m]>that would be step 1, making sure that works, and then seeing what happens on something with multiple libgl (needs to know at build? not sure how it works)
<podiki[m]>I should say mesa with libglvnd is just a quick change in the package def, but beyond that I'm not sure what else
<jackhill>civodul: manually removing the ip works
<jackhill>ok, so first test, it seems happy with the deprecated style, now to port over to the new, but this is a fairly boring single static ip case.
<jackhill>I was really excited to test v6, but I guess I'll hold off for a little bit there :)
<mbakke>rekado: it's already possible today by copy-pasting the examples from the ganeti blog post FWIW, but then you have to maintain a Ganeti cluster :P