IRC channel logs

2019-07-15.log

back to list of logs

<minall_>Hello guix!
<minall_>Is there a way of improving a driver, I loaded the driver for my graphics card, but the performance is not as good as a propietary one
<minall_>Is there a way to improve a graphics driver on guix? I installed my graphics driver succesfully, but the performance is poor than a propietary system for example, or maybe I'm not loading something
<pkill9_>minall_: if you're running nvidia then the performance isn't going to be good without the proprietary driver, so unfortunately guix isn't good for systems running an nvidia gpu
<minall_>Yes, but I'm running VIA, so I need the xf86-video-openchrome driver... But is there a way to improve the driver, because the performance is not good, or is there a way to improve the performance but still use free driverS?
<rvgn>nckx I lost the link you sent me regarding TargeTube something? Can you please resend the link? Thanks!
<raingloom>heey, anyone knows how to get sftp mounting to work? i can't find anything in /run/user/$UID/gvfs but I can browse it in Thunar
<raingloom>(it=the sftp mountpoint)
<civodul>mbakke: re core-updates, done!
<civodul>i don't remember if it needs a new push or not
<mbakke>civodul: \o/
<civodul>yay!
*vagrantc uploaded guile-ssh to Debian today ... and waits for review ...
<vagrantc>one more step in the process
<mbakke>We are going to need more ARM nodes if we want to merge it any time soon, though.
<mbakke>vagrantc: awesome :-)
<vagrantc>scheme-bytestructurs is hung up, but once that goes through i can upload guile-git ... and then it's pretty much down to getting the gnutls maintainer to re-enable the guile bindings
<vagrantc>also working on getting mes and freinds into Debian...
<civodul>mbakke: i've done something that should trigger a re-evaluation of 6389
<civodul>vagrantc: good to see that!
<mbakke>civodul: Great, ty :-)
<mbakke>civodul: it does not look quite allright though: https://ci.guix.gnu.org/jobset/core-updates-core-updates
<mbakke>Now it looks good :)
<mbakke>I'm getting a lot of WARNING: (guix store database): imported module (guix build syscalls) overrides core binding `AT_SYMLINK_NOFOLLOW' on offloaded builds after switching to core-updates.
<rvgn>civodul mbakke core-updates done???
<mbakke>rvgn: now ... we wait.
<rvgn>mbakke Ah I see. I just saw civodul's msg and got excited :D
<civodul>mbakke: re AT_SYMLINK_NOFOLLOW, yes, that's because Guile 2.2.6 provides it too
<civodul>i'll take care of it tomorrow
<civodul>night!
<mbakke>gn
<quiliro>saluton Guix
<Dynamicmetaflow>Hey everyone, out of curiousty does anyone have a simple example of how to use guix workflow
<quiliro>no hay...no idea!
<Dynamicmetaflow>hola quiliro, lo encuentro curioso el workflow language, me pregunto para que otras cosas se puede usar afuera de data science etc
<quiliro>ordonez
<Minall>quiliro: Kiel vi fartas!
<Minall>Hello guix!
<quiliro>saluton Minall ...kio (qué) vi faras?
<quiliro>Dynamicmetaflow: revisaste https://www.guixwl.org/ ?
<Dynamicmetaflow>si pero ni se como corerlo
<quiliro>Dynamicmetaflow: pienso que esas páginas estás obsoletas porque gwl ya está incorporado en guix y debe estar en el manual pero encontré esto https://www.guixwl.org/getting-started ...revisa si es actual
<Dynamicmetaflow>si trate pero no estoy seguro todavia ni como ser hello world
<Dynamicmetaflow>no se si es porque no entiendo o el documento
<quiliro>Dynamicmetaflow: revisaste los logs de la lista de correos? https://lists.gnu.org/archive/html/gwl-devel/
<Dynamicmetaflow>si lo estaba revisando, pero creo que voy a regresar a esta tema otro dia
<Dynamicmetaflow>ya esta in poco tarde
<quiliro> https://git.savannah.gnu.org/cgit/gwl.git/tree/README.md
<quiliro>Dynamicmetaflow: eso parece que dice cómo empezar
<raingloom>hey, so, I wanna test a package before sending the patch and have a local copy of guix, i ran ./bootstrap followed by make test but it failed. what do?
<Dynamicmetaflow>bueno, ahora hice un paso
<Dynamicmetaflow>gracias quiliro
<quiliro>ok
<Fzer0>hello, new user here. I am trying to understand environments and have a few questions. Would the closest thing to a python (conda envirionemnt) be using the --manifest flag.
<Fzer0>?
<ryanprior>Fzer00: like a Python environment file, you can use a manifest file. In that way it's similar.
<ryanprior>Not all Python packages from pypi are in Guix yet, but there's an importer (see https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-import.html)
***MinceR_ is now known as MinceR
<roptat>hi guix!
***nalkri is now known as Guest18976
***apteryx is now known as Guest94032
***zacts is now known as Guest58212
<civodul>Hello Guix!
<roptat>civodul, have you seen my reply to the sysadmin list? I was pointing out that doc/build.scm doesn't create an index.html for /manual/, and there is no doc/build.scm on the 1.0.1 branch
<roptat>do we want to build the manual for that branch or for master or both?
<civodul>roptat: i think i cherry-picked doc/build.scm in the 1.0 branch last Friday, no?
*civodul checks
<civodul>yeah commit 48aa30ce73d45dc5f126f42f01e65f1be4a9b578
<roptat>but that's not in version-1.0.1
<civodul>it is
<civodul>ah no!
<civodul>crap
<civodul>sorry
<roptat>I see it only in version-1.0.0
<roptat>don't worry :)
<roptat>so... I'll push my patch to the berlin configuration this evening then
<civodul>ok
<roptat>then, what will be left before we can redirect from gnu.org?
<civodul>did you figure out how to handle the PDF files that are not in the repo?
***ng0_ is now known as ng0
<roptat>oh, not yet
<roptat>I think we should simply have a separate directory on the server...
<civodul>yeah, let's do that
<jonsger>hm, building guix from source fails on core-updates with http://paste.opensuse.org/view/raw/33468057
<civodul>oh
<civodul>could it be that the build system ends up loading (gnu packages bootstrap) from master?
<civodul>like from /usr/share/guile or something
<rekado_>ugh, TeX is such a mess
<rekado_>everything about my approach to TeX in Guix feels so wrong.
<rekado_>the whole TeX Live distribution is designed to operate on shared mutable state and resists modularization at every turn.
<rekado_>I’m trying to get us to a usable modular TeX Live distribution, but it is pretty hacky.
<rekado_>the countless configuration files provided by the TeX Live distribution itself assume a complete installation with any possible feature enabled.
<jonsger>civodul: I assume, as in "guix environment --pure guix" it works fine
<rekado_>the Guix way to deal with this sort of thing would be to do all the work in a profile hook, but the work that has to be done is really slow.
<rekado_>(e.g. building all enabled “formats” for all enabled hyphenation patterns)
<rekado_>the tlpdb turns out to be not as helpful as we hoped; it does not tell us what files are generated and it contains some backwards (and some woefully incomplete) dependency information.
<rekado_>I finally got back to a working build of texlive-latex-base after reshaping and packaging many of the early texlive-* packages, but it’s still ugly.
<civodul>uh, you're a hero, rekado_!
<davidl>I just installed the pcre package but didn't get any pcregrep in my PATH, is that normal?
<rekado_>davidl: pcre has a bunch of outputs.
<rekado_>davidl: the “bin” output provides the executables.
<davidl>rekado_ yeah I thought it would too based on the package def, so not sure why it doesn't work for me.
<davidl>rekade_ odd thing is I got the manual pages.
<davidl>Ill try to relogin
<rekado_>david-l[m]: did you install the ’bin’ output of that package?
<rekado_>davidl: did you install the ’bin’ output of that package? Logging out and in again won’t help if you haven’t installed the right output.
<davidl>rekado_ hmm, I thought it did that by default - I just did guix package -i pcre.
<rekado_>do “guix install pcre:bin”
<davidl>rekado_: thx that did it. The pcre2 package on the other hand installs the bin output by default.
<rekado_>no, it doesn’t. It only has one output, which includes the “bin” *directory*.
<pkill9_>are multiple outputs used to save download bandwidth? since if you build it then it has to build all the outputs anyway
<rekado_>pkill9_: no, the reason is to keep the package closure small for packages that depend on one part of the package, but not on other parts that may be large.
<davidl>rekado_: I just now did guix package -i pcre2 and got pcre2grep in my path.
<pkill9_>what's the package closure?
<pkill9_>or more generally, a closure
<rekado_>davidl: yes, as I wrote “pcre2” only has one output, so naturally you’ll get all files that are provided by the package.
<davidl>aha ok. then I understand.
<rekado_>pkill9_: “closure” is a computer programming term (for different things, actually, but let’s not get into that)
<rekado_>pkill9_: say you have a procedure that references variables that are not bound by itself but that are defined in the enclosing environment.
<rekado_>pkill9_: the procedure together with the referenced variable bindings would be called a “closure”.
<rekado_>pkill9_: for packages we use the same term to mean a package including all of the packages it references.
<pkill9_>ok
<rekado_>you may have a really tiny package that depends on some library that is very large. The package closure then would be very large even though the package itself is small.
<rekado_>packages that are near the roots of the package graph that Guix describes can contribute significantly to the size of individual package closures.
<rekado_>to keep package closures small we will sometimes split up packages into separate outputs, especially when those packages are generally found near the roots of the graph.
<rekado_>this way a package needing only the pcre libraries will not have to include the executables that it has no use for.
<rekado_>splitting things up only really makes sense when there are independent files of considerable size for disjoint uses.
<rekado_>we often move large documentation files to a separate output, for example.
<pkill9_>what's the benefit of smalle rpackage closures? I assume speed?
<rekado_>smaller disk images, smaller “guix pack” containers/tarballs, etc
<rekado_>it’s also nice to download fewer things that aren’t actually needed
<rekado_>(see modular texlive vs monolithic texlive for an extreme example of why it is nice to download smaller things :))
<rekado_>a real-life example is PiGx, the genomics pipelines that my colleagues and I have been working on.
<rekado_>the exported Docker container image for PiGx is nearly 5GB in size, and a big chunk of that is due to files that we aren’t even using.
<rekado_>(a big chunk is Qt for pyqt for matplotlib)
<pkill9_>why are packages split into different outputs instead of different packages? (i assume because it means you only have to build the package once?)
<rekado_>pkill9_: yes, that’s the primary reason.
<rekado_>from a user perspective there is little difference. Installing “pcre:bin” (the “bin” output of the “pcre” package) or “pcre-bin” (a separate package with that name) is just a single character difference.
<pkill9_>yea
<pkill9_>i think some packages can potentially confuse that, e.g. alsa-lib, alsa-plugins, but i think upstream those are actually separate packages that use those names, so i guess it's clearer
<roptat>pkill9_, you can use "guix build pcre" to get a store path to all outputs of pcre, and then "guix size /gnu/store/...-pcre" to get the size of the closure
<roptat>pcre:bin is 78.7 MiB whereas pcre is only 69.6 MiB
<roptat>most of the size is contributed by glibc and gcc:lib
<rekado_>that’s also the reason why glibc-locales is a separate package, because that would make everything even bigger.
<roptat>I wonder if we could split gcc even further into gcc:lib and gcc:libstdc++ or something?
<civodul>roptat: i think we should split LLVM first!
<civodul>it's terrible
<civodul>just adding an "include" output would already be an improvement
<roptat>I see
<civodul>since MESA pulls LLVM, we pretty much all end up with a copy of LLVM
<roptat>what does MESA need from it?
<civodul>for some Gallium-ish rendering thing
<civodul>i'm really not familiar with these things
<civodul>if you do "ls $(guix build llvm)/lib", you'll see that it contains all the backends that LLVM supports
<civodul>and that's certainly unnecessary for MESA
<roptat>ok
<roptat>I've seen mariadb too for gtk applications, I wonder why...
<roptat>I remember therer was a script to cut "guix graph" between two packages...
<rekado_>it also needs it for the OpenCL toolchain (but I put that in a separate package)
<roptat>oh, actually it's via qtbase, not gtk at all
<roptat>mh.. icecat -> ffmpeg -> sdl2 -> fcitx -> extra-cmake-modules -> qtbase -> mariadb
<rekado_>oof
<roptat>mh... but actually it's not referenced, so maybe guix only downloaded it for some build...
<roptat>but now I wonder what qtbase needs from mariadb
<roptat>the closure of qtbase is 1330.8 MiB
<roptat>and mariadb is 14.4% of that
<roptat>hey, weird error message: guix size: erreur : path `/gnu/store/dkpdqm1r8lk3z93al509z3a3cid8ljsq-qtbase-5.11.3/lib' is not in the Nix store
<roptat>could we get rid of the static libraries first?
<civodul>extra-cmake-modules depends on qtbase? uh
<civodul>yes, we should get rid of static libraries
<civodul>(i assume you're talking about qtbase, right?)
<roptat>yes
<roptat>we could also separate mariadb into mariadb:out and mariadb:lib (`guix build mariadb`/bin is 149 MB, while lib/ is only 37 MB)
<roptat>I'll work on this :)
<bandali>hey y’all
<bandali>any updates about the state of guix.gnu.org?
<roptat>bandali, we still need to test the new configuration, but that should be quick (I need to get back to my personal computer to push something, so that'll have to wait a few hours)
<roptat>so maybe tomorrow? definitely by the end of the week :)
<roptat>unless I forgot something
<efraim>it we try to hit qtbase we should upgrade it to 5.12.* first
<civodul>roptat: whenever you deploy the thing on berlin, we can test the web site
<civodul>and if everything's alright, we can tell bandali to hit the red button
<roptat>civodul, I can't deploy on berlin, because I don't have an account
<civodul>oh?
<civodul>well, you can add yourself there
<roptat>I can still push the patch, but I need someone to deploy it
<civodul>yeah
<civodul>one of us can reconfigure
<roptat>ok, I'll add myself then :)
<civodul>anyway, let's synchronize :-)
<civodul>cool
<bandali>alrighty :) will keep an eye on the ticket then
<civodul>bandali: it's taken a while, but we'll have a super high-tech setup :-)
<civodul>so we added ~6 packages *per day* over the last year
<bandali>civodul, hehe, sounds exciting! i’d love to peek under the hood in guix/maintenance.git soon to see how everything’s configured
<civodul>the web site setup might be worth a blog post
***Guest18976 is now known as nalkri
<bandali>i think so too
<bandali>potentially including the dns configuration :)
<civodul>i have eval/container, which is nice, but it uses call-with-container which simply returns an exit status
<civodul>how does that sound?
<mbakke>roptat: I tried to split mariadb outputs back in the day, but hit a problem because "mysql-config" needs to refer to all outputs, and most packages use that. I don't remember all details, hopefully you have better luck :)
<roptat>mbakke, mh... if we have "mysql-config" part of mariadb:bin, then we could use maridb:bin as a native-input
<roptat>nothing from mariadb needs to refer to mysql-config, right?
<mbakke>civodul: Minifying LLVM is high up on my priority list. I think reducing size in general will be a topic for the next big rebuild :)
<mbakke>roptat: I think so, sounds good so far :)
<minall>Hello guix!
<civodul>mbakke: cool!
<civodul>i wonder if we should work on LLVM before the branch is fully built
<roptat>probably not mariadb:lib though, since the libs are refered to by out, but in a separate output of its own, like mariadb:config
<minall>I posted a question on the guix mailing list, but got no responde, but, managed to fix my problem, how sould I update the entry, so I can close the subject?
<rekado_>minall: sorry about that. If you have a solution it would be great if you could tell us about it.
<mbakke>civodul: I think we have good time to work on LLVM. At this rate armhf will be done maybe by October.
<civodul>heh :-)
<civodul>rekado_: what was the story with qemu-binfmt not working on the build machines?
<civodul>should we guix deploy 'em all?
<rekado_>yes
<rekado_>“guix deploy” failed on all of them, but that’s just because of the user-homes service.
<civodul>right
<civodul>should we sudo reboot them all? :-)
<rekado_>IIUC this means that there is no GRUB entry for the newly reconfigured system
<rekado_>so I think we shouldn’t reboot them yet
<civodul>oh true
<minall>rekado_: My subject was, how to add the module 'openchrome' which is on the xf86-video-openchrome, I got help from this IRC and managed to load it, so my question is... how should I update, maybe my findings can help someone else...
<rekado_>I was going to wait for “guix deploy” to be modified to better deal with errors like that.
<civodul>that makes sense
<civodul>in the meantime, what if we "herd restart guix-daemon" on a couple of them?
<rekado_>minall: it would be great to simply reply to your original email to the mailing list
<rekado_>civodul: would that help?
<civodul>maybe?
<civodul>i mean if service upgrade happened, then it will work
<civodul>it'll be easy to see anyway: if there are lots of --chroot-directory arguments, then it worked
<minall>rekado_: Thanks! i'll do
<buenouanq>How do kernel-patch outputs work? how do you apply them?
<quiliro>saluton minall and all other hackers
<quiliro>saluton minall kaj ĉiuj aliaj hackeroj
<quiliro>i was investigating gwl last night
<quiliro>i can see how it works. GWL looks really useful and well structured. I installed it with guix install gwl. I even started the web browser that showed me the GWL tutorial.
<quiliro>But when it comes to using it on real life, how do I do it? it is not on that manual...i have not checked the info page....will report after checking
*civodul posted eval/container: https://issues.guix.gnu.org/36668
<civodul>er, https://issues.guix.gnu.org/issue/36668
<quiliro>guix workflow --help
<quiliro>civodul: will check your link
<minall>quiliro: https://hpc.guix.info/blog/2019/01/creating-a-reproducible-workflow-with-cwl/, there seems to be more stuff here
<quiliro>thank you minall :-)
<minall>:D
<efraim>what do I need before a (file-append? '#$' ?
<pkill9_>i want guix on the go
<efraim> http://guix.gnu.org/manual/en/html_node/Web-Services.html#Web-Services I'm having a hard time with httpd-module, with file using 'file-append'
<quiliro>minall: did you progress on your report? please remember to include logs and configuration files
<efraim>nvm, I was leaving out %default-httpd-modules so I needed a list instead of cons*
<minall>quiliro: I updated it, I just pasted my services part that worked
<quiliro>minall: i did not get it yet...probably on its way
<minall>quiliro: I was cheking too, we should wait
<rekado_>civodul: okay, I’ll see if I can restart them.
<rekado_>(I worry that I may have to stop, reconfigure, and then start them)
<rekado_>quiliro: the GWL is for use in scientific workflows. Do you have such a use case?
<quiliro>rekado_: i was investigating....i like science, so i wanted to test it in case need it sometime or in case i encounter someone else that does
<quiliro>rekado_: isn't science ubiquitous after all?
<rekado_>using the GWL isn’t science. It’s just that for genomics you often need to use a lot of tools that run for a long time and require lots of resources, and you want to use your cluster resources wisely. The GWL provides abstractions to hopefully make this easier.
<rekado_>here are examples: https://guixwl.org/beyond-started
<mbakke>qt4 JavascriptCore fails to build with GCC 7 on core-updates. I think maybe now is the time to get rid of it...
<rekado_>mbakke: yes, please!
<rekado_>do we still have qt4 packages?
*rekado_ is afraid the answer may be in bioinformatics.scm…
<mbakke>11, according to guix refresh.
<minall>using guix import should help me to add a package to guix?, I read the manual, but I still have some questions
<minall>for example, adding polari
<roptat>minall, yes
<roptat>I don't know about polari, but generally, if a package comes from a package manager known to guix import, you can "guix import <package-manager> <package-name>" at least, usually there is also a -r option (recursive import)
<roptat>so, for pypi, you would do "guix import pypi mypackage -r", for opam you would do "guix import opam mypackage -r", etc
<roptat>that will output a sketch of package objects you would need to add to guix. They might not work right away, but it will at least help you find all the needed dependencies and such
<minall>I think that's the part that I don't understand well, for example, I can't add polari by downloading it manually from any source? -r for dependencies of course
<nckx>minall: It won't help you package Polari, I'm afraid.
<minall>Or just for the sources available ? for example, if polari is available on the package manager of NixOS, I can add it from there?
<minall>nckx: o/
<roptat>I don't know, what is polari?
<nckx>minall: o/
<nckx>roptat: A GNOME IRC client.
<nckx>(Probably ‘The’.)
<minall>Is an app to connect to channels, as freenode, the difference is that it's very well implemented on GNOME
<roptat>I think we have an importer for nix, but I think it needs a working nix installation, and not sure how it works...
<amz3>what is the procedure to close a ticket?
*nckx tried using it once; hated it; can't remember why.
<amz3>please
<minall>And why 'gnu' is a package available from where I can import?, don't I have all the packages availables on guix?, or there are some GNU packages that are not added, but one can add?
<nckx>amz3: Send mail to nnnn-done@debbugs.gnu.org.
<amz3>tx!
<rekado_>minall: “gnu” is an “upstream”
<rekado_>we can import packages from upstream directories or registries.
<nckx>minall: ‘gnu’ isn't a package, but a platform, presumably we don't have *all* GNU packages (for various reasons me might not even want all), and there can always be new ones → easy packaging.
<rekado_>not all GNU packages are available through Guix yet
<nckx>Upstream is a better name.
<rekado_>an importer makes it easier to get those packages into Guix.
<nckx> https://gitlab.gnome.org/GNOME/polari/tree/master/src
<nckx>It's in… JS?
<rekado_>a lot of GNOME things are written in JS
<minall>Mhh
<rekado_>though in the past it was just limited to extensions (such as GNOME Shell plugins and the like)
<minall>I think I'm understanding a little jeje
<nckx>rekado_: …huh.
<minall>So gnu is an upstream which has all the GNU packages available?, so one can import them is necessary?
<minall>So, for example, how whould I add polari, adding one package will help me understand this better
<nckx>minall: It will give you a very basic ‘skeleton’ package which you can add to Guix (or your own channel) and further edit to get it to work, yes. Try ‘guix import gnu grep’. It's missing inputs and arguments (you can compare it to the ‘real’ grep in gnu/packages/base.scm), but it's a start.
<nckx>I really don't think the importer will help you with Polari, unless the Nix importer is awesome and you have a working Nix installation it can use.
<civodul>i think the Nix importer is broken, isn't it? :-)
<nckx>Welp.
<amz3>nckx: sorry to bother you again, related to guile-pfds, issue #35518, the very last patch does add a notice that the "patch" is done like that because upstream aka. the original maintainer 'ijp' is not responding... I can not comment more on the patch because fwiw I don't understand the code, but the patch makes it work... This is a very import package (VIP) for guile.
<davexunit>does that importer have any use still?
<quiliro>rekado_: that was a beautiful description of GWL...thank you... https://guixwl.org/beyond-started does not say how to run the files with guix workflow ...
<minall>Mhh I'm a little confused, but I understand better the workings of guix import
<amz3>nvm, I will raise the issue in guile mailing list.
<nckx>amz3: To make sure I'm up to speed: we're talking about https://github.com/ijp/pfds/pull/6/files, I'm guessing amirouche is you, so you're the author?
<amz3>yes
<minall>So what should I do to import polari.. maybe gnu has it?, and what do you mean by a nix installation I can use? what if I install NixOS in another hard drive and add packages to guix through it?
<davexunit>minall: don't bother with the nix import method. it doesn't work.
<davexunit>it may be that an importer is not a viable option here.
<rekado_>minall: I suggest writing the package from scratch and see how it goes.
<davexunit>an importer can only automate so much. there's lots of limitations.
<nckx>amz3: Well, if even the authority on the patch doesn't know how it works… 😛 Yeah, maybe guile is a good first stop. If really nobody understands it (I'd be surprised) but it ‘works’, well, I guess it's OK to note that in a comment.
<rekado_>quiliro: that’s right, it doesn’t. The manual does, though.
<rekado_>quiliro: but I’ll still have to make a new release. What you’ll get from Guix now does not behave as advertised on the web site.
<minall>Well I don't mind writing it from scratch, so how goes it
<quiliro>rekado_: the guix manual?
<minall>I'll get an example from gnu/hello for example,
<rekado_>quiliro: the GWL manual.
<minall>But should I install polari in any way? or have the package and then write the package?
<quiliro>how can i see the GWL manual?
<nckx>minall: I learnt by reading code; it depends on how you learn. There's also a whole section on packaging in the manual and https://www.gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/ seems even more hands-on.
<amz3>nckx: tx
<rekado_>minall: you don’t need to install it first
<rekado_>minall: here’s how I’d start: look through the repository at https://gitlab.gnome.org/GNOME/polari/ to see what build system it has.
<rekado_>minall: it uses meson, so we can use (build-system meson-build-system)
<nckx>minall: You'd download the source, write a basic package (with URL, hash, some mandatory fields like licence &c.), then try to build it. Then fix/add something. Loop until success.
<rekado_>next we’ll look if we already have all dependencies: blob/master/meson.build
<rekado_>we need gio, gtk+, telepathy-glib, gobject-introspection, and gjs.
<rekado_>try to find those in Guix (they may have slightly different names)
<rekado_>then write an “inputs” field: (inputs `(("gtk+" ,gtk+) …))
<rekado_>the rest is as nckx wrote.
<minall>Wow
<minall>You're such a good help guys, thanks!
<minall>I'll try it, if I success I'll report, so I can help to add something to this amazing project
<rekado_>also report if you don’t have success. That’s normal and we might be able to help.
<rekado_>(BTW: you can use “Guix” here instead of “guys” ;))
*rekado_ is annoyed with the timeouts on issues.guix.gnu.org
*rekado_ proceeds to hack on guile-debbugs
<minall>JAJAJ ok guix!
<minall>*How does rekado do that
<minall>that nice messages jeje
<nckx>minall: /me does something.
*nckx does something.
*minall I'm impressed
*minall is impressed
<minall>Thanks jaja!!
<nckx>[Vague intuition] Does guix-publish leak memory?
<civodul>nckx: i don't think so, why?
<civodul>on berlin it's been running "forever" and the RES column in top is still relatively low
<nckx>civodul: Here RES was 113M, but when I ran ‘herd restart guix-publish’ my swap usage in htop went from 3.5G to 0.
<nckx>That's as much detail as I have since I wasn't expecting that.
<nckx>(Mentioning htop just in case it's relevant but I really doubt it. Other tools agree.)
<nckx>Am I misunderstanding RES?
*dutchie wonders if there is some way to get guix builders to use somewhere other than /tmp to work in
*nckx always took it to mean ‘how much memory is this process using, really, probably, approximately, usually, in the human definition of the word’.
<rekado_>dutchie: TMPDIR in the daemon’s environment.
<dutchie>(i have /tmp mounted as a tmpfs and some builds fill it up and fail)
<nckx>dutchie: TMPDIR=/foo in the *daemon's* env?
<dutchie>makes sense
<dutchie>annoying to change as a one-off though
<PotentialUser-69>is the bare-bones.scm config supposed to launch a login console after booting?
<civodul>nckx: i do see that VIRT is large (more than 1G), but i don't think it matters
<nckx>Hm.
<PotentialUser-69>do i have to put getty as a service explicitly in my configuration?
<nckx>Whatever it was, it was really allocated, since it caused another task to get itself OOM-killed.
<nckx>PotentialUser-69: Not if you use %base-services or want more getties than the default tty[1-6].
<nckx>And agetty claims ttys ‘automatically’, whatever that means.
<nckx>(from a peek at (gnu services base).)
<PotentialUser-69>I use %base-services, but when booting nothing happens after "populating /etc..."
<nckx>I won't defend Guix System's early-boot debuggability, but that doesn't sound like getties are what's failing. Any more info than that? ☹
*nckx AFK in few minutes; hopes someone else can help too…
<PotentialUser-69>"error in finalization thread: Success" is giving me mixed signals
<PotentialUser-69>also a "no sender credentials received" print from udevd a bit later, but i assume it's unrelated
<nckx>PotentialUser-69: Sorry about that ‘finalization thread’ one. That error is the worst, but completely harmless, red herring. It's been known for years. /me bugs civodul, a Guile maintainer. ;-)
<nckx>Yeah, I think I get the sender creds one too.
*civodul agrees that it's terrible
<nckx>PotentialUser-69: A literal screen shot is fine, as long as it's not on imgur.
<nckx>civodul: I don't know what it means. Is it a ‘let's keep it to encourage a proper fix’ thing? Because then it's really not working.
<nckx>Especially since it's printed at the worst scary time for new users. 🙂
*nckx AFKs so hard
<PotentialUser-69>That's pretty much it though
<PotentialUser-69>there's an fsck error about missing mtab
<PotentialUser-69>some gc warnings "pthread_getattr_np or pthread_attr_getstack failed for main thread" and "couldn't read /proc/stat"
<quiliro>rekado_: Where is the GWL manual?
<amz3>quiliro: https://git.savannah.gnu.org/cgit/gwl.git/tree/doc
<mbakke>rekado: 'ant-bootstrap' fails on core-updates, if you are looking for something to do :P
<jonsger1>rekado_: something makes the "body" box from mumi a little to small, so it wraps the lines to "early". e.g. https://issues.guix.gnu.org/issue/36376 compare it with https://issues.guix.gnu.org/issue/36376/attachment/0/
<rekado_>jonsger1: the wrapping is the same here. It’s probably a font problem.
<rekado_>my browser says it used DejaVu Sans Mono here. What does it use on your end?
<rekado_>bah, TeX errors are the worst…
<rekado_>\x_resetint #1#2->\eval_expr {#2}\setsomething_global \ifnum \result <
<rekado_> \max_mathchardef \ifnum 0>\result \x_cs \edef {i-#1}{\the \result }\else \x_cs \mathchardef {i-#1}=\result \fi \else \x_cs \edef {i-#1}{\the \result }\fi
<rekado_>\setint #1#2->\x_cs \ifx {i-#1}\x_relax \x_resetint {#1}{#2}
<rekado_> \fi
<rekado_>
<rekado_>all clear?
<rekado_>! Missing number, treated as zero.
<jonsger1>rekado_: Source Code Pro
<jonsger1>rekado_: yeah, tex has industry leading error messages :)
<lispmacs>hi, I've been trying to get Guix SD running on an 32-bit netbook. I tried to use the installer to install Xfce desktop, but that failed with some build error, so I just installed the base system. I have been working since to try to get Xfce install (next page...)
<rekado_>jonsger1: I don’t have that font, so I can’t fiddle around to see what might be causing it. AFAICT I’m not restricting the width anywhere. It’s all bootstrap CSS classes + custom padding here and there.
<lispmacs>I got xorg-server, gdm, and xfce-desktop installed, but am having trouble starting Xorg (next page...)
<rekado_>lispmacs: what do you mean by “got them installed”? Are they part of the operating system configuration?
<lispmacs>the errors I see in the log are "failed to load module intel (module does not exist, 0)" as well as "failed, etc... fbdev..." and "failed, etc... vesa", so I installed xf68-video-vesa, etc. but am still getting the same errors
<jonsger1>rekado_: okay, in chromium it looks fine here... don't know for sure what font theres used
<lispmacs>rekado_: I used the command "guix install" to install all the package. I am not sure if that Makes them part of the operating system configuration
<rekado_>lispmacs: that’s not going to work. Installing packages into your user’s default profile won’t have any effect on system services.
<lispmacs>rekado_: I logged into root to install the packages, does that matter
<rekado_>lispmacs: no. As far as guix is concerned “root” is just some other user.
<lispmacs>rekado_: ok, can you point me to the correct command?
<rekado_>lispmacs: you would need to edit your operating system configuration file (e.g. at /etc/config.scm)
<lispmacs>rekado_: rekado_: is there a walkthrough for that in the manual or something, or something I can drop in?
<lispmacs>if somebody could send me an example file from their system, I could probably figure out how to adapt.
<davidl>Is there some way to remove cache from a failed a package installation? I failed building llvm as Im working on defining a new package and trying to install it with guix package -f new.scm, and it appears to just try and build and install llvm no matter, even though I have changed the package to not depend on anything pulling llvm.
<davidl>I did a guix gc before to fix a similar issue but I don't want to do that again since I would then lose a ton of packages.
<amz3>lispmacs: what are you trying to do? I back logged a little bit, but I don't understand all of it
<amz3>lispmacs: yeah, You need to improve the config.scm you used during guix system init
<amz3>lispmacs: there is several example in guix git tree
<amz3>IDK which directory from the top of my head
<amz3>lispmacs: after you change config.scm (which should prolly versioned) you have to call again guix init
<PotentialUser-69>nckx: KMS turned out to be the culprit. Thanks for the pointers, glad i didnt sink hours into troubleshooting the "error: success"
<amz3>davidl: can you paste new.scm ?
<amz3>PotentialUser-69: funny error indeed
<amz3>davidl: also when working on a package, I think, the best way to go is to use guix build -f
<amz3>davidl: also use -K to keep the failed build to be able to investigate?
<amz3>davidl: in theory, if you change the definition, the build will change its store path name
<amz3>davidl: there is not such a thing as build cache afaik again
<davidl>amz3: thank you I'll try those things. can't post new.scm right now :/
<dutchie>can anybody reproduce `guix build kodi` failing its test suite?
<amz3>dutchie: I guix pulling and then I will try
<dutchie>i have a draft bug report but maybe someone here can help me fix it
<dutchie>it takes a while to build
<lispmacs>amz3: I'm trying to install a desktop environment. I couldn't get Xfce to install using the installer program, so I just installed base system and am trying to do the rest myself. I will check in the guix git tree and see if I can find a usefully config.scm
<ilikeheaps>A question to Emacs users here: how to ensure Emacs has required (Guix) packages from Emacs config file?
<ilikeheaps>Does emacs-guix have some functions for that?
<rekado_>lispmacs: what does your /etc/config.scm look like after you installed your base system?
<lispmacs>rekado_: it is on a different computer, so hard to copy and paste, but I don't see anything in it about desktop environment
<lispmacs>rekado_: I think I can probably copy over what I need from some example in the git repo, if I can get to it. The barrage of work-day phone calls has started so I keept getting distracted
<rekado_>lispmacs: desktop environments are deployed via system services
<lispmacs>rekado_: okay, I see a service s-exp in the config file, so probably I will just need to add something to that list
*dutchie filed https://issues.guix.gnu.org/issue/36675
<nckx>Good luck, PotentialUser-69, wherever you are & whatever your nick is tomorrow. o/
<nckx>Anybody using RIME/ibus on Guix today?
<roptat>civodul, I just pushed my changes to maintenance.git
<roptat>I made it so pdfs are served from /srv/guix-pdfs
<roptat>that means we should try to reconfigure berlin now :)
<civodul>roptat: let's do that!
<civodul>roptat: nginx doesn't start: unexpected "}" in /gnu/store/kdp0k405qd9y37zacx0ypsq276l83n0z-nginx.conf:1029
<roptat>can you show me the generated config?
<roptat>I might have forgotten semicolons...
<rvgn>Hello Guix!
<civodul>oh got it
<civodul>hi rvgn!
<rvgn>civodul o/
<roptat>civodul, do you want a new commit, or are you doing it yourself?
<civodul>roptat: http://guix.gnu.org/guix.html works \o/
<civodul>i can do the commit
<roptat>ok, thanks :)
<roptat>is that served from the new configuration?
<roptat>probably the new config, since I can't access the manual yet
<roptat>great!
<rvgn>civodul I had a question. Since LVM is kernel-side module/feature, why it is not implemented in guix yet?
<civodul>roptat: from the new config, yes
<civodul>alright, same with a top-level index.html: https://guix.gnu.org/
<civodul>the manual will come up soon
<civodul>rvgn: this was discussed a few days ago on guix-devel
<amz3>dutchie: successfully built /gnu/store/5gcq94bm4ix0sq1h5gizq6jj598192b4-kodi-18.1.drv
<amz3>/gnu/store/nq3ak4zs1j0arbxhc8cj92gz28b3v3jz-kodi-18.1
<janneke>hmm, channels cannot have overlapping module names
<rvgn>civodul Thanks! I will check it out.
<amz3>ilikeheaps: did someone give you an answer?
<amz3>ilikeheaps: you might be able to rely on emacs guix mode to check for the presence of some packages and (automagically) install them if they are not present, but I am no (guix (emacs)) expert
<dutchie>amz3: hmm, i had 18.2
<amz3>dutchie: I just pulled, did you do it from guix-git ?
<amz3>guix pulled
<amz3>I will check guix-git
<dutchie>no, from normal pulled one. odd
<civodul>roptat: open() "/srv/guix.gnu.org/manual" failed (2: No such file or directory)
<civodul>so i think we have an invalid location block somewhere
<roptat>mh...
<roptat>can you show me the generated config?
<amz3>dutchie: kodi 18.1 is not in my guix pull. but I can find it in guix-git, I launch that build.
<roptat>civodul, I might have misinterpreted the meaning of "alias"
<amz3>dutchie: forget it, my ubuntu/guix setup is broken, I can not build from git
<roptat>although it should talk about /srv/guix.gnu.org/srv/guix-manual or something if that was the case...
<dutchie>ah well. i submitted a bug so hopefully someone else will be able to repro
<dutchie>ty for trying!"
<Minall>Hello guix!
<amz3>o/
<roptat>civodul, maybe it's just missing a trailing / in the alias directive
<roptat>(same with the root directive for pdf actually)
<amz3>alias and root do different thing, one of them takes the last component of the url path and append it to the argument of root or alias (I never remember which one is which)
<amz3>I means they do similar thing, but differently, they use the url path differently like explained above
<roptat>amz3, yeah I think I got that right, but was starting to wonder whether alias was taking the name to be relative to the root or not...
<roptat>it's not completely clear to me from the documentation, but elsewhere on the internet, it seems to be the right thing
<amz3>ok
<roptat>I want guix.gnu.org/manual/* to be served from /srv/guix-manual/*, not /srv/guix-manual/manual/*
<amz3>idk i always use absolute path names
<amz3>dutchie: sorry to bother you again, what is the issue, looking up kodi at https://issues.guix.info/ doesn't yield any result
<amz3>I fixed my guix setup and it's building
<dutchie>amz3: https://issues.guix.gnu.org/issue/36675
<rekado_>hmm, looks like there’s an XML parse error for /issue/29302 :-/
*dutchie to bed now though
<rekado_>hmm, it’s gone now. Oh well.
<amz3>dutchie: I think, it would help to have some dmesg output if it interesting..