<ryanwatkins>Hey guys, I am constantly getting load-thunk-from-memory: no such file or directory errors right now everytime I run a guix command, any idea why that might be? :D <Sn0wDay>Guys, am I right if I want to change for example timezone I need to run guix system recofigure configuration.scm, and there is no other way to do that ? <Sn0wDay>Or for example if I need to add additional service to the system... <Sn0wDay>And it will again download all the packages and install them over the existing <Sn0wDay>Will create additional generation etc... ? <OriansJ>Sn0wDay: mostly just create new generations, as nothing in the previous packages will be altered by any guix installation <Sn0wDay>But it downloading againg all the packages (they are already exists)... Why it do all this... I only need to change timezone... <OriansJ>Sn0wDay: reconfigure will also update all the applications listed in the configuration. <Sn0wDay>mmm. Is it possible to update all the applications optionally ? <OriansJ>Sn0wDay: the specification can dictate any version of the software you wish and reconfigure will ensure that state <Sn0wDay>Ok, I mean next. I already has all packages I need. I don't want to upgrade them. I simple need to reconfigure some things that not related with packages... Change local or timezone. May be mount some additional partitions at startup, etc... Can I simple recofigure only this things without any downloads (all I need already installed) and packages updates ? <Sn0wDay>Can this recofigure stuff detect only the changes between current configuration and new config.scm and simply do only required things but not the whole system rebuild ? <Sn0wDay>is it a build-in command, or I need to install it separately ? <Sn0wDay>because I already look in repo: there is no such package also... <Sn0wDay>mm, I need to install tzdata package... sorry <Sn0wDay> Hmm... no, tzdata don't contains any tzselect script or app <Sn0wDay>Ok, I already reconfigured system. It downloaded all the new stuff (but I don't ask it to do this) and it updated timezone... And after restart is still working. Greate. Thank to Guix developers. <Sn0wDay>But it will be more optimal to check what was changes, any do not upgrade all the system, instead of simple change time zone IMHO <OriansJ>By default, timezone related utilities (zic, zdump, and tzselect) are installed with the GNU C Library. <Sn0wDay>You right ! After I was installed glibc, tzselect app also has been installed <OriansJ>You should now be able to set timezones on a per user basis if you wish <OriansJ>everything in guix can be configured on a per application basis if you wish <Sn0wDay>And how it can be done ? Does any manual about system / apps configuration. Because what I was found on a official Guix web site provide a guix system reconfigure way... <epronk>I'm trying to figure out how shepherd starts. I'm running the usb-install image in qemu. <epronk>when I inspect /proc/1/cmdline it contains ids I don't see in the image. <rekado_>ACTION notices that ‘guys’ is used more often on this channel than before <rekado_>ryanwatk`: ‘load-thunk-from-memory’ means that you are using a version of Guile that cannot read the compiled Guix modules. <rekado_>ryanwatk`: you can fix this by finishing the upgrade to Guile 2.2 and the latest version of Guix. <rekado_>sneek: later tell Sn0wDay Guix will only install packages when it needs to. ‘guix system reconfigure’ will not download or build packages you already have. If you upgrade Guix between reconfigure (e.g. with ‘guix pull’), however, you may need to rebuild/download packages again. <rekado_>sneek: later tell Sn0wDay If you want to avoid updating packages with reconfigure it helps to keep the operating system configuration small, i.e. use per-user profiles instead of putting all packages in the system configuration. <rekado_>epronk: What do you mean ‘figure out how shepherd starts’? <davidl>Im trying to install a package using Cabal and get the message "cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times)" <davidl>Any suggestions what to do about that? <janneke>epronk: have a look at grep -o 'load=[^ ]*' /boot/grub/grub.cfg, the `boot' file is being exectuted and that file does a execl of the shepherd binary <epronk>janneke: At least now the lxd container starts. /gnu/store/zk41gmzbibvpx9dpsm5gs8p0liz8shy0-guile-2.0.14/bin/guile --no-auto-compile /gnu/store/q49si29djfcrpzibqg6cg8k6xixxvd2f-shepherd-0.3.2/bin/shepherd --config /gnu/store/df56ad2rw1ayjyhs1kqadskf5zsmsc5l-shepherd.conf <epronk>I created an /sbin/init with #!/sbin/dumb-init <epronk>lxd calls /sbin/init without arguments, so I'm trying to use dumb-init as a wrapper for shepherd. <sturm>I'm running GuixSD via `guix pull` at the moment. Is switching over to using a git checkout as simple as `ln -sf [guix-repo] .config/guix/latest`? Is there anything more I need to do? <sturm>(before I can `guix package --upgrade`) <alezost>sturm: yes, making that link should work, but make sure the git checkout is compiled <sturm>alezost: as in `guix environment guix; ./configure --localstatedir=/var; make`? <alezost>sturm: yes, but if you have not built it yet, you also need "./bootstrap" before "./configure" <alezost>then (for further rebuilds after "git pull") only "make" is needed <rekado_>supposedly I should run ‘latex’ on the dtx files <rekado_>but latex seems to depend on the latex base, which is also provided as dtx files <efraim>ACTION is currently working on updating modular qt to 5.9.0 <civodul>it seems that Scalapack occasionally fails a test <janneke>epronk: what does it mean that lxd container starts, are you up and running -- does shepherd also start? <janneke>epronk: lxd does not want to load /gnu/store/deadbeef1234-system/boot instead of /sbin/init? <jsierles>rekado_: hey, had a few more questions about packing if you have a moment. <jsierles>if a packed build is reproducible, is there a file or some metadata I can use to reissue the same build? for example if i do 'guix pack r' then run 'guix pull' and pack again, i might have a different build due to R being upgraded. <jsierles>so i'd like to have a way to know exactly whats in a packed build. so i could run that one again with all the correct versions of packages. <rekado_>jsierles: this feature doesn’t exist, unfortunately. <rekado_>jsierles: to achieve reproducibility a user must have at least two things: the effective version of Guix (this must include the versions of all custom modules on GUIX_PACKAGE_PATH) and a manifest. <rekado_>a manifest is a formal description of what packages are to be installed into a profile. <rekado_>these two things are sufficient to fully describe the state of a profile and therefore the state of a pack. <rekado_>but Guix does not record these things. <jsierles>ah ok. so reproducible builds is not possible yet <jsierles>in the sense that as time passes, the same commands used to run a build could produce different results? <rekado_>no, reproducibility is possible and for most packages builds are reproducible already <rekado_>it’s just that users must keep track of the guix version manually <jsierles>ah, OK. and the manifest - where is that located? <rekado_>if I tell you to check out Guix version foo-bar-0.1.cabba9e and build ‘r-minimal’ then you should get the exact same binary as I do. <rekado_>the manifest is supplied by the user <rekado_>it’s essentially a list of variables that map to package expressions, which is then fed to a Guix procedure that returns a manifest. <rekado_>note also that Guix produces a ‘manifest’ file in the generated profile <rekado_>(though I don’t know how this is generated and if it could be used to recreate the profile state) <jsierles>rekado_: ok, so we'd probably have to generate manifests right now by hand <jsierles>rekado_: also, you mean that package definitions are not updated until a new Guix version is installed? <rekado_>jsierles: since you’re invoking ‘guix pack’ with some arguments I suppose that wouldn’t be too much of a detour. <rekado_>package definitions are part of Guix. <jsierles>ah ok. I thought 'guix pull' might update those. does it also update guix? <rekado_>‘guix pull’ actually updates guix :) <rekado_>it does *not* update the daemon, though. <rekado_>the ‘guix’ executable checks if ~/.config/guix/latest exists, and if it does loads the modules from there. <rekado_>whenever you run ‘guix pull’ the pointer gets updated . <jsierles>i see. so it is possible to run a build with a previous guix version? <rekado_>when you have a clone of the Guix git repo, you can run ‘./pre-inst-env guix’ and it will use the local modules in that repo <rekado_>currently, ‘guix pull’ only allows for a single link: ~/.config/guix/latest <rekado_>but we’re currently discussing about whether to extend this to a real profile <rekado_>then you could just use a past version of Guix without messing with git. <rekado_>feel free to join the discussion on guix-devel@gnu.org! <rekado_>‘guix pull’ is probably the weakest part of Guix at this point, which is why we’re discussing improvements <rekado_>ACTION has to get back to working on Texlive <rekado_>jsierles: feel free to ask questions even when I’m not around. Someone else might be able to answer; if not, I will at a later point. (I usually read the logs.) <jsierles>so it sounds like doing manifest-driven builds is still young <rekado_>no, building from manifests is well-established. But going back to previous versions of Guix is not. <jsierles>ok. so for now i'll look into a way to figure out what versions of packages are current, and write out a manifest along with the pack. sound reasonable? <rekado_>you *can* do it, but that currently involves either using git or changing ~/.config/guix/latest (e.g. by doing guix pull --url=https://…/some-commit <jsierles>have to get my hands dirty with scheme. i don't know it yet <rekado_>jsierles: Guix always defaults to the current version when it’s given a package name. <rekado_>e.g. asking for ‘icedtea’ will give you the package behind ‘icedtea-8’ (i.e. the JDK for Java 8), although we have ‘icedtea’ for version 6 and 7 as well. <rekado_>the manifest could just be a list of package names. Given a particular version of Guix this will be unambiguous. <jsierles>rekado_: right. i get that, but i would either need to use a specific guix version to reproduce the build, or have a manifest that lists the versions and pass to 'guix pack' <jsierles>unless i can specify the guix version too in the manifest. <rekado_>the manifest does not list the guix version. <rekado_>using a specified version of guix is the only way to binary reproducibility <rekado_>because it’s not just an individual package that needs to be reproducible, but the complete graph that it stands on. <jsierles>alright. so for now using git is the way. <rekado_>civodul: having that huge (gnu packages cran) module sitting in my directory sure slows guix down :( <jsierles>rekado_: last thing then. to change the 'latest' link, do i have to do git pull on older versions, or are they stored somewhere locally? <rekado_>jsierles: I’d always use both, but in your case you might get away without using a manifest. (If you’re just passing package names to ‘guix pack’ directly there’s probably no point in using a manifest, other than to give users a file with which they can reproduce the thing on their own.) <rekado_>the ‘latest’ link really just points to a ‘guix’ package in the store. <rekado_>if you use git you can point that link manually to /path/to/guix/from/git/ <rekado_>since the target of that link (i.e. the git repo) is managed by you Guix has no idea what’s behind it. It won’t take care of storing previous versions of the git repo on your behalf. <civodul>rekado_: do you mean that all the commands feel slower? <efraim>When I finish with qt 5.9 I plan on having qt inherit from qtbase <epronk>janneke: I have seen the shepherd process run inside the container, but it doesn't show up in pstree. <epronk>janneke: it must be possible to load /gnu/store/deadbeef1234-system/boot instead of /sbin/init. Many changes from lxc to lxd. <epronk>I should probably learn some more about guix in a VM so I learn what to expect in lxd. <janneke>epronk: weird..., of course on guixsd i have ptree start with: shepherd(1)-+-- <epronk>One option is would be to do an install in qemu and then add a grub entry to try the same, but with an ubuntu kernel. Then I have a console at least. <epronk>janneke: my ptree looks like this: dumb-init(1) - bash - guile <epronk>too tired now. Good night folks. <civodul>efraim: do we still need the non-modular Qt? <efraim>I think we still have packages that either don't build without it or don't run properly <efraim>I'm showing gcompris-qt, avidemux, vlc, and keepassxc which I haven't finished testing yet <rekado_>I tried moving the remaining packages from the monolithic Qt to the modular one, but vlc and avidemux were a bit too challenging. <rekado_>doesn’t help that it takes a very long time for them to be built <rekado_>civodul: I’ve only tried with ‘guix build’ so far, but it does seem to be noticeably slower. <civodul>rekado_: and you compiled the file, right? <jsierles>so i created a docker image with 'guix pack'. but it doesn't seem to have a default command, nor can I run anything with the PATH it seems to include <thomasd>Strange, I'm on commit ae44ebb90, which corresponds to evaluation 109668, yet I'm not getting a substitute for qt-4.8.7 (and many others, it seems). Did I miss something? :) <rekado_>jsierles: you may need to use the ‘--symlink’ option to link the bin output of the profile to some well-known location. <rekado_>thomasd: if you’re trying to get things from mirror, it might be that it hasn’t cached the requested item yet. <rekado_>thomasd: maybe try with hydra.gnu.org directly? <jsierles>rekado_: so there is no path set, and the location of installed binaries is only known at build time? <thomasd>rekado: thanks! still so much to learn... <jsierles>this is the path set in the container: /sbin:/bin:/usr/sbin:/usr/bin <rekado_>jsierles: despite having implemented the Docker export I haven’t played much with it (I’m not using Docker myself). You may even have to source the profile’s /etc/profile file to set up required environment variables. <rekado_>civodul: ah, the reason why it’s slow is that it failed the compilation. <rekado_>civodul: Guile crashed with ‘Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS’ <efraim>How many definitions in that module? <rekado_>efraim: I haven’t counted, but it’s 250k lines. <efraim>I think Python is in the 15k area <rekado_>it’s slow because it wasn’t compiled. <civodul>did you ask your boss to buy more RAM already? <civodul>ok we really really need to fix that one <civodul>could you try compiling it with 2.0? <civodul>with "\\time guild compile gnu/packages/cran.scm" <civodul>so we can see how much memory is used <rekado_>I’ll do this inside guix environment --pure --ad-hoc guile@2.0 <civodul>you might need the 'time' package too <rekado_>I can get it from /usr/bin/time (I don’t have GuixSD on my workstation) <civodul>bavier`: with mumps-metis-openmpi, i have things like: <civodul>/gnu/store/c5p4cpkwfqxsm1ljnjj6qhwd0njm64d7-mumps-metis-openmpi-5.0.2/lib/libzmumps.a(zana_aux_ELT.o): In function `zmumps_ana_f_elt_': <civodul>(.text+0x2e62): undefined reference to `metis_setdefaultoptions_' <rekado_>to get GuixSD on my workstation I still need to figure out how to make logins work with LDAP / SSSD. <rekado_>my problem was that nss doesn’t seem to load the plugins by default, even after augmenting nscd-service-type by adding ‘nss-pam-ldapd’ to the ‘name-services’ field. <rekado_>but that doesn’t work with agetty/mingetty <rekado_>I’ll play with this maybe next week; hope I can soon switch to GuixSD! <civodul>there's also a subtle race condition with nscd <civodul>none of the services depends on 'nscd' <civodul>so if they happen to be started before nscd, they'll just don't use it <civodul>usually we can't tell the difference, but maybe there are cases where it matters <davidl>Im trying to install a Haskell package (xmobar) and Im getting "Use of GHC's environment vaiable GHC_PACKAGE_PATH is incompatible with Cabal". Any suggestions for how to fix that? <rekado_>davidl: have you tried unsetting GHC_PACKAGE_PATH? <davidl>"failed during the configure step..." <davidl>There is more detailed info on the help-guix mailing list. <davidl>I tried old suggestions but it didn't help. <brendyn>Anyone else notice the new font-build-system shows starting phase `install-locale' <brendyn>warning: failed to install 'en_US.utf8' locale: Invalid argument <civodul>brendyn: i think that's because it misses a dependency on glibc-utf8-locales <brendyn>I wonder what goal I should set for my Guix contributions. 100 patches by the end of the year? <thomasd>I'd like to create a pcscd-service (pc smartcard daemon). Our pcsc-lite package expects usb smartcard reader drivers in /var/lib/pcsc/drivers ... so should I add a service to create a /var/lib/.. directory first? <civodul>thomasd: you could do that, but i think it's even better if you put the driver in /gnu/store <thomasd>civodul: I was afraid you'd say that :-) It seems like pcsc-lite expects all its drivers in a fixed directory, determined at compile time. <thomasd>so I guess it's hard to do, unless we create a fixed bundle of usb drivers, which all go in one store location. I think users will want to configure which USB smartcard drivers they want to install on their system. <efraim>$driverdir = $(libdir)/pcsc/drivers <thomasd>efraim: you mean pcsclite takes an environment variable to change the location? <efraim>No idea, but that's what I would search for in the makefile <rekado_>wow, guild is still compiling that module. <thomasd>efraim: ah yes, but that's already taken care of in our pcsc-lite package, with the configure flag "--enable-usbdropdir=/var/lib/pcsc/drivers" <efraim>We must have something somewhere that is a union of other packages for this, maybe the cups service? <thomasd>efraim: I'll look at that for inspiration. But I don't see how the contents of the directory can be changed in a Guix system configuration, if it's hardcoded in the package. Unless we parameterize the pcsc-lite package itself (am I making sense? :-) ) <efraim>As part of the service we could take several store items and combine them in /var/lib/pcsc/drivers <thomasd>ah, ok, that's what I meant to do :) . <thomasd>we definitely have such things already (e.g. the sbin directory is also populated with symlinks to store items) <thomasd>well, I don't think I'll be submitting this year's tax return form using GuixSD :-) <civodul>thomasd: it could be an env var or maybe there's a command-line option <civodul>thomasd: that said, to be on time for your tax return form, it's okay to use /var/lib to begin with :-) <thomasd>thanks for your consideration :) Well, I'll take it one bit at a time. For me, time pressure (or tax form pressure) doesn't improve productivity... <civodul>what's the normal location for gfortran .mod files? <rekado_>civodul: I see that some are under ‘finclude’ <rekado_>ice-9/boot-9.scm:109:20: list too long <rekado_>9773.59user 11.22system 1:45:27elapsed 154%CPU (0avgtext+0avgdata 1933976maxresident)k <rekado_>7560inputs+0outputs (68major+481467minor)pagefaults 0swaps <civodul>we have substitutes for guile 2.0 no? <rekado_>no, guile 2.0 compiling the big cran module. <thomasd>civodul: btw gfortran doesn't find .mod files in ${HOME}/.guix-profile/include by default, and AFAIK there is no suitable environment variable to fix that (Guix sets $CPATH, but that only helps when using the C preprocessor). <civodul>is there a GFORTRAN_PATH or something? <civodul>my understanding is that CPATH works for all the languages supported by GCC <thomasd>for fortran, only if the preprocessor is involved <civodul>thomasd: oh right, the gcc manual says "This environment variable is used regardless of which language is being preprocessed" <thomasd>civodul: yeah, it has already annoyed me to no end :) I don't understand why there's no general way to add an include directory for gfortran. (but then, there are many things about fortran which puzzle me) <thomasd>btw our netcdf-fortran package also has a .mod file <jsierles>rekado_: so i peeked inside the docker tar file. i see everything stored at /gnu/store. but not sure what symlink to expect to see. there doesn't see to be an /etc/profile, or a directory containing links to binaries in the store. <jsierles>sorry - the symlink IS there, but points to a non-existent profile. <jsierles>it points to: /gnu/store/bhg0i3nfqdk69brzrm11fyr96scqh7vx-profile/bin. but this directory doesnt exist in there. <thomasd>ACTION wonders why each of the 511 kodi tests takes exactly 30.22 seconds <sneek>davexunit, you have 1 message. <sneek>davexunit, sirgazil says: the black mug handle is white. <mbakke>thomasd: they used to take a few MS before the gcc-5 core-updates merge <rekado_>it’s annoyingly hard to override search paths <rekado_>I always need to dig into perl scripts to figure out what it tries to do <thomasd>mbakke: weird, they're hardly using any cpu. I'll try to look at it, some time. <civodul>rekado_: Andreas & i had long discussions on the topic of TeX search paths when he was working on it <civodul>some of it must be in the list archive <civodul>thomasd: i've noticed that the kodi tests take a long time; maybe there's "sleep(30);"? <thomasd>civodul: must be something like that <rekado_>jsierles: here’s what I did: guix pack -f docker -S /bin=bin coreutils <rekado_>jsierles: this gives me an image with a layer tar. Inside of that layer is a /bin symlink. <rekado_>jsierles: after importing the image I can run this: docker run 4d26255a9be2 /bin/ls <jsierles>here's what I tried: guix pack -S /usr/bin=bin -f docker r-base64enc r-jsonlite r-plotly r-ggplot2 r-dplyr r-rcolorbrewer r-scales r-gridextra r-caret r-stringr r-dt r-da <jsierles>ta-table r-ggthemes r-readr r-purrr bash <rekado_>civodul: I’ve already built the metafont base file and I’m almost done bootstrapping latex-base. <jsierles>rekado_: maybe i just needed to add coreutils as well <rekado_>texlive-20160523-source/texk/kpathsea/tex-file.c contains a lot of environment variable names that could come in handy <jsierles>rekado_: i see, so perhaps even though I installed R packages, the R executable is not installed. do you know which package has it? <rekado_>jsierles: it’s either ‘r’ or ‘r-minimal’ <rekado_>‘r’ contains the default packages as well, but I’d suggest just going with ‘r-minimal’ <jsierles>yes, it's r-minimal but that binary is not there <jsierles>rather, it's not linked into the profile <jsierles>so i see tar, sh, etc. but not the R binary linked. <rekado_>ls $(guix build r-minimal)/bin shows me R <jsierles>when i did this before, without coreutils, the linked binary dir was empty <rekado_>the docker thing is just a post-processing step <rekado_>first we build a profile (which ends up in the store), then it’s copied into the docker format. <jsierles>ok. for some reason, i have r-minimal in this image but the binaries arent linked. now i'll try with r-minimal being packed explicitly. maybe it's because i didn't make it explicit ? <rekado_>jsierles: only those things end up in the profile that are mentioned explicitly (or that are propagated inputs) <rekado_>jsierles: everything else just ends up in the store. <rekado_>that’s by design as it is not necessary for all things to be in the profile. <jsierles>ah, that would do it then. thanks for the clarification <rekado_>libraries, for example, can be found via the RUNPATH feature, so they don’t have to be linked to the same prefix. <rekado_>looks like I first need to build all fonts for Texlive before I can bootstrap latex-base. ***andreh1 is now known as andreh
<rekado_>this takes a bit longer than I want, because the build dependencies are not obvious. <jsierles>ok, now the R binary is there, but when running it i see: Fatal error: cannot create 'R_TempDir' <rekado_>jsierles: because the docker image only contains the bare essentials: just the contents of the profile and the json files mandated by the image format. <rekado_>jsierles: it might make sense to add /tmp by default; not sure. <jsierles>is it also holding a subset of the guixSD operating system? <quiliro>is there a forum or chatroom for pragmaOS? <jsierles>rekado_: on one hand it makes sense to keep the container read only <fusion809>Hey whenever I try to change my user shell to Zsh I get the error: "chsh: PAM: Authentication failure". Do I need to install some PAM package? <rekado_>jsierles: no, it doesn’t contain GuixSD, just the plain store subset. <catonano>quiliro: there's a mailing list. See pragma site <fusion809>I tried editing /gnu/store/*shadow-4.5/etc/pam.d/chsh but it also failed due to perm issues <jsierles>what's the right naming for files that go in GUIX_PACKAGES_PATH? <jsierles>for example, an R package imported from CRAN. <fusion809>Guessing this means no one has the foggiest how to fix this issue? I'll just have to stick to using bash, or starting zsh manually with /gnu/store/*zsh-5.2/bin/zsh? <efraim>fusion809: don't edit store items directly, it will break things. To change your shell it has to be in the OS config <brendyn>I just discovered there is a SICP package. Are we starting a Guix Library now ^.^? <fusion809>Ya that's why I tried copying it my OS config folder /etc/pam.d <fusion809>Also tried directly editing the file in /etc/pam.d/chsh and setting it what it is on my host machine where chsh works fine and it's still refusing to save... <fusion809>Nano also says /etc/pam.d is a read-only file system. This is from my root account on GuixSD <davidl>Is anyone working on making xmonad and xmobar usable on GuixSD? <buenouanq>we should have an official wiki or something to help answer questions like that <buenouanq>if you're packaging something make a page about it, then others will know where to look and who to offer help etc <jsierles>if it were on github, we'd have pull requests and issues for that <efraim>i hate the qt documentation, trying to figure out how to make sure examples don't get built is nearly impossible <efraim>qtlocation has bundled 3rd party code which in turn bundles 3rd party code ... :/ <rain1>you can edit this wiki if you want, it is NOT official <jsierles>looks good. better of course would be a PR-style workflow, as you can see actual work happening and comment on it. wikis tend to get out of date as soon as they are created. <mbakke>jsierles: you can subscribe to the 'guix-patches' and 'guix-bugs' mailing lists, and/or use the 'emacs-debbugs' interface <mbakke>wikis tend to get outdated fast, it's better to improve the documentation <jsierles>yeah, i will do that. but i do find using mailing lists a much less productive way to review code changes. call me new-fashioned :) <buenouanq>what we're sort of talking about though is stuff that doesn't yet exist yet <buenouanq>to which there would of course not be any docs yet either <bavier`>sneek: later tell civodul re mumps/metis, the error looks familiar so I'll take a look at it <quiliro>catonano: i cannot find the bugtracker <quiliro>i cannot find how to test pragmaOS either <quiliro>is there a configuration file for GuixSD or a download with an image of PragmaOS? <catonano>quiliro: fish guix is a shell. It's one of the parts tat pragmatique is made of. Gnunet is anothher part. There are more <catonano>quiliro: there's nothing to download for now <quiliro>catonano: so how can i contribute and where is the mailing list...i could not find that info on the site <catonano>quiliro: you're right, I can't find it either <catonano>quiliro: the best thing is you contact ng0 directly and ask them <davidl>quiliro: pragmaOS is ng0's project. He is migrating some of his hosting at the moment and he has been purposely keeping the git repo private, don't remember why. <davidl>quiliro: but he mentioned they are are moving away from autistici. <OriansJ>janneke: I think we are going to need to discuss incremental builds <janneke>i did not have much time for mes the past week, made a just bit of progress on compiling tcc.c by implementing arrays as struct fields <OriansJ>janneke: correct me if I am wrong but MESCC doesn't actually have a mechanism for generating precompiled libraries or leveraging them. <janneke>OriansJ: that's right. It's only a week ago that I added the -c option, to allow combining several compilation units. Before that the only option was one C file -> ELF <OriansJ>janneke: for large programs, we would really want to make them incrementally <janneke>i was hoping to change the .o files to your hex2 format and that doing that would be good enough... <OriansJ>I should probably make an example of that being useful for you. So that the potential points would be covered <janneke>is tcc such a large program, or do you have dreams beyond compiling tcc? at the moment, tcc (or easier equialent) is my horizon :-) <OriansJ>janneke: tcc, like gcc and the linux kernel all are broken in to segments that can be build on standard hardware in under 40 seconds <OriansJ>it makes aborting a build, crashing and getting built on multiple systems much easier <OriansJ>making similar changes to your mes will greatly improve the debug and update experience for builders <janneke>we should make working on the bootstrap project workable and fun <OriansJ>janneke: especially for ourselves first and foremost <janneke>well, that's why i almost exclusivly run mescc on guile, and only on mes to test it <reepca>agh... my multi-display troubles seem to have no end. Tried putting in a radeon hd 6670, hoping it was old enough to not need proprietary microcode to be full-featured (according to dmesg it needs proprietary microcode... and I'm still not sure that's what's causing the problem), which does nothing except for some reason renaming the ethernet interface from eth0 to enp2s0. On removing it and plugging back into the integrated graphics, I <reepca>now only have one display showing anything and the other black (but on). So confused. <janneke>even then, it's too slow -- i really misengineered some things i guess <OriansJ>janneke: to make something fast, you first must make it simple and out of small pieces <janneke>OriansJ: i have the real bad habit of making things work first, and only then start to care about making it [more] simple -- something that i care about/like a lot <OriansJ>janneke: that isn't a bad habit, it is extremely useful for starting a search into a problem space <bavier`>and you learn things along the way too <janneke>i keep cleaning up mess that i created myself though... <OriansJ>and honestly, it is a very good counter to my habit of trying to only do the correct thing <OriansJ>I've honestly been burning alot of time trying to figure out the optimal way to implement a trivial lisp compiler in lisp <janneke>OriansJ: oh, wow -- it's so great to hear you say that! I was going to say something like: my habit isn't so bad at all if I work together with someone who can balance it <OriansJ>janneke: reading your mescc, I see alot of great pieces and something that has potential but not as a single big program. Rather something that might actually be a production grade micro-pass C compiler, which could scale rather impressively. <OriansJ>janneke: I honestly could see with effort making MESCC the best C compiler to experiment new optimizations and languages on. <janneke>OriansJ: wow, looking forward to your ideas and patches! <OriansJ>janneke: The first patches will be a linker that uses hex2 and provided a _start is exported will combine multiple hex2 compiled files into a single ELF <janneke>OriansJ: great, yes i was thinking to first allow mes's o[bject]->elf to grok a heterogeneous mes-lambda/hex2 object format and gradually remove all mes-lambdas <janneke>that would mean repeating your hex2 linker work and throwing it away afterwards... <janneke>it would be great if you see an easier way and if we could work together on it, that would be more fun <OriansJ>janneke: how about I make an ELF linker that also support arbitrary binary inserts, which would allow you to just gradually remove all mes-lambdas <efraim>font-google-noto source failed the hash check <janneke>OriansJ: i like the gradually remove bit a lot, i don't understand how this would work exactly, yet; the mes-lambdas are called with text-address and data-address and only then produce pure binary <civodul>bavier`: re metis, i found the culprit in the meantime <civodul>actually there's a comment saying that it's up to the user to do the right thing <bavier`>oh, right; which package was the failure in? <OriansJ>janneke: you simply eliminate the need to know the addresses, only the stack displacements need to be computed <OriansJ>for example instead of determining the address of function named bar(int a, char* b); you simply output a call with the @bar to have it computed by the linker <reepca>hey rekado_, what GPU are you using? You said you had multiple displays working, correctly, aye? <OriansJ>janneke: similar tricks can be used with global variables and all local variables are just simple displacements from the stack base of the function call <civodul>bavier`: in some other package at work <janneke>OriansJ: hmm, we can probably write a trivial variation on mescc's object->elf to do object->hex2, where waaay to many jumps/addresses are already calculated, but some use @/: <janneke>and we let your hex2 linker produce the elf <janneke>then it's just a matter of removing jump calculation from mescc and outputting more @/: <rain1>some of the work he has been doing on bootstrapping a tiny linux distro could overlap with mes <OriansJ>rain1: actually I think it is more parallel <OriansJ>rain1: He is looking at minimal bootstrap for the system (which will be important), while MES is an ultra dependency lean compiler which could probably shrink his minimal distro once we get far enough along <janneke>OriansJ: yes, he might like the ideas of stage0..2/mes <rain1>I think that the info collecting on C compilers has been good, I wonder what we might need to know next <OriansJ>rain1: probably can tcc build binutils or do we need to find more intermediate steps <rain1>it might be possible to use neatld until we get binutils <janneke>rain1: i have made a little progress on compiling tcc -- mescc now fully supports typedefs, arrays in struct fields and comments everywhere and i patched-out some gratuitous unions... <OriansJ>rain1: basically we need to keep chipping away at the guix bootstrap binaries until we have solved them all <janneke>rain1: i'm still very much interested in alternatives to tcc <rain1>when I tried an early tcc - before they added very many files. it does not actually produce a binary it just executes the code directly <OriansJ>rain1: not ideal but we have plenty of time to play around and look for more options <OriansJ>janneke: plus we can start checking off other guix bootstrap binary dependencies like mkdir <OriansJ>tar, xz, bash, glibc, and guile-2.0.7 <OriansJ>plus, I still need to extend the stage0 lisp enough to write a lisp compiler in lisp that is capable to compiling itself <quiliro>would someone please guide me through mounting a guixsd substitute mirror on debian? <janneke>OriansJ: so many things to do..then rewrite mes intepreter in stage0 lisp :-) <janneke>sneek: later tell epronk: re: dumb-init(1), is your dumb-init instead of doing exec invoking guile+shepherd? <quiliro>i would like to lift the mirror in this debian laptop and then use it to install a guixsd substitute packages mirror at home for offline use and then install guixsd on this laptop offline <OriansJ>janneke: mes intepreter rewrite can wait, getting MESCC on guile to be able to build guile will be a major step in the right direction. <quiliro>maybe the best thing is to make a config.scm file to install all the needed packages and configurations to set up a hydra mirror <janneke>OriansJ: ok, giving eval.c a try is a nice distraction from the tedious, enormous tcc.c task <OriansJ>janneke: good night, I hopefully will have something fun for you by the time you wake up <reepca>anyone have multiple displays working on guixsd, and if you do, which GPU are you using? Looks like I'm in the market for a linux-libre-friendly one. <civodul>reepca: same here: with an intel thing it works fine <quiliro>reepca: i have nVidia 9400m and have worked with 9800gt with an xorg.conf file <quiliro>but i suppose it will be the same as in parabola and trisquel <quiliro>it says it is because pyqt is not installed <quiliro>i verified and it is through guix on debian <reepca>Now I just need to decide if multiple displays is worth getting a new cpu... thanks for the info. quiliro: have you updated the various paths since installing it (bash -l)? <quiliro>reepca: i have used the 9800gt with a projector and a monitor <quiliro>reepca: i have not used them on guixsd <reepca>quiliro: and in those cases, the different displays weren't duplicated or anything? <quiliro>am using intel with one display on intel on guixsd <quiliro>reepca: yes they were duplicated when i set them up on gnome as that...but they were separate by default <quiliro>that was on parabola and on trisquel <quiliro>['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7'] <quiliro>that means the version of python I am using is from debian and not from guix 