<fr33domlover>"The guile command must be in the search path on the build machines" - this is for offloading builds. `which guile` finds nothing. Should I `guix package -i guile`? If yes, which version is recommended? <ZombieChicken>Anyone here use (dependencies ...) in the file-system definition? I can't seem to figure out what it's expecting for a mapped device <iyzsong>fr33domlover: packages from guix won't use the locale from host, see '2.6.1 Locales' of the guix manual. <iyzsong>in summary, you need to install the glibc-utf8-locales package, and set GUIX_LOCPATH. <iyzsong>if the warning is from the guix-daemon, then you need to install that with root user, and restart the guix-daemno service. <fr33domlover>iyzsong, I did all that (except the locales seem to already be installed, idk I'm going guix package -i just in case <rekado>fr33domlover: are you using the systemd service for guix-daemon? <fr33domlover>rekado, no I use upstart. But it happens even when I do guix --help <slyfox>does 'ls -l $GUIX_LOCPATH' make sanely? <fr33domlover>slyfox, in my first guix install it's a symlink too, I started at guix 0.11 there. But now I installed 0.13 on a fresh install, other machine <slyfox>and to sanity-check: 'locale' shows local available as a directory in 'GUIX_LOCPATH', right? <fr33domlover>My locale is UTF8 but not included in the utf8-locales package <slyfox>'locale -a' should output rough list of understood locales <slyfox>i think proper spelling is UTF-8 or utf8 <slyfox>(not sure about the casing. glibc can canonicalize those somehow) <slyfox>i use locale exactly as its specified in SUPPORTED_LOCALES <fr33domlover>slyfox, `which locale` says /usr/bin/locale so that one seems to work again the system locales, not guix's <slyfox> /gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/bin/locale <slyfox>make sure your guix is build with the same libc version <fr33domlover>Q: I did guix pull, moved from 0.11 to 0.13. Then I did the setup for offloading. Now I run `guix offload test` and I get this: guix: offload: command not found ***jonsger1 is now known as jonsger
<fr33domlover>Q: I tried running `guix pull --url=...` with the commit fixing the guile ssh issue <fr33domlover>Guile is running, `top` says 10% CPU usage, no input is being printed, --verbose doesn't help ***jonsger1 is now known as jonsger
<oriansj>quiliro: is here but not always attentive <RX14>I'm trying to build a guix image on scaleway for fun, and they require init to be at /sbin/init and not be a symlink <RX14>what's the best way to achieve this? <RX14>looks like it's basically impossible to run guix on scaleway given i have no control over the initrd <jsierles>can I use 'guix archive' to get a newer version of guix, instead of using 'guix pull'? <sneek>Welcome back jsierles, you have 1 message. <sneek>jsierles, rekado says: You don’t have to use old hardware to use GuixSD. You only need to make sure that your hardware is supported by Linux libre. <civodul>jsierles: no, or you'd need to have an archive of Guix to import <civodul>there are similarities with the GuixSD initrd + Bournish <jsierles>civodul: ok. i'm just trying to find a good way to reproduce a 'guix pull' without actually having to run guix pull and wait around for compilation <jsierles>since it seems to be building packages I already have in a substitute server <civodul>you could point it at your server with --substitute-urls maybe? <civodul>the only thing that may still be built is Guix itself <jsierles>despite that, it seems to build a lot of packages <jsierles>is there a way to see which packages it needs? <quiliro>i was trying to incorporate qscintilla for openmolar to work <quiliro>rekado: could you help me finish the openmolar package definition? <rekado>quiliro: sure, what do you have now? <quiliro>rekado: please tell me how to paste from emacs <rekado>I don’t usually do that. You could get a shell with “M-x shell” and then paste with curl <castilma>how usable is guixsd while upgrading system services? i.e. $ guix system reconfigure <castilma>do normal users notice something? and does that command reboot? <rekado>castilma: the command does not cause a reboot. <rekado>castilma: after ’reconfigure’ you need to restart running services. <castilma>for what upgrades is a restart needed? kernel, grub only? <rekado>castilma: I would recommend a restart whenever you want to be certain that all running processes are up-to-date. <rekado>castilma: but yes, for kernel updates a restart is required. <quiliro>rekado: it was asked for when running ./pre-inst-env guix environment --ad-hoc openmolar -- openmolar <rekado>quiliro: have you started packaging it yet? <quiliro>rekado: i dont know how...but found the package in parabola.nu/packages <quiliro>but i am not sure that is really needed <rekado>I see that “Qsci” is imported from PyQt5 <rekado>could it be that our package for PyQt5 is not fully featured? <quiliro>or should i do that? how do i do it? <rekado>quiliro: I think we’re just missing Qscintilla. <quiliro>rekado: yes ...i tested it with guix package -A qscintilla <quiliro>ok...same proceedure as medical.scm? <rekado>but this time you can add this package definition somewhere in qt.scm, close to python-pyqt <rekado>let’s compare hashes. I get “0r7s7ndblv3jc0xig1y4l64b6mfr879cdv3zwdndn27rj6fqmycp” <rekado>quiliro: start by reading QScintilla_gpl-2.10.1/doc/html-Qt4Qt5/index.html <rekado>quiliro: looks like this needs to use the gnu-build-system with some modifications. <rekado>quiliro: you will need to replace the configure phase with a procedure that runs “(zero? (system* "qmake"))”. That gives you the Makefile that the gnu-build-system needs. <rekado>you will also need to (chdir "Qt4Qt5") first. <rekado>I need to go for a couple of hours now, but I’ll be back later. <quiliro>rekado: what you have told me...just that it take long for me <quiliro>would someone please tell me how check the hash of a file? <rekado>quiliro: did you create a new package definition already? <quiliro>i was reading what you told me...did not create it yet <quiliro>i did not understand what you suggested to do <rekado>have you looked at the install.html yet? <quiliro>rekado: i did not find relation of what you asked me to read with what you suggested <rekado>for any package you first need to figure out how to build it. <rekado>the install.html tells us that we need to “cd Qt4Qt5”, then “qmake”, then “make”, then “make install”. <rekado>the last two steps are the “build” and “install” phases of the gnu-build-system. <rekado>we can add the other two steps with “modify-phases” <rekado>and then create a new definition for qscintilla <rekado>i.e. (define-public qscintilla …) <rekado>use the gnu-build-system and add a native-inputs field like this: (native-inputs `(("qtbase" ,qtbase))) <rekado>we need qtbase for the “qmake” tool, which we are supposed to execute. <rekado>when you’re done with that let me know and we’ll work on the extra build phases. <quiliro>rekado: do you think all the file will fit in a paste? <rekado>you could just paste the output of “git diff” <rekado>try “git diff” first and make sure that it only prints your changes <rekado>otherwise try “git diff gnu/packages/qt.scm” <quiliro>rekado: WARNING: terminal is not fully functional <quiliro>i have to press q to go back to the console <rekado>yes, that’s whta “git diff” does. <rekado>if you’re in M-x shell you can set the PAGER environment variable to “cat” <rekado>because Emacs would be your pager in that case <quiliro>it looks very simple but it was a learning experience for me....especially in the use of emacs! <quiliro>and of course in the construction of guix packages <adfeno>quiliro: I'm glad you enjoyed it :) <rekado>quiliro: you’re missing the build-system field <adfeno>If qscintilla has a "Makefile" inside the directory, it might be the GNU build system. <rekado>it does not, but it will after “qmake” <adfeno>rekado: What do you mean? Do you mean that: only after qmake there will be a Makefile? <rekado>quiliro: next step is to do as the documentation says and first enter the directory, then run qmake <rekado>we do this by changing the standard build phases of the gnu-build-system <rekado>quiliro: in qt.scm take a look at the “qwt” package. <adfeno>quiliro: "by changing the standard phases" we mean to do something similar to what is done in the openmolar package that you were making. <rekado>the value of the “arguments” field is a quoted list of things that we pass to the build system to change its behaviour. <rekado>in “qwt” the arguments list consists of the #:phases keyword followed by a new list of phases. <rekado>the new list of phases is the result of modifying %standard-phases <rekado>%standard-phases is a list of build phases, such as “unpack”, “configure”, “build”, “install”, and so on. <rekado>quiliro: while you are in a Scheme buffer hit C-c C-z to switch to geiser <rekado>then type ,use (guix build gnu-build-system) <rekado>this will show you the value of that variable. <rekado>you’ll see that this is just an association list (alist) of phase names like “unpack” and procedures <jsierles>civodul`: sorry I wasn't clear earlier. On my substitute server, the daemon is building using a specific guix git revision <rekado>to enter the directory and run qmake we need to add a new phase. <jsierles>so I have 'guix-latest' in the store. can i somehow archive this so I can use that version of guix on another machine? <quiliro>rekado: it makes sense...but on theory...i will try...some things i do not know how to do.... yet <rekado>quiliro: that’s okay. We’ll do this together. <rekado>here’s the default: (arguments '(#:phases %standard-phases)) <rekado>this means: for the selected build system use the standard phases as the build phases. <rekado>to change the build phases we can use the “modify-phases” syntax <adfeno>quiliro: rekado gave us an important example: the qwt package in "gnu/packages/qt.scm" :) <rekado>(modify-phases %standard-phases (replace 'configure (lambda _ (zero? (system* "qmake"))))) <rekado>this means: take the phases from %standard-phases and replace the phase “configure” with a new procedure <rekado>that new procedure runs “qmake” and returns #t (true) if it returned no error, otherwise #f (false). <rekado>this will not be enough in this case, though. <rekado>before we run “qmake” we need to enter the Qt4Qt5 directory <rekado>there’s a Scheme procedure to make that happen: “chdir” takes a string of a directory name and changes the current directory. <rekado>quiliro: are these hints enough? Would you like to give it a try? <rekado>it should be part of the build phase <quiliro>rekado: and what would its syntax be? <rekado>(getcwd) returns the current directory <rekado>play around with chdir and see if that changes what “getcwd” tells you <rekado>if that doesn’t work maybe you haven’t set up Geiser yet <rekado>in that case you can just run “guile” in M-x shell <quiliro>(chdir "/home/quiliro/QScintilla_gpl-2.10.1/Qt4Qt5/") <quiliro>$3 = "/home/quiliro/QScintilla_gpl-2.10.1/Qt4Qt5" <quiliro>learning scheme is just repeating bash <rekado>okay, so you now know how to use it <rekado>the documentation says to first enter Qt4Qt5 and then run qmake <rekado>so just place the chdir call before the (zero? …) call. <rekado>also, note that “/home/quiliro” won’t exist. <rekado>you only need to give it the last directory part. <jsierles>guix export seems to work with the latest guix derivation. so the question is how to determine which packages it depends on. <jsierles>ideal flow would be: update guix on server, archive the derivation and a manifest with its dependencies. download and install locally, and set the ~/.config/guix/latest link. any reason this wouldn't work? <quiliro>rekado: when i first entered guile, i got: <quiliro>$2 = "/home/quiliro/guix/gnu/packages" <quiliro>but i do not understand what we are doing this for...i thought we had to do it in qt.scm <adfeno>quiliro: rekado Just suggested you to open the Geiser/Guile console and test (getcwd) and (chdir ...) so that you could get used to what would have to be done in the .scm file. <quiliro>(arguments `(#:phases (modify-phases %standard-phases (replace 'configure (lambda _ (chdir "Qt4Qt5") (zero? (system* "qmake")))))) <rekado>(though a closing “)” is missing) <quiliro> (native-inputs `(("qtbase" ,qtbase))) <rekado>I normally put the arguments field after the “build-system” field, but that has no impact on behaviour. <rekado>I guess you can try to build it now. <rekado>./pre-inst-env guix build qscintilla <rekado>I think you’ll need “2>&1” to redirect the error output to stdout. <adfeno>"2>&1" like so: ./pre-inst-env guix build qscintilla 2>&1 | <rekado>you can check this yourself with M-x eww <rekado>it may be better to do this in two steps <adfeno>quiliro: Remove the quote before 2 <rekado>that’s because in qt.scm we use a prefix for all values from the license module <rekado>so replace ‘gpl3’ with ‘license:gpl3’ <rekado>(it’s possible that this really should be license:gpl3+, but we’ll check this later again) <quiliro>guix build: error: qscintilla: unknown package <rekado>there’s got to be another error that you aren’t showing us <quiliro>;;; note: source file /home/quiliro/guix/gnu/packages/irc.scm <quiliro>;;; newer than compiled /run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/irc.go <rekado>this just means that you didn’t run ‘make’ to compile your Guix checkout from git. <adfeno>If I'm not mistaken, the (define-publich qscintilla ...) is right, however, the (name ...) inside isn't. <rekado>I remember that you ran ‘bootstrap’ more than once. <rekado>that will create a new configure script and reconfiguring may force rebuilding of more sources than you should. <quiliro>guix build: error: build failed: build of `/gnu/store/lidv0sq5k2n1ff83ykjrklpph00pppyl-qscintilla-2.10.1.drv' failed <adfeno>quiliro: What precedes this one? <rekado>is that really where the sources come from? <rekado>yeah, it’s trying other locations <rekado>but the first of these errors should worry you more <rekado>double check the URL for the tarball. <quiliro>i get a lot of permission denied error <quiliro>Error copying libqscintilla2_qt5.so.13.0.0 to /gnu/store/6wmrf9c7rpv2c8q02vxvv1frsmljr5lh-qtbase-5.9.1/lib/libqscintilla2_qt5.so.13.0.0: Cannot create /gnu/store/6wmrf9c7rpv2c8q02vxvv1frsmljr5lh-qtbase-5.9.1/lib/libqscintilla2_qt5.so.13.0.0 for output <quiliro>/gnu/store/6wmrf9c7rpv2c8q02vxvv1frsmljr5lh-qtbase-5.9.1/lib/ exists <rekado>quiliro: this probably requires patching. The package tries to install the finished binaries into the qtbase output directory. <rekado>but it should install into its own directory <rekado>it might be easiest to do this after running ‘qmake’ <rekado>there could be another build phase that patches the generated Makefile <rekado>but I can’t help with this now; too late :) <adfeno>quiliro: I think that variables like "dir", "path", "directory", "folder", "prefix" (or any match *similar* to those) should be carefully studied. <adfeno>I think that the qwt package in "gnu/packages/qt.scm" can provide some example. <quiliro>adfeno: where do i search for those? in qscintilla source code? <adfeno>quiliro: Yes, that would be agood place to start, but Guix has something that facilitates this: look for the --keep-failed option. <adfeno>After the error it will tell you that it kept garbage in "/tmp"[something else]. <adfeno>Oh... eh... I mean --keep-failed in the GNU Guix build options. <quiliro>i will return in 1 or 2 days after doing my guix homework ;-) <quiliro>oh....by the way, how can i configure my keyboard? instructions on the manual do not work <adfeno>quiliro: Don't worry, even I have guix homework to do sometimes, this is why I don't exitate to send my packages and questions to the guix development mailing list :) <quiliro>i cannot configure my mail client (gnus) yet <adfeno>About keyboard: I wonder if some GuixSD user can help us on this one. :) <quiliro>loadkeys /gnu/store/6a3yahf1116qm2rgxwf5ww1crz7c2xhs-kbd-2.0.4/share/keymaps/i386/dvorak/dvorak-es <adfeno>I think there is a "${HOME}/.profile" variable missing.