<arbi>Hey there! I'm having trouble with my GuixSD install on my Dell XPS 13 (9343). My wireless device isn't being recognized. According to the Arch Wiki it uses the BCM4352 chip, which should be supported by the b43-open Linux-libre driver. Does the system install provide this driver by default? <arbi>It seems like it should be there out of the box as part of %base-firmware <arbi>nevermind... it looks like my Network Controller is "Intel Corporation Wireless 8260 (rev 3a)" <lfam>arbi: Unfortunately neither of those (BCM4352 or the Intel one) are likely to be supported with free drivers in Guix <arbi>so my only option is to install something like NixOS as a base, then use guix package manager? <lfam>I don't have direct experience with the Broadcom one but it appears to do 802.11ac and I don't think there are any freely-supported 802.11ac cards <lfam>I might be wrong though (hopefully!) <arbi>gotcha. thanks for your help <lfam>Basically, GNU Guix won't support the nonfree hardware. There are many options for dealing with this <emsyr>arbi: you can buy an external usb wifi atheros AR9271. <daviid>str1ngs: could you use the gnome gio low-level and high-levelD-Bus support instead, because then you'd use GI for automatic bindings <str1ngs>daviid I will take note of this thank you. It's going to take sometime till I can look at this <janneke>arbi: i installed an atheros wifi in my dell <daviid>str1ngs: if you can use gnome gio, then you can use guile-gi (right now) or G-Golf (in the future) to have full automatic bindings for guile, which will save you a huge amount of time (and no ones wants to write a manual binding for D-Bus, imo) <arbi>emsyr, janneke: thank you for the tips! I'm going to try making two packages, one for the kernel, one for the firmware off the guidence of lfam. and now I have a backup plan ;) <daviid>str1ngs: note that guile-gi also provides a few examples precisely for webkit GTK and janneke just packaged (and used it iiuc) for guix <emsyr>arbi: using open hardware keeps you in the core of linux-libre <str1ngs>daviid: ok this helps. I need to get my GTK branch up to speed. then I'll start looking at this more. it's really going to be needed in order to access GTK DOM. without it, it won't be able have interactive guile web interfaces <str1ngs>thought that was kinda secondary. I've mainly been focused on simple scheme and C api for basic web browsing <arbi>emsyr: understood. an important next step for me regardless it seems *vagrantc has been working on packaging guix for debian, and fixing installing debian chroots on guix ... *janneke cheers for vagrantc <vagrantc>janneke: oh yeah, i should take a stab at mes on debian again <vagrantc>janneke: i eventually realized i had reimplmented some of the packaging changes you had done a couple months earlier <janneke>vagrantc: iirc you found a problem with the latest nyacc; i'm still at nyacc 0.86 <janneke>vagrantc: no, there's a real small "nyacc-binary-literals.patch" in guix *janneke really should get up to speed with latest nyaccs <vagrantc>maybe i should try with that patch applied and see if it works any better <vagrantc>janneke: that appears to be a two-line patch ... have you tried to push it upstream? <janneke>that would be nice -- you also reported bashisms, right? <janneke>vagrantc: i'm pretty sure it's upstream in later releases <vagrantc>janneke: ah, then getting sync'ed with upstream might help me out :) <janneke>but upgrading can sometimes be a lot of (debugging) work <janneke>nyacc has been great at finding cases where mes != guile :) <vagrantc>janneke: maybe i should just get the ball rolling on uploading mescc-tools and nyacc and just use upstream's versions at this point <vagrantc>since it'll inevitibly involve waiting anyways, may as well start the wait now <vagrantc>that reminds me that if the guile-ssh dependency for guix is technically optional, maybe i should initially upload guix to debian without support for it <janneke>waiting early, i like that -- of course i cannot promise or predict when mes will run with latest nyacc <daviid>str1ngs: it would greatly surprise me if you could not 'access GTK DOM' using a GI gnome lib, either webkit itself or gio or ... (not my domain), then guile-gi is your immediate friend (g-golf is making great progress, but still not usable, though what is there works ...) <str1ngs>daviid: actually maybe I can do more with DBUS. that might be more written in scheme. and it avoids threading issues <str1ngs>more things written in scheme, I meant <Marlin1113>installing the whole texlive just for the pdflatex package? <kmicu>arbi: b43-open supports only some BCM43* chips (I have one im my old laptop and WiFi on Guix System works out-of-the-box on it). <Marlin1113>i might try setting up a store for refurbished libre hardware here in brazil someday <Marlin1113>the lack of good compatible hardware here makes me sad <daviid>str1ngs: I highly recommend you try to use gnome gio low and high level d-bus api, using guile-gi, then your code will be 100% schenme code <faif87>Hello everyone. I installed GuixSD 1.0.1 via graphic installer, and everything seems okay, but for some reason bash's clear command doesn't work for me. I get the message, "bash: clear: command not found". Anyone know how I can fix this? <Marlin1113>either by guix install ncurses, or by editing your .scm file <bluekeys_>Well guix, I did not know I also had that problem. <faif87> I use GNOME right now, and would like to use MATE too, so I installed the 'mate' package. I've read that I'm supposed to add MATE to my .scm file, but I'm not sure which one. All I know is the graphic installer used /etc/config.scm. Is that my system file? <lfam>You can also press CTRL+L to clear the terminal <lfam>faif87: Yes, if that file exists you should use it <lfam>faif87: You can use any filename but that is the convention <faif87>lfam: Ah, that explains why 'find -name "config.scm"' at the root level returns a lot of results. :) <faif87>Anyone able to use MATE? I installed the 'mate' package and added "(service mate-desktop-service-type)" below my line for GNOME which I'm using now, but I don't see anything when I press F1 at the login screen. <bluekeys_>fai87: The only mate config I can see is the service you mentioned already. <bluekeys_>faif87: * previous 2 comments were meant for you <faif87>bluekeys_: Huh, interesting. I'm pretty sure I added it to the right .scm file. Guess I've got a bit more reading and searching to do. :o <lfam>faif87: Did you reconfigure your system? <faif87>lfam: Huh, I didn't even think to do that. I was under the impression that just modifying the .scm file and rebooting would do the trick. <lfam>faif87: To actually make it take effect, you use `guix system reconfigure /etc/config.scm`, which builds the new system (as with `guix system build /etc/config.scm`) and then puts it into effect <lfam>`guix system build` can be done unprivileged, but reconfiguring requires root privileges <faif87>lfam: Ah, I see. I didn't read further enough, heh. Thanks! I'll give that shot. ***apteryx_ is now known as apteryx
***MinceR_ is now known as MinceR
<rekado_>Marlin[m]: you can install texlive-bin along with all the other texlive-* packages you need. <civodul>the wording is suboptimal in some ways, but hey ***jetomit_ is now known as jetomit
<efraim>civodul: in doc/guix.texi, for the --compression commit, '.. gets compressed using all the selected methods.' I think '... gets compressed using each of the selected methods.' would be better <pkill9>what could be causing this error?: guix/build/download.scm:741:0: In procedure url-fetch: <pkill9>Invalid keyword: #vu8(132 154 110 6 131 25 46 197 4 218 154 99 29 223 200 46 4 151 53 131 244 160 40 253 57 184 205 172 46 254 41 234) <pkill9>I'm trying to build a package made from `guix import hackage --recursive` <pkill9>oh, it's probably something to do with this: In guix/build/download.scm: <pkill9> 741:0 0 (url-fetch _ _ #:timeout _ #:verify-certificate? _ # _ # …) <efraim>either in cache or in the checkout <pkill9>all the old guix's do the same thing, and i deleted ~/.cache/guile <jonsger>which parts of gash are under CC0 janneke? <rekado_>bavier: their suggestion is to build gfortran 7 and up with “-fno-optimize-sibling-calls” <rekado_>we aren’t using version 7 by default yet, so it doesn’t affect us now. <rekado_>oh, I misunderstood: Fortran code should be compiled with “-fno-optimize-sibling-calls”, not gfortran itself. <rekado_>civodul: congrats on getting the press release out! <rekado_>pkill9: do you get this for *any* URL or just for one? <janneke>jonsger: good question, samplet added that license just recently <janneke>jonsger: i think it's some readme files like NEWS and such <pkill9>just run `guix build -f <that-file>` to test <rekado_>pkill9: unrelated: note that you’ve got a stray #F in your file; looks like the importer couldn’t generate one of the package definitions for you. <rekado_>pkill9: have you been able to reduce the problem to a single package? <rekado_>would be good to see where exactly it fails <pkill9>i had a quick look at each url to see if it wasn't imported right, but they all look like they were written right, i gues next step is to check if guix downloads them all correctly <rekado_>that’s one way of doing it. Another is to comment half of the file and see if the problem disappears. <rekado_>if it does, reveal half of the commented expressions, etc *kmicu sees that Ruben released the 60.7.0 ESR version of GNU IceCat but Mark pushed it 2 weeks ago to Guix already. 😺 <kmicu>(Though Guix’s IceCat update is a sole security bump and GnuZilla’s IceCat has additional goodies like Hardened privacy settings and more.) <rekado_>Mark is ahead of the curve for IceCat security fixes. <rekado_>he often backports fixes all by himself before they make it into IceCat. *jonsger successfulled gash for openSUSE and tests it now :) <civodul>roptat: oh, i hadn't noticed "freeware", this is terrible :-/ <janneke>"cannot exec /usr/bin/gcc" -- after /me finally gets ./configure to exit 0 ***mouldysammich is now known as sammich
<civodul>this password issue that Florian reported is really weird <roptat>what's the right source field for a local checkout I want to build with guix? <roptat>I tried (source (local-file ".")) but I get "regular file expected" <brendyyn>roptat: local-file can take #:recursive? #t <brendyyn>and a #:select thing i dont quite understand <brendyyn>i think that removes all .git and .gitignore stuff <brendyyn>thats just from an example. in this case it was (define %source-dir (dirname (current-filename))) <civodul>roptat: they've now fixed "freeware"... <rekado_>civodul: I’m amazed that this was fixed so quickly! I’d love to know the correct arrangement of words that doesn’t result in merely a shrug. <janas>I've just installed the MPD service, however when mpd is playing it blocks all other audio on my system. From what I've read it sounds like mpd might be using ALSA instead of pulseaudio, is there any way to change this in the service definition? <rekado_>janas: the MPD service configuration unfortunately does not permit this. <rekado_>janas: I had plans to extend the service so that this can be configured, but I haven’t found the time to do this. <rekado_>janas: if you’re reasonably familiar with MPD maybe you can give it a try? <rekado_>I’d gladly help you find the correct Scheme expressions to improve this. <janas>rekado_: Right now I'm installing the pulseaudio ALSA plugin to see if that will fix the issue <janas>rekado_: If not I wouldn't mind trying to fix the issue as best I can :) <civodul>rekado_, janas: i think if you use (service alsa-service-type), then ALSA will redirect its output to PulseAudio (info "(guix) Sound Services") <civodul>rekado_: i'd like to run 'guix publish' with lzip+gzip on, say, qualif.ci.guix.gnu.org, but i'm not sure what it takes to do that, WDYT? <janas>rekado_: It's strange that mpd is using ALSA even though you've added the "type: pulse" line to the config file <rekado_>janas: that’s because it’s hardcoded in the mpd service <rekado_>this is one of the many things I wanted to change in the mpd service. <rekado_>civodul: we’d need to add an nginx server block to the berlin configuration file for qualif.ci.guix.gnu.org and have it redirect to wherever the new “guix publish” service listens. <janas>rekado_: I'm not sure I understand, where is it hardcoded to use ALSA? In mpd source code? <rekado_>civodul: I don’t know how to set up a new sub-domain name with knot, though. <rekado_>janas: no, it’s in the Guix code that defines the mpd configuration file that’s installed when mpd-service-type is used. <rekado_>currently, this configuration file is not at all flexible. <civodul>rekado_: on the nginx side, maybe we can turn %berlin-locations into a procedure with %publish-url as a parameter? <civodul>and then we'd use that for both ci.guix.gnu.org and qualif.ci.guix.gnu.org, right? <janas>rekado_: Oh so you want to add more configuration options to the record type? <rekado_>civodul: yes, that could work, though I guess not all of the locations are needed for qualif.ci.guix.gnu.org. (The Cuirass locations, for example, wouldn’t be needed.) <rekado_>janas: yes, and to use them in the generated configuration file. <rekado_>janas: currently, you can only get one mpd output and it’s always going to be the alsa type. <rekado_>janas: that’s inconvenient if you want to offer an HTTP stream, for example, or if your output requires other configuration. <rekado_>(for audio over bluetooth, for example) <civodul>rekado_: ok, i'll try something along these lines <janas>rekado_: Ok that makes sense, what I'm still confused about is why the "type: pulse" line in the hardcoded config file doesn't force it to use pulseaudio. <janas>Does that make sense? I thought that 'type: alsa' forced alsa, and 'type: pulse' forced pulseaudio <janas>No worries, I just wasn't sure if I was misunderstanding something! <rekado_>I’ve been meaning to check the “perfect setup” document on freedesktop.org, which is a guide for Pulseaudio setup for distros. <rekado_>I’m not convinced that we’re doing 100% the right thing <janas>hmm the archLinux wiki suggests that we might also need to add 'name: pulse audio', I might try it later today! <janas>I mean I'd like to do it now, but I've been procrastinating on studying all day <civodul>Ozymandias42: if you do (package-derivation store package), you get a <derivation> record <civodul>you can call derivation-file-name on that record <Ozymandias42>if it works it does. I tried with the guile repl and the stuff from the store-monad page. nothing worked <civodul>the example i gave is non-monadic, so it's easier to read <civodul>but the same can be done with the monadic style <Ozymandias42>I don't really care about monads. they are useful in practice but terrible in documentation imo. <civodul>monads in general or monads in Guix? :-) <civodul>that said, you rarely need to worry about derivation file names and all that <Ozymandias42>both but guix especially. the docs are terribly lacking. according to a friend that shouldn't be too bad though as the guile repl should provide live docs for everything. <Ozymandias42>unfortunately there's no introduction to be found on how to work with that either <Ozymandias42>btw. I tried your command in the repl with ,use (guix monads) important and ,enter-store-monad didn't work <jackhill>I'm setting up Guix on a foreign distro, and I'm seeing "substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)". I have glibc-locales installed in both my user and root's profile and GUIX_LOCPATH is set. What step did I miss? <arshin>jackhill: generating en_US.utf8 locale? *jackhill is spolied by mostly being able to use Guix System and not having to worry about the additional pieced needed on a forign distro :) <arshin>jackhill: depends on distro. On Arch edit /etc/locale.conf and run # locale-gen <sirgazil>Besides the jami memory leak, it seems there is another bug. I removed jami, restarted the computer and the ".gnome-ring-rea" process is still around, and that's the one that leaks. <Gamayun>jackhill: I think I might have had that... If I recall it was _maybe_ GUILE_LOAD_PATH that needed set. <Ozymandias42>(package-derivation store bash) complains about wrong argument types. <jackhill>Gamayun: do you recall what value you needed. Poking around root's profile, I don't see any obvious Guile code. Perhaps in root's guix-pull profile. <Ozymandias42>tested pretty much all variation now. (package-derivation store package) does not work. it complains about wrong type and expects some kind of struct but I don't see that in the source. is there a way to have guile print me a list of all functions and their signatures for arbitrary modules? <Gamayun>jackhill: probably ~/.guix-profile/share/guile/site/2.2 or such... <jackhill>hmm, my guix-profile has not share/guile (probably because there are not guile packages in the profile?) <nly>how long does it take for substitutes of qt to be built(on the guix.gnu.org builder)? *janneke gets "waiting for locks or build slots..." again after a hup'ed build -- i forgot how to solve that <dongcarl>Hey all, I'm going to be presenting on bootstrappable Guix builds at a bitcoin security conference. I'm brainstorming an outline right now and if anyone has ideas for things to mention, I'd really appreciate any input. <dongcarl>Current status on my bitcoin builds: works for x86_64, i686, armhf, aarch64, and riscv64. Still need: osx cross-compile, windows cross-compile. <dongcarl>:-) I've been upstreaming riscv64 support as I go along... and will contribute the packages I write for osx/windows that are free software <janneke>dongcarl: cool! i assume that you've seen my fosdem slides on mes as well as rain1's bootstrapping wiki? <dongcarl>janneke: Yeah I'm going thru your slides right now actually haha <janneke>for the archives: kill all guix-daemon processes (herd stop guix-daemon is not enough) <rekado_>janneke: oh, you’ve secured funding for mes? Congratulations! <dongcarl>janneke: Congrats. Admiring your work from afar and very glad it got funding! <janneke>thanks, i was waiting for an "official", announce-able start, guess that happened <janneke>i haven't really started, i'm kind of waiting for milestones being defined, but still awesome :) <dongcarl>janneke: In your slides, how did you get the list of bootstrap binaries for Guix? <janneke>dongcarl: you can do something like: guix build --system=i686-linux bootstrap-tarballs <janneke>ah, that command was only in my fosdem17 slides, hmm <dongcarl>janneke: I'm listening to your talk right now and struggling with the bad audio quality... Fosdem messed up there... <dongcarl>One question that I get a lot from people when I talk about this stuff is: why not use the body of work already done in debian <janneke>dongcarl: to be fair, it was i that messed-up; i didn't check the mike was on so you're hearing the backup track <dongcarl>I feel like the answer is that they don't have bootstrappability, but I'd like to get an understanding of how their system works, if anyone knows <janneke>dongcarl: let's try to involve vagrantc in that question or possibly ask on #debian-bootstrap@oftc <janneke>i would also give that answer...i'm sure there's a lot of ignorance here with the questioner and also with us :-) <bavier>iirc, debian's bootstrapping efforts assume a set of trusted debian binaries as a base. i.e. not a source-based bootstrap <janneke>i have been postponing really introducing myself there <janneke>yes and they talk about "bootstraping a new architecture" things <dongcarl>janneke: I'm looking thru your slides, and I guess I still don't 100% understand how Maxwell's Equation of Software ties into this... <dongcarl>My naive guess is that it allows the scheme interpreter written in C to be simpler? <janneke>dongcarl: i was looking for a way to write a bootstrappable c compiler; it seemed easier to write that in scheme (thanks to maxwell's equations of software) than in assembly <dongcarl>janneke: Okay, so the overall goal is to write a minimal C compiler to bootstrap gcc and remove it from our bootstrap binaries... And so you write that minimal C compiler in scheme... And you wrote a minimal scheme interpreter in even-minimaler C? <janneke>mes may not survive in the long run, m2-planet may grow so powerful it can compile tinycc, but that will take quite some time yet. m2-planet cannot even yet compile mes, which is written in real simple C <dongcarl>I guess I'm having trouble understanding the bootstrap chain here... as I know mes is both a minimal C compiler and also a minimal scheme interpreter? <janneke>dongcarl: yes, exactly; not knowing at the time how i would bootstrap that minimal scheme interpreter, i was opting for writing it in assembly, but now m2-planet has solved that puzzle in theory <janneke>dongcarl: yes, they could have been two projects... ***jje_ is now known as jje
<dongcarl>janneke: What does m2-planet do right now? What is it written in, what is its input and what is its output? <rvgn>Hello Guix! URGENT! I am looking for a free stoftware (offline/desktop application) that has feature-sets suitable for Tutoring Bussiness. All I need is to manage tutor-student appointment/session scheduling. It's kind of urgent, so I would appreciate if some one could please help me with this. Thank you! <janneke>dongcarl: m2-planet is a compiler for a c-like language and is currently prototyped in that c-like language. it is being translated to M1, most functions of its very modest c library have been translated <janneke>m2-planet is self-hosting, and it's simple c-like language may have to grow a bit for it to be able to build mes, so that's why we have been pragmatic and use c prototypes and c-like languages (that can still/barely be compiled with gcc) <dongcarl>"build mes" as in build the mes scheme interpreter? <Ozymandias42>what modules do I need to make (package-derivation store bash) not complain about unset variables store and bash? <str1ngs>janneke: how far did you get with Emacsy? <janneke>str1ngs: i'm still playing with it and am looking for a way to get rid of the bits in C, even if that means using guile-gnome and webkit1+gtk2 until guile-gi works well enough <janneke>i'm OK with doing bits in C if i must, but would like to play and prototype those bits in scheme first <janneke>there's hacky/play'y stuff on my gitlab, i'm hoping to create a nice example application some time soon <janneke>ah, i just successfully built webkit-2.4/webkit1 for guile-gnome, but after install the last packaging failed :-( ... almost there <str1ngs>I did'nt know guile-gnome had a webkit class <dongcarl>Does Guix have any strongly connected components in its dependency graph? <janneke>str1ngs: it doesn't, i'm working on adding that... %-/ <janneke>dongcarl: what do you mean by "strongly connected?" <janneke>guix does not have cycles (apart from the bootstrap binaries) <dongcarl>I think I know, but why precisely are bootstrap binaries cycles? <janneke>yeah, all those problems/cycles; we don't have them because we didn't (couldn't?) create them <str1ngs>janneke: I think guile-gi looks interesting. I'm wondering how much overlap your work has with nomad. is your intention to have a functional web browser? <janneke>debian builds every package from source, but installs all its dependencies as binaries <dongcarl>janneke: Oh man... debian vs. Guix was the question I was scared of the most... Now that's easy to answer <janneke>add ~25y of of unawareness and you create a huge pile of work <janneke>str1ngs: my work is only play...but yeah, i would hope to share guile code once guile-gi gets feasible -- hopefully <str1ngs>janneke: I'm just concerned with duplication of effort. <dongcarl>janneke: So I wanted to center my talk around trusting trust... And was wondering if this thought is true: because debian seems to build itself from previous generations... Any previous generation that wasn't reproducible was able to be trusting-trust attacked, and even with the current reproducible efforts, we can't detect it? <janneke>str1ngs: yeah...let's keep in touch; i'm only/mostly investigating possibilities right now <janneke>and there's next, what do you think of that/have you seen it? <str1ngs>I have seen next, I'm looking from something more GNU oriented and is extensible with guile <janneke>dongcarl: i think that's right, although OriansJ (on #bootstrappable) may have something interesting to say. similarly, it's true for Guix but "only" for its bootstrap binaries and that's why we have taken up the challange of replacing them with a full source bootstrap path <str1ngs>janneke: but yes, I think this exploration has potential. I'll continue to pick away at nomad. but maybe at one point we can pull the two together. This kinda project is to large for a single to work on IMHO <janneke>str1ngs: okay, yeah i'm pretty happy with its functionality and lisp is much nicer than javascript, but i'm still a bit hesitant about the cl choice; there could be overlap/sharing of ideas (and possibly C-interface code) with next though <str1ngs>my issues with next and emacsy as well. was lack of autotools support. neither seems like proper GNU projects. I'm sure they are good. but I wanted something that could maybe one day. have some stamp of GNU approval <tsarfox>Is there a safe way to make a connection to the store from within a G-Expression, or is that a bad idea? <janneke>str1ngs: emacsy itself uses autotools; while playing i'm extending the emacsy-webkit-gtk[-w-windows] example -- no worries, my projects are all gnu'ish :-) <str1ngs>cool, well keep in touch. I'm just wanting to avoid duplication of effort <civodul>tsarfox: at first sight it looks like a bad idea :-) <civodul>roughly, i think you don't need 'open-connection' unless you're writing a tool around Guix <tsarfox>Though I'm trying to connect to the store from a gexp because I'm writing some tests for my tool <civodul>tsarfox: your gexp is ultimately passed to computed-file or gexp->derivation? <civodul>so that gexp is going to be evaluated in the build environment, where (presumably) the daemon is not running <civodul>in which case open-connection will fail <tsarfox>Yeah, trying it out I was getting ENOENT <janneke>woot, just got guile-gnome's first web page loaded <davidl>does anybode here know how to clone a repo from software heritage? I wanted to fix a package - guile-bash - by providing a git clone of the original repo which today is only availabe on software heritage. <davidl>I was only able to download a specific commit of the package, thus lost all the git history. <mbakke>davidl: Do you need the history? The guix hash for git checkouts ignores the .git directory, so maybe updating the hash is enough? <davidl>mbakke: I don't need it to package and install the application (which is already done) but on the mailing list it was suggested to me that it was important that the git history is maintained. I have put the repo on gitlab https://gitlab.com/methuselah-0/guile-bash which I used for commit and hash in the update I suggested for the guile-bash package. <matt`>hey all, i'm flashing a guix installation to a flash drive. How do i copy the config into the root filesystem? <matt`>is there a way to specify this in the os declaration? i'm havng trouble mounting the root partition which is an hfsplus filesystem <bavier>matt`: not tested, but I think you can have the os config insert itself into the root as a "special file". See the manual <matt`>bavier: i'll take a look, thanks <emyles>If anyone can help with a package that needs git submodules, could you please have a look at my question on the ML? <bavier>emyles: is the CMakeLists.txt file missing? or is the submodule not checked out at all? <emyles>thanks for looking, not checked out at all <bavier>emyles: does output contain any useful info? <emyles>it`s working! I deleted the source from /gnu/store mentioned after "starting phase unpack" <emyles>by doing guix gc -d /gnu/store/whatever <emyles>Then it said error: Server does not allow request for unadvertised object 03fa5..etc <emyles>So I change the commit to fetch and now it is cloning submodules. ***tilpner_ is now known as tilpner
<emyles>So, maybe 'guix build' doesn't check to see if the package definition has changed, probably just the (source) block <sebboh>str1ngs: replying to my "lots of free ram but not enough to start a guest even though it should be enough" issue from days ago.. it turned out I had left a box checked for 'dynamic ram size' for my guests. Host is microsoft HyperV. Guests are debian and guix. Everything is better since I unchecked that box. <str1ngs>sebboh: oh, I had not even thought to ask what OS you were using for the host. I assumed you were using Linux sorry about that. <bavier>emyles: a change in the package would yield a different derivation. But I don't know exactly what you did, so hard to say why it seems to behave different now <str1ngs>sebboh: that understandable. I've had to use hyperv for work as well. It's actually not bad