<civodul>snape: i'll push a fix tomorrow, in the meantime you can "chown -R" :-) <snape>civodul: it works if I delete .cache/guile <rekado_>I just changed my system time to Feb 28 and a few seconds later the X server restarted :-o <civodul>catern: not yet, but this looks like a great source of inspiration! <civodul>rekado_: a less risky option would be to use faketime :-) <bavier>we don't use gnutls for 'guix pull' anymore, right? <bavier>guile-ssh handles everything now I think ***magrathean is now known as slartibartfast
<iu>Is it any chance to make guix-pull less memory-hungry? It eats 900Mb of memory, 1Gb of swap on 75% of compiling process. <roptat>civodul: you probably didn't see may mail yesterday: on the website, the "Bug Reporting" title is indented with the Chinese text <roptat>I proposed to use "clear: both" on each div and on the last p of the contact-medium div <roptat>another solution is to use flex boxes, but I'm not sure how compatible they are with browsers <civodul>actually i have problems with my imap server today ***phant0mas_ is now known as phant0mas
<thomassgn>I have Libreoffice crash when I try to set certificate paths in the Tools->Options->Security menu. Haven't checked if there are bugs or anything. Will look into it when I have the time, but not now - got to go. <civodul>"Settings schema 'org.gtk.Settings.FileChooser' is not installed" is probably the root cause <civodul>because it crashes right when it should open a file chooser <g_bor>I've just talked to Alex, and we did not received any attempt from outreachy applicants so far. I something wrong with our communications setup, or something else. Should we do something to get in touch, or should we wait? <resh>Hello! This is Reshu Singh(resh) from New Delhi,India.I am Outreachy'18 applicant. I want to work on "Improve the user experience for the "guix package" command line tool" <resh>Since,I am new to environment of communication flow via IRCs,not able to understand it properly. Looking forward to interacting working with GUIX community! <bavier`>resh: I would suggest following the application process on Outreachy <bavier`>or if you've already done that, thanks <bavier`>resh: I'm excited to see what comes of that project ***resh is now known as bavier
***bavier is now known as resh
<resh> Some projects accept contributions through a project repository. This project has not provided a link to a project repository. <resh>Applicants will need to contact a mentor to find out how they can make their first contributions to the project. <resh>How can I contact the project mentor rekado via mail or here on IRC? <bavier`>resh: an email to guix-devel@gnu.org would be appropriate <bavier`>of the 21 guix dependencies I've installed manually on this system, I didn't think texinfo would be the one to give me trouble <civodul>bavier`: is that because of Perl dependencies? <bavier`>I get an assertion failure, but it's not clear from where <civodul>if you're building from the tarball you don't need Texinfo <civodul>perhaps you could build from the tarball and after that use 'guix environment guix'? <resh>Virtual box or dual boot for GUIX distro needed to work on? <bavier`>resh: you can run guix on top of another GNU/Linux distro <quiliro>bavier`: hello! are there websites bloggin about guix? <quiliro>bavier`: you're always here...right? nice to see someone is present <rekado>resh: I usually send prospective interns an email with hints on how to get started. <rekado>you can send me email to rekado at elephly dot net and I’ll reply with those hints. <resh>Ohh okay,sending one. :) <rekado>mbakke: this Python patch really does help with reproducibility in many cases. <mbakke>rekado: Great! Let's include it :) <rekado>mbakke: I’m currently rebuilding all Python dependencies for the paper and many of them build reproducibly now. <mbakke>Any idea what's required for Python 2? <rekado>on core-updates or can we get this in more quickly…? <rekado>(I’d love to have it in master soon, in time for the paper) <mbakke>I think it will have to go through core-updates, though you could push a python-updates branch and poke guix-devel :) <rekado>re Python 2: I don’t know. Haven’t looked at it. <rekado>I’ll push python-updates (with the patch to python-build-system and python-3.6) tonight. <rekado>will also check how to get berlin to build it. <g_bor>rekado: do we still have those three additional tests failing? <g_bor>and one more thing, that I don't clearly understand, but I'm not too much into python: why do we have 'allow-non-deterministic-compilation phase? <g_bor>Ok, it just compiled, yes, it seems that with my version we still have these three tests failing. I will take a look. <rekado>g_bor: that phase is for the other tests that would otherwise fail. <rekado>g_bor: we still want Python to be able to refresh a stale pyc file. <rekado>one thing to note is that the python-3.6 package itself is not reproducible with the patch I posted. <rekado>but many “python-” packages are. <rekado>it’s a big improvement, but it’s not complete. <rekado>if you have ideas how to fix reproducibility for python-3.6 itself (e.g. by rebuilding all pyc files at the end with DETERMINISTIC_BUILD set), please do test and submit the required changes ***pkill9_ is now known as pkill9
<chewzerita>Submitted my first contribution to an open source project today! <jayspeer>hi. can anyone point to step-by-step guide to creating custom packages in guix? <bavier`>jayspeer: section 4.1 in the manual is a good start <axg>So I'm trying to run a executable, that I downloaded, from the command line and it won't work. I set teh permission properly, but bash complains that `bash: ./fastboot: No such file or directory` when I try to run it. Using the file command on it gives this: `fastboot: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.0, with debug_info, not stripped`. After a <axg>little searching it seems that the problem is with the interpreter, and that it's supposed to be used for 32-bit apps. I suppose it isn't installed and I'm not certain how to find it, a few quick guix package -A's didn't turn up much. Any help appreciated. <sneek>axg, atw says: I opened a few Dired buffers to remote servers via TRAMP. Emacs seems pretty responsive but autocompletions in ERC and CIDER sometimes hang with a message like "Pinging example.com (Commercial)...". Completion seems slower in general. <jayspeer>bavier`: thanks for the answer - I'm reading it right now, however it'i little heavy for a start. I was hoping for something easier to comprehend :) <bavier`>axg: so you downloaded a dynamic executable, and you're wanting to run it on GuixSD? <axg>bavier`: well yeah, it's supposed to be a simple program for flashing images onto android phones, I'm not trying to install or keep it, I just thought it would just work, as if it's a bash script, and I can get rid of it later. <axg>on other distros it was as simple as downloading it, setting the execute bit and running it. <axg>/lib/ld-linux.so.2 is probably the culprit, but not sure what to do with that <bavier`>axg: the patchelf utility is probably your best option. you can set the path to the interpreter with it <axg>bavier`: so I would do something like this? `patchelf --set-interpreter /lib/my-ld-linux.so.2 my-program` <axg>this is an example from their github page, where would I find the ld-linux.so.2 on guix, do you have any idea? <bavier`>axg: right, but you'll need to find where the interpreter is on your system. I'm not on a GuixSD atm so I can't help much more <axg>bavier`: I used the `guix gc --requisites /run/current_system` to get a list of everything installed and after grepping for linux there is nothign that turned up with ld-linux. Is there a package that would provide it? <bavier`>axg: you could maybe explore one of the dynamically-linked executables in your profile? <bavier`>i.e. figure out what it's interpreter is <bavier`>axg: `patchelf --print-interpreter ~/.guix-profile/bin/emacs` <axg>bavier`: So you think that it must be installed be default? I don't really know where everything is on the system, but I checked ~/.guix-profile/lib/ and /run/current-system/profile/lib/ and couldn't find ld-linux. I'm grasping for staws here a bit <axg>thank you for the help regardless, patchelf is an important utility <bavier`>axg: did you try what I typed above ^? <axg>sorry missed that, let me see <axg>bavier`: well I have emacs installed for the system as a whole, but /gnu/store/xxxx-emacs-25.3/bin/emacs instead of your path return that it is not an elf executable <bavier`>axg: doesn't have to be emacs, any other dynamic exe in your profile would do <axg>bavier`: I just tried doing that, curl is linking to ld-linux-x86-64 in the glibc package's bin <axg>bavier`: using this 64-bit library for the interpreter resulted in `bash: ./fastboot: Accessing a corrupted shared library` message, so I do suppose that I need a 32-bit one <bavier`>axg: that's possible. you could acquire one with `guix build --system=i686-linux glibc` <axg>bavier`: would that replace my current glibc or install it as an additional package for the user profile? Sorry haven't messed around with guix build as of yet <rekado>jayspeer: I often find it easier to copy from a simple package and adjust the fields. <bavier`>axg: it would just build it/substitute it into the store; doesn't modify the system or your profile <rekado>jayspeer: we also have package importers to generate code from package collections (e.g. CRAN, CPAN, Pypi, etc) <axg>bavier`: oh I see, so if I ran guix gc, it would be removed since it isn't linked from any profile? <jayspeer>I'd prefer to learn how to do it, cause I think it will help not only me but whole community. I need to connect with company's vpn, unfortunately we only use lt2p and pptp. Neither is present in guix package repository, so I'm trying to prepare package definition for both pptp and networkmanager-pptp plugin. <rekado>jayspeer: the best way, in my opinion, is to look at a simple package and copy from there. <rekado>do not copy the “arguments” field. <rekado>then build the package and see how it fails. <rekado>hope you won’t need luck that urgently :) <g_bor>I think that I've found out why we need to disable those additional test in python. <axg>bavier`: thank you. The build it running right now, will report with the results, but I suppose this should be the end of this little problem. Do you know if there is a plan in guix's timeline to be able to handle more programs by default or is it just going to require patching for the packagers? What I mean is like bash scripts working by default when copied from a different distro which try to use /bin/bash, etc. <g_bor>It seems, that they are testing for import failures based on bytecode headers, and disabling the check in importlib allows to import pyc files where the import should be failing. <g_bor>The test errors are all related to expected errors not occuring. <g_bor>I believe that it is safe to ignore these. <rekado>would it make sense to disable the check in importlib only conditionally? <g_bor>I don't think so. These checks just do not matter in our environment, and will eventually fail in other, so I think it is fine. <g_bor>I will have a look at this one more time, but I think it is not a problem, that we had to disable these tests... <rekado>but there’s also the case where people use Python inside of an ad-hoc environment. <bavier`>axg: there has been some talk of extending 'guix environment' to emulate a debian-ish FHS <g_bor>Actually the worst thing that could happen, is that they can import a pyc file, that should not be allowed to be imported because of problems in the header. <g_bor>At least now it seems like that... <rekado>g_bor: thank you for taking the time to look over this! <thorwil>i just read, that as alternative to chainloading, one may reference one grub instances grub.cfg in the configuration of another one. which will the appear similar to a sub-menu. but how to get a stable path to the most recent grub.cfg of a guix system (without actually installing grub)? <g_bor>I still intend to decorate the sources a little, to see exactly where the error comes from, but it should no cause serious problems according to my findings. <g_bor>Now I think I will try to see if recompiling at the end with deterministic build helps. <rekado>I’m currently testing with a recompilation phase at the end. <bavier`>do we have requirements docs for some of these summer projects? <bavier`>e.g. for guix-daemon -> don't assume chroot enabled implies run as root <bavier`>let guix-daemon manage multiple stores <nckx>Does Cuirass have a (non-Emacs) Web interface yet? <rekado>there is berlin.guixsd.org/status <rekado>bavier`: we have a wiki page for that somewhere <rekado>for the outreachy projects mentors need to submit their proposals on the outreachy website. <nckx>rekado: Thanks! I'd tried that, but without much luck (or understanding). <nckx>However, it keeps timing out on me, so I'd say we're nicely on the way to replacing Hydra! <nckx>Am I correct in assuming that, when it works, it's read-only? <rekado>I also don’t understand the status page, to be honest :) <nckx>Ooh, the mysterious check-boxes now show tooltips. <nckx>Even without Unicode support, that is an accurate representation of my current understanding. <rekado>g_bor: rebuilding everything once after installation works, but there are 1956 different files. All pyc. <rekado>oh, wait: these end on “opt-1.pyc” and “opt-2.pyc”. That’s why we need to recompile three times: once for each optimization level. ***pkill9_ is now known as pkill9
<platoxia>my user's guix package is broken...I keep getting "guix package: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux'" even though locate finds it in several places. <bavier`>haha, was hacking on guix-daemon and killed by entire DE <rekado>platoxia: does ~/.config/guix/latest exist? <rekado>platoxia: do you have a Guix checkout from git? <platoxia>rekado: yes ~/.config/guix/latest exists. I do not have any git checkouts...this is GuixSD. <platoxia>rekado: I can use some functionality on the user account but guix pull, guix package -u, and guix package -r all throw that error. <rekado>platoxia: did this work for you before? Are other users affected? <platoxia>rekado: it all worked before and there are no other users but root <rekado>One thing you could try is to move ~/.config/guix/latest out of the way (don’t remove it), and then try “guix pull” again. <rekado>the first part lets you use the system Guix, the second part gets you a new Guix. <rekado>(it will create ~/.config/guix/latest, which will point to the new Guix) <platoxia>rekado: moved latest to latest.old and guix pull is now working. <platoxia>rekado: so was ~/.config/guix/latest just too many versions behind to update? <rekado>platoxia: I don’t know. It’s also possible that there was actual corruption in the store for the particular version of Guix you used. <platoxia>rekado: given the way guix works...I'm going to lean towards store corruption. I should probably test my file system and hdd. <rekado>platoxia: you can also run “guix gc --verify=contents,repair” as root. <platoxia>rekado: Thanks. I'll have to read up on that some more. I only played with gc very briefly at this point. I didn't realize it had that ability.