<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]! <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]>if this can all be addressed better, not saying „fixed“, it’s not trivial and I’m happily awaiting it ;) <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]>for now I’m doing it with kernel arguments which seems a bit overdosed^^ <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) <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 <jgart>It's a library for typesetting sheet music with lisp <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 <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 <zamfofex>I think the problem is that there is no good way to differ the URL between versions. <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 <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? <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. <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") <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>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) <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. <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>podiki[m], do you happen to remember the command of the top of your head to check those transitive deps? <jgart>is there a way to show transitive deps as a ascii list? <podiki[m]>this exhausts my knowledge, but guix graph clikan | grep pandoc does show pandoc in there <lilyp>you might want to do BFS still, so that you can announce some levels <xelxebar>jgart: guix gc --requisites not what you're looking for? <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]>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]>> <@florhizom:matrix.org> 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 <jgart>florhizome[m], Could you share the package definition <jgart>what version of mutter does gala need? <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 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^^ <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] 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. <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 ***wielaard is now known as mjw
<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>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 <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. <jgart>florhizome[m], have you tried wgetpaste? <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]>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>jlicht: is there a convenient way to configure a faux system on top of another distro, system services included? <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] is trying to build guix on alpine linux docker to get cached build to speed up the crate2guix thing *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 <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’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. *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? <rekado>M6piz7wk[m]: ? Guix does have docker. <rekado>and it’s impossible to address your comments when you don’t respond to requests of clarification <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? <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? <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 <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@7.1.4.2 hugin@2020.0.0 enblend-enfuse@4.2 are the packages which use it directly <rekado>the patch seems to exist, and it’s listed in gnu/local.mk as well <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 :) <vivien>M6piz7wk[m], join us at 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] 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>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? <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 <singpolyma>It would be possible to have a service that scans all known upstreams, and even tries to auto-update <singpolyma>vivien: nice, that's even better than I expected <ekaitz>hi, I have problems doing guix pull atm <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? <civodul>rekado: nice stuff regarding the texlive importer! tests/texlive.scm needs an update tho :-) <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) <civodul>ekaitz: fixed in 21357224bc1f450931fb3a64fe6d06f9d1137b67! <civodul>on behalf of Guix Inc., apologies for the inconvenience <vivien>Does Guix Inc. stand for Guix Inconveniences? <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 :) <civodul>i gather merging is the best way to get testers :-) <vivien>At least putting it on a branch, so I can reconfigure my system <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? <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 <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/libsqlite3.so: 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 <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” <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 <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 <civodul>you'll just get a deprecation warning <M6piz7wk[m]>kreyren@leonid ~/Repositories/crate2guix [env]$ cat crate2guix.sh | curl -F 'f:1=<-' ix.io <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 <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 <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' <apteryx>can you paste the failure at paste.debian.net? <apteryx>to give us some more context; perhaps the minimal source you're working with so we can try it <mahmooz>collect2: error: ld returned 1 exit status <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. <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 <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 <rekado>sdl2 is a bit special: you’ll need to use sdl-union with the list of sdl2 components you want to use <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>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? :) <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 ¯\_(ツ)_/¯ <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>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>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>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 <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 <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... -__- <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 <apteryx>podiki[m]: it passes their CI, which uses Fedora 34 <yewscion>ekaitz and civodul: I am doing the same, haha. <podiki[m]>guess they have a magic machine, wonder if they tested on anything else successfully <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 ci.guix.gnu.org…) <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) ? <civodul>apteryx: it's about getting things done together! <jackhill>I might be able to squeeze in one hour around 16:00 UTC. <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) <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? <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 <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_>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 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_>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_>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... <roptat>jonsger, did you cons with a non-list? <roptat>asking because of (expecting empty list) <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? <roptat>M6piz7wk[m], no we don't have the human resource for that <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] 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 <M6piz7wk[m]>how do i parse a variable with a value from `config.scm` *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? :-) <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 :) <M6piz7wk[m]>let me show you how exherbo ppl are doing it with paludis <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 <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 <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 <M6piz7wk[m]>ok imagine a function that returns a package definition <M6piz7wk[m]>you are parsing version input to that function that changes the output of the function <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]>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 <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... *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 <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"? <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 :-)) <roptat>vagrantc, git push :foo to delete foo <roptat>ah I really shouldn't be on IRC :/ <civodul>i've removed core-updates-frozen-batched-changes <vagrantc>civodul: thanks, sorry for the confusion ... i guess i needed to prune my remote branches or something <jackhill>vagrantc: there's also now a --delete option to git push <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 <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. <vivien>jackhill, I had the same, but if you reboot it works *jackhill mutters about the evils of state :) <vivien>jackhill, jonsger, did you configure an IPv6 address? <roptat>jonsger, it's probably just a link-local address, starts with fe80:: *vivien infers that jonsger lives in a civilized place *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>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 <roptat>not sure about the options you'd use <roptat>(oh in the command above, replace eno1 with the name of your device) <rekado>there’s a chance of getting new hardware for ci.guix.gnu.org <vivien>Who’s paying for the electricity? <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>(and thus the German tax payer, I guess) <vivien>I guess D and C is for Data Center <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 <rekado>is multipath + mdadm known to work in the early boot? <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) <lilyp>as one would expect from x86 :) <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>we'll need to pay the German taxpayer a beer one of these days <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) *apteryx discovers the gles2_libname mutter build option <vivien>c-u-f starts to look good, I could finally reconfigure my home :) Thank you! Now the only obstacle is issue 51916. <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? <vivien>Don’t forget to sleep too, depending on your location <vivien>(well, depending on your location, sleeping should happen at different times ^^) <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 <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 <civodul>you can try things like "./pre-inst-env guix upgrade -n" to get a feel <vivien>What’s the sprint? Is it a race to fix issues? <podiki[m]>i'm excited about the sprint, ready to get c-u-f done <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) <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>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>still a significant improvement though :-) <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`>hehe! :-) Are they broken or Cuirass does not build them? <civodul>zimoun`: dunno, i suppose we'll have to investigate <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]>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) <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. <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>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>somehow, firefox isnt getting mass rebuilt <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. <daviid>rekado: fwiw, i forgot to mention that vigra is also used by hugin, which <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>getting libglvnd to function should make guix a viable option for foreign distributions <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 <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 ***janneke_ is now known as janneke
<jackhill>civodul: just v4 for now in the service. This network as slaac though, so a v6 address is being set ***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>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