<maximed>jpoiret: Some upstream support would be nice, but expirementing within guix is a bit more practical, I think <maximed>I'd recommend trying out things in guix first, and later see if it can be done more generally in guile itself <jpoiret>yes, i'll be reading a bit more on all of the inner workings of guile in the meantime <awb99>how can I install a screen lock (after say 15 minutes idle time) in xfce ? <raiguy>i need help with my performance. i had no issues with nouveau on manjaro, but on gnu guix, it's abysmal <awb99>raiguy - you mean your nvidia graphics cards are slower on guix than on manjaro? are you also using free driver fro nvidia on manjaro? perhaps manjaro uses a nvidia binary blob as graphics card driver? <roptat>there's one package per target (which might be a little too much, but it works :)) <awb99>I get this error when I try to print via cups. The snippet is from 7var/log/cups/error_log <jeremyc>Brand new to guix, just got it booting. When installing packages, I'm downloading at 500-800kib/s. I have a 1G connection, routinely see 50-80MiB/s. Is there a way I can change my mirror? <robin>he started asking questions like "can i use guix with debian" and "are packages usually reasonably up-to-date" so i think he'll at least install guix and try it out :) <robin>roptat, that android sdk work is super-cool :) i've long thought that android development support might be useful for, e.g., f-droid, and of course free software android hackers in general <robin>(at one point i almost decided to attempt packaging it myself, but it's a lot of work!) <roptat>I've got almost nothing still... <roptat>what would be useful for f-droid would be to package the java libraries, and that requires gradle, which in turns requires kotlin <robin>ohhh yeah, i had forgotten *that* mess <roptat>I have a few old versions I managed to build, but I'm still missing a lot before I can get a recent kotlin <roptat>right now I'm a bit stuck trying to build rhino, a js engine written in java <roptat>(well to be honest it's been a few weeks since I last worked on that, I think I'll continue this week-end) <robin>will we need something like the mrustc->dozens of old rust versions->up-to-date rust package tower to deal with the gradle/kotlin problem, do you think? (presumably there wasn't *always* a circular dependency...) <roptat>it's faster to build though, each version takes ~2 mins <robin>certainly better than rust :) <roptat>yeah, but with that number of versions, it might really take longer to build than rust: starting from 2013, with 2 versions per month so far... <roptat>plus multiple versions of the intellij-sdk <brettgilio>do we have an official bittorrent file / magnet for the ISOs? ***jess is now known as catoshi_nyakamot
***catoshi_nyakamot is now known as CatoshiNyakamoto
<brendyn>It's interesting that Nix has the notion of build inputs and propagated build inputs <brendyn>i noticed a case where a package kept a reference to qtsvg in the /etc/ld.so.cache file, but then failed to make use of it anyway. does this ld cache thingy result in closures getting inflated with references that would otherwise be deleted? ***CatoshiNyakamoto is now known as jess
<KarlJoad->Does Guix have a way to force the /gnu/store to be a read-only bind mount, like NixOS does with `nix.readOnlyStore`? ***iskarian is now known as Guest6896
<bdju>I noticed in Andrew's Guix home patch from about an hour ago that there's a typo in the comment, "dissapears" should be "disappears". I wasn't sure if it was worth replying just to say that <bdju>but in case someone else wants to get involved I thought I'd mention it here <maximed>KarlJoad: guix does that by default I think <KarlJoad->maximed: So an unprivileged user (such as myself) could not do anything to the store without going through the guix daemon? <maximed>KarlJoad: Yes, and privileged users cannot do anything to the store either -- at least by accident <maximed>I suppose root won't have much trouble remounting the store read-write <maximed>E.g., echo a | sudo tee /gnu/store/something will normally fail <brendyn>multimedia programs in guix seems to be randomly wrapped with gst-plugins base, or good etc, or not. seems inconsistent. <civodul>a colleague was hoping for an AArch64 ISO that could work on Apple laptops <civodul>do AArch64 boxes have a +/- standardized boot process these days, with OpenFirmware? <efraim>civodul: It looks like the powerpc cmake-bootstrap issue was due to the debian kernel version, 5.14 is pretty broken on powerpc. it's building just fine with the older 5.10 version. <efraim>there are some that are "server ready" and use UEFI to boot, but the best we could hope for would be something debian-like, with a uefi image and a bootloader image and cat the two together <civodul>efraim: re powerpc, "good" i guess (i didn't know cmake was broken there!) <civodul>efraim: right, the OverDrive was plesant since it's just UEFI <civodul>if UEFI is widespread enough on AArch64 hardware (laptops?), we could provide a UEFI image <ss2>Is it important for match-lambda that I keep the references in the same order the way they where defined in the first place? <ss2>I've defined a record-type, and say I've define a <service-configuration> with the options “one” “two” and “three”, and but two may be commented out. <ss2>Then further down with match-lambda things could be mixed up? I noticed that somehow, where the value of a different variable was placed into the file instead. <lilyp>ss2 records are ordered by abi <lilyp>so you can effectively access the first N fields with your match <lilyp>if you want to skip over some, use _ ***herlocksholmes4 is now known as herlocksholmes
***brettgilio7 is now known as brettgilio
<awb99_>I have improved my qemu images by making sure I have kvm enabled Now I also have the issue that my docker images are very slow when they use xwindows. <awb99_>could it be that I have to enable kvm for the docker daemon as well ? <awb99_>to use swap files: do I have to use "swapon" on a guix system to enable a swap-file? Or can this be done somehow via os definition? <brendyn>i cant believe gzip just refuses to decompress a file if it doesnt have the righ suffix. wtf <apteryx>civodul: i'm fine! slowly working out problems I had introduced on the staging branch, related to gdk-pixbuf propagation. I should have a patch series soonish, and after it's reviewed and merged, we'll be able to merge staging into core-updates{,-frozen} <lilyp>brendyn: is that really gzip? <awb99_>thanks civodul! I read the manual multiple times before posting my question, and have not found this section at all. thanks!! <lilyp>brendyn: though apparently you can use -S to remedy, so maybe that's fine? <OJ[m]>Looking for help to a problem. I seem to be building absolutely everything despite having substitutes. <civodul>apteryx: oh neat! i thought (hoped? :-)) 'staging' was for later <civodul>does anyone happen to have the source of texlive-marginnote, as per "guix build -S texlive-marginnote"? <apteryx>civodul: I think we're going pretty much "all-in" on that next release :-). With the usual benefits and drawbacks. <apteryx>question; in deprecated-package, OLD-NAME is the *name* field of the deprecated packaged (rather than it's symbol name), correct? <lilyp>IIUC it's (name replacement) with name being the name field and replacement being a variable <apteryx>the example I'm puzzled with is this one: I've removed the inkscape-1.1 variable (now known as just, inkscape), both had the same name; what would the correct way to mark it as deprecated? <lilyp>and by "variable" i mean any expression could fit there but it's typically a variable <lilyp>Do you need to provide a deprecated inkscape 1.1? <lilyp>variable names don't matter in the context of deprecated-package, that's for UI <lilyp>also, the easier thing would be to have inkscape-1.1 exist and then (define inkscape inkscape-1.1) <civodul>apteryx: re "all in", that's why i was kind of hoping "staging" would come later <civodul>apteryx: re deprecated-package, yes, the first argument is the package name (string) <civodul>it wouldn't be useful to give the variable name <civodul>in tex.scm on core-updates-frozen, there's a sophisticated variant that takes care of both the variable and the package name <apteryx>lilyp: you're right, it's probably unnecessary, given it's allowed to move packages from one module to another without worrying about deprecating the previous location <apteryx>civodul: by "all-in" on the next release, I meant that we've been open to integrate important changes in the frozen branch <civodul>we've managed to be quite conservative in the frozen branch <civodul>or maybe that's because i have a hard time being conservative myself? :-) <apteryx>I'm referring to my own changes w.r.t. the rust bootstrap for example or the planned merge of the GNOME 40 branch. <lilyp>We did tack a few extra things onto the free world rebuilds, yes <lilyp>Let's hope there's not too many unstable things that require world rebuilds remaining <lilyp>the next one is supposedly the last <Inline>i just discovered that something supposed to build in the gnu store chroot env didn't do anything <zap1>Hey, what if my channel contains a guile extension? When building it cuirass is going to load all files in search of packages and fail because there is no dybamic libs isnt it? How would you avoid that? <zap1>(considering that dinamic loading happens in file that is not related to files with package definitions) <lilyp>Inline: didn't do anything as in did not produce any output? <Inline>oh wait a bit, i think build stuff happens in my /tmp <lilyp>I don't think you're supposed to see the build, it happens in a container <raiguy> i'm starting to think linux-libre doesn't like my gtx 970 gpu <Inline>lilyp: i at least see the temporary build directories etc. appear in /tmp <PurpleSym[m]>Do we have any process for merging larger wip-* branches like wip-haskell? I’m pretty confident it won’t break much, but maybe now is a “bad time” to merge it or … <PurpleSym[m]>I’d just like to be done with it, so I can stop rebasing it on top of master and move on to other things. <apteryx>how much package builds to it trigger? <apteryx>Seems Xinglu has done a good review of it. <apteryx>Seems to me it should be good to merge to master then <apteryx>don't forget to delete the branch and remove it from ci afteward <PurpleSym[m]>Alright, thanks apteryx, I’ll merge it in a few days. But I don’t have access to CI unfortunately. Not sure who has. <podiki[m]>after that is merged I'll try again on the taffybar package, which requires a bajillion haskell-gi (gobject introspection) packages <podiki[m]>I almost had it working before running into haskell dependency hell, but with a newer ghc and stackage I hope it will work ***bread is now known as bread33
<apteryx>PurpleSym[m]: feel free to ping me after the merge, I have access to it ***thung[m] is now known as boosh[m]
<bread33>Is there a way to put a guix with some channels into a manifest? I can do "guix pull -p profile --channels.." after I apply the manifest but it would be better to do everything declaratively <bread33>that actually doesn't do what I want either since it removes all the packages but guix, i thought it would add a guix <roptat>bread33, what guix pull builds is different from just the guix package <roptat>do you mean you want to build the profile with a given guix and some channels, or do you really want to install guix in the profile? <roptat>if you really want to install guix with channels, I think the easiest would be to install guix, and create a package for the channels, separately <bread33>The reason i wanted to do that is because I have a profile that uses different channels then my system (using an inferior), and i wanted to be able to use guix show/edit etc. on packages in those channels <roptat>bread33, I think in that case you can use the time-machine <roptat>you'd declare your channels in a channels.scm, and use it like "guix time-machine -c channels.scm -- show ..." <roptat>the time-machine not only can travel through time, it also travels through dimensions where you have different channels :) <bread33>very powerful time machine! that's definitely an easier way to do it <ruffni>is there file-based logging for `guix pull` and `guix build` and the like? <roptat>ruffni, if something fails, guix should print the location of a log file <ruffni>yeahyeah, i know and it does :) i was just wondering if the output itself is printed to some file.. <vivien>So, today my emacs tramp seems to require a 'ls' command available on the server (I don’t 100% understand what’s happening), so I made one available with extra-special-file and it stopped complaining. <vivien>Or at least I should say, it fails for another reason... <roptat>ruffni, ? I don't understand the question <ruffni>roptat: i thought -- at least in what i'm doing right now -- it would come in handy to have all those guix outputs automatically written to some system-wide logging facility. <roptat>I think you'll find them in /var/log/guix/drvs/ <ruffni>on another note, i get "waiting for locks or build slots..." but there is (or at least should) nothing building on that machine right now. should i reboot? <lilyp>try guix processes first to make sure really nothing is building <lilyp>vivien: emacs uses remote ls to list files <lilyp>we can't really patch in Guix tools in those locations <ruffni>killed the daemon, restarted it, started to build the package and again... <vivien>I think I narrowed down the problem to reading a scheme file over tramp <vivien>I’ll restart emacs as soon as my background job is finished :) <zap1>Has anyone had experience with cuirass web to respond very slowly? For example logs in evaluation for 40 packages it says only 7 are succeded whereas logs say that most derivations are already built. <zap1>* For example *in web interface* <apteryx>how to debug cycles between a bin output and a out output? <roptat>I suppose the bin need some libraries installed in out, and maybe some scripts in out need the bin? <roptat>I think with -K you can explore the results in both outputs <roptat>and then grep the files to see which ones need the other output <apteryx>OK; yeah I was running strings some-binary | grep gnu/store in the build output, was wondering if there's a better way <apteryx>the cycle detector could print more useful info :-) <apteryx>it just says: cycle detected in the references of `/gnu/store/0g632xdy6hyl9gy4c0424cfk46kk3sac-glib-2.70.0-bin' <podiki[m]>question on patches: a flatpak related package broke on core-updates-frozen, and I have several flatpak related patches to submit...should they target core-updates-frozen (will fix the build failing too)? <lilyp>if it fixes stuff on core-updates-frozen, then where else should it go? :P <lilyp>don't forget to tag your patch appropriately by using --subject-prefix <podiki[m]>well I mean most of it is updates that would just be on master <podiki[m]>side effect is it will fix the core-updates-frozen failure <podiki[m]>I wanted to submit them all together since they are related packages (flatpak and portals) <lilyp>hum, if they target master then the core-updates-frozen thing would be fixed once master gets merged into it (happens weekly IIRC) <podiki[m]>I'm not sure what broke on core-updates-frozen, looks like some dependency change that's non-obvious <podiki[m]>hmm..maybe I'll just base of master with a note about core-updates-frozen fix? <apteryx>roptat: indeed, many test binaries need the libraries in out <podiki[m]>another question: if a package has as an input something that provides dbus rules it will need when running, should that be a propagated-input? <roptat>apteryx, maybe install the libraries in a lib output? <apteryx>I guess the test binaries shouldn't be installed in the first place <roptat>yeah, or don't install the test binaries :) <apteryx>roptat: wouldn't that cause another issue (test binaries refering to "lib" instead of "out")? <podiki[m]>and if there is a search-path-specification, that will then be "live" if it is in a propagated input? (so the package that depends on that doesn't need to also specify it right?) <roptat>you can have them refer to other outputs <lilyp>propagated search paths work as you stated <lilyp>as to whether or not to propagate inputs with dbus rules: I think there's a discussion to be had whether simply symlinking the rules might be more appropriate <lilyp>for now propagate it with a comment <podiki[m]>so we have any build procedures that do something like that easily? or just some make symlink refering to an input path? <podiki[m]>lilyp: okay, will do. it should fix a bug and confusion in how to use a package I ran into. dbus I find confusing in general :) <lilyp>podiki[m]: we don't, I'll maybe start making one for pkg-config in the next core-updates cycle if no one else does <podiki[m]>sounds good. seems like there's a bit of boilerplate for doing things with input paths that could be cleaner <podiki[m]>at least when I've had to do some wrapping type stuff it seems that way <apteryx>roptat: I think the problem lies with the pkg-config files; they are installed to "out", but refer to some commands found in "bin" <apteryx>and the bin tools must use the "out" libs, of course <roptat>I suppose the easiest would be to remove the tools <roptat>otherwise, you could install the pkg-config files in a dev output <apteryx>ah, it was currently worked around by simply patching out bindir in the pc files; seems suboptimal <apteryx>ah, actually it's not too bad, it means the tools were looked up from PATH <apteryx>the reason it stopped working is because the text changed and the substitution didn't happen anymore <mekeor[m]>hey. i'm using emacs-no-x-toolkit and xmonad on guix system. all windows have a window border except emacs(client). any idea whats wrong? <mekeor[m]>how does a x-toolkit relate to window borders? i was thinking window borders are simply drawn around every window by the window manager? <mekeor[m]>does anyone have a package definition for emacs-lucid? ***do is now known as w1gz
<lilyp>mekeor[m]: emacs-no-x-toolkit is probably launched inside your terminal emulator if any <lilyp>perhaps xmonad special-cases such terminal commands? <mekeor[m]>i dont think that emacs-no-x-toolkit is started inside a terminal emulator. i dont think that this is xmonads mistake. its prolly an emacs bug <podiki[m]>I use emacs and xmonad, but without window borders on anything (purposefully) <podiki[m]>I'm guessing emacs-no-x then doesn't have something that xmonad recognizes for drawing borders <podiki[m]>(how does emacs-no-x work exactly if not run in a terminal? must talk directly to X or something? but "no-x"...) <lilyp>plot twist: it talks directly to wayland <podiki[m]>oh, it refers to what toolkit emacs uses for things like scrollbars, so rather than eg. GTK, it just uses native X <podiki[m]>not sure what that means for xmonad, but i'm guessing that's a clue <apteryx>I have slim using 100% of a core on a remote machine, and killing it has it respawned. Any idea what I could try? <apteryx>killing xorg-server would be a way I guess <mekeor[m]>podiki: emacs-no-x does not equal emacs-no-x-toolkit. the latter probably directly talks X <apteryx>yeah, I tried 'herd stop xorg-server', but the slim process went on <dissoc>i get the error: imported module (guix build utils) overrides core binding `delete'. what is best way to resolve this? using a prefix? <apteryx>it's not an error but a warning, I think <apteryx>it's done in a couple places already <dissoc>gotcha. i wasnt sure if it was going to be a problem <apteryx>mekeor[m]: eh, herd stop xorg-server worked this time around, thanks!