<rain1>frnmst, this looks very interesting :) <frnmst>rain1: I installed this distro just today and I know very very little anything about {lisp,scheme,guile}. Some minutes ago i tested my package and it works better than on Trisquel :) <lfam>mark_weaver: I'm looking at the 'fix-letsencrypt' job on hydra.gnu.org, but I don't know how to tell if it's done or not. <rekado_>I just packaged a Gimp plugin, then noticed that Gimp doesn't provide a search path for plugins. <marusich>How does one normally install plugins for Gimp? <marusich>There must be some way to specify it, rekado_ <rekado_>marusich: there is a way to add plugin paths in the settings. But Gimp won't respect any environment search paths. <rekado_>normally they are installed into the plug-ins directory where Gimp is installed <rekado_>so after installing plug-ins via Guix users will also have to edit the search path in their Gimp settings to include ~/.guix-profile/lib/gimp/2.0/plug-ins <marusich>Does Gimp provide any way to define a "site-specific" configuration of some kind? If so, maybe we could modify it so that when the user installs Gimp, the version installed will use that site configuration to find plugins installed via Guix. <rekado_>marusich: I don't think that's good because a user may have more than one profile and may not necessarily have a ~/.guix-profile <marusich>Well, I think we do something kind of like that for emacs packages; I just thought maybe it would be possible to use the same sort of method for GIMP <marusich>It's too bad GIMP doesn't have something like a PLUGIN_SEARCH_PATH <ng0>for systemservices to be tested, I need to reconfigure a system with it somehow, right? <iyzsong>ng0: yes, avoiding reboot, the modified (or newly added) service will be start by shepherd when it's stoped or not exist when doing the configure. <ng0>when I normally use a guix pull to update my system, do run this update with ./pre-inst-env guix system reconfigure (in the checkout where the new service is) and the file which i normally use + the added service in it? <iyzsong>use ./pre-inst-env if you put the services in the 'gnu/services' of the checkout. <iyzsong>for test, I can write the service in my guix.scm, etc. <ng0>now I just have to learn more guile to understand some of the services better. planing is finished for the gnunet service <iyzsong>how do I match any or more characters include newline in 'substitute*'? ***Digitteknohippie is now known as Digit
<ng0>where are the mirror:// things defined in guix? do we have "debian" pool as a mirror option? <rain1>debian reproducible project is putting importance on same build output, different environments - rather than setting up one very special strict environment that makes builds reproducible <rain1>I thought that was interesting, just trying to understand the project more <jmd>ng0: I don't think debian hosts many original sources, so I don't suppose anyone has bothered to define a mirror:// for it. <rain1>what about all the patching debian does? in particular to make builds reproducible? <rain1>could these be useful in guix? <ng0>do we have some libiconv providing package? <jmd>davexunit: The point about minimal packages is very pertinent. <ng0>i only see virtual/lib* in some gentoo packages <rain1>find /gnu/store/ > gnu_store.txt <jmd>Guix needs a for-check-phase-only class of dependency. <rain1>I stopped it, 2.5 million lines already! <jmd>davexunit: It could reduce the installed size of many packages. <davexunit>jmd: I don't see how. I think you might be misunderstanding how store item references work. <davexunit>the installed size of a package is determined by the store item itself + the size of all the store items it references, recursively. if the installed package doesn't reference an input, it is not part of the closure. <davexunit>if a package is holding references to things only needed at build time, then that's a bug to fix in that package's recipe. <jmd>How does a recipe say "this package is needed only for build" ? <rain1>a neat thing you can do is view the 'guix graph' of a package <rain1>that shows all the build time deps i think <jmd>I only see recipes with "inputs" and "native-inputs". <rain1>then if you do -t references it shows the runtime deps instead <jmd>Can you point to an example of a package which has a "build-input" ? <rain1>you can probably just grep for one <jmd>I have. It came up null. <rain1>grep -r 'build-input' ~/.config/guix/latest/ --include='*.scm' <rain1>%build-inputs is a different thing <rain1>seems like build-input mostly appears in build systems themselves <Jookia>I think the closure is determined by which packages the output references? <Jookia>I think it does this using a grep <rain1>funny they all seem to require themselves <jmd>Lets take a concrete example. Many packages have a native-input on perl. But perl is not needed to run the program. It is only needed when building. But guix doesn't know that, and has to install perl anyway. <jmd>No. It will get installed when one does guix package -i <package> <jmd>(assuming it isn't already installed) <jmd>Or rather I say, it'll get installed into /gnu/store not necesarily in the profile. <Jookia>Do you have a concrete example of this package <rain1>pretty much every single package that exists needs perl as a build dep <rain1>based on looking at guix graph of a lot of packages <jmd>well yes. That was just an example. <rain1>jmd, well the build-inputs thing is really interesting, it is only ever used inside build systems <rain1>maybe there are a lot of opportunities to start using it in package definitions? <Jookia>build-inputs references things in the inputs/native-inputs fields methinks <rain1>I wonder if things can be move from native-inputs to build-inputs sometimes? <jmd>I think %build-inputs is just an alist containing the union of native-inputs and inputs <ng0>"for historic reasons this bundles mkpasswd" noope. nope. so many bundled things and everytime you have to patch them out. <davexunit>jmd: typically native-inputs are for build-time things <davexunit>because those are packages that need to be compiled for the host machine <davexunit>Jookia: build-inputs is not a field of a package object <jmd>davexunit: right. typically that is true. But once the package has been built it isn|t needed anymore. <jmd>Bu guix doesn't know that. <davexunit>by scanning for references in the store item <davexunit>only things that are referenced are part of the closure <davexunit>if you notice that a closure includes something that is only needed for build time, then something is referencing that package and you need to find it and fix it. <jmd>I don't follow. How would I fix that? <davexunit>'guix gc --references /gnu/store/whatever' will tell you what store items are referenced <davexunit>and then figure out what needs to be done to remove it <davexunit>we have cases where some log file of what was used to build the software ends up getting installed <davexunit>and it contains references to all the build-time stuff we don't want <jmd>So where does gc --references get its information from? <ng0>so "whois" also includes another package, "mkpasswd". Can I do 2 packages for 1 source in this case? <mthl>ng0: I have never done it but it is possible and desirable <ng0>I would not expect someone who wants mkpasswd to look for whois <ng0>Nix does it the same way <janneke>do we have something like debian's /sbin/resolvconf ? <ng0>(substitute* "file1" "file2" (( for multiple files, right? <ng0>or just file1,file2? <mthl>ng0: (substitute* '("file1" "file2") ...) I think <mthl>ng0: you can look its docstring in guix/build/utils.scm for more details <ng0>can i just prefix = $out or does it need to be some sort of prefix = (assoc-ref %outputs "out") <ng0>for people using gentoo: my work in progress on guix on gentoo has been merged into an overlay, visible at www.psyced.org/download.html , just use `torify git clone` to get it, rest should be known if you use gentoo. I need some input on the odds of guix on gentoo and why it breaks as soon as build users should be called. -bin is broken currently, but the one without (from source) installs into all kinds of <ng0>locations, works, but breaks as soon as guix calls builders. <jmd>I need to run a test with gcc 4.2 How easy would it be to package that? <ng0>it's just a bit sad that guix will probably never get into portage because of #355355 bug and policies or just plain ignorance of portage. <rain1>maybe when there's a new guile release they can get it in <alezost>ng0: "mirror//:" things are defined in (guix download) module, and there are mirrors for debian: grep for "mirror://debian" in gnu/packages dir <rain1>I reproduced the failure with --rounds=2 you mentioned, thank you for showing that <rain1>I wasn't sure how to compare the outputs though.. <lfam>I left --rounds=5 going overnight, and it worked on the previously failing machine when the $TMPDIR was on ext4 <rain1>I tried something myself: Created a new package the same as linux-libre but named differently, then --rounds=2 and --rounds=3 both worked (no determinism failure) <rain1>I got all the debian tools setup for reproducibility too <rain1>They put a lot of work into getting the linux kernel reproducible <rain1>currently it is not - hopefully it will be again soon... <rain1>I think there is a lot of opportunity for cross-pollination in this <rain1>one of the feelings I got from the debian project is they want builds to be the same in a variety of environments <rain1>(instead of just packing everything into docker) <lfam>Yeah, so that users on different machines can compare the results of their compilation. <rain1>maybe guix can get a page there ? :) <rain1>I'm looking forward to trying this script! <lfam>If you search the guix-devel archives on this topic you will find civodul's report from the reproducibility summit he attended <lfam>The script is not up to my usual standards for public distribution, but I do use it all the time, so it's not terrible ;) <lfam>One annoying thing is that you must make the copied directories writable so you can delete them when you are done. But I didn't automate this at all. <lfam>CTRL-r is sufficient for me <lfam>And it may be necessary to increase the maximum report size for diffoscope, although this might be unnecessary due to some recent changes in diffoscope that make the output much less verbose <lfam>Previously it reported differing ctimes, but they silenced that <marusich>There is a special Wacom settings section in the GNOME3 settins <marusich>However, it does not seem to do anything. I am going to file a bug report about that. <marusich>I don't really know what the correct behavior is, but since it fails to auto-detect my wacom tablet when it's plugged in and clearly working at least well enough to move the mouse, something must be broken <marusich>have you used wacom tablets with GNU/Linux before? <marusich>Does it require some kind of special driver to be installed? <Piece_Maker>ACTION wonders if his steam controller works with guixSD.. <roelj>marusich: Yes, you need the Wacom Linux kernel driver. <ng0>back in 2007, the wacom i had only required to compile and install the firmware for the system i was using. <marusich>Oh, I see. Is that available as free software, roelj? <roelj>marusich: It's included in Debian, so yes I think so. <roelj>marusich: I don't know the specific packages that you need to install though. <roelj>Which package in Guix provides the "clear" command? <roelj>davexunit: Woah, I never knew ncurses was used for this. Thanks! <rain1>wish for a command to tell go from name of a binary -> package <roelj>rain1: Yes, I would like that too! <rain1>I think it has to be part of the build server that generates the information which could be downloaded <ng0>kensington: yeah, but it's currently only for debugging and the ebuild i've done needs a second push because i missed some parts. <roelj>rain1: Yes, then the build server could index what's in the output of a package.. <Piece_Maker>isnt this information already available to us, as when we install packages the package manager must query the server for whichever .scm file provides the exact package requested (such as the .scm files that contain more than one package like the mozilla one)? <rain1>Piece_Maker, not the list of files in the build output <rain1>I think this data could all be put into one file and then a script like ^ would be great <roelj>Which package provides "su"? <davexunit>we can't reasonably provide such a tool right now <davexunit>because it would be a feature that in practice forces users to trust a third party <davexunit>because building every package and building an index of all files is not practical for almost everyone. <roelj>rain1: I get "sudo: /home/roel/.guix-profile/bin/sudo must be owned by uid 0 and have the setuid bit set" <janneke>i tried openvpn (it works yay!); how do I use the vpn's dns server? <rain1>davexunit, would it be acceptable to request from a build server a database saying which files it knows come from which packages? <rain1>you can always verify that it didn't lie by building the package from source <davexunit>I don't want to see any request to a substitute server that isn't the equivalent of a cache lookup. <rain1>any thoughts how to make a pkgfile type program that fits with guix/guixsd? <davexunit>I'm interested in alternative approaches to the problem <davexunit>I don't see a way around the fact that you must build the entire distro to build the index <ng0>at best it is "somehow" in the source and the call to the server is never made. But we would need to build everything to have an overview about all the packages and references. <davexunit>maybe we could make an exception for this particular feature, but we must be *very* careful about introducing such things <marusich>To find out what package a file came from, you could do it ad-hoc by running "readlink $the_file", and then examining the store path. E.g., "readlink $(which python3)", right? <rain1>marusich, ah but you'd need to ask that of someone who does have that installed <rain1>the main use of the tool is "I want X but i don't know what to install for it" <marusich>Oh, I see; you want it for other use cases <davexunit>'readlink -f' will follow many layers of symlinks <efraim>could we scrape it from the build logs? <alezost>roelj: I suppose you're not on GuixSD, right? You can't use guix's sudo on another distro because it lacks setuid bit. On GuixSD such programs are added to /run/setuid-programs <kyamashita>Has anyone figured out printing under GuixSD yet? <kyamashita>It's the only thing holding me back from using GuixSD full time at this point. <marusich>Someone on the mailing list has discussed that. <marusich>I'm not sure what the current status is, but I agree I'd love to be able to print easily from GuixSD! <pizzaiolo>kyamashita: I guess for the moment compiling the drivers from source would have to do <pizzaiolo>but yeah I'm also looking forward to having them packaged neatly :) <marusich>paroneayea, some wacom software is already in Guix: guix package --search=wacom <marusich>I don't have my tablet with me, but I'll bet installing some of those will make GNOME's wacom settings application work properly