<rain1>janneke: 2) remove anonymous unions and structs from 8cc <rain1>I think I could do this, maybe <rain1>we will have to see what comes out of thread thouh <rain1>there is only 1 anonymous union in 8cc? <janneke>beyond the first anonymous struct in anonymous union, that is <rain1> http://ix.io/xEu well here is a patch to name that anonymous union, if there are others or other reasons mes cant compile it i can refactor it more <rain1>Missing dependencies [i686-unknown-linux-gnu-gcc], run <rain1>hm is there a workaround for this? or do ihave to install a cross compiler <janneke>...but doesn't `guix environment mes' work for you? <rain1>ah i did not try inside guix, i only have a guix virtual machine just now <janneke>the hard depedency on i686-unknown-linux-gnu-gcc has been dropped on my wip-hex2 branch <janneke>but configure and make have not been updated <OriansJ`>jeez, I almost forgot how many weird edge causes x86 encoding has <OriansJ`>janneke: I might have to modify hex2 to get a couple edge cases of x86 to fit into M0. (x86 has requirements on Immediate sizes that can cause serious encoding problems) <OriansJ`>rain1: do you think it is too aggressive of an idea simply forbid labels that start with a digit and use the !@% symbols to indicate the size of the immediate? <rain1>I actually prefer it that way! <OriansJ`>rain1: but comes the question of if we want to bother with the signed/unsigned variable sized immediate values or simply forbid them for now <rain1>i think in x86 they can all be signed <OriansJ`>rain1: nope, about 70+ instructions are unsigned only <OriansJ`>and I have absolutely no intention of making it 5% complete <OriansJ`>as there is rarely a need for more than 170 of those lines in a program <OriansJ`>heck the hex assembler example, I am preparing is only requires about 22 of those definitions <OriansJ`>looks like I'll have to extend M0 to also be able to deal with big and little endianness of immediate values <catonano>janneke: I was just checking if someone had left sneek something for me ;-) <sneek>efraim, ng0 says: One thing I haven't figured out in E21/Enlightenment is that one Webbrowser extension behaves very weird thinking the binary path is /usr/bin, while all other WMs/DMs are okay. <janneke>catonano: i was just saying `hi' in a funny way back <efraim>under GuixSD what's the absolute path to reboot? <rekado>efraim: reboot is a message to shepherd <efraim>rekado: right, but i'm patching enlightenment's configure script to say 'REBOOT="/usr/bin/systemctl reboot"' <rekado>for me reboot is “/gnu/store/…-shepherd-0.3.2/sbin/reboot” and it’s linked to “/run/current-system/profile/sbin/reboot” <efraim>is there a suspend or hibernate command? <rekado>I only see halt, reboot, and shutdown. <rekado>the suspend and hibernate commands come from the power management packages I think <buenouanq>isn't reboot an alias of something like $ shutdown -r now <rekado>the shepherd does things differently <rekado>“halt” itself is just a short Guile script <rekado>it runs the “main” of (shepherd scripts halt) <efraim>git signing on my firefly is killing me, I got pinentry-tty working so I can --detached-sign things but I can't sign commits on that machine <civodul>maybe bad interaction between gpg-agent from Guix and gpg from the foreign distro, or vice versa? <efraim>i think at this point i have all from the foreign distro, haven't tried logging out and back in since I got partial functionality <efraim>worst case is I'll switch the odroid to core-updates and pass the patches there to sign and upload and keep my laptop on master <civodul>rekado: i think we should do an e-"coding sprint" to work on the performance issues that you have <civodul>at the very least to clearly identify the source of the problems <civodul>then we can have PoCs for each solution <civodul>just to make sure we're on the right track <rekado>I need to first set up my machine so that I can make changes to guix without affecting everybody else’s installation <rekado>GUIX_DAEMON_SOCKET=guix:// is really useful <civodul>rekado: i just posted a patch to test my RPC performance hypothesis <jsierles>any way to get some more info on what the guix-daemon is doing? i'm stuck with it trying to fetch substitutes. ***nmp is now known as nparody
<jsierles>tracing the process it appears to be writing to the same files over and over in the store. <civodul>jsierles: could you capture that and send it to bug-guix? <civodul>please make sure to include as much info as possible <nparody>hi, i am following instructions in Binary-Installation.html <civodul>jsierles: for instance, whether the store items mentioned in the /var/guix/substitute/cache/xyz at fault actually exists <civodul>also the complete content of the /var/guix/substitute/cache/xyz file it touches if any <civodul>can you try "guix pull --no-grafts"? <nparody>yesterday at least 4-5 hours before i killed it. today i tried 'guix package -i emacs' and the same thing has been happening for 2 hours now <civodul>nparody: like jsierles, could you strace the 'guix substitute' process? <jsierles>civodul: the files seem to exist. do you know a way meanwhile to work around it? just now i can't build anything which is not already in the store <rekado>civodul: I’m going to test the patch shortly. Thanks! <jsierles>civodul: which process should be traced - substitute --query or substitute --substitute? <civodul>it's the one that prints "updating the list of substitutes" <jsierles>could there be an issue with the substitute server? <rekado>civodul: the timings of “guix build hello” and “guix build -n hello” are extremely variable. <rekado>sometimes it only takes 5 seconds, other times it takes 41 seconds. <rekado>it’s hard to test the impact of a patch this way :- <civodul>is it over the network or on localhost? <rekado>I use a remote GUIX_DAEMON_SOCKET to talk to the server that has /gnu mounted over NFS <civodul>and if you run this on the server that runs guix-daemon, with guix://localhost ? <rekado>I can try this but need to get a separate Guix first <rekado>I’ll copy my directory over in a moment <civodul>this is very sensitive to network latency <civodul>with ssh://localhost it takes 2 minutes, terrible <rekado>copying my guix directory right now. I have to leave for a couple of minutes; will test this as soon as I’m back in the office <divansantana_>busy with guixsd install, says "substitute: updating list of substitutes...100%" and keeps doing that forever. <divansantana_>that's when doing `guix system init /mnt/etc/config.scm /mnt` or `guix pull` <civodul>divansantana_: a couple of people just reported the same issue <divansantana_>civodul: I'm happy yo here this. Thought it was just me or my luck. <jsierles>is it a big chore setting up a substitute server? <jsierles>i see, so it's just for sharing our store. maybe then what i want right now is to bypass fetching substitutes and just build? <civodul>right, so you could do --no-substitutes if you don't mind building <jsierles>a way to just fetch a substitute and cache it in the store without using guix? <efraim>the only thing really worth caching ahead of time would be the source tarballs, you can always build offline later <jsierles>hmm, now things seem to be working again <janneke>sneek: later tell rain1: on my Mes wip-hex2 branch, CC32 is now optional. <janneke>sneek: later tell OriansJ`: on my wip-hex2 branch i have a handcoded exit42 example in hex2, that can be inspected with objdump and debugged with gdb. handcoded bits because i needed substraction. <rekado>so, I’m trying to use socat to export the daemon socket over TCP, so that I can use GUIX_DAEMON_SOCKET=guix://localhost:12345 <rekado>I’m a bit confused about the fact that I cannot seem to connect to it. <rekado>remote systems can connect though :) <Petter>Wild guess, maybe you need to use 127.0.0.1 instead. <civodul>rekado: we'd have to look at what socat does exactly <civodul>BTW, i'm also working on supporting --listen=localhost:2342 <rekado>civodul: what do you think about supporting multiple daemons to run on different nodes? <rekado>e.g. in a redundant / round-robin setup? <rekado>that came up today and I think that there’s an assumption in the daemon that there can only be one. <civodul>rekado: yeah, there can only be one, more or less <civodul>at least the database is shared, and there's a limit on the number of concurrent accesses <civodul>but note that "make check -j" actually runs several daemons in parallel <civodul>BTW running tests in parallel causes difficulties for GC <civodul>because each guix-daemon instance is unaware of the temporary GC roots of the other instances <civodul>Makefile.am arranges to run tests/guix-gc.sh last for that reason <quiliro>this is the third day i get "not enough space left" message when installing guixsd on macbook air (has EFI) <quiliro>tryed with and without EFI partition <quiliro>tryed with 2 GB partition and with 110 GB partition <quiliro>i don't think it is because it is an solid state disk, is it? <civodul>normally if you have enough space on the target device, that shouldn't happen <civodul>did you run "herd start cow-store /mnt"? <civodul>then it probably means the file system on /mnt is full <civodul>i mean that it was full at the time you got the message <quiliro>let me check, maybe i was using another disk <quiliro>there were 3 disks whern installing: usb installer, embedded disk and usb data with light-desktop.scm <civodul>yeah make sure you're mounting the right disk on /mnt <quiliro>lsblk says /mnt is in sda1, mount says /mnt is in sda1 and /tmp is on sda1 twice <quiliro>lightweight-desktop.scm says bootdevice is sda <rekado>civodul: I’m afraid I cannot see any difference between a version of guix after applying your patch to guix/store.scm and the unpatched version. <rekado>but that’s not because of the patch <rekado>building bwa I get anything between 6 seconds and 42 seconds <rekado>best time yet is 5.7s for the patched variant <civodul>quiliro: if you run "herd start cow-store /mnt", then the image's root file system should not be filling up <efraim>i built python and python2 from core-updates on aarch64, now building toward gtk gtk2 cmake guix qemu-minimal <quiliro>civodul: perhaps i did not type it correctly and it failed, i do not remember checking if it worked correctly...thank you <quiliro>the passwd command is not installed on the usb installer, thus it makes it impossible to lgin from another machine to install remotely <efraim>Guix still doesn't have anything like apt-file yet <civodul>it's waiting for someone to write it :-) <efraim>If I add '#:system x86_64'(or whatever) to a package definition, does that just change the --target? <civodul>#:system corresponds to --system, not --target <civodul>i think the only case where we do that is Wine <efraim>so the result is it uses i686 make and i686 gcc and everything? <quiliro> i have installed with wireless without password... i followed these steps <quiliro>then i edited lightweight-desktop.scm <quiliro>guix system init /mnt/etc/lightweight-desktop.scm /mnt --fallback <rain1>I got errors about wchar_t when I 'make' mes <sneek>rain1, janneke says: on my Mes wip-hex2 branch, CC32 is now optional. <janneke>rain1: ugh...gcc configurations and build whoes, someone should create an reproducible build environment! <civodul>rekado: did you try to build Bazel & TensorFlow? <civodul>i remember this was discussed at some point <civodul>and Bazel had a zillion bundled deps <rekado>yeah, I once tried building Bazel <rekado>but I gave up when I saw that packaging Bazel wouldn’t be easy <rekado>at the repro builds summit the Bazel folks admitted that at that time building Bazel required Bazel. <rekado>apparently work was under way to make it build with just a shell. <rekado>civodul: has someone requested TensorFlow? Or do you think we should give it a try for the Guix HPC work? <civodul>rekado: there's a team at work that needs it <civodul>currently the approach is to build by hand and to make "modules" <janneke>rain1: what kind of system/compiler are you running? Mes has been tested with `guix environment guix.scm' which installs gcc-5.4.0 <janneke>rain1: sorry that things -- even compiling C -- can be such a nightmare <janneke>can you try gcc-5.4? what version gives you this problem, so that i can look at it? <rekado>I have a feeling that Bazel doesn’t quite deserve to be listed there when it really just bundles dependencies. <rekado>“To bootstrap your first bazel binary, please download a dist archive…” <civodul>and remind them of the discussion we had <civodul>if we threaten them with a line in the "best bootstrapping practices" hall of shame, that might work :-) <rekado>it might be possible to generate these files without using their pre-built stuff. <rekado>ugh, this means we have to package a lot of the stuff in the third_party directory <rekado>but many of the remaining things seem pretty complicated :-( <rekado>as a first step we could unbundle as many of the third_party jars as we have already packaged and see if the bootstrap script will work. <civodul>rekado: yeah let's see how complicated it is <efraim>its not pretty, but I finally figured out if I pipe mail in Hebew from mutt to fribidi and then to less I can read it right to left rather than backward <janneke>rain1: ah, okay. let me check if i can reproduce your bug report. <rain1>i installed gcc5 and tried building again, same problem <janneke>ugh! i broke something adding headers for 8cc and all. great! <janneke>you can go back a couple of commits, say to bee152ec doc: Release update. <janneke>i'm flabbergasted why i didn't notice this before, oh well, thanks! <rain1>did you get my patch for 8cc? <rain1>the reason im setting up mes is to try te help building 8cc with it! <rain1>ah i removed the anonymous union <janneke>i have been adding C headers (mostly as stubs) to get past 8cc and guile's eval.c #include's , so that's where i goofed up something <rain1>unfortunately going back to an older commit gives me the i686-unknown-linux-gnu-gcc problem again <janneke>rain1: do a fresh fetch and hard reset? <janneke>i fixed configure on master and rebased wip-hex2 <janneke>rain1: you need: f7823d6c build: Make CC32 optional in configure too. <rain1>sorry, i am still not able to build it! <Tekk_>Hey, I just installed guix overtop of dragora through the binary installer last night. I think that guix is in an infinite loop with guix pull <Tekk_>It grabs the .tar.gz, it extracts it, but then it goes on substitution for hydra <Tekk_>and then prints the substitution at 100% <Tekk_>and again, and again, and again <Tekk_>It *is* on a netbook so maybe it's a cpu bound problem, but I let it sit for a few hours and it was still trying to guix pull <bavier>Tekk_: the repeated "fetching substitutes from ..." is a know issue <bavier>it's not a loop, just needs to get a lot of information <bavier>and isn't properly squashed into a single progress bar at this point <janneke>rain1: ugh! i haven't found the problem yet, although if i do: ***jonsger1 is now known as jonsger
<efraim>CVEs against glibc, exim, libffi, the kernel, and sudo i believe <efraim>I assumed it is all the architectures ***jonsger1 is now known as jonsger
<efraim>debian's security email didn't say i386 only <waynedpj>ahoy all, trying to install 0.13 on a i686 and after the "guix system init" call lots of compiling is happening. is that because the i686 binaries substitutes are not yet available for the packages ? or is there some way to avoid this and speed up the install? <lfam>waynedpj: We should have the binary substitutes available. It's possible there was a network connection issue at the time you ran the command. I recommend cancelling it and trying again. <lfam>Well, we should have substitutes available for the 0.13.0 release. If you ran `guix pull` then we won't have built some things yet. <waynedpj>lfam: thanks. if i hit control+C to stop the "guix system init" call, will i have to start over or will it leave things in a bad state? <lfam>You can also add --fallback to the `guix system init` command in another TTY to get a full list of what will be done <lfam>It's safe to cancel and restart the command <waynedpj>lfam: i did not do a pull but perhaps the init did? <lfam>No, it won't do it by itself <waynedpj>OK, then i will try to restart it and see what happens. thanks again, GuixSD looks very interesting, excited to try it out <lfam>ACTION Can't work on the stack clash updates right now, but maybe later today <waynedpj>lfam: PS: is there a way i can check if a pull was done? because if i did it unintentionally i will restart the entire installation to avoid compiling everything <lfam>waynedpj: I think you'd remember doing it, because it takes quite a long time <lfam>At least 15 minutes on recent x86_64 hardware <efraim>cve-2017-1000366 hits all of our linux glibc packages, not sure about hurd's <lfam>efraim: This is perhaps the first time I've wished we were on the distros list <efraim>i'm working on the glibc one first <waynedpj>lfam: just ran "guix system --dry-run init" and while many packages were for downloading, about the same number are for building <efraim>it looks to me like some of the glibc packages can share their patchsets and shorten their definitions ***robmyers_ is now known as robmyers
<efraim>we aren't SElinux enabled, right? <boskovits>I am having a hard time to get a working system from the images on the downloads page <boskovits>Currently i am tring the vm image, but guix pull is not working <boskovits>Tries to download linux-libre 4.4.47, and fails. <boskovits>efraim: It seems, that by default selinux is no enabled <efraim>'366 is glibc, '370 is the kernel, '369 is exim, '376 is libffi but needs selinux <efraim>'367 and '368 is sudo and already patched <efraim>finally almost done building guile@2.2.2 on aarch64 on core-updates <boskovits>I would like to know, if anyone else is experiencing problems with linux-libre 4.4.47 failing to download. <quiliro>cy dao xññb ocq dhgpo cboyanncbi ncidy,ñcidyzeñotyhl <quiliro>it has been 6 hours since start of lightweight-desktop started <efraim>Sneek_ later tell lfam I could use some help finishing the glibc patch huuttps://paste.pound-python.org/raw/cEY8Y82W8OJXAp3NMG24 <rekado>efraim: we have selinux, but we don’t build any of the core packages with it. <sneek>lfam, efraim says: I could use some help finishing the glibc patch huuttps://paste.pound-python.org/raw/cEY8Y82W8OJXAp3NMG24 <quiliro>is it necesary to guix pull before using guix system init? <mekeor>quiliro: no, AFAIK, it's not "neccessary" <mekeor>quiliro: "guix pull" just pulls the latest version of guix. <quiliro>why is it taking so much time to install GuixSD? <mekeor>sneek: later tell civodul ... 0.12 to 0.13 should work. <mekeor>ugh, i should probably write an e-mail for this... i will do so soon. <mekeor>quiliro: i guess it has to compile many things <quiliro>6 hours and i suspended and started again <civodul>lfam: i *think* GuixSD is immune to the LD_LIBRARY_PATH one, FWIW <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, mekeor says: ... 0.12 to 0.13 should work. <civodul>lfam: because of the way is_trusted_path works in glibc <rekado>mekeor: I remember trying the xmonad upgrade, but I could not build it. <quiliro>is there a guix tutorial? (not manual) <rekado>quiliro: the manual is the tutorial <rekado>mekeor: our haskell packages are a little outdated, so they really should be updated to the latest version of the haskell platform. <rekado>quiliro: is there something you miss from the manual? <civodul>mekeor: we need your input on this :-) <mekeor>civodul: you first have to apply ghc-x11.patch, then xmonad.patch. that will work. <mekeor>civodul: yes, i want to work on packaging haskell packages from latest haskell-platform; including ghc@8... <civodul>mekeor: i did apply both in this order, to no avail; could you double-check? <quiliro>rekado: i find the part of installing GuixSD very useful...it is step by step and helps understand by doing. I don't see something similar on the rest <quiliro>i am not saying the manual is bad...in fact it is very good <mekeor>civodul: what does "to no avail" mean? <quiliro>i suggested adding how to connect to unencrypted wireless <quiliro>my major problem is installation time <civodul>mekeor: that was more than a month ago, so i forgot the details <quiliro>so i am still trying to make a hydra mirror...but i see that will be of no use because not all packages have subtitutes <quiliro>perhaps a repository of sources is possible? <rekado>quiliro: in section “6.1.4 Preparing for Installation” there’s an example for how to connect to *encrypted* wireless networks; for unencrypted networks you would have to check “man wpa_supplicant”. <quiliro>i have not received answer for my reports on the mailing list (help) <quiliro>wpa_supplicant is of no use on wireless without password <mekeor>civodul: the error message in the mail you wrote doesn't make sense to me. it states "At least the following dependencies are missing: directory >=1.2.3" but i did add package "ghc-directory" to the dependencies of xmonad. <civodul>mekeor: i won't argue about the error message :-) <civodul>i just applied the patches, built, and that's it <quiliro>what would be very nice would be a .scm file for working with emacs in order to contribute to Guix <civodul>mekeor: if you have patches rebased on current master that work, i'll happily apply them <quiliro>or a tutorial to become a contributor <rain1>is there a guide to set up hydra? <rekado>quiliro: oh, you’re right about wpa_supplicant. My bad! <rekado>rain1: I don’t think so. But we have an example configuration for Cuirass (in guix-maintenance.git) <quiliro>not a suggestion or manual about contributing but a tutorial <rekado>quiliro: the manual has a dedicated section on how to contribute (section 7). <rekado>quiliro: no, cuirass would be used to build a set of packages continuously from git. <quiliro>rekado: but a tutorial would be better for contributing <quiliro>rekado: so cuirass is what i need then, is there a manual of how to set up a source server for guixsd repo? <mekeor>quiliro: why not fix the link in the git-repository and then send a patch to the mailing-list? ;) <mekeor>quiliro: what would be the difference of a "tutorial" in contrast to the "how to contribute" section of the manual?