<ngks>the template does contain things that are evil in the strict sense used by Gnu but that's only incidental, I plan to package nice software. I have now cloned the whole evil repo and find/sedded the channel's name to a new name of my choosing. after doing it this way `guix pull` runs with no error. <ngks>It looks like I can now install evil 3rd party packages from the local, renamed repo. <ngks>the emacs interface to guix doesn't seem to be aware of the new channel but I'd say that is a different issue <leoprikler>ngks: just to make sure there's no misunderstandings, you do know, that your channel need not necessarily copy the entire guix tree, do you? <ngks>I know that in principle but I might be doing it anyway through user error <ngks>but at this point my local channel is just a renamed and relocated dupe of a widely used channel, so I think my local channel is only doing superflous work if the original 3rd party channel does that too. Which seems unlikely. <leoprikler>Is it the widely used Voldemort channel by chance? :) <ngks>maybe, but my intentions are pure <dumb_bot>Hi, what is the current method of installing from bootstrap binaries, to get gcc-bootstrap compiled, with other bootstrap binaries that used to be available in guix installation back in 2016 <stikonas>dumb_bot: I guess you need to edit bootstrap.scm <stikonas>and replace current bootstrap binaries with your <kabaulga> Chromium has menu in my locale but IceCat not. Is that known issue or you'll use IceCat in English? <kabaulga>It's calm so I will reply to leoprikler you've narrowed 'correctness' to final instructions execution. So sure that is ''correct'' ''eventually'' and theoretically, but is incredibly difficult to formally prove that mess is correct. That's why oooe is can of warms which will bring new papers every year. There are test simulations for oooe but no <kabaulga>formal proofs. That’s not correctness in scientific sense but in engineering sense and I get that could be enough for many. <pkill9>interesting issue: quassel tries to use xdg-open from current revision of guix, but it's not in my store, and my current xdg-open is from older revision of guix <pkill9>interesting issue: quassel tries to use xdg-open from current revision of guix, but it's not in my store, and my current xdg-open is from older revision of guix <mroh>so quassel is missing a xdg-utils input?! <pkill9>possibly, but it shouldn't be looking for a store path to a nonexistent inputs <wleslie>hi, your local ia64 user / capability snob here to point out that the problem with spectre is not really about speculative execution, it's about implicit shared state, in many cases shared between processes <wleslie>of course if you want to verify no covert/timing channels it's going to be easier with something simpler, which is why the seL4 people love risc-v so much <kabaulga77>wleslie yes, and that’s why I love sel4 too (not licensing tho) and strict systems which maximize our ability to reason about them. Regarding correctness of speculative/oooe there is ton of papers about the topic. ***vup2 is now known as vup
<kabaulga77>same with machine learning vs propagators. It's a matter of preference and priorities. Some folks care about performance no matter what, some prefer formal reasoning. <wleslie>you don't like a gpl'd kernel? whoa. <wleslie>the difficulty with preferences is that you've got to be in a special position economically to have them; I guess that may change <wleslie>well, I've been personally frustrated exploring DRI with a view to port it to coyotos (though it's probably not the approach we'll go with eventually) that many important graphics drivers (significantly, MALI) are gpl2-only, where our system is gpl2+ <wleslie>none of the drivers I personally use, but still <wleslie>so from an effort perspective, it's nice to be able to allow people to build and use gpl2-only graphics drivers without having to gpl2-only your kernel source *kabaulga77 is from Europe, time to sleep and dream about correctness in Guix. <jsoo>One of the first things I started working on way back when I started using guix was adding fontconfig and x style keyboard specifications for the kmscon service. I ran into an issue with the font configuration not being loaded by the profile hook prior to kmscon starting (so fonts would not be found). Is there any reason the kmscon service <jsoo>shouldn't depend on the profile service? <raghavgururajan>For the love of all that is lovable. The telegram upstream is messed up. <raghavgururajan>Folks! How do I see what default/common configure and make flags are added by a build-system? lets say gnu-build-system? <raghavgururajan>sneek, later tell leoprikler: Telegram-Desktop's true shenanigans come out when you do "-DDESKTOP_APP_DISABLE_WEBRTC_INTEGRATION=ON" xD <dumb_bot>But the installation instructions for Guix used to describe a way to use bootstrap.scm to install a new system, instead of just downloading substitutes from ci.guix.gnu.org <sneek>leoprikler, you have 1 message! <sneek>leoprikler, raghavgururajan says: Telegram-Desktop's true shenanigans come out when you do "-DDESKTOP_APP_DISABLE_WEBRTC_INTEGRATION=ON" xD <leoprikler>that's why I was ranting about telegram earlier – its configuration options make no sense whatsoever <mroh>Hmm, fr translations are broken somehow. <retropikzel>When defining new guix package can I get the path of the temporary folder somehow? <dumb_bot>Or: how can I install a new Guix system using bootstrap.scm instead of just downloading substitutes? <leoprikler>sneek later tell kabaulga77, you *can* formally verify, that an instruction stream and its reordering are equivalent. Now for speculative execution, there really is no proof. <leoprikler>note, however, that this can change, when you're doing multiple failed builds with -K <raghavgururajan>leoprikler: Any ideas crossed your mind regarding seg-fault? One of the upstream devs mentioning something about same mem-alloc type crash happening in gentoo as well. <leoprikler>I don't happen to have a Gentoo machine on my hand, so sadly no. <leoprikler>hmm, so you're trying to package tgvoip for telegram desktop separately *mothacehe is working on a simple-cuirass-service <civodul>mothacehe: oh, Cuirass for the people? :-) <GNUtoo>When I do (display glibc) I get that: <GNUtoo>#<package glibc@2.31 gnu/packages/base.scm:688 950fe60> <GNUtoo>Is there a way where I can modify an existing package from scheme itself? For instance if I create a package that inherit glibc, can I programatically modify it? <GNUtoo>The context here is that I need a version of glibc that has --enable-kernel=3.2.0 replaced with --enable-kernel=3.0 <GNUtoo>leoprikler: I can modify simple things with that such as name, version, source, etc <leoprikler>be warned though, that this triggers an almost world rebuild <leoprikler>you can also substitute-keyword-arguments for arguments <GNUtoo>but --enable-kernel=3.2.0 is burried deep into the (arguments <GNUtoo>that was what I was looking for thanks a lot <GNUtoo>can I just replace --enable-kernel=3.2.0 and nothing else? <GNUtoo>(instead of redefining all flags) <GNUtoo>civodul: I looked at that but I missed the substitute-keyword-arguments *GNUtoo goes looking up if he can subsitute just 1 flag with that <leoprikler>(list (cons "--enable-kernel=3.0" (delete "--enable-kernel=3.2.0" flags)) <leoprikler>btw. idk why you need to wrap the results in a list again, but it seems you have to <leoprikler>delete may also be the wrong procedure here, don't know which one does element comparison *GNUtoo has find an example in arpack-ng-openmpi <civodul>GNUtoo: oh it seems substitute-keyword-arguments is not documented in the manual (yet!) <GNUtoo>however I end up with a core dump <GNUtoo>I fear that it gets into some infinite recursion somehow <GNUtoo>Also note that I'm a newbie with Scheme <GNUtoo>for instance I know ' but not '' nor _ <GNUtoo>Though I vaguely recall _ from lambda functions <GNUtoo>The modified glibc package is at the end of that file <GNUtoo>(the rest works fine at parsing time at least) <mubarak>I have read that guix 2.0 will be based on GNU hurd kernel. my question is, wireless connection has been added to gnu hurd? <doncatnip>Hey Guix! Has anyone gotten AppImages to work in guix system? If so, how? It says "Failed to execute process [...]. Reason: The file '[...AppImage]' does not exist or could not be executed. <doncatnip>I tried 3 different AppImages so far, its all the same. <GNUtoo>mubarak: That was an april fool joke, though it now supports hurd as well <GNUtoo>So you still have all the limitations of hurd but AFAIK they are being worked on (like sound for instance, there are some preliminary work that did some hack to make it work) <zimoun>the ‘new’ convention is to not end the “phases” by #t, right? <mubarak>I have read it before in Debian GNU/Hurd that only ethernet connection only supported <GNUtoo>Personally I don't know much about hurd, and I wonder how they handle hardware state (in Linux it's done by having 1 software (Linux) controlling the resource access) <GNUtoo>Though it doesn't always work fine like with iopl for instance <leoprikler>zimoun that's the way things are heading, but it's not yet done on master (on c-u it may already be done?) *GNUtoo tried guix pack hello --target=arm-linux-gnueabihf --with-input=linux-libre-headers=linux-libre-headers@3.0.101 --with-input=glibc=glibc-with-kernel-3.0 for building a package with the modified glibc <GNUtoo>commenting arguments also seem to produce the same issue <GNUtoo>Maybe this glibc creates a circular dependency somehow? <GNUtoo>It takes a big time and prints nothing <GNUtoo>That was with arguments uncommented <GNUtoo>it looks quite similar with them commented <GNUtoo>guix pack hello --target=arm-linux-gnueabihf --with-input=linux-libre-headers=linux-libre-headers@3.0.101 seems to work fine though <zimoun>leoprikler: thanks. New and fixes should not add them, right? <GNUtoo>it fails due to some glibc isue though <GNUtoo>(so I probably need to pass the right argument to fix that) <leoprikler>I'm not really a core-updates denizen, but if they're omitted and no warning is displayed, then everything is good :) <zimoun>that’s my understanding too. :-) <GNUtoo>I'll try older glibc in the meantime <GNUtoo>hmmm, guix pack hello --target=arm-linux-gnueabihf --with-input=glibc=glibc@2.27 seems to have this behavior too (with my modified glibc being commented) <GNUtoo>allocate_stack failed: Cannot allocate memory <GNUtoo>Warning: Unwind-only stack overflow exception; skipping pre-unwind handler. <jonsger>mothacehe: cuirass-simple still requires postgresql or? <mothacehe>jonsger: yes, I have completely removed SQLite support from Cuirass <mothacehe>the Guix package definition is not updated yet <mothacehe>simple-cuirass-services returns three services: cuirass, postgresql and postgresql-role. <GNUtoo>though building a modified glibc (such as the one I created) seems to work fine, including the transformation which passes the right with-kernel to ./configure <civodul>GNUtoo: oh, that crash is the symptom of an infinite recursion <GNUtoo>did someone already manage to replace glibc with a modified version somehow without modifying guix source code itself? <GNUtoo>Because if so that person probably fixed that issue somehow <civodul>hmm "guix build hello --with-input=glibc=glibc@2.27 -n" has that problem too <civodul>the best thing to replace a libc is to graft it: "guix build hello --with-graft=glibc=glibc@2.27" <civodul>that way you avoid the world rebuild *GNUtoo hopes they are the same <civodul>it's like updating libc on an "imperative" distro <GNUtoo>Though it won't work with the kernel headers but I can still try <civodul>and the length of the name/version strings must be the same, too <GNUtoo>could that work: guix build hello --with-graft=glibc=glibc@smdk ? <civodul>strlen("smdk") = strlen("2.31"), so i guess yes :-) <GNUtoo>can I also combine both --with-graft=glibc=glibc@smdk and --with-input=linux-libre-headers=linux-libre-headers@3.0.101 ? <GNUtoo>Or would that end up doing strange things <civodul>yes, but the latter would trigger a world rebuild <GNUtoo>the question is how glibc would react to that <GNUtoo>so not rebuilding would be risky <GNUtoo>The idea is to run on top of a Linux 3.0 vendor kernel *GNUtoo tries running hello <GNUtoo>Basically I'll get rid of that kernel at some point but I've a chicken and egg issue <GNUtoo>I need to run some tests on top of that kernel and building them with Guix is probably faster than through the Android build system <GNUtoo>+ it opens the door to better tools (busybox etc) <civodul>i guess you can define your own glibc variant (like you did) and have that one built against the right kernel headers <civodul>then you only need --with-graft=... on the command line <sarg>Hey! How do I make a package variant with an additional file? I want to add a config file for my mouse to libratbag. I've researched a little bit and seems that it's either package/inherit or union-build. Am I looking into the right direction? <GNUtoo>sarg: some packages uses variant from within guix <GNUtoo>sarg: guix has an example with arpack-ng-openmpi <GNUtoo>So you can use something like that to define your own package version <GNUtoo>Alternatively you could also just package that file as an individual package and depend on libratbag somehow <GNUtoo>In the long run it's probably best to upstream that file in libratbag though. <sarg>oh, actually it's already fixed upstream. I could just package the latest version and use it <GNUtoo>The guix manual has stuff that may or may not work for that <GNUtoo> --with-branch=guile-gcrypt=master \ <GNUtoo>So you can do some part through the command line at least <GNUtoo>There is also a whole chapter on package transformations *GNUtoo has just discovered how to use all that and is waiting for the resulting packages to build <sarg>yeah, simply building the latest version worked out. Thanks <GNUtoo>/gnu/store/a5gzssbmhbjak3brg00pzllldd5dy5rv-profile/bin/hello <GNUtoo>I guess it really needs everything built with the right kernel headers *GNUtoo tries replacing the haders too without graft <GNUtoo>checking installed Linux kernel header files... missing or too old! <GNUtoo>oh ok it didn't override the kernel somehow <GNUtoo>--with-headers=/gnu/store/cdcmy3y6dsm3gydwrr1z20wczyxb7gvd-linux-libre-headers-3.0.101/include" "--enable-kernel=3.2.0" <GNUtoo>hence my question at the begining, did someone manage to do it <GNUtoo>because I'll probably spend way way way more time than intended here otherwise <GNUtoo>And note that I'm also a newbie with Guix so I'll probably fail at the end <nefix>Hello! Is there a place where I can search for lib***.so and returns me which package installs the library? Thanks! ***Guest96465 is now known as zimoun
<apteryx>nefix: it's lacking for now; you can search your /gnu/store; it often contains already what we are looking for if you've been accumulating stuff for a while ;-) <rekado_>this looks pretty simple, which is great. No patches to Python, which is a very welcome lack of complication. <rekado_>we still have lots of packages that set PYTHONPATH or read it to embed it when wrapping scripts. <rekado_>I suppose they would all need to be changed to use the appropriate GUIX_PYTHONPATH_x_y variable <apteryx>rekado_: right! Although PYTHONPATH will still work as it always worked, so there shouldn't be an immediate need to fix all occurences of it. <apteryx>but perhaps we will, because we depend on (getenv "PYTHONPATH") returning a list rather than #f often, I guess. <apteryx>I'll add something to the python-build-system so that sed can be used to fix most of these occurences with a simple procedure call to for the new GUIX_PYTHONPATH_X_Y string. <nefix>mothacehe: Thanks, I'll check it out! <apteryx>mbakke: eh :-) I wish I would have thought of that in 2016. <nefix>apteryx: Yeah, there are some that I've found them there, but there's for example `libgcc_s.so.1`, that's inside `/gnu/store/...-gcc-10.2.0-lib/lib/libgcc_s.so.1`, but that's not a package <apteryx>gcc is typically offered via gcc-toolchain <apteryx>so that's probably what you want as a user <nefix>apteryx: it's not providing the library <PurpleSym>apteryx: Just curious regarding PYTHONPATH: Would it be possible to get rid of it entirely and just generate a profile-specific sitecustomize.py in a profile hook? <jonsger>civodul: is their a way to enforce the usage of zstd compressed substitutes? <leoprikler>jonsger: I think it would still default to non-zstd substitutes if zstd ones aren't available for whatever reason <civodul>jonsger: not (yet) on the client side <civodul>currently clients take the most compressed thing, which usually means lzip if the server provides it <jonsger>that makes the transition a bit more complex... <rekado_>hmm, it would sure be nice if not only computed-file but also program-file would be able to pass options down to gexp->derivation. <civodul>rekado_: ah yes, i seem to recall wanting that <apteryx>PurpleSym: On the build side there's no profile involved; so you still need a mean for Python modules discovery. <rekado_>I’m not sure, but it seems to me that I could simplify the GWL code a lot by passing #:references-graphs `(("profile" ,profile)) <PurpleSym>apteryx: Good point. Also wrapped executables. <rekado_>my problem is that in order to build a container I need to know all store locations for a <program-file> object that should be mounted in the container. <rekado_>I wonder if I can do this without first building the corresponding derivation <civodul>rekado_: re references, see 'references-file' in (gnu services base) <civodul>that most likely solves your problem <zimoun>civodul: does guix.bordeaux.inria.fr provide default + specifics or only specifics? <jonsger>mothacehe: what is the easiest way to test the cuirass-simple-service? <mothacehe>and then you should be able to create a cuirass-simple-service as described in the documentation <rekado_>civodul: wow, it looks like it does! Thank you so much! <liltechdude>with `guix environment --ad-hoc python -- python3` and `import asyncio` get error <zamfofex>Hello, everyone! When running “guix pull”, I’m getting “Git error: unexpected http status code: 502”. Is this normal? <avalenn>Is it possible to host a substitute server statically (only generated static files, no `guix publish`) <snai1>hi, i'm trying to install forge packages from octave's package manager installed on Guix but i get this error https://pastebin.com/cwq8MxSQ ; anyone has some ideas about how to configure properly the octave libreries? Thanks <pineapples>Hello! In https://guix.gnu.org/manual/en/guix.html#Invoking-guix-package it is said that "When upgrading, package transformations that were originally applied when creating the profile are automatically re-applied", but it's later contradicted in the same article: "However, note that package transformations are lost when upgrading;". Which of these statements is true? <civodul>zimoun: it provides substitutes for a few things, notably the guix-hpc channel <civodul>the first one actually: transformations are preserved <civodul>i'll remove the second sentence, thanks for reporting! <jas4711>is there a way to search for which package provides which binaries? or is there a recommendation that 'guix package -s BINARY' should work? <jas4711>i was searching for the binary 'genisoimage' and it took some time until i found it was in the cdrkit-libre package, and I'm not sure how I was supposed to find that out <joshuaBPMan>jas4711: I've always posted in #guix or #debian or whatever distro I was using. <joshuaBPMan>Sometimes the program that you are looking for is bundled with another program. <civodul>jas4711: hi! there's on-going work in that area, but currently there's no program to do that <civodul>i typically go to packages.debian.org when in doubt :-) <jas4711>civodul: thanks. yes, that is how i found the reference to cdrkit which i then found in guix too <civodul>Python question: did anyone try to package bokeh, datashader, & co.? <mdevos>I want to use #:supplementary-groups in a service, but it isn't in any released shepherd yet. Is choosing a different shepherd package currently unsupported, or am I missing something? <mdevos>(the definition of shepherd-boot-gexp suggest it isn't. The shepherd package seems hardcoded) <zimoun>civodul: no, but it could be cool to have. :-) <civodul>mdevos: correct, we're missing an option to choose the shepherd to use <civodul>it's a bit ridiculous, but easy to fix <civodul>would you like to give it a try? :-) <mdevos>civodul: I'm doing that right now :) <zimoun>with “guix build foo -S” I get the source where the snippets in the ’source’ field is executed, right? <roptat>zimoun, no, you get the source after the execution of the snippet <roptat>I've translated that part of the manual yesterday, where it explains what a snippet does, and that the result is "treated as the corresponding source" ***leoprikler_ is now known as leoprikler
<zimoun>maybe, I miswrite, but it was what I meant. :-) So, the snippet should only used to remove non-compliant code, right? <roptat>indeed, that's also what the documentation suggests <roptat>it's used to remove non-free code, bundled libraries and binaries mostly <roptat>never to hard-code a store path or anything like that, which would be specific to guix <roptat>the idea is that the result is the corresponding source, which should be buildable on any platform already supported upstream <mdevos>are (rnrs lists) or (srfi srfi-1) procedures preferred in Guix? I believe it's the latter, but best check just in case :) <zimoun>just reading examples (trying to fix proof-general), I find emacs-graphql using source snippet instead of phase snippet. I guess. <roptat>I translated the manual yesterday and commited it, but the website doesn't look up to date <roptat>(the devel version, which is not too old either as it mentions weblate) <roptat>somehow, we need to find these errors earlier <roptat>what did you use to find the errors? <zimoun>roptat: you patch 5d03ef73c3 replace long line (one string) to multi-lines (one string per line). Is it expected? <roptat>I don't think it matters, but that was mostly because weblate was complaining <roptat>unless you're talking about multiline in the po format? as long as there's no explicit \n, that's fine <roptat>so msgstr "something very long" is the same as msgstr "something " "very long" on two lines for instance <zimoun>where, everywhere :-) po/doc/guix-manual.fr.po | 67181 ++++++++++++++++++++++++++++++++------------- and po/guix/fr.po | 4160 ++- <roptat>right, that's not the content of the translation, but the format used by the TP and weblate are different, but have the same semantics <roptat>there are a few translations where I added and removed explicit \n, but not that much :) <zimoun>so maybe one commit should do the “transformation“, from one-line to multi-line <roptat>I don't know, that sounds unreasonable <zimoun>but there is so much noise that your commit 5d03ef73c3 Updating ’fr’ translation looks weird. <zimoun>Magit and Emacs are hanging with trying to open it. :-) <mdevos>Does ‘Base Services’ in the Guix manual look like a good place to document a hypothetical ‘shepherd-service-type’ with a ‘shepherd-configuration’ that has a ‘shepherd’ field that can be used to choose a non-standard shepherd package? <roptat>zimoun, but OK, I see your point <roptat>not sure how to transform the file though <roptat>mdevos, is that different from the shepherd-root-service-type? <mdevos>roptat: oops, I meant shepherd-root-service-type, not shepherd-service-type <zimoun>I do not know what is the “best”. Maybe export with Weblate without changing any translation and commit that. <roptat>it's already documented in "Shepherd Services" <roptat>but it's just formatting, so maybe we can revert that to a single line <zimoun>since the commit is reverted, it is not too late :-) <zimoun>but yeah, maybe it is Weblate config. <roptat>I couldn't find any settings for that <roptat>but I'm thinking it could be part of the process: after downloading a translation from weblate, normalize it like the TP does <pineapples>A complete beginner's question: how do I specify multiple packages in the procedure (first (lookup-inferior-packages inferior)? I'd like to pin multiple packages specified in my manifest file to a specific commit at once. I tried to cook up something using "map" and "compose", similar to the procedure (map (compose list specification->package+output) but I'm still lacking the knowledge to make it happen. <roptat>(map specification->package+output '("foo" "bar" "baz")) <zimoun>roptat: yeah let recreate TP ;-) <roptat>but I have no idea what command they run to canonicalize po files <roptat>well, no, but it could be part of our download-po make target <zimoun>yeah maybe, civodul would have the answer since they spotted the errors. :-) <roptat>to spot the error, you'd run msgfmt -c <roptat>but it doesn't change the file like we want, that's two separate things <zimoun>pineapples: well, maybe the best it is have one manifest file per pin and these pins are give by channels file (guix describe -f channels), you create one profile per pin, and last compose your profiles. Well, it does not answer your question but a manifest file with too much inferior does not seem a good idea, IMHO. <roptat>very inefficient, but msgfilter -i my.po --no-wrap cat seems to work, for canonicalizing po files <roptat>though it's already taking more than a second for the guix domain <pineapples>zimoun: I considered using multiple user profiles but my problem with them is that they can't be set up declaratively from within my system configuration ***zimoun` is now known as zimoun
<roptat>pineapples, (map (cut lookup-inferior-packages inferior <>) '("guile-json" "guile-zlib")) maybe? <roptat>cut builds a procedure similar to (lambda (spec) (loopkup-inferior-packages inferior spec)) <zimoun>pineapples: you mean that you want different pinned packages for your system and not as an user, right? <roptat>then you apply that to every member of the following list <roptat>you'll have multiple packaged pinned to the same inferior <zimoun>yeah, I do not know how (or if) the po files should normalized before committing them. <roptat>ah, you want first too, so maybe (map (compose first (cut lookup-inferior-packages inferior <>)) '("foo" "bar")) <roptat>zimoun, that would kind of be good practice I think <Urist>Have a problems with ip routes => can't access internet (local network, probably too..) <pineapples>zimoun: I want to pin a few selected packages in my manifest file, which I'll pass to 'guix package -m' <zimoun>roptat, yeah it sounds reasonnable :-) <roptat>Urist, ip route looks reasonable <roptat>settings for wlp2s0 doesn't make sense to me though <roptat>it's your wireless interface, which I suspect is not connected to your router? <Urist>exactly. They doesn't correspond to #:gateway setting (they should) <pineapples>roptat, Thanks! I've tried your procedure with "compose first, and it's getting somewhere — I think it did the trick but I have to do some testing for good measure before I can call it a day :-) <roptat>mh? gateway is declared to be 192.168.1.1 and that's your default route <roptat>how does your wireless network card know which router to connect to, and with which password? <Urist>what does additional routes mean? <Urist>Then restarting networking-interface service <roptat>default route is if nothing else matches, send via your router. Other routes mean, for 192.168.0.0/24, use this or that interface <roptat>if you remove them both, your computer has no idea where to send packets to <roptat>because it doesn't know where the router is <Urist>I don't have a router at 192.168.1(not 0).0 <zimoun>pineapples: in this case, I would take the multi-profile road… otherwise as roptat said :-) The multi-profiles allow to upgrade only one profile without recomputing all, and inferior can be slow; depending on the number of packages, obviously. ;-) <roptat>yeah 192.168.0.0/24 is a notation for 192.168.0.0-192.168.0.255 <Urist>my wpa-supplicant config is working 100% <Urist>I have a method for getting current setup to work (manually) <Urist>But I don't know how to make it work proper way <Urist>I have same problem on 2 machines <Urist>default routes are right and working <roptat>meaning, to reach 1.2.3.4 (the internet), Linux will look at the routing rules: no specific rule, so it falls back to the default route, send to 192.168.1.1, then it looks for a rule for that IP, and find it needs to send through enp6s0 <roptat>the routes are right, but I don't think it makes sense to use static-networking for a wireless network <roptat>ah! you're not connected through the wired interface, are you? <Urist>i tried on other machine which have exactly same configuration and problem <roptat>the default route goes through enp6s0, which is the wired interface <Urist>it doesn't connected through wired now, and it have same ip r output <apteryx>zimoun: it's useful to lighten the source archive from useless bundle library files <Urist>i can get it to work using manual method of deleting routes and restarting services, but why doesn't it work as configured <roptat>Urist, can you try "ip l set enp6s0 down"? <roptat>there's some sort of conflict, I think it only registers one default route, the one that goes through the wired interface <roptat>but if you're not connected via wire, it can't work... <Urist>i did it on other machine :0 ***rekado_ is now known as rekado
<roptat>did the default route change? especially, does it go through wlp2s0 <Urist>no default route. only one route now, going through 192.168.1.0 linkdown <Urist>it goes through wlp2s0, sorry <roptat>so "ip r add default via 192.168.1.1 dev wlp2s0" should let you connect to the internet, I suppose <Urist> either "to" is dublicate or "wlp2s0" is garbage <roptat>there's no "to" in the command above <roptat>ah sorry, "ip r set default via 192.168.1.1 dev wlp2s0" <roptat>sorry, I have to read the doc again ^^' <Urist>Typing that on other machine returns <Urist>RTNETLINK answers: File exists <roptat>but I guess on the other machine the interface names are different, right? <roptat>so you need to give it the right names <Urist>I assumed we talk about two machines. One with wired enabled and connected. One with disabled and disconnected. I hope now I made it more clear <roptat>can we focus on just one machine? <Urist>What you are trying to find? <Urist>If defaults are sent by router and right. Wireless would surely work if I manually set it right. What then? <roptat>ok, let's take the first machine with wired enabled and connected <Urist>I mean, If I would get ip r show <Urist>default via 192.168.1.1 dev wlp2s0 <Urist>wireless will work, i guarantee <roptat>but default is via enp6s0 instead, which is the reason why it doesn't work <Urist>i believe non-default, which aren't sent by router, should be 192.168.1.1 instead 192.168.1.0 as I configured <zimoun>apteryx: how is defined “useless”? I mean, snippet should remove non-free and binary, otherwise it should be removed by phases. Otherwise we should provide a command to be able to download the real source package (or display the URL). What Guix says useless is not necessary useless for user; again, free and non-binary. For an example: emacs-graphql removes “examples.el“ because it is <zimoun>useless for building, but it is not useless for an user: typing ‘tar xvf $(guix build emacs-graphql -S)’. <roptat>Urist, 192.168.1.0/24 is exactly the same range as 192.168.1.1/24 <Urist>got that. Thank you for mentioning it again <roptat>so, I think there's some sort of conflict or race condition that leads to having only one default route, which happens to be the wrong one <Urist>network works only when default route is configured via wlp2s0 <Urist>non-default route 192.168.1.0 via wlp2s0 <Urist>If that's the correct behaviour. Than I should probably not use two static-ip configurations <mdevos>civodul: I've send a patch, after wrangling with emacs mail <apteryx>zimoun: it's a place where judgement must be used; there's no clear line. Carrying 20 MiB of windows-related code (not built on Guix) is not very useful and raises bandwith requirements, for example. <apteryx>Stripping the bundled LLVM from Rust 1.29 halves the archive size from 50 to 25 MiB as an other example. <apteryx>but the doc captures the spirit, I think <zimoun>apteryx, I agree. That’s just I am looking for examples and scrolling emacs-xyz and the 4 snippets (over 5) should be phases, IMHO. And that’s just random examples for a Friday’s evening procrastinating. :-) <zimoun>apteryx: Well, in fact the best should to have an option, say under ‘guix package’ to display upstream URL; then ‘guix download $(guix package --upstream-url=<foo-package>)’ and everybody is happy. :-) <zimoun>or expose the upstream url to package->rectutils, so ‘guix download $(guix show <foo> | recsel -P upstream)’ does the job. <apteryx>zimoun: that could be a problem for FSDG, I think. <apteryx>I don't think it's worth the complications, to be honest. <leoprikler>Well, in terms of FSDG, we do already link to homepages, that's close enough to a compromise in my opinion. <zimoun>apteryx, leoprikler: from my understanding, it is fine with FSDG because 1) it is source code (with acceptable license since it is in Guix) and 2) Guix will not distribute this code; neither source or binary. <roptat>zimoun, not necessarily, it could have non-free code we remove in the snippet <zimoun>And? downloading non-free code is not forbidden. What is fordidden is to run it and dustribute it. <roptat>and we would distribute non-free code <zimoun>no, I am proposing to display the upstream URL, only <Sharlatan>how may I get os type and arch type from Guile? <zimoun>roptat: show at the command line ’(origin-uri (package-source <pkg>))’ with the mirror resolved to have concrete URL. Then the user can pipe that with ‘guix download’ <roptat>in guix you can check the value of %current-system <zimoun>I do not see why it should be against FSDG *roptat needs to go, see you later <bavier[m]>the "upstream" source question was belabored during Guix's initial FSDG discussions. iirc the conclusion was that the guix interface shouldn't make it "easy" to get unpatched upstream source because that source may be patched for freedom reasons. <lfam>I agree with bavier[m]. This was discussed to death. IMO the status quo is worth preserving <lfam>I don't know how that relates to what you were discussing <lfam>But, I think we reached a good compromise <lfam>Or, others reached the compromise :) I was not involved <zimoun>If typing ‘guix download $(guix show <foo> | recsel -P upstream)’ is “easy”… and the returned code is not buildable as it is. I do not see where there is a trap. <zimoun>What is Guix interface? Scheme interface? Command line interface? <lfam>Another aspect of what makes the status quo "good" is that Guix enjoys significant autonomy in deciding how to satisfy these requirements <lfam>It's worth considering how to preserve that <zimoun>I do not understand, on one hand, the argument is snippet in source because it saves ressources (I buy the argument! :-)), for example rust and LLVM. But LLVM is free, so it should be removed in phases because it Guix convience. “guix build -S” should return the full free code. On the other, you are refusing to only display at the command line level the upstream URL. <zimoun>I miss the arguments, if there is. :-) <zimoun>Anyway! Have a nice evening. Cheers! <shcv>how do I load the 'special-files-service-type' variable? It's mentioned in the docs, but I'm having trouble finding the package to load <shcv>I tried (gnu services base) and several other options without success <rekado>shcv: can you show us what you tried and what error you get? <shcv>I get "error: special-files-service-type: unbound variable \n hint: did you forget a `use-modules' form?" <shcv>I tried setting services in my operating-system form with "(services (list (...) (service special-files-service-type `(("/usr/bin/env" ,(file-append coreutils "/bin/env") ...)))))" <shcv>basically following the docs and several example config files <shcv>my use-modules form contains: (gnu) (gnu services) (gnu packages base) (guix profiles) (guix packages) (srfi srfi-1), and I also have (use-service-modules networking ssh desktop base) <shcv>trying to load the base package mentioned in the docs <shcv>I don't get errors from having those, but they don't fix it either <shcv>looking at the source code, it should be exported by (gnu services)... <lfam>Or, at least the (services ...) part? <rekado>shcv: you’re missing (gnu services base) <rekado>the manual says at 10.8.1 Base Services: “The ‘(gnu services base)’ module provides […] special-files-service-type […]” <rekado>oh, you wrote that you do have “(use-service-modules networking ssh desktop base)” <shcv>I tried (gnu services) and (gnu services base) and neither seemed to work <lfam>It will be easier with your entire config.scm, but your services section looks incomplete. Usually you want at least %base-services as well <shcv>I didn't get any errors saying they didn't exist though <lfam>Your system would *only* have services for guix-daemon, nscd, the special files, and xorg. But lacking all the lower-level stuff that's required <shcv>I'm targetting wsl2 which is a slightly unique environment since the kernel is managed externally <shcv>copied the config from somewhere else, and it mostly works <shcv>I'm just trying to add a few things <lfam>Maybe someone else has some advice. It's rather uncharted territory <shcv>wow, I think I finally found the spelling error, despite checking it 30+ times already >.< <lfam>Fingers are crossed that it works now <shcv>please excuse me while I hit my head on my desk <lfam>If it does, it's worth an email to guix-devel explaining what you accomplished. <lfam>I don't think that WSL 2 has really been discussed yet <lfam>It would be nice to have some info on record <shcv>which mostly works, though as mentioned in the comments there is an interesting issue with nscd <shcv>what causes the warning "cannot determine provenance for current system"? <lfam>shcv: Either not using `guix pull` <lfam>Maybe before the first `guix pull` <lfam>For example, I have a system that I manage from a Git tree, and it shows that error <lfam>It's about the Guix code authentication and anti-rollback-attack features in `guix pull` <lfam>It's warning that you aren't protected <lfam>The "provenance" of Guix is the info you see in `guix describe` <lfam>The URLs and versions of all the source code <shcv>but i have used 'guix pull'? <lfam>What command did you run that produced the bug. Please always provide this info when asking for assistance :) <shcv>'guix system reconfigure wsl-config.scm' <lfam>Something didn't work as expected. Is it on Guix System? On WSL 2? <lfam>The more info you give, the more we can help <shcv>yes, I'm trying to run guix-sd on wsl2; I used the binary tarball to install the system according to the instructions in that gist I mentioned <lfam>Is it your first reconfigure? <shcv>no; I don't remember if the earlier ones had the same warning or not <lfam>I think it's okay to ignore it <lfam>My system works well despite it <lfam>You're going off the "happy path" on your journey, so a number of things won't work as expected <shcv>I'm used to that though; my normal work environment is gentoo on zfs root + EXWM <rekado>heh, unusually, EXWM is a rather common configuration among certain Guix users :) <lfam>The manual talks about provenance in a few contexts. If you wanted, you could read about them and pinpoint which expectation is not being satisfied on your system <shcv>I'm not surprised; guix + emacs work well together <lfam>Provenance might depend on using channels, not sure. I'm working from Git and also using old-school GUIX_PACKAGE_PATH <apteryx>rekado: I'm in the process of adapting all the PYTHONPATH occurrences... it's busy work. <lfam>Thanks for working on it apteryx <rekado>apteryx: do you remember hartmut’s “case study” way back? <rekado>Hartmut proposed a few scenarios and how the options he considered failed in those scenarios. <rekado>I wonder how your elegant fix fits into that picture. <pkill9>lighttpd needs documentation and default config files copied into store path <pkill9>and it needs directory listing enabled by default <apteryx>I can have a quick try; do you have the thread URL at hand? <pkill9>the second one being a need is more hyperbolic <lfam>I think it's more expected for a webserver to disable directory listing by default, right? <apteryx>it's interesting that Hartmut thought sitecustomize.py as a bad idea <apteryx>the first point is respected: PYTHONPATH is preserved, not overridden. <apteryx>the second point says if python runs with -S, it will not honor anything defined in site.py or sitecustomize.py. Considering site.py is the place that defines Python's own site-packages, I think that's OK. <lfam>Anyways, we should go with the upstream default <lfam>Except in extraordinary circumstances, it's not the role of a distro to make decisions about that kind of thing <lfam>Notwithstanding the practices of some other distros ;) <pkill9>annoyingly they require you to provide a configuartion file <pkill9>but they provide a default configuration <pkill9>and i think it's supposed to list directories by default <rekado>apteryx: I vaguely remember that I encountered packages that had commands where Python was invoked with “-S”. Of course I don’t remember any details… <rekado>but I guess we can work around that <pkill9>but it would be nice to be able to just go into an environment and run it to serve a directory <rekado>this shouldn’t keep us from having a better solution than what we have now. <lfam>pkill9: Python itself includes a webserver like that <pkill9>i know lfam, but it doesn't support seeking within a file <pkill9>so not good for serving audio/video files <lfam>The reasoning is that Debian simply lacks the resources to do it any other way <lfam>I've never worked in Debian, but I'm not surprised. It seemed to me they had a choice between "no kubernetes" or "kubernetes with bundled dependencies" <lfam>There was nobody to make "kubernetes with unbundled dependencies" an option they could choose from <lfam>I suppose that nobody with the resources (time or money) to make the 3rd option a reality saw any value in it <vagrantc>i get the rationale, but it's still a surprise as someone working in debian for 15+ years :) <avalenn>I wonder what it would mean for any attempt to get kubernetes in Guix <lfam>We already have some Go packages that bundle everything, if I remember correctly <civodul>lfam, vagrantc: i'm somewhat surprised too, and disappointed <lfam>I don't know what else one can do <civodul>i have the feeling that if Debian gives up, we're doomed :-) <lfam>Go has "distribution" built-in, so Debian really doesn't have a role to play <lfam>So, nobody is going to hire someone to do this work <lfam>Go is a post-distro language, for sure <vagrantc>guix in Debian should be working again building against guile-2.2 ... still just in experimental, but if that package works ok, i'll push it to unstable and hopefully it will make it to the next Debian release <lfam>Older languages didn't provide deployment or distribution, so distros had to exist. Go took all that into account when designing the language tools <civodul>it took the Go part into account and ignored the rest <vagrantc>civodul: i think the only blocker is the guile-gnutls issues... <civodul>but that issue is present with Guile >= 2.2.7 too <civodul>so i guess it just works by chance... <vagrantc>it seems to work consistently, at least... <vagrantc>also uploaded guile-zstd to Debian, in preparation for what looks like will eventually be needed to build guix :) <vagrantc>also today, i used the dpkg package from guix! it's come full circle :) <vagrantc>civodul: still waiting for review, but it was a pretty easy packaging job <vagrantc>there was one quirk with packaging it ... *vagrantc tries to remember <vagrantc>civodul: i had to pass ZSTD_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) to configure <vagrantc>civodul: not sure why it didn't take that from --libdir= <civodul>otherwise it would guess the wrong one? <civodul>(ZSTD_LIBDIR is for libzstd, not for the guile-zstd being installed) <vagrantc>civodul: it would guess /usr/lib instead ... what was odd is i think guile-2.2 would guess the right one, but guile-3.0 would guess the wrong one something weird like that <vagrantc>civodul: maybe vice-versa with the versions