***jo is now known as Guest55285
<nckx>Hmm. ’libva info: Trying to open /gnu/store/clhrbkacyrclwzkzdj2ql8y572whwjzi-mesa-19.1.1/lib/dri/i965_drv_video.so’, which doesn't exist, only i965_dri.so. <nckx>Great. Now I have to figure out how mesa works. <Guest55285>hey everyone. everytime i log into my guix system the time is set to jan 1st 2010 how do i fix this? *nckx doesn't see the dependency. *Dynamicmetaflow realizes humor doesn't translate properly with text <nckx>Dynamicmetaflow: Do I have a pending question of yours? Sorry! What is it? <nckx>Dynamicmetaflow: The needlessly tense exchange above didn't tip you off? *nckx buys str1ngs and Dynamicmetaflow their bevvies of choice. <nckx>Dynamicmetaflow: Where are you stuck? <Dynamicmetaflow>nckx: I kinda just signed on to IRC today and it all flew over my head <Dynamicmetaflow>nckx: I just know I appreciate you and I'm thankful for your support <nckx>Now you're just flirting. <Dynamicmetaflow>nckx: Eh, I'm taking a break at the moment from it all. Going to work on sending what I have to guix patch and see if someone can help out with the quirky issues with gnome-boxes <nckx>Mainly the bogus smartcard thing, right? <nckx>(Not-too) WIP patches are fine! <Dynamicmetaflow>nckx: yeah, the smartcard thing, i tried yesterday figuring out how to patch QEMU but couldn't figure it out <civodul>pkill9: this particular .guix-channel file LGTM, but maybe it's another .guix-channel file that's incorrect, such as that of pkill9-free-channel-dependency? <erudition>2¢: Corrections are not personal attacks, and clearer communication should always be preferred over catering to people who don't realize that. For example, I sat here wondering what the heck any of this had to do with diseases, probably because others were scared out of correcting "pandemic" to "pedantic". Or at least I think that's what it was supposed to be <nckx>Dynamicmetaflow: Oh. Wow. It's that bad? I thought it was just a quirk in G-B. <Dynamicmetaflow>nckx: it seems like some flags need to be enabled with QEMU, right now you can run gnome-boxes, the ui icons are messed up, you can create vm's etc but they won't run, <rekado_>Dynamicmetaflow: icons being weird is a common issue <rekado_>Dynamicmetaflow: so this shouldn’t block your patch <nckx>You're saying it almost works *and* there's One Weird Bug? <rekado_>Dynamicmetaflow: if you can send your qemu change attempts to guix-devel or guix-patches I’ll take a look. <rekado_>I’ve seen the problem when testing gnome-boxes and I’m sure we can figure this out. <Dynamicmetaflow>Would you recommend part 3 from the creating a package videos from the archive? *rekado_ hasn’t watched the packaging videos yet… :( <kori>there are packagng videos? <Dynamicmetaflow>rekado_: Ok well I will try to send the patch tomorrow morning base off the video and I may ask in IRC for support <rekado_>(the three failures seem to be unrelated to my changes) <civodul>rekado_: in other news, i'm planning to merge the guile-json3 changes like now <civodul>so i can provide support in the aftermath before i leave ;-) <rekado_>I looked over them and they seem straight-forward, but I guess you never know with something as deep cutting as that… <civodul>i found that i had forgotten about the github updater, for example <civodul>but the fixes are rather straightforward <kori>nckx: im kinda easily frustrated by failure <kori>(im working on my fork of guile-xcb lol) <nckx>Ooh, the notorious Guile X proto rewrite? <civodul>kori: what you did with Xlambda is a success, not a failure, IMO *nckx nods painfully fast. <kori>civodul: oh I wouldn't consider Xlambda a failure at all <kori>I am failing at understanding what most of this code does, though <kori>as you can see, all my first commits are <kori>"zap everything i don't understand/don't intend to understand" <kori>and rework the things i don't understand until I understand them <kori>well. the things I don';t understand and want to understand <civodul>there are pros and cons to that approach ;-) <kori>wish I could talk to mwitmer <str1ngs>by the way xorg kinda implies xorg while xcb is more of a protocol for communication. just something to consider in terms of naming. <kori>i thought xorg-lib (can't do xlib because xlib is another thing) <kori>mbakke: I don't know how to :< <kori>im a zoomer, im used to Instant Replies <kori>but yeah i guess email could work <str1ngs>yeah the main thing is people know it's xcb. I know I'd rather use that myself <kori>str1ngs: I have... very different ideas <kori>about a guile lib in xorg <kori>...about a xorg lib in guile <str1ngs>well xorg lib != xcb . it gets confusing i know lol <kori>absolutely [expletive deleted] me <kori>scheme code, based on a xml spec of xcb <kori>lots and lots of layers of abstractions that i would need to unfold <kori>i'd rather reduce that work for future generations(tm) <kori>if someone just wants to do something like (xorg:connect) (xorg:draw-line! 0 0 100 100) <kori>and it'd draw a line on the screen <kori>i'd like that to be as simple and straightforward as it looks <kori>or maybe even something wild like (xorg:draw-rectangle! 0 0 100 100) <rekado_>kori: it seems to me that the surface API can be as pretty as you want. That doesn’t mean that the lower level needs to *directly* provide this interface. <kori>rekado_: it doesn't but i come from Go where going down the layers of abstraction is pretty direct, the documentation is kinda insane in that regard, you can like, clearly see how something like "xorg:draw-line!" would actually behave. Xlambda does very well in this regard, imho <kori>rekado_: im gonna take a look <str1ngs>kori: it's xcb self defining can you auto generate something. I know there are bindings out there that do that already. <rekado_>the idea is simple: define a “compiler stage” that converts the spec to Scheme, then let Guile take care of the the rest. <rekado_>that’s defined in language/aws/spec.scm; it’s really just instructions for how to turn this particular JSON AWS specification into Scheme modules. <str1ngs>kori: yeah go's duck typing is really nice sometimes. <rekado_>whatever sits on top of that is up to me, syntactic sugar. <kori>rekado_: the json spec in this case is quite short and i think it's fine to take this approach in this scenario i guess <kori>(it still is a bit weird to me still, but I guess i'll learn how to understand this sort of code better) <kori>str1ngs: the question I haven't had answered yet is like <rekado_>one of the specs is 1.5MB. There are dozens. *rekado_ —> zzzzzZZZ … zzz <kori>it feels weird to me to have a "guile-xcb" considering like, libxcb (and im assuming, its spec too) were built on top of the quirks of C <nckx>‘guix install icecat’ just broke the fonts in all newly opened termite terminals. <kori>there's a lot of code to "unquirk" that C, so you can do it the Guile way, and then a lot of code to "requirk" it the Guile way <kori>I think I might be wrong <kori>you can see how this is like, hard to follow, right? I'm not saying it's hard to follow in general, but like <kori>if this is my first impression as a semi-beginner <kori>it's kinda hopeless to ever expect me to figure it out in a reasonable amount of time <str1ngs>kori: no, I'm getting the general gist of the issue. <kori>tl;dr i wanna talk to the X server and only really hopefully rely on Guile's quirks <kori>rather than two levels of translation <kori>(or 3, if you count xml) <str1ngs>what's the issue with the orginal guile-xcb is it not maintained? <mbakke>nckx: Did it "undo" another profile generation or what? <kori>str1ngs: my issue with a lot of software (including guile-xcb) is that they don't really provide clear examples <nckx>mbakke: That was my first thought too (thinking of recent ML content), but it's not that. <kori>but it could be... way more documented <kori>I'm severely worried I might get lost in my own code, so I document it a lot <kori>and I recorded a demo for example <civodul>guile-json3's in the house; lemme know if it eats your laptop or something <mbakke>nckx: perhaps you wrote a profile hook to update the font cache while intoxicated, and only now found a bug in it? :P <kori>I got a bit lost in guile-xcb's thing like <kori>i don't even know what xml-xcb means anymore. I guess it's like, the project that wrote the xml specification for xcb? <kori>but there's guile code that deals with that <kori>and it's also called xml-xcb(.scm)? <kori>its all very confusing, you see <nckx>mbakke: I am at this very moment staring at fc-cache output, yes. But me? Intoxicated? Only by the thrill of the hunt, my friend. <kori>the actual library code was under a xcb/xml dir <kori>took me a while to even find it <kori>sorry, guix. I'm venting, mostly <kori>this is why I have a headache, im just frustrated <kori>str1ngs: what's now under src/ is the output <kori>this is what did the generation <kori>i.e. theres no build system yet <kori>i need to write a new makefile and a guix package definition <kori>do colors even work here <str1ngs>looks like this is using rekado idea to create a guile language for parsing <civodul>maybe these are topics for #guile, or #xorg, or #autotools, dunno :-) <str1ngs>kori: autotools gets a bad rap, you have to understand that its' old but still effective :P <kori>civodul: definitely, i was thinking that too <civodul>i like to say that autotools are what users want (not necessarily what developers want) <kori>i moved the convo to #guile <nckx>It was a f****** fontconfig bug, because of course it was, and it's happened before. sudo rm -r /var/cache/fontconfig ‘fixed’ it, but since I'd never run ‘sudo fc-cache’ (yes, even while shitfaced) something is doing it behind my back. Or so. <nckx>Gettin' real tired of fontconfig. <kori>controversial opinion: guix font packages should run fc-cache automatically <civodul>i never really had bad experience with fonts <nckx>I believe you. I thought mine was a one-time fluke (and possibly user error) but now I'm positive I didn't do anything stupid. <civodul>we could have a profile hook that generates the fontconfig cache, but i think there was a reason why that wouldn't work <nckx>(I'm calm now. I promise. I just had 1 working terminal and constantly afraid of closing it by accident 😃) <kori>nckx: i know that feeling <kori>civodul: we should talk someday <nckx>kori: Not that controversial, actually. <nckx>This was just a different issue (I ran fc-cache -rv about 12 times in the past 3 minutes, the problem was a root-owned cache directory). <str1ngs>Dynamicmetaflow: just ask, but yes I do at least :P <Dynamicmetaflow>str1ngs: Could you do me a quick favor, could you export a org-mode document to ODT <str1ngs>is there something specific you need to test? as in guix? <Dynamicmetaflow>I tried emacs -Q and tried to export a org-document to ODT and was unable to had to do a workaround and install pandoc <str1ngs>Dynamicmetaflow: will try in a sec, not on my guix machine right now <Dynamicmetaflow>alexanderbarbosa: I think this may be a guix specific issue with paths <str1ngs>Dynamicmetaflow: I can test just might take a few minutes till I can <str1ngs>Dynamicmetaflow: I get OpenDocument export failed: Buffer is read-only: #<killed buffer> <str1ngs>Dynamicmetaflow: what does the *Messages* buffer say? <str1ngs>Dynamicmetaflow: i'm on hosted guix though. just an added caveat. but if you get the same thing. <Dynamicmetaflow>seems like emacs ODT export needs, zip, soffice, and maybe it's also related to paths though not sure <Marlin1113>it seems that i can't do anything that involves using https stuff <Marlin1113>i tried guix import for a pypi package, it says the signer could not be verified <Marlin1113>also, i can't get stuff from guix channels that use https <nckx>Marlin1113: What does it say? Do you have the (most recent) nss-certs package installed? Is your system clock correct? That's all I can think of off the top of my head. <str1ngs>Dynamicmetaflow: my hosted emacs export's to ODT okay. wonder if its an issue with emac 26+ <str1ngs>Dynamicmetaflow: though I don't have anything to read it with :P <str1ngs>I suspect it's a valid export though <wdkrnls>Hi, for some reason my root user doesn't seem to know about it's channels. <wdkrnls>However, my personal user account does know about them. <wdkrnls>Is root supposed to find channels in it's "home" directory? <wdkrnls>Maybe... the point is that I am able to ~guix system reconfigure~ from sudo -E as regular user, but I can't ~guix system reconfigure~ with root. <wdkrnls>Guile doesn't seem to have the load path for the modules defined in the channel. <str1ngs>wdkrnls: does guix describe match for root and user? <wdkrnls>Hmm... guix describe matche sudo guix describe, but logging into root, guix describe gives an error. <wdkrnls>guix describe: error: failed to determine origin <wdkrnls>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version <str1ngs>wdkrnls: I would maybe do guix pull --commit=<hash> to match user <wdkrnls>Is the hash the last element of the first line of the output of: "guix describe -V"? <quiliro>Mi ne povas uzi icecat-on aŭ epiphany-on kun tiu retpaĝo? <wdkrnls>My check out guix has a commit hash of 7304d5623a according to git. Is there a nice way to find this from guix? <wdkrnls>guix hash seems like it would tell me, but I can't figure out how for it do so. <wdkrnls>oh. I see: the full hash is 7304d5623ab5cc35289cb1535cbd0d8a37691fac <quiliro>wdkrnls: can you test epiphany or icecat with meet.jit.si for me please? <wdkrnls>well, if it's a web address, then it's not supported in epiphany <wdkrnls>"please try again with the latest version of Chrome or Firefox" <davexunit>has anyone here built a windows executable using guix? <erudition>Yeah Jitsi Meet needs the latest WebRTC tech <erudition>Epiphany silently fails on complex stuff like that, so at least Jitsi tells you <bandali>anyone else having trouble with guix pull? <bandali>i’m getting a “guix pull: error: symlink: File exists: …” error <erudition>davexunit that would be awesome to hear about <str1ngs>bandali: sounds like the link already exists in /var/guix/profiles/per-user/$USER/ <davexunit>erudition: I'm going to experiment with mingw. should be possible. guix makes cross-compilation an easier task. <davexunit>need to re-familiarize myself with some stuff, though. <str1ngs>bandali: how many links are in /var/guix/profiles/per-user/$USER/ ? <bandali>str1ngs, ha, about 20 or so, including current-guix and guix-profile <erudition>davexunit I can Imagine one day guix being the only tool needed for a cross-platform app <str1ngs>bandali: you could figure what link exists that it's trying to create and remove it. but that might cause orphaned files /gnu/store or GC issues <bandali>str1ngs, great :p so there’s no “easy”/reliable way around this? :( <str1ngs>bandali: well you can discount guile-profile links. guix pull uses current-guix so it's one of those <davexunit>erudition: would be nice! you may have to do a little more work than you'd like, but all the tools are there to make it happen. I've built binaries for AVR microcontrollers with Guix before. <bandali>str1ngs, would i be trying removing current-guix itself, or e.g. current-guix-4-link pointed to by current-guix? <str1ngs>bandali: that is most likely the culprit but I would back it up to be safe. at least note the store path <str1ngs>current-guix-4-link and current-guix <bandali>str1ngs, thanks, will give it a shot <str1ngs>bandali: just be carefully this may effect garbage collection <bandali>str1ngs, in that i may run gc and it’d delete something it’s not supposed to delete? <str1ngs>more likely that it won't delete something <str1ngs>it's very hard for the GC to delete something contained in a root aka profile <bandali>well, trying the current-guix symlink and leaving everything else seems to have “worked”, in that i don’t get that error on pull anymore <str1ngs>but I don't understand the GC and var database enough to safely navigate a better solution. <bandali>i don’t even know what causes/caused this issue to begin with <str1ngs>it's more of a question of how it's not aware of the profile and thinks that's the profile to use. <str1ngs>there is larger issue which cause this state. if that made sense. <bandali>hmm, i changed my system user to something else and then back last week <str1ngs>I don't think this fix will cause system breakage though <bandali>i wonder if that may have anything to do with it <str1ngs>I don't think that would case problems guix is per-user based <bandali>i *think* i used the profile from my old user <str1ngs>in the future. just note you don't need to use your other user profile. guix is per user based. if you want functional profile use a manifest <str1ngs>in which case you can recreate your profile on a whim :P <bandali>thanks for the tip, i’ll definitely do that next time :) <bandali>i know close to nothing about manifests yet <bandali>thanks for the link, will look through it <ryanprior>I've created many Dockerfiles as build/test/repl environments for projects I'm working on or code I'm shipping. <ryanprior>I'm hoping to get familiar enough with guix manifests to use them in a similar manner. Slow going so far. <roptat>htgoebel, if it doesn't exist I think you can create it ***raghavgururajan is now known as Guest46217
<mfg>hi there :) I'm trying to compile some 32-bit program and get the following error: <mfg>.guix-profile/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory <mfg>do i need a special gcc version? <mfg>gcc-multilib or something? <roptat>mfg, I don't think our gcc supports multiple architectures, you should use --system=i686-linux iirc <mfg>so i need to guix install --system=i686-linux gcc ? does this get removed with the next update? <htgoebel>roptat: I have a maven-build-system laying around on my pile. Is it worth submitting the patch? <htgoebel>I did not work with the java stuff in guix for more than one year <roptat>it works, but I still need a lot of binaries from maven central <roptat>although I'm pretty sure now I can build the plugins properly (it will maybe take a week or so to finish that), and that's the only dependencies left for building a hello world maven project <roptat>I'll also probably have to change a few things there to patch dependency versions <roptat>and change the ant-build-system to patch and intsall a pom file if it exists <htgoebel>You build-system looks much more sophisticated than mine. <htgoebel>I assume I never finished mine, so I'll just drop it. <htgoebel>If you like for curiosity, I'll send you my patch. ***Guest46217 is now known as raghavgururajan
***raghavgururajan is now known as Guest94158
***Guest94158 is now known as raghavgururajan
<htgoebel>you are welcome. Thanks for all the work you put in maven. <roptat>it's not even what I wanted at the beginning :p <roptat>I wanted gradle, but it seems that maven is a necessary step for that <desttinghim_>After running `guix install guile-chickadee`, `(use-modules (chickadee))` tells me that there is no code found for module chickadee <htgoebel>I not even wanted gradle, but just an application build by gradle <desttinghim_>Do I need to run any command other than `guix install *some-guile-module*` to be able to use a guile module? <roptat>desttinghim_, try to install guile itself? <roptat>also make sure you source ~/.guix-profile/etc/profile from your ~/.profile <desttinghim_>I need to log out and back in for changes to .profile to take effect right? <desttinghim_>That was the problem! I needed to add source ~/.guix-profil/etc/profile to ~/.profile <roptat>I think it's in the manual, let me check <roptat>it's in "4.2 Invoking guix package" <roptat>probably not the best place, or at least there should be a link from the installation section <roptat>"f you are not using Guix System, consider adding the following lines to your ~/.bash_profile (see Bash Startup Files in The GNU Bash Reference Manual) so that newly-spawned shells get all the right environment variable definitions: " <desttinghim_>Yeah, I think that deserves a mention in the installation section <roptat>I guess there should be a paragraph about it in the application setup (2.6) <roptat>oh, then you shouldn't have to do that <roptat>it should already be the case by default <desttinghim_>So I created it and added `source ~/.guix-profile/etc/profile/` <roptat>oh, we don't provide a .profile, only a .bash_profile <roptat>although that isn't it either... it's in /etc/profile <roptat>I wonder why it's not loaded in your case... <roptat>because when you add a package that changes .guix-profile/etc/profile, it's not loaded automatically <roptat>since /etc/profile is only loaded at login <desttinghim_>Applications work immediately because the get added to .guix-profile/bin/, right? <roptat>yes, and that's already in your $PATH <roptat>but if something adds another environment variable like GUILE_LOAD_PATH and such, they are added to profile, but not loaded immediately <Dynamicmetaflow>Has anyone received this error with cups? D [25/Jul/2019:06:28:21 -0400] [Job 21] sh: hpijs: command not found D [25/Jul/2019:06:28:21 -0400] [Job 21] GPL Ghostscript 9.26: Can\'t start ijs server \"hpijs\" <rekado>you may need to install hplip globally <rekado>no need for root, but if that’s the cup service you may need to add it to the packages section of the operating-system configuration. <rekado>(as far as Guix is concerned root is just some other user account) <Dynamicmetaflow>ah so root in this instance is adding it to the packages section of operating system <rekado>Dynamicmetaflow: yes, “global” means adding it to the packages section. <rekado>the result is that the package will be installed into the system profile at /run/current-system/profile <rekado>I’m not sure this is the right fix for your problem. Could be that you need to just add it to a field in the cups configuration. The manual probably has something to say about that. <Dynamicmetaflow>Well I got the printer working but it's not printing correctly, I think it has to do now more with the PPD <Dynamicmetaflow>was trying to pdf and it printed the images but not the text, whereas the text printed on the test-page <rekado>Dynamicmetaflow: I’ve been having mixed results with my own printer. <rekado>like for Chinese documents it would sometimes print nothing at all (not even digits or lines) <rekado>had to resort to printing to a file before printing that file <rekado>could be due to the different backends that are used. <rekado>could be that the act of printing to a file rasterizes the document, which makes it trivial to print <rekado>my professional opinion is that printers are the best evidence for the existence of hell. <rekado>I’m using a Brother HL-L2370DN FWIW. It works fine with free software, except for these occasional quirks that I’m willing to blame on every component in the setup: Guix, CUPS, the driver, the printer, ghostscript (for good measure). <Dynamicmetaflow>And, I'm like "oh no I have to setup my printer, it will either take 2min or 2 days" ***tux is now known as Guest40963
<Dynamicmetaflow>Apparently when using Ungoogled-Chromium there is a checkbox to print the document as an image, I checked that off and it printer correctly <rekado>2 days is still good as far as printers are concerned, I think. <rekado>of course not when under time pressure <rekado>(are people ever printing anything when they are not under time pressure?) <Dynamicmetaflow>Rekado in a little bit I'm going to work on sending gnome-boxes, I want to fix up the inputs and such before I post it <Dynamicmetaflow>Going to be away until Monday and would prefer to send it to the mailing list before then <nothingmuch>i've been trying to write a package for blocksci (https://github.com/citp/BlockSci), and it seems i'm too thick/ignorant to understand some interactions between cmake and gcc-7, i'm seeing "/gnu/store/...-gcc-7.4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory". if i understand correctly this is a result of C++ wrappers for C headers not being found before the corresponding <rekado>feel free to Cc me. I have a hard time catching up on all email that goes to the mailing lists. <nothingmuch>if anyone is familiar with this, can you confirm that i am following correctly? <rekado>nothingmuch: on the core-updates branch where we use gcc-7 by default we’ve had to deal with this kind of problem as well. <rekado>I don’t know the details, but I think it was enough to set different environment variables, which are not set by default in the build systems in the “master” branch. <rekado>I’ve built ITKsnap a few days ago, but I’m struggling with an annoying problem. It can’t actually load any PNG images. Instead it prints “libpng error: unexpected zlib return code”. <rekado>has anyone seen anything like that before? <rekado>(ITKsnap is a medical imaging / segmentation tool, and it’s unusable without, well, image support.) <Dynamicmetaflow>I don't know, when trying to build gnome-boxes I studied how it was built on other platforms, gentoo arch etc <rekado>hmm, looks not too different from what I’m doing. <rekado>annoyingly, the error is actually reported by libpng. <rekado>perhaps some bundled copy of zlib ended up in the output and causes trouble…/ <rekado>or maybe I should use libpng-apng <rekado>it’s frustrating that this is in dependent packages. Gotta rebuild all of them just to test this :-/ <nothingmuch>what determines the compatibility of guix & guix-daemon? i think i've been running a ./pre-inst-env guix w/ the system daemon, and i'm not sure how wrong that is to do <rekado>raghavgururajan: I appreciate your updates on bugs. Could you please not override the bug subject with “ATTENTION REQUIRED”, though? The original subject is usually more helpful. <rekado>nothingmuch: that’s totally fine. <rekado>nothingmuch: the daemon rarely ever changes and when it does you can still use a newer Guix with an older daemon (with degraded features) <rekado>I can’t remember the last time I ran the daemon under pre-inst-env. <rekado>using the system daemon is the common case. <raghavgururajan>rekado Oh Shoot! I assumed it will not over-ride the original subject. My bad. <rekado>raghavgururajan: well, it does for the current email anyway. <rekado>don’t worry, you didn’t retitle the bug in debbugs <rekado>but in email clients it appears as “ATTENTION REQUIRED”, which is … yeah, well, all emails kinda require attention. <rekado>really good that you keep track of reported bugs, though <tqbl>recently installed guixsd. it seems to download a lot of packages that shouldn't be dependencies. why is this? *raghavgururajan 's OCD comes in handy for keeping track of bugs xD <rekado>tqbl: Guix will only download things that are declared as dependencies. <rekado>tqbl: what makes you think it’s downloading things that aren’t needed? <tqbl>rekado: e.g., why is mpv being downloaded? i used the light-desktop config. <tqbl>i changed it a bit since then <tqbl>i basically added a few other things like fish, rxvt-unicode <tqbl>i'll see if using the gc can free same space. right now, the system is using 4.3 GB, but there are a few generations <roptat>tqbl, could you have been downloading mpv for something unrelated to the system configuration (a user profile, ...)? <tqbl>roptat: i used the light-desktop config and just changed the username <roptat>if you know where mpv is in the store, you can try to run "guix gc --referrers /gnu/store/..." to see why it needed *rekado would like to see a derivation tree mode for emacs, allowing us to quickly browse through dependencies <roptat>tqbl, when did it download mpv? on guix system init? on a reconfigure? <tqbl>strange. 'which mpv' returns no mpv, but i could've sworn i saw it downloaded <tqbl>roptat: guix system init <rekado>tqbl: it could have been downloaded, but this doesn’t mean it’ll end up on your PATH. <rekado>could just quietly sit in /gnu/store minding its own business. <roptat>I don't really understand why guix would need mpv in your case... <tqbl>i'll install the distro again soon and log the output <roptat>can you try "guix gc --referrers `ls /gnu/store/*-mpv-*.drv`"? <rekado>I don’t see it used in any profile hook, nor in any service. <rekado>there are only two packages that use mpv as an input. <rekado>(or could it have been some store item whose hash included the letters “mpv”?) <rekado>raghavgururajan: looks like only curseradio@0-1.1bd4bd0 and gnome-mpv@0.16 use mpv as an input. <tqbl>rekado: hmm. i'll double check when i install again. <roptat>tqbl, you don't really need to reinstall just because of mpv though... <roptat>I insist: can you try "guix gc --referrers `ls /gnu/store/*-mpv-*.drv`"? <tqbl>roptat: no matches for wildcard mpv <tqbl>roptat: that's okay, i installed on virtualbox. it's not a hassle to reinstall again. <roptat>how did you determine it downloaded mpv? <tqbl>roptat: i suppose i could've made a mistake. <tqbl>i just saw mpv-{version} <tqbl>... being downloaded. or at least i thought i did. <rekado>unless you deleted the initial system and ran “guix gc” the thing should still be in /gnu/store <tqbl>sorry about the lack of certainty. i'll get back at some point once i check things properly. <roptat>if it does that again, please don't run "guix gc" before reporting it :) *davexunit getting back into guix a bit for the first time in awhile <davexunit>one thing I'm working on is generating redistributable binary bundles of games written with guile and sdl2. back in 2017 I had a working prototype of this, but it used gcc 4.9. I haven't yet figured out the magic hacks needed so that I can unguixify gcc 5. <davexunit>by unguixify I mean "don't hardcode runpaths and other stuff that inextricably links shared libraries to the store" <nothingmuch>the toolchains used aren't gcc-5, but dynamic linking issues were discussed and addressed especially in the top third of that PR's comments <nothingmuch>(note that the actual build is just using guix for the toolchains and containerized build environment, it's independent of guix's own bitcoin-core package definition) <davexunit>that's essentially what I'm going for as well. <roptat>davexunit, what about guix pack -R? <davexunit>roptat: I know about them but it's not what I'm looking for. <davexunit>I really just need a few .sos, guile, and some guile modules. <davexunit>the second is the runpath problem. without user namespaces the resulting pack won't work. <davexunit>or you get a pack that you have to extract onto / <davexunit>the third is that I'm looking to target osx and windows with this project, so I need something special. <davexunit>I've prototyped this approach for linux before. it's very feasible if you know exactly the stack you are working with. making a general purpose tool would be extremely difficult. <minall>To install a driver, is it necessary to add it on the config.scm and then reconfigure? is there any other option?, or by installing it on the user you can use it normally on that user? <quiliro>minall: no funciona si no ejecutas un reconfigure <minall>Entonces, al instalar algun driver, siempre es necesario hacer un reconfigure? <minall>Cause, for example, to install a driver on any other distribution, you just search the package and install it, simple, of course, but to add a driver on guix seems to be more complicated, and not user friendly at all <minall>Maybe a command that allows to install system wide packages? <roptat>null_radix[m], that's expected. You can use "./pre-inst-env guix environment --ad-hoc hello" to have a temporary environment, and not have hello installed in your default profile <roptat>note that hello (from your checkout) will be installed in the store, but not in your profile <minall>How can I rebuild emacs, but with xwidget support?, do I just, rebuild it? <roptat>minall, you'll need a package definition where emacs is built with xwidget <minall>roptat: The #emacs people sayed the same, but not sure what that means <raghavgururajan>After setting account through setup wizard, nothing happens. No window at all. Even restarting app does not work. <minall>Do you mean, not rebuild emacs, but one that's emacs but with xwidget? <roptat>to have xwidget support, emacs probably needs to be built with xwidget <roptat>but the package definition in guix doesn't do that it seems, so you need a new package definition for emacs with xwidget <roptat>(just building emacs with xwidget installed in your profile won't do, because builds are completely isolated from your environment) <roptat>null_radix[m], it's OK, the file doesn't exist anymore ^^' <roptat>null_radix[m], not the doc, you're only reading a blog post <roptat>oh, actually it's not a bug in the doc: it says "assuming the new package is called gnew" <roptat>so basically, it says "if you had a module named gnew, here's how you do it" <null_radix[m]>so doing `./pre-inst-env guile -c '(use-modules (gnu packages guile))'` is compiling a bunch of stuff... i wasn't expecting that, is `use-module` building the module? <jonsger>uff openSUSEs guile core dumps on building actual guix from master <quiliro>minall: not user friendly is that installing a package breaks other packages...that does net happen in Guix <quiliro>finding something new is a reason to learn it, not to criticize it before knowing how it works <minall>quiliro: makes sense, so is for mantaining stability? good <minall>roptat: so, since builds are isolated, then how should I build emacs with xwidget support? maybe make a package entirely of it? <roptat>you can make it inherit from emacs, so you don't have to rewrite the whole package <minall>Mhh, I see, perhaps add the xwidget support as an argument on how to build the package, and add it as a package named> emacs-xwidget_support <minall>How can I add the package to be available on GNU natively?, or should it be added as a channel? <quiliro>minall: to make a new package, you need to make a package by just modifying another package <quiliro>you just need to install a package from a file <minall> Yes, I mean, for example: I get the emacs package, I changed it to have xwidget support, I install it, it works, then, if I want to make is public, like natively on GNU, just by installing guix having it, is there a way, or does it have to be a different channel?, or should I send a message to add the package at that point? <minall>Marlin1113: Yes, it seems that it is brokem <roptat>minall, then you can send a patch to guix :) <minall>Does the guix installation checks your device drivers, or do you have to add them manually? <Marlin[m]>nckx the issue with https is that .profile is not being sourced <roptat>Marlin[m], a login shell I think <Marlin[m]>i have the .profile sourcing .guix-profile/etc/profile <tqbl>to follow up on what i said about unwanted dependencies, while i don't see mpv (maybe that was on another system with a custom config or i just have bad memory), i see ffmpeg, for instance. <tqbl>which requires quite a few packages <Marlin[m]>As .profile is not being sourced, .guix-profile isn't either <roptat>on the guix system, it should already be sourced in /etc/profile though <roptat>tqbl, so can you try "guix gc --referrers `ls /gnu/store/*-ffmpeg-*.drv`"? <roptat>that should tell us why you needed ffmpeg <tqbl>roptat: i believe it was alsa <roptat>tqbl, alsa-plugins is a leaf package, do you really need it? <minall>Guys, is there something you think one should always add on a config.scm? <tqbl>roptat: no. how do i get rid of it? <roptat>isn't it referenced in your system configuration? <tqbl>roptat: it's not. also, a barebones install needs flac <tqbl>because of shepherd-udev apparently <roptat>tqbl, oh, it's from the alsa service <roptat>we need it only for the alsa pulseaudio thing <tqbl>is there a way to cut down on these dependencies? <roptat>we could have a smaller alsa-plugins package which only depends on pluseaudio <roptat>or you could remove the service entirely <roptat>(but then some audio stuff will not work correctly) <minall>Yep, I think that you should have always pulseaudio installed, since most apps use it and may not work with alsa, <minall>Or is there a reason to use alsa instead of pulseaudio? <roptat>no, some apps only use alsa, but then that conflicts with a running pulseaudio <roptat>so we have a service to install a configuration file so alsa uses pulesaudio as its output <roptat>and that requires alsa-plugins because of the alsa pulseaudio plugin it contains <roptat>but alsa-plugins also comes with more plugins <minall>roptat: which apps, for example? <Marlin[m]>i sourced .profile in my .xsession and it works <minall>Yes, I think adding alsa to the config.scm doesn't use pulselaudio <nalkri>Am I right to think that I can't use guix-sd on a Pi because it needs the blob? <minall>That's the think, I maybe can say, some apps don't work on alsa, but work on pulseaudio, but I'm not sure I can say some apps don't work on pulseaudio, but do on alsa <tqbl>ffmpeg requires a lot of packages for codecs that i suspect also-plugins doesn't need. <minall>But I think there's a way o use alsa directly but having pulseaudio installed <roptat>minall, yes, that's exactly what our alsa service is about :) <tqbl>is there a way to override ffmpeg so that it installs fewer dependencies? i mean, modifying the configure flags. <minall>I mean, in the manual, says> adding the (gnu services sound) module, provides a service to configure the Advanced Linux Souns Architecture (Alsa) system, which makes pulseaudio the preferred ALSA output driver. <minall>So, just by adding (gnu services sound) I'm using alsa instead of pulseaudio, but I still have pulseaudio installed, for apps that use pulseaudio?? <roptat>tqbl, you could try to chaneg the alsa-service configuration to use another alsa-plugins that doesn't need ffmpeg <tqbl>roptat: thanks. i'll look into it. <roptat>minall, no, the module only provides a service, then you need to instantiate it <roptat>alsa is always available, the service is only to make it play nicely with pulseaudio <roptat>it won't make apps use alsa all of a sudden <roptat>tqbl, I'd be interested in results, maybe I can even work a bit on it <minall>Mhh, so for example, adding the module and calling in the services part /alsa-service-type/, and then I can do something like /alsa-configuration(pulseaudio f)/ <minall>What do you mean, \play nicely with pulseaudio\, the sound works fine all the time, so why should I use the module ? <roptat>because sometimes some apps will use alsa instead of pa <minall>roptat: No, I mean, on the manual you can configure alsa to don't use pulseaudio, thats what I mean <roptat>but don't worry too much, I think the alsa service is included in %desktop-services by default <minall>So adding the module will make the apps work, but still have pulseaudio installed? <roptat>with the service, alsa apps will talk to alsa, which will then talk to pa, which has reserved the audio output for itself <roptat>without the service, alsa apps talk to alsa, which can't open the default output, so no sound <minall>I see that adding the module of a service, being for audio, for cups, or somthing else is just to configure the service, but service is already added <minall>Or there are some services that are not added ? <roptat>minall, some services are added because they are part of %base-services or %desktop-services, and that's independent of what modules you include <minall>roptat: What do you mean?, for example, is CUPS, for printing is added? <roptat>some services are added by you, but you need to import the module before you can configure it <minall>How can I see which services are added on desktop packages, and base packages for example? <roptat>I see cups-pk-helper-service-type is part of %desktop-services <minall>Well that makes sense, since the desktop-services provide all services needed for a -normal desktop usage-, which will include print services of course <roptat>minall, I'm looking at the source, but I guess one can also use the repl for that <roptat>then ",use (gnu services)" then ",use (gnu services desktop)" and finally "(map service-type-name (map service-kind %desktop-services))" <minall>And that will show you all the moduels <roptat>you can do the same with %base-services if you use (gnu services base) first <minall>Amazing, I need to reread the manual of course! <roptat>even better is adding ,pp in front of the last command <minall>roptat: What are you reasons to use and like guix? just asking <roptat>I tihnk guix (and nix) is the only system that can provide that <roptat>it's not necessarily the same as stable <roptat>it could crash or have unexpected behaviors, as long as it's easily recoverable <roptat>also, I like the fact that I can hack on my system and have guarantees on what I'm doing <roptat>I know that nothing will ever change the state of my system, because it's frozen in the store, and I'm the only one who can decide to change that state (with a reconfigure) <minall>And you can always test the latter technologies, the libre ones of course <minall>But not losing stability, as archlinux, which can break sometimes <minall>And why do you prefer guix instead of nix? perhaps for the use of guile? <roptat>mostly because I discovered guix before nix :)@ <bandali>guile is worlds better than nix-the-language :) <minall>roptat: And because you care about freedom of course! <minall>Yep, learning a new language that you can't use for anything else is, not preferable <roptat>minall, yes, but to be honest I think I would use nix had I discovered it first ^^ <minall>bandali: But is a little hard sometimes, for example, when I can't read a phone sd card that has information I need, because the driver is propietary, has this happened to any one? <minall>roptat: welp, guix is more close to the freedom than Nix, though nix seems to be a nice system though <bandali>minall, freedom does require a bit of sacrifice, sometimes :) <bandali>it hasn’t happened to me, but i wonder if you could use some off-the-shelf sd-to-usb converter <roptat>minall, and you can sacrifice that freedom, we just won't help you to do it <minall>bandali: yep, very hard though, with some printers too, but welp, I think the better way, is to create a way to read it, but libre, since that will keep your freedom, and help the project too <minall>bandali: well, there are options too, I can just search another pc, but I'll prefer to have all the functionalities available on my system <bandali>speaking of printers reminds me of rms’s origin story :) <bandali>oh haha, i *really* wouldn’t be able to do it justice :p <lispmacs>I'm still confused on one point: how can you tell in advance if a substitute is available? If I do a dry run install, it just says "the following derivations will be built". Does that mean no sub is available? <pkill9>my .guix-channel is now fixed, the problem was i was using procedures within it which i think guix doesn't work with due to how Guix treats it, plus now my repo isn't failing to build \o/ <lispmacs>okay, I figured out how to look the builds up on the Guix website, anyway. <lispmacs>looks like gcc-toolchain-7.4.0 is built but nothing higher yet <civodul>sneek_: later tell pkill9 indeed, .guix-channel is declarative: it's not code *jonsger still debbugs a coredump of guile while building guix with more then 3 threads :P <rekado>lispmacs: some builds cannot be substituted, because it doesn’t make much sense to do so. For example, grafts are easily computed locally so we don’t offer them as downloads. <rekado>lispmacs: other derivations will be built when there’s no available binary. *jonsger made some progress on debugging :) <jonsger>where should I know report the bug? At guix, at guile or both? <lispmacs>rekado: oh, okay, well the central question is basically, how do you know in advance whether installing a package is going to take 2 minutes of download, or 12 hours of compiling. It isn't clear to me from the dry run output, but maybe I need to look at the documentation more closely <lispmacs>there are just a lot of packages or packages versions I won't bother trying to install if it will cost 30,000 billion CPU cycles <dongcarl>Given Guix is used in quite a few academic institutions... Perhaps a good fit? <bavier>might be good to participate in the discussion channel *Digit should read back more <rekado>dongcarl: the GWL is actually roelj’s idea. I’m just co-maintaining it. <Digit>has anyone suggested guix to them? are they already on it? chosing many? <dongcarl>I think bavier is talking about the CERN discussion channel mentioned in the link? <rekado>Digit: civodul and I presented Guix at CERN about a year ago. <rekado>but CERN is big, and I don’t know if any of the people involved in Malt were present then. <dongcarl>rekado: That's excellent. It seems the website requires a privileged login which I don't have, I would go vouch for Guix if I could, perhaps you or civodul can contact the CERN people? <nckx>raghavgururajan: I replied to your ATTENTION REQUIRED mail before reading the discussion here on IRC. <rekado>ATTENTION! The issue has been dealt with on IRC! <nckx>Please send a mail to everyone next time to tell them. <nckx>Anyway, I hope the positive angle shone through. I'm not great at writing e-mail. <nckx>I felt like a real office worker with real job and a real manager for a minute though. So thanks for that experience :o) <rekado>dongcarl: this looks like a bug, but does it still exist in the latest version of Guix? <rekado>I know that we had a little leak with guile-json being taken from the user’s environment, but I forgot the details, so I don’t know if this could be related. <dongcarl>rekado: Still happened on Tue Jul 23 23:56:21 2019 +0200 with 7304d5623ab5cc35289cb1535cbd0d8a37691fac <rekado>it may be interesting to see the contents of /gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv (and its builder) <rekado>it’s mentioned in the derivation. Look for “-builder”. *dongcarl types furiously <rekado>info-dir is a profile hook, so the problem is near the end of building the profile. <rekado>everything else is probably already in place. <dongcarl>rekado: Let me know if I can supply any more info. <rekado>uhm, is this related to a cross-building experiment? <rekado>because I see so many references to this cross and that cross. <rekado>or is this just because your manifest includes all these toolchains? <dongcarl>rekado: Yeah my manifest includes all these toolchains <dongcarl>rekado: Oh sorry, I was mistaken earlier <dongcarl>It doesn't happen for 7304d5623ab5cc35289cb1535cbd0d8a37691fac <dongcarl>it only happens for an older one b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f <jlicht>rekado: some cool stuff on your guile-aws repo! Are you already doing something with it? <rekado>jlicht: it’s still pretty rough, but I’m going to make the GWL set up EC2 instances (when requested) as needed and store data and Guix things in S3 <rekado>dongcarl: b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f is just a month old. <dongcarl>rekado: Right... Yeah I want to figure this out before pushing inferiors out to my colleagues... They're quite excited about reproducibility across time <rekado>dongcarl: does it work with 4fde0030d42068b347d7af58ed3b746c5ea2f877? <rekado>or with commits *before* 1d3acde5087d50af6a4901fd7614f0940eb7b41d (Tue Apr 2 03:02:51 2019 -0700) <dongcarl>rekado: Okay, just to be clear, I'm going to `guix pull --commit=1d3acde5087d50af6a4901fd7614f0940eb7b41d`, and try to build the exact same manifest again... <dongcarl>rekado: I'll experiment and report back. <rekado>dongcarl: I wonder about the channel dependencies <rekado>your channel is declaring a particular version of Guix as its dependency. <rekado>does it even work to use “--commit” then? <dongcarl>rekado: Well perhaps I should describe what I'm trying to accomplish... <dongcarl>I want users to be able to install any version of guix, run `guix environment --manifest=manifest.scm`, and get identical environments <dongcarl>which is why I pinned the Guix version in my manifest <dongcarl>and also why I'm trying out `guix environment --manifest=manifest.scm` with different guix versions as the default profile <dongcarl>I also want to say that... The fact that this is even possible is... <nckx>roptat: Did you submit dkimproxy anywhere? <dongcarl>rekado: Oh! What's interesting is that v1.0.1 works... ***jonsger1 is now known as jonsger
<rekado>dongcarl: perhaps. But it’s concerning that it’s not working in all cases — and that the info-dir derivation results in an unexpected output. <dongcarl>rekado: True. I'll experiment around the commits you gave me, those are the ones that you think introduced the issue and solved the issue? <dongcarl>rekado: 4fde0030d42068b347d7af58ed3b746c5ea2f877 DOESN'T trigger the error. *dongcarl building 23635b2ee95c2deb5041329fc2124636319a6333 now, which is the commit before 1d3acde5087d50af6a4901fd7614f0940eb7b41d <roptat>nckx, did I make a mistake? I didn't think it would cause trouble to push these patches? <roptat>nckx, I actually wrote these yesterday, as well as a service (but I didn't take the time to actually make a patch for the service) and I'm using it now on my server <nckx>Yeah, I've been using it for a few months too. <nckx>Well, it would have been nice. I'll push my IPv6 patches after adapting them. Why does perl-net-dns-resolver-mock propagate perl-net-dns? ***jonsger1 is now known as jonsger
<nckx>Actually, why is it in networking.scm and not dns.scm 😛 <roptat>nckx, because perl-net-dns is in networking <roptat>I'll send a patch to the mailing list properly for the service then, sorry for the trouble :/ <nckx>roptat: No, actually I thought I'd submitted *my* dkimproxy and thought someone had pushed it. <nckx>roptat: Is re-licencing it as GPL3+ a conscious choice? <roptat>all I could find was "gpl" with a link to the latest version of the gpl <nckx>I mean dkimproxy itself. <nckx>Which says ’DKIMproxy is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the <nckx>Free Software Foundation; either version 2 of the License, or (at your option) any later version.’ in all files. <nckx>I think it's legal to redistribute it as GPL3+, just a bit... hm. <roptat>mh... I might have not looked hard enough ^^' <nckx>That's fine. I just wanted to know, didn't want to silently change it to 2+ if you'd made the decision on purpose. <dongcarl>rekado: 23635b2ee95c2deb5041329fc2124636319a6333, the commit before 1d3acde5087d50af6a4901fd7614f0940eb7b41d, also DOESN'T trigger the error <nckx>roptat: Do you think unpropagating perl-net-dns from perl-net-dns-resolver-mock could cause problems? It's a test dependency. My version doesn't, seems fine, but I'm no Perl guru. <rekado>dongcarl: that’s good. Perhaps we can bisect this and find the commit where this regression is introduced. <rekado>perhaps add this information to the bug report <roptat>nckx, the importer did add it to the propagated inputs, I didn't check more than it looked legitimate <roptat>if it's not needed, let's not propagate it <nckx>roptat: Excellent. Thanks. <nckx>Actually I will double-check. <nckx>roptat: Like you still care, but it seems to work fine, possibly because dkimproxy imports perl-net-dns on its own (but doesn't propagate it, yaay). So immakill it in my holy war against propagation. <nckx>I'm really looking forward to your service, by the way, it can't suck more than mine so then I can switch. <roptat>well, it's really nothing: it loads a config file as a file-like object <roptat>nothing more fancy that opensmtpd itself :p <roptat>but I'd like to study it a bit more so I can have a proper scheme wrapper around that config <nckx>I like to think that I have a pretty good grasp of it (it's quite simple after all), just a bit stale. I'd definitely love to help. It might be the first service where I actually use the Scheme wrapper since it's so simple. <roptat>we'll see, I'll send a patch soon :) <nckx>My ‘service’ just does ’dkimproxy.in --user=nobody --group=nogroup --daemonize --conf_file=$HOME/dkimproxy_in.conf’. <nckx>(I've been told that using nobody here instead of a dedicated privsep user+group is poor practice.) ***jonsger1 is now known as jonsger
<Marlin1113>i'm getting this error when i try to use guix download <Marlin1113>and that issue i had with git and https is fixed, so i don't think it has anything to do with that