<danielszmulewicz>alezost: I will tomorrow. I'll compile all the gotchas I've encountered and will report. <danielszmulewicz>I've written a hello world module. Put it in a directory under the GUIX_PACKAGE_PATH. Now I would like to open it and establish a connection with geiser so that I can evaluate stuff in the REPL. <alezost>danielszmulewicz: while working with a package file you need to use various modules which you put in a '(define-module ...)'. You can evaluate this clause to make these modules available, but it's likely that guix modules are not available for you right now. Try to evaluate this in the geiser repl: ",use (guix packages)". Do you have "no code for module (guix packages)"? <NiAsterisk>./pre-inst-env guix environment + what appended is the best way to test a package build in a clean environment to get all direct dependencies to build again and see what's being linked etc and check functionality of a graphical application and daemon (gnunet-arm, gnunet-gtk) later on? I might have fixed it, but I can't be sure because I have like 10 15 or more build dirs of gnunet* <alezost>danielszmulewicz: how did you install guix? <detrout>Is there anything like GUIX_PACKAGE_PATH for the emacs M-x guix-all-available-packages? <lfam>NiAsterisk: `guix environment` shouldn't have any effect on `guix build`. If you want to test the execution of the program provided by package foo in an isolated environment, you could use `guix environment --ad-hoc foo -- foo` <lfam>With either --pure or --container <alezost>detrout: emacs commands respect GUIX_PACKAGE_PATH, so a list of packages should also contains your packages from GUIX_PACKAGE_PATH <lfam>Sorry I forgot to mention pure and container. container is better but pure is worthwhile if you can't use containers forsome reason <NiAsterisk>and if it's in the working branch of a git, ./pre-inst-env obviously. <danielszmulewicz>alezost: I've installed a binary tarball on top a debian distro according to instructions. <detrout>alezost: Thank you, apparently I forgot to set _PATH in the shell I launched emacs in <NiAsterisk>well.. not exactly what I wanted with container: (gnunet-gtk:2): Gtk-WARNING **: cannot open display: <alezost>danielszmulewicz: ah, ok to make guix modules available you need to set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly. I can think only of one way to do it: by installing guile and guix into your user profile (with "guix package -i guile guix"). Then you can source ~/.guix-profile/etc/profile which will contain all required environment <detrout>well my packages show up in the list. I haven't tried installing one through emacs yet <alezost>great, there should be no difference between your and guix packages <alezost>danielszmulewicz: btw did you run "guix pull" after installing? <detrout>Is there a way to see what the guix-daemon's job list is? <alezost>danielszmulewicz: great, otherwise you would end up building old versions of packages. I think recently the manual was improved to recommend "guix pull" <alezost>also you will probably have to use --no-grafts option for "guix package -i" command: there is a problem in the current master (not sure if it is fixed already) that may lead to building perl if this option is not specified <alezost>danielszmulewicz: sorry for breaking the conversation, I really have to sleep :-) <NiAsterisk>BÄM! i think i fixed gnunet-gtk to some degree.. i have not run gnunet-arm , but it's more fixed than the state ricado described on gnunet-dev <NiAsterisk>goodnight. hope my patch fixes at least part of the problem with gnunet, I want to get it completely fixed and then get gnunet-svn / gnunet-gtk-svn in, because 0.10.1 is old. <lfam>danielszmulewicz, alezost: If you use --no-grafts, my understanding is that you will not receive a very important OpenSSL security update, as well as a Perl security update. <Jookia>"In procedure open-file: No such file or directory: "/gnu/store/krz1qv98s4nvlq9zihzzpcgc6qkyv4sl-shepherd-tor.scm"" ? <mark_weaver>Jookia: I got an error like that once when reconfiguring. if that's when it happened for you, I guess it's a problem with the new code that means to restart existing services without rebooting. <mark_weaver>Jookia: it might be that tor-service is already running, or else you might need to reboot <mark_weaver>Jookia: maybe it wasn't fixed adequately, so maybe better to email 22753@debbugs.gnu.org to add to that existing report, if you think it's similar enough. <Jookia>i'm running an old guix so i may have missed the fix, i'll check <Jookia>mark_weaver: Yeah, I don't have that bugfix commit in yet <mark_weaver>anyway, even with that bug, you should be able to reboot and things should work <mark_weaver>the bug only affected the live-updating of services, iiuc <Jookia>Yeah, I rebooted and it worked :) <Jookia>In the meanwhile I'll fix my coreboot patches since I found a bug then if I have time, mess around to see if I can add an EFI platform ***fkz is now known as Guest76362
<lfam>I just sent a couple patches for xfce4 power management to the list, if anybody wants to test them.jk <lfam>I didn't mean to write 'jk' <robsyme>Hi all. When guix calculates the hash that is used to give the package's path in /gnu/store, what is provided as input to the hashing function? Is it the binary files of the dependencies/inputs, or some description of the package (such as the package definition, with inputs replaced by their hash values)? <robsyme>oops. Ignore that last (htop) message, sorry. <mark_weaver>robsyme: the hash is based on the description of the package, specifically the *.drv file <mark_weaver>all of the output path names can be computed before building any package <robsyme>mark_weaver: Thanks! That makes sense. <mark_weaver>the description of a package includes the descriptions of the inputs, transitively, all the way down to the bootstrap binaries <mark_weaver>it *does* depend on the hashes of those bootstrap binaries <mark_weaver>and also, of course, on the hashes of all other raw inputs such as downloaded sources <robsyme>mark_weaver: The hashed description of inputs - are they included recursively like a Merkle Tree? <robsyme>mark_weather: or are they explicitly included when the hash is calculated? <mark_weaver>robsyme: I don't know that level of detail of hand. civodul would know, or you could look it up in the Nix thesis. <mark_weaver>but *.drv files are just text files, and if you look, you'll see that they include references to *.drv files, whose names include the hash <robsyme>mark_weaver: That probably answers it then. <mark_weaver>robsyme: note that the inputs don't form a tree, but rather a dag <mark_weaver>treating it as a tree leads to massive duplication, and real performance problems in practice <robsyme>mark_weaver: OK. Merkle DAGs are everywhere these days. <robsyme>I'm looking to try my hand at writing package definitions. I wrote a fairly simple one: https://gist.github.com/robsyme/ac4888b34f84396eaf98, adding the file to a directory in GUIX_PACKAGE_PATH. When I run 'guix package -s codingquarry', it returns the error: "custom.scm:9:2: warning: extraneous field initializers (synposis)". Any pointers in the right direction would certainly be appreciated. <marusich>robsyme, I think you've misspelled "synopsis". <marusich>Sometimes it takes a second pair of eyes to notice these things. ***Digit is now known as digitteknohippie
<JeanLouis>anyone knows how to use mcron (with-mail-out action . user) - to get emails sent from mcron ***fps_ is now known as fps
<wingo>guix package -u went fine, but for some reason guix system reconfigure is building perl. weird. <alezost>wingo: other people (including me) experience the same (building perl). --no-grafts should help <Jookia>ok i think my libreboot patches are ready to be tested, i'ma upload it <rekado>wingo: there seems to be a problem with hydra. <rekado>on guix-sysadmin a solution is being discussed. <wingo>so many guix mailing lists now :) <alezost>but as lfam pointed with --no-grafts an OpenSSL security update will be missing :-( <efraim>wait, there's a guix-sysadmin ML too? <efraim>I still need to check jasper to see if it's vulnerable <rekado>the sysadmin ml is an internal one for sysadmins working on hydra. <wingo>for me building with --no-substitutes seems to be fine <civodul>a perl build a day keeps the doctor away <civodul>things like 'guix package -u' should be noticeably less slow now <civodul>there's still room for improvement, because the grafting stuff is quite challenging <Jookia>I wonder why my package won't run ./configure <civodul>wingo: could you move the elogind tarball to the elogind/ subdir on wingolog.org? :-) <wingo>civodul: done about 5 minutes before you asked :) <wingo>ok it's wingo-idle-wishlist time. wouldn't it be AWESOME if you could "guix hack foo" and it would check out the source for foo, put you in an appropriate environment, and then any edits you make to the source get collected into a patch? <civodul>bonus points if it puts a recipe for the patched thing in $GUIX_PACKAGE_PATH <wingo>i think ideally (?) it integrates with git <civodul>super bonus points at this point ;-) <wingo>if the upstream source is not git, then it does a git init and adds everything <wingo>in that way you can control your patches more <civodul>i think it could potentially make it much easier to contribute code, or at least to try out changes <wingo>yeah. and if git-send-email works, that could solve the patch submission problem <Jookia>I wrote my own mail tools in part to make it so I could just drop some patch files in a directory and send them off <df_>this leads me to a question about guix environment in general - is one expected to start a new emacs instance in the new environment? <df_>because depending on what you're hacking and how it seems like that might be necessary <civodul>df_: to make things nicer, i think we'd need an environment-aware M-x compile <Jookia>Why is it that the builder can't edit the build directory? <Jookia>I went to a broken build that was having permission errors, guix environment --container'd my way in and tried to run the script in general, and it failed to write to the build directory. I can't write 'touch 1' either, it fails <roelj>Can I disable parallelized make jobs in a package description? <Jookia>roelj: Did you try #:parallel-build? <roelj>Jookia: No, thanks. Now I know what to look for <efraim>I'm working on the jasper security fixes now <efraim>if anyone else was looking at it <civodul>Jookia: the build tree after --keep-failed is owned by root <Jookia>Ah, I see. That doesn't help me figure out why I have permission denied issues in the build :( <Jookia>If I don't run that pogen.sh, I also later get "bin/msgmerge: cannot create output file "de.po": Permission denied" <Jookia>Running it in a container after copying source files, I can't reproduce it <Jookia>I'll wait until someone updates the package and see how they fix it <efraim>ok, pushed the CVE update with jasper, now working on python2-tempest-lib <efraim>although since my wife is out for the next few hours now would be a good time to set up my pentium4 with guixsd <roelj>If something links to libgcc_s.so.1, should I use gcc as a propagated input? <rekado>roelj: no, you just need to make sure that the linker flags set the RUNPATH properly. <roelj>rekado: Ok, of course :) Is libgcc_s always there like libm? <roelj>rekado: Have you looked at icedtea8? Otherwise I'm going to attempt to add it. <civodul>roelj: gcc itself is patched to make sure libgcc_s is always in the RUNPATH, see (gnu packages gcc) <roelj>civodul: What is libgcc_s exactly? <JeanLouis>I wonder why so many GNU packages are not included in Debian? Is there animosity to GNU from Debian community? <ringst>They're the largest distro that calls itself GNU/Linux, so I don't think there's animosity <ringst>It might just be that there's not enough interest in those packages <ringst>Also one of the few distros with a HURD version <JeanLouis>ringst: I have open Emacs from Debian, it said something like license cannot be displayed in editor, as it is against Debian guidelines. Deleted, and installed emacs from GNU. <ringst>You can add the non-free repository and install a package for it, I think <JeanLouis>ringst: gurgle for example is reporting tool for databases, not in Debian. <JeanLouis>ringst: why I would add "non-free", that is exactly the reason why I wish to use Guix. <ringst>Because Emacs' manual doesn't allow modification of some parts, making it non-free according to Debian <JeanLouis>it sounds strange that most free software is being advertised as non-free, right? <ringst>The documentation is being advertised as non-free <ringst>Because the documentation arguably is <ringst>The FSF doesn't apply the same standards to documentation and software, Debian does <Jookia>It might be worth labeling documentation and non-software licenses too <ringst>The GNU Free Documentation License optionally allows non-variant parts <ringst>Non-variant parts are parts that you're not allowed to modify <ringst>The Emacs documentation uses that <Jookia>I'd certainly like to filter out documentation/images/non-software items that I can't modify <civodul>i wouldn't call it "stricter" since it allows the "non-free" repository add-on and used to allow non-free firmware <ringst>contrib and non-free don't adhere to the DFSG <Jookia>True, but it's also stricter in that it disallows things Guix allows <ringst>You can judge Debian as a whole by them, but not the DFSG <JeanLouis>civodul: yes I know that. That is why I use GNU, I am not using it because it is free of charge, but free to learn, distribute, and preserve freedom for future. <Jookia>Perhaps if documentation gets split out it could be individually licensed <ringst>I think the GFDL doesn't allow removing invariant parts <Jookia>This has been a talked about subject for a long time <Jookia>GFDL won't be useful for full modification, the best thing to do is just let people uninstall documentation but that'd require more work <JeanLouis>Jookia: I will simply uninstall Debian, I guess <ringst>Keeping packages you consider non-free out even with the non-free repository enabled is easy <ringst>And you can install Guix on Debian <JeanLouis>ringst: if I put "non-free" I am offered non-free software through apt-cache search. I am not running "non free" software. That was my main reason to use Debian in the first place. But now I see what I have missed. <lfam>efraim: Thanks for adding the Jasper patches <JeanLouis>basically, because of GNU Manifesto, there is free software, but as it cannot be "modified" in Emacs, Debian is excluding licenses from Emacs editor and putting it in non-free section, thus harming all users and instructing them to install other non-free software in that manner. What a nonsense. <rain1>wow that's so strange to learn that the GNU free documentation license does not allow modifications... <Jookia>rain1: it does! but not in certain sections <Jookia>FWIW a lot of programs don't use these sections, like Guix <JeanLouis>rain1: I don't know why such personal matter like GNU Manifesto shall be modified. <ringst>They want to have a consistent policy <ringst>A consistent policy that allows modification for all of the things they package in the main repository <Jookia>IIRC the biggest problem was that they didn't want to get in to the debate on what 'software' is in their definition <Jookia>They don't have a distinction between 'software', 'practical works' and 'works for aesthetic use' <JeanLouis>rain1: I guess most important one, and many are not aware of it. <rain1>JeanLouis, yeah I had no idea about this until I checked the logs here today <rain1>It's always been that you can't edit the license of a piece of software <rain1>this could be seen as an extension of that <Jookia>You can't edit the license, but the license governs what you can edit <Jookia>So if I put a work in GFDL I can allow some sections (they have to be of certain types and not the main subject) to be unmodifiable and unremovable <rain1>about unremovable: It's always still possible to distribute the software without any documentation? <rain1>or even with entirely new written docs <rain1>I would quite like to change the pari gp package to have two outputs <rain1>because if i just want a calculator texlive is a lot to install <rain1>I made a gp no-docs package but I didn't try to make a 2-output version <JeanLouis>I see it like this: for sake of freedom, people using Debian Emacs get it hard to learn about GNU Manifesto and why they have Debian at all. <ringst>The licensing terms of the GNU manifesto don't exactly embody that freedom <ringst>Do you want them to send a message "You can modify everything, except this thing about freedom, because that one's special"? <rain1>we would have to get RMS to change it to say that right? <JeanLouis>it reminds me of: (future-freedom (freedom? (remove future-freedom)) <rain1>or maybe the new current emacs maintainer <Jookia>I think regardless of what we all think about it (and believe me, I'm strongly anti-unmodifiable parts) it's not productive to have a discussion about it without offering 'solutions'. I think the best way would be to accurately split and license parts of things, including video games for instance <rain1>Jookia, yeah mostly I was just learning about this new issue - I packaged a very nice GPL3 game but the levels sets are all a variety of very ad-hoc non-licenses.. I should really split it into two separate parts <Jookia>rain1: You could package commercially free but non-derivative stuff (so people can put it on CDs) <Jookia>rain1: I saw a level set that allowed this for TIles World <Jookia>JeanLouis: Again, this is a Debian issue <JeanLouis>it is issue of anyone promoting free software. Large user base with Debian uses non-free because it is offered and referenced as such. Guix is solution for future freedom. <rain1>JeanLouis, I agree - don't like this. If I had any power in debian community I would suggest that they make a special repo for gnu free documentation. <Jookia>#debian@irc.oftc.net is a good channel methinks <rain1>maybe it would be worth asking guix mailing list or something how guix will handle this issue? I am pretty sure guix will include docs under GFDL with no trouble <JeanLouis>I hope so, it is using GNU directly from savannah <Jookia>FWIW I'd like it to be split so I can remove it <rain1>so you don't agree with GFDL? <rain1>I can sort of understand it (but I think I wouldn't use it for my own things..), and to me software is the really important thing - it's very surprising <Jookia>Eh, it's very hard to pin down why software should be free but not other content <phant0mas>hey guys can you access the repo? I am getting "fatal: Could not read from remote repository." <JeanLouis>I don't care if that piece of text is removed -- but I do care if it is replaced with non-freedom references, such as "install from non-free". They could put a link to it, or anything, or completely remove the option. Right? But no, there was intention to point to non-free. <Jookia>JeanLouis: Ironically the text they put up is free to modify, so you can change that ;) <ringst>Would you rather have them not package it at all? <ringst>Or package it, but keep it a secret? <JeanLouis>Jookia: I cannot change the impact on thousands of people. <Jookia>JeanLouis: I feel like this is misplaced <rain1>Have you tried talking to any debian folk about it? <rain1>I think they wont listen but maybe it's worth a try <rain1>phant0mas, yeah i just did a sucessful git pull <rain1>of git://git.sv.gnu.org/guix.git <phant0mas>maybe something is wrong with my network here <JeanLouis>rain1: no, that's why I am here, to remove Debian. <Jookia>JeanLouis: maybe it's time to move on from debian and not worry about it <rain1>oh you're stopping using debian? <JeanLouis>I was thinking this channel is for Guix distribution, but now, maybe it is just for package manager <JeanLouis>rain1: absolutely, pointers to non-free software, don't contribute to free software <rain1>JeanLouis, I did the same when the systemd thing happened <rain1>+ I'm using guix right now it's great :) <JeanLouis>I don't know about systemd, I could switch without problems. <rain1>systemd is fine, but not the way they treated people <JeanLouis>rain1: so you installed guix, and use only guix? <rain1>hmm it's a bit off topic but PM me if you like to continue about it :) <JeanLouis>rain1: thanks, you installed guix? Like from CD/USB? <rain1>I don't think there is any CD <JeanLouis>aha yes. Do you think I can try first switching to linux libre kernel on Debian? I have sources.list already, but I am hesitant... <JeanLouis>I feel that I need to make list of required software, and simply switch to Guix -- I like the GNU + Guile approach very much. <JeanLouis>[ 12.023562] iwlwifi 0000:03:00.0: firmware: direct-loading firmware iwlwifi-6000g2b-6.ucode <JeanLouis>I am worried, my network card is maybe using non-free software.... <JeanLouis>update-grub: Found linux image: /boot/vmlinuz-4.4.4-gnu, let me reboot to see if it works ***thetan is now known as JeanLouis
<JeanLouis>linux libre, I wish to run it with iwlwifi without proprietary firmware <civodul>JeanLouis: sadly there's no free firmware for Intel's wifi devices AFAIK <civodul>i recommend getting on of those RYF-stamped, Atheros-based devices <JeanLouis>Jookia: thanks. civodul: you suggest me to change to different device? Yes, I will do that, but not today. <ringst>JeanLouis: Debian doesn't package Linux-libre, but it doesn't need to <ringst>I don't know about any important differences with linux-libre <Jookia>ringst: linux-libre won't load nonfree firmware even if it's installed <JeanLouis>ringst: yes, but I am on #guix channel, I want to run wifi with free software <ringst>Switching to Linux-libre won't help you running wifi with free software <Jookia>JeanLouis: replace your wifi card or buy a USB adapter <ringst>Debian sans blobs has the same hardware support as Linux-libre <ringst>As long as you use the same version <rain1>I am using wired connection with guix <JeanLouis>aha wired connection yes, sure. I will re-install my laptop and change for one which does work with free software. <ringst>The easiest solutions are a wired connection or a usb dongle <JeanLouis>maybe for you, it will not run on my laptop, I need iwlwifi non-free software <Jookia>JeanLouis: No free distros will work on your laptop <JeanLouis>they will work, I just need to uninstall laptop <ringst>There is no free version of that driver <davexunit>my thinkpad x220 came with a problematic intel wireless mini PCI-e chip. I flashed a hacked version of the proprietary BIOS onto it to enable replacing it with an Atheros chip. <ringst>Not on Debian, not on GuixSD, not on Trisquel, not on Linux-libre <davexunit>the less elegant approach is to leave the chip in but use a small USB wireless adapter. <JeanLouis>and we were speaking here of free software in Debian and how they thought GNU Manufst is not enough free, so they removed it. But Intel firmware is what? Free enough to be included in Debian... <davexunit>I got lucky many years ago when I switched to GNU/Linux. I had a cheap Compaq laptop that just happened to use an Atheros wireless chip. <Jookia>JeanLouis: If you think nonfree isn't part of Debian, then Intel firmware isn't part of debian <davexunit>JeanLouis: Debian has a non-free repo for proprietary things. <Jookia>JeanLouis: If you think nonfree is part of Debian, then the GNU Manifesto is part of Debian <davexunit>yeah, this package is specifically in the non-free repo. <ringst>That's in the same part of the repository as the Emacs documentation <JeanLouis>See you later, I go to see if I can buy USB wireless in this city in Eastern Europe. I don't need non-free firmware in my "free" system. <Jookia>JeanLouis: Make sure you find a USB wireless that doesn't use nonfree drivers <myglc2>I hate to put 'SHELL = /run/current-system/profile/bin/bash' at the top of a makefile that I also use on non-guix systems. Is there a portable solution? <Jookia>Use autotools to configure the makefile <davexunit>ringst: for maximum portability, you should never assume the absolute paths of any executable program. <davexunit>a good build system will probe for their locations before compilation. <myglc2>Agreed, but these are just little makefiles I use in everyday life. autotools seems like overkill. <myglc2>all makefiles are happy makefiles <Jookia>or allow setting it by env vars, who knows <rain1>maybe you could amke two makefiles <rain1>makefile.guix and makefile.debian <myglc2>Yikes! I think I will just put a stupid conditional in the makefile <myglc2>OK, now I need to know the reco way to test if we are running on GuixSD? <JeanLouis>Jookia: I could not choose, there is only one USB in the town, so I have to gamble on it <JeanLouis>Product: 802.11 n WLAN -- but how do I find now how to enable it? <rain1>to try guix out before getting a usb <Jookia>JeanLouis: What's the exact model? <JeanLouis>Ralink Technology, Corp. MT7601U Wireless Adapter -- searching if there is anything <NiAsterisk>JeanLouis: if you can get "TP-Link TL-WN722N" those work, for others there's also hnode.org (or was it h-node.org) <davexunit>JeanLouis: Atheros chips are *the* chips that are known to work well. <myglc2>JeanLouis: do you already have Guix installed? <JeanLouis>I am in city in Bosnia -- this means, limited access to hardware. One store had 1 adapter only. One piece. Last. I will see other stores if this one does not work <JeanLouis>OK I will walk again to stores... to find USB WIFI thing <ringst>That way you can check in advance <rain1>JeanLouis, oh no. did you lose important data? <ringst>I think it just unmounted, so no data loss <JeanLouis>Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter - it seems I do have wlan1 but firmware: failed to load rtlwifi/rtl8188eufw.bin <myglc2>So I put this at the top of my cheesy little makefile: <myglc2>ifeq "$(findstring -gnu,$(shell uname -r))" "-gnu" <myglc2> SHELL = /run/current-system/profile/bin/bash <Jookia>that will also break linux-libre <ringst>If you really want to keep it inside the makefile, it would make more sense to check if /bin/bash exists <ringst>And if it doesn't, to check if /run/current-system/profile/bin/bash exists <myglc2>OK thanks, that does sound better. Just for context, these are makefiles I would never give to another person w/o improvement. <Jookia>i dont see whats so hard about having environmental variables that configure your source code when building <myglc2>Jookie: just not a fan of environmental variables <mthl>civodul: we will need to discuss about GSoC soon <myglc2>Jookia: Thanks, I made a note to learn autoconf soon <myglc2>How about SHELL := $(wildcard /run/current-system/profile/bin/bash /bin/bash) <Jookia>i also have no idea why you don't just run $(which bash) ? <JeanLouis>I have got: Realtek Semiconductor Corp. RTS5139 Card Reader Controller -- ath9k_htc: Firmware htc_9271.fw requested, registered new interface driver ath9k_htc <myglc2>Jookia: Possible rationale: $(shell which bash) spawns a shell whereas $(wildcard) is built-in <myglc2>^ oops, sorry, typed in the wrong spot <rekado>roelj: I have a package for icedtea8 <rekado>but icedtea8 hasn't been released yet <janneke>can i check `why' a certain package gets rebuilt? <JeanLouis>running kernel: Linux libre without non-free firmware on TP Link TL-WN722N <JeanLouis>now only to uninstall BIOS and replace with free one... <janneke>i run guix publish and use substitutes from another machine <avoine>JeanLouis: you should have a predictable interface name instead of wlan0 <roelj>rekado: Could you share your icedtea8 package? I want to test it :) <davexunit>janneke: the "why" would be the derivations that have to be built. <avoine>not the systemd one but like that <janneke>davexunit: okay...but those hashes do not mean much to me? <janneke>i have same guix version, pointing to same git checkout <janneke>how to start finding out what's different? <davexunit>janneke: it means that the build outputs of those derivations are *not* available on the server you run 'guix publish' on. <janneke>davexunit: yes, i understand that... <JeanLouis>avoine: first no wlan1, but I went out and bought the 3rd wireless adapter on USB, and now it works. Third time the luck, we say. <davexunit>you could be running the same version of guix, but that doesn't matter if you haven't performed the relevant builds on the 'guix publish' machine. <davexunit>so let's first verify that you've done that. <janneke>what i do not understand is why derivatives/hashes turn out differently <avoine>JeanLouis: I had to do the same thing <avoine>JeanLouis: I tought you were on guix <janneke>davexunit: i'm saying: guix environment guix --ad-hoc git guix emacs <rekado>roelj: the URL you posted is for downloading the drops <janneke>on the publish machine: no rebuilds, on the other machine it starts building gdk-pixbuf and what not <JeanLouis>avoine: without adapter, I could not run Linux libre kernel <rekado>it's probably a little stale already. <rekado>may need to update it to latest master. <NiAsterisk>I posted a patch yesterday regarding gnunet-gtk, but there has to be some discussion about it, see reply 1 and 2 in the thread by Jookia and myself. <JeanLouis>NiAsterisk: absolutely, I want. But before I make configurations as I am 3rd day on guile, (made 4 scripts), I like to install from source, that will work? <NiAsterisk>so you meant if you can install software which is not in the source tree? <Jookia>you have to package it to install it <JeanLouis>because I see much of changes to what I was used <Jookia>Though I suppose you could always build it in an environment and use it in there <Jookia>You'd have to patch shebangs too <Jookia>JeanLouis: Guix packaging is very easy compared to other distros <Jookia>'make install' won't work in Guix for a lot of reasons <JeanLouis>I mean can I compile program and install? Should be possible, without packaging? <JeanLouis>ok, and how do I install Perl modules for example? <rain1>it would be a shame if you can't use CPAN <Jookia>You could probably use CPAN/Cabal/npm/insertotherpackagemanager <Jookia>But why would you when Guix is so homely? ;) <JeanLouis>Jookia: please help me where to look for what? <rain1>I maybe try it at some point <NiAsterisk>always extending list of import functionalities for packaging :) <Jookia>JeanLouis: I'm not exactly sure what you want, friend. Sadly I have to go and I won't be on much tomorrow, otherwise I'd help you <rain1>so ican easily make a guix package from cpan packages! <Jookia>rain1: Yes. Never leave Guix. Ever. <rain1>there was a big security issue with npm recently <JeanLouis>Jookia: please point to me reference why not leave guix? For stability? For integrity? Why? <NiAsterisk>JeanLouis: you might want to watch the talks from fosdem 2016 :) <JeanLouis>sure I want to watch, I have seen some slides, but rather I read it <Jookia>JeanLouis: For the sake of specifying your dependencies accurately, so stability and integrity. Ever update your system on Arch and have it break your installed Haskell programs? Me too. Guix dependencies allow multiple package versions to be installed at once <JeanLouis>Jookia: I never used Arch, and Debian is stable in that regards, normally packages are not broken. I see the point with all the node modules, and pip, cpan, it becomes all mess. <Jookia>Arch once updated from Python2->Python3 and broke everything <Jookia>Fantastic but also bad because all your scripts broke <Jookia>The least you can do with Guix is set up an environment of packages that you can use for your development and use something like CPAN on top of it <JeanLouis>Jookia: absolutely, I agree. I am now using GNU SRC in similar manner like Guix. I have separate environment for GNU programs and I like it. <JeanLouis>not separate by version I guess, but for me as user, it is separate from Debian. <Jookia>Guix has a 'guix import' command that can do that I think <NiAsterisk>hm.. one aspect I like: debian can be affected by breakage with packages which bring in other package managers and you rely on the phase of the moon to hope your server application still runs when you installed it. with guix you can replicate why it broke and help. (gentoo same, even worse for picking solutions, it's not only the moon, it's the food your cat gets, number of jumping unicorns, moon, and which <NiAsterisk>like, what mediagoblin is currently to solve by getting into guix packages. <Jookia>Reproducible environment horror stories <JeanLouis>so I cannot even test/use guix package manager to prepare packages, before I switch <NiAsterisk>only problem (and potential), guix is just starting and people can shape and contribute to its form :) <Jookia>JeanLouis: That's such a strange issue, I dunno how to help. Others probably can <Jookia>JeanLouis: You should try to reproduce it in a Live CD somehow <JeanLouis>I have reproduced it and can now reproduce it <JeanLouis>once it happens, the system is unmounted, X breaks (files missing, probabl Xauthority, etc) and I cannot even report or save what happened <rekado>that's a very odd issue and I have never seen it before <Jookia>Could you try recreating a system in QEMU with Debian in it inside that does the same problem <Jookia>Then you can upload the image and people can utest it <rekado>could you give us more information about your system? <Jookia>It's a lot of work but it'd *really* help <JeanLouis>Jookia: too complicated for me, I never used QEMU <rekado>are you using Guix on top of some other system? <Jookia>I have a bad feeling it's to do with the filesystem override that's being done since you're mounting over a directory with directories in it <rekado>only the daemon runs as root, so only it could possibly unmount anything. <JeanLouis>I am using Debian GNU/Linux, Jessie, and I have /dev/sda8 as cryptsetup partition, standard, not LUKS, which after setup to /dev/mapper/protected mounts later to /home. <JeanLouis>But before that I do have /home on /dev/sda7 because if somebody steals my laptop, or try to turn on, to read information, they don't find my private data <Jookia>Yeah, so you have /home/fake-user/, then you mount over it to get /home/real-user/ ? <rekado>btw, I use GuixSD and my home is LUKS in LVM <rekado>and I need to manually unlock the encrypted home <Jookia>I'm super itching to get people to test my Libreboot patch <rain1>rekado, you can get it to automatically do it <rekado>JeanLouis: you could attach "strace -f -p <pid of daemon>" <Jookia>Uuugh I should go to sleep since I'm suppose to be at the dentist in like 10 hours but I got woken up by my shower and now I'm reading autotools documentation <JeanLouis>rekado: should I put logs somewhere ? If I do that, once unmounted, I don't get any information <rekado>JeanLouis: you could write the logs to /tmp, no? <NiAsterisk>Jookia: i was awake early, did some work on projects and then a late appointment got canceled. <Jookia>rain1: it yelled at me to wake up, obviously ;) <rekado>strace -f -p <daemon> 2>/something/not/tmp <Jookia>But yes, <pid of daemon> should be replaced with the PID of guix-daemon <Jookia>You can find it using pidof, ps -A | grep guix-daemon, etc <JeanLouis>9992 pts/0 S+ 0:00 sudo ./pre-inst-env guix-daemon --build-users-group=guix-builder <JeanLouis> 9993 pts/0 S+ 0:00 guix-daemon --build-users-group=guix-builder <Jookia>I think it's 9993 but I may be wrong <Jookia>You should upgrade to a good theme like Clearlooks ;) <JeanLouis>sudo strace -f -p 9992 > /var/www/guix/9992.log 2>&1 -- I do this <Jookia>i think 2>&1 should go before the first > <JeanLouis>sudo strace -f -p 9993 > /var/www/guix/9993.log 2>&1 <Jookia>sudo strace -f -p 9992 2>&1 > /var/www/guix/9992.log <JeanLouis>it is working, so I don't look now in references <Jookia>maybe that's another way to do it? idk <JeanLouis>restart_syscall(<... resuming interrupted call ...>% <JeanLouis>./pre-inst-env guix package -i hello --- I will do this <rekado>have to go now, but will check back in a few hours <Jookia>JeanLouis: You may aslo want to run 'dmesg > /var/www/guix/dmesg.log' <JeanLouis>Jookia: but dmesg exits, I search for option to continously follow <JeanLouis>This is the Z Shell configuration function for new users, <JeanLouis>The following environment variable definitions may be needed: <JeanLouis> export PATH="/usr/local/var/guix/profiles/per-user/admin/guix-profile/bin" <JeanLouis>in one window, I can see programs in mounted partition <JeanLouis>guix programs, if I do cd, it will disappear <davexunit>JeanLouis: what groups does your user belong to? <davexunit>JeanLouis: how are you running the guix daemon? <Jookia>davexunit: "sudo ./pre-inst-env guix-daemon --build-users-group=guix-builder" <JeanLouis>I did not yet kill straces, because i research <NiAsterisk>or for example ptpb.pw which can be accessed with bashscript upload. <rain1>ix.io is a cool one like that <mik_>Anyone very familiar with the configuration of grub in guix system configuration? I can't be sure, but from the documentation it seems to only support MBR grub installation through (cannot specify a partition on a disk, just the disk) <JeanLouis>mount |grep mapper -- is zero, so it is not mounted any more <Jookia>mik_: IIRC It installs grub to /boot <Jookia>JeanLouis: Could you paste the straces and dmesg output <JeanLouis>but where to upload, my keys are not available <JeanLouis>ok in 9992 PID there is nothing, so that I delete <Jookia>I'm afraid I'm very tired right now but I'll have a look and see if there's anything obviously wrong <JeanLouis>if you can just download files, for later please <JeanLouis>what I think -- guix has recognized my system mounts, as there is one /home to /dev/sda7 <JeanLouis>because I see [pid 10721] mount(NULL, "/home", NULL, MS_PRIVATE, NULL) = 0 <JeanLouis>what I think, it simply mounted /home on top <Jookia>why is filetea not loading for me <Jookia>filetea just shows a blank page for me <JeanLouis>9993.log.gz:[pid 10721] mount(NULL, "/proc", NULL, MS_PRIVATE, NULL) = 0 <JeanLouis>9993.log.gz:[pid 10721] mount(NULL, "/proc/sys/fs/binfmt_misc", NULL, MS_PRIVATE, NULL) = 0 <JeanLouis>9993.log.gz:[pid 10721] mount(NULL, "/etc/machine-id", NULL, MS_PRIVATE, NULL) = 0 <JeanLouis>9993.log.gz:[pid 10721] mount(NULL, "/home", NULL, MS_PRIVATE, NULL) = 0 <Jookia>I wonder if this is to do with chroots somehow <Jookia>I wonder if bug-guix would allow that as an attachment <Jookia>mik_: That is the case. Where do you want to install it? <mik_>Jookia: I wish to specify a partition and use EFI booting <Jookia>mik_: EFI booting isn't implemented (yet), but it's on my todo list <mik_>Jookia: I guess the way to do this ATM is to install grub2 manually, and pass a parameter to the invocation of the system installer <mik_>Jookia: I don't want it to sound like I'm complaining, I definitely appreciate all the hard work you guys do <Jookia>mik_: If you can figure out that parameter I'll work up a patch for you in a day or two that might help <paroneayea>Jookia: re-ping me about it later, I'm in a meeting <Jookia>mik_: basically i have some changes that would really benefit from EFI support and it wouldn't be too hard to do <Jookia>mik_: I just don't have an EFI machine or knowledge on what parameters need to be used when running grub-install <Jookia>mik_: Oh, I only ahve patches that work in the my-os-config.scm <mik_>Jookia: I guess I was thinking a work-around at the moment would be to manually install grub2 in a efi manner and specify in my system configuration to mount that EFI partition at /boot (so that additional generations can be added to the boot menu) <mik_>Jookia: is my understanding correct that your patches would support some additional syntax in the operating system specification file (e.g. my-os-config.scm)? So that the workaround wouldn't be necessary? <Jookia>mik_: Yes, let me find the patch <Jookia>So pretty easy to add EFI support <mik_>Jookia: thank you. I'll have to do some extra reading; to my embarassment, I haven't even heard of coreboot before <Jookia>mik_: The coreboot code just moves some files around in /boot/grub/ . For EFI support, I'm unsure where you'd put the partition. Perhaps reusing the device field and relaxing the requirements in the documentation would be okay. These patches aren't upstream yet though <NiAsterisk>in package definition, when you see (substitute) occurence, that is. <JeanLouis>I was thinking guix substitute maybe, by working on its purpose, mounts system directories ... as that is how my encrypted /home was re-mounted on system partition, so guix stopped <rain1>substitutes are pre-compiled versions of packages <rain1>so instead of compiling it yourself, it downloads a compiled version <rain1>you can use --no-substitutes to make it compile from source <JeanLouis>rain1: I am only trying to find out why guix daemon mounted system directory defined /home on my encrypted /home <rain1>that sounds like an extremely hard bug to track down <JeanLouis>I guess recado: helped with strace, and I can see where it is happening <JeanLouis>Putting guix on USB, to see if I can boot... <a_e>rain1: Hello! I would argue that the Russian Sokoban levels you mentioned the other day are in the Public Domain. <rain1>I'm happy to include his great levels in my repo.. I doubt guix will take it but it's ok <JeanLouis>does that mean, everybody can make new operating system configuration and get such system? For example I need on 3 computers this and that, I install and get exactly that? <a_e>Well, "use it, copy it, modify it, I am not interested in the copyright" sounds like public domain to me. And then we can take it. <a_e>It would be nice if you could propose the package on the mailing list. And also discuss licenses of levels there. <rain1>a_e, I just thought it would be easier ot split game/levels apart -- although that often makes it hard for a beginner to install or use the program.. <JeanLouis>looks good. I look from viewpoint of how future will be shaped by guix approach. <rain1>and i have also thought about rewriting the game in guile <a_e>It could be complicated in Guix, depending on how the game finds its levels. <JeanLouis>rain1: and Guix based on this kind of guile configuration -- will force in future people to learn programming <a_e>I suppose the levels are little data, so free ones may as well be included. <rain1>JeanLouis, maybe encourage and help rather than force :) <JeanLouis>because right now, society is way back in regards to programming. <JeanLouis>dd: writing to ‘/dev/sdb’: Input/output error -- something is wrong <JeanLouis>[11435.401452] VFS: Dirty inode writeback failed for block device sdb (err=-5). <rain1>a_e, I am feeling like it's time to start archiving soko levels.. would be a shame if the classics disappeared <a_e>Guix as an archive... Why not? <NiAsterisk>sorry, the word colides with "special task force" where i live <hyperreal>I'm trying to build a guixSD vm, and I get the error "Could not access KVM kernel module: permission denied" <davexunit>hyperreal: your user needs to have permission to use kvm <hyperreal>davexunit: I did this about 11 months ago, but I forgot how to fix it. Now that you've said it, I remember now I have to chmod 666 /dev/kvm. Thanks :) <civodul>on most distros there's a "kvm" user group that has write access to /dev/kvm <kqb>hi, I tried guix system vm-image $f, where $f contained the no-X example from the guix-manual. It updated the substitue lists about 20 times in a row and then dumped a stack trace to guix/mondas.scm line 317. The source-code at that location is " <kqb>(define-inlinable (state-bind mvalue mproc) <kqb> "Bind MVALUE, a value in the state monad, and pass it to MPROC." <kqb> (lambda (value state) <kqb> ;; Note: as of Guile 2.0.11, declaring a variable to hold the result <kqb> ;; of (mproc value) prevents a bit of unfolding/inlining. <kqb> ((mproc value) state)))))". Note: warning: failed to install locale: Invalid argument <kqb>according to a blog entry such a VM-stack-overflow originates in the guile-VM from recursive function calls <civodul>kqb: i cannot reproduce it; what Guix commit is it? <kqb>could the problem be related to the comment in lines 8,9 (paste); 373,374 (source)? <kqb>guix (GNU Guix) 0.9.1 <kqb>current master; called "$ guix pull" first <JeanLouis>Wow, GuixSD is great. On boot, I could see for first time: "GNU with Linux-Libre", and not Linux something. Finally true GNU distribution. <civodul>kqb: the OS config you're trying to build is bare-bones.tmpl? <kqb>I restarted it again, just in case I messed something up; 3 minutes in and ok so far. Weird. <kqb>ok, stack overflow SEEMS to have been fixed. Now it complains qemu failed "qemu-system-x86_64"; Could not access KVM kernel module: Permission denied; <kqb>failed to initialize KVM: Permission denied; How do I fix that? (Kernel-modules (kvm, kvm-<arch>, virtio) are loaded!) <kqb>rain1: guix is supposed to run on any GNU/Linux <kqb>rain1: I am using arch <civodul>kqb: make sure you have write access to /dev/kvm <kqb>"crw-rw----+ 1 root kvm" does this imply that root has wright access? I think so. <ringst>root has write access, and the members of the kvm group have write access <f0ff>wow this dist is strange :-) <f0ff>also why is gnu.org so broken.. is it only for me? <f0ff>well sometimes one can't connect then when one connect it seems to max 8mbps if you are lucky <rain1>oh i had some weird stuff like that, maybe it's DNS <rain1>icecat is really weirdly strict about TLS <f0ff>though it it slow also, but dunno <rain1>as if it's actually giving you security <f0ff>oh i meant when downloading from hybrid.gnu.org <f0ff>i try to install the distro <kqb>civodul: i can execute qemu-system-x86_64 as an unpriviledged user. It just informs me that there nothing bootable present. <rain1>oh im sorry thought you meant the website! <f0ff>ok thanks i'll check it out if i need to later <f0ff>it is a hard to dist to install that is for sure :P <f0ff>i got everything downloaded now atleast i think <hyperreal>I'm installing GuixSD and ran into an error while running 'guix system init ...': "suspicious ownership or permission on '/gnu/store/...-harbuzz-1.0.6-bin'; rejecting this build outpit" <kqb>civodul: $ /gnu/store/fx8wa04b40fcs79p7apiza1gq1hrxbrd-qemu-minimal-2.5.0/bin/qemu-system-x86_64 <kqb> ==> VNC server running on '::1:5900' <kqb>civodul: so it seems to be working <f0ff>btw i have a question about the hashes on the packages, when i read the manual it sounded like it was a hash of the "./configure && make && make install" ? :P <f0ff>that seems kinda pointless? <kqb>f0ff: as far as I can tell they hash the entire input, shell variable and all <f0ff>but what hinder anyone to just enter a exploit somewhere in the code? 
