<rain1>kyamashita, yeah I think that will work <rain1>although it has everything in one repo? <rain1>mabye it could be a dockapps package, with many outputs <kyamashita>Yes. You clone the repo and every dockapp is in one folder. <kyamashita>So unless there is a way to iterate over all the folders and build each one, they would have to be separate inputs. <kyamashita>I'll be back eventually. Hopefully with a solution. <rain1>what package provides mount? <rain1>./include/stdint.h:22:9: error: unknown type name 'int8_t' <rain1>when trying to compile a program in a guix environment container, I got this error <rain1>do you know what extra package or what I need to add? <rain1>I tried adding linux-libre-headers, that didn't help <marusich>I've seen funky stuff in containers... I got a segfault when trying to run a build script once, and it was because of some missing dependency of all things :/ <rain1>containers are a bit shaky yeah <rain1>on arch i have firefox segfault about 20% of the time for no reason, when run in a container <marusich>It must be some dependency problem I would think, unless you've modified the source or taken it from a non-release version <marusich>without knowing more about what you're packaging, it's hard to say. sorry <rain1>ill see if there's a package that seems like it might ehlp <marusich>One thing I found kind of useful is to compare your package definition with the package definition of a similar package already in Guix <marusich>If you're lucky, it might be that one of the dependencies they used will pop out at you and you'll go, "Aha, I should have used that!" <marusich>In the process of trying to package anthy and ibus-anthy for Guix, I've discovered that emacs has built-in Japanese language input support out of the box which just works. My mind has been blown. Emacs is so good! <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, lfam says: The graph coloring is very useful! ***kelsoo1 is now known as kelsoo
<roelj>Is there a command to copy a Guix profile? <ajgrf>roelj: check out the manual section on guix archive, there's a few examples <roelj>ajgrf: Thanks. I would like to copy a profile on one machine (local), so I can test upgrades on the copy, without creating inconvenience for other users. <rain1>for some reason I can't use ldd <rain1>oh it works on other files, nevermind ***Basstard1 is now known as Basstard`
<rain1>civodul, I packaged up guile-zenity like you suggested :) <rain1>still improving it for release 2 though <anthk_>34ºC on idle with Gnome Shell , this is awesome <anthk_>(celsius-fahrentheit 36)$1 = 484/5 <anthk_>idk how to convert rational to integer in scheme , btw <paroneayea>"tzag" was popular on the federated social web for some time :) <mahmutov>is there any guix iso with xfce4 desktop <davexunit>mahmutov: in guix, you write your own OS config file and choose whatever you want to put on it. there's no "default", really. <bavier>mahmutov: there are multiple examples in the manual <bavier>mahmutov: see the 'Substitutes' section in the manual <davexunit>mahmutov: yes, binaries are available if you authorize our key. if you are using the USB installer image, then it's already done for you. <davexunit>then you should be all set if you follow the instructions <davexunit>which are available in one of ttys on the live system you are running <mahmutov>an xfce4 desktop how much time rsumes to end? <rain1>it takes a few hours to fully install it <rain1>It would be nice if there was a livecd .iso so people could try it out before doing an install <mahmutov>a few hours is much time to test a system isnt it? <mahmutov>cant we make an iso-image with a desktop ? <davexunit>our download bandwidth isn't the greatest, but downloads haven't gotten much more reliable as of late. <davexunit>mahmutov: anything's possible, but no one has done so. <davexunit>making ISO formatted images is something that we don't yet have the tools for <davexunit>but it would be easy enough to make another raw disk image with a desktop system <davexunit>but our desktop support is still rather young <davexunit>we have GNOME and XFCE. Neither are complete, but both are usable. <rain1>mahmutov, I think it's possible to make an iso - nobody has done it. I agree that it's too long to just test the OS <rain1>I'm not sure what is required to make an ISO <rain1>some tricky stuff about init ramfs isn't it? because it's not writable <davexunit>the mailing list archives surely have something on this subject <mahmutov>have you ever hear "dracut" initrd maker <davexunit>it's not out of sheer forgetfulness that we don't provide ISOs <davexunit>I think a lot of people aren't used to seeing a distro start from scratch these days. ;) <davexunit>currently using my Novena running Debian for all AVR hacking. <phant0mas>davexunit: we need to find out why gcc doesn't build the extra libs for avr <phant0mas>and I have suspicions that this is one of the reasons the toolchain is not working <mark_weaver>it might require someone to dive head first into the build system and makefiles <mark_weaver>GNU make has some debugging aids which probably produce massive quantities of output for a project like GCC, but that output could perhaps be searched for strings, e.g. makefile variables of interest <mark_weaver>ACTION is relieved to discover that the audio-playing problems introduced since he last updated his Yeeloong system were not due to toolchain or C library, but due to the libao 1.1 -> 2.0 update. <mark_weaver>oh, I got mixed up. there was never any update to 2.0. the 1.1 -> 1.2 update is what broke audio playback on the Yeeloong. <davexunit>mark_weaver: yeah I need to look further. I dug as deep as I knew how to last time I looked at it. <davexunit>the problem is as phant0mas described. everything builds successfully, avr-libc seems perfect, but avr-gcc is missing many libraries for almost every AVR chip. <mark_weaver>davexunit: the substitutions done in the 'pre-configure' phase of the gcc-4.7 package (which is inherited by most other gcc variants) are fairly crude and approximate. it might be that they are causing problems in this case. <davexunit>mark_weaver: that's where I left off. making heads or tails of that code proved tricky. <mark_weaver>davexunit: the 'post-configure' phase might also be causing problems, dunno. <mark_weaver>davexunit: the 'post-configure' phase is not essential, it is only to avoid retaining unneeded references, so you could try removing it for the avr gcc <davexunit>mark_weaver: I'll just have to take another deep dive and hopefully I'll spot something that I didn't notice the last time around. <davexunit>are logs of successful builds kept in the store? <lfam>davexunit: I believe the logs are kept in the localstatedir. With Guix on Debian, mine are in /var/log/guix <lfam>mark_weaver: Thanks for handling the fix-letsencrypt branch <mark_weaver>lfam: np, I did the easy part. thanks for doing the harder part :) <lfam>I didn't know how to tell what the new failures were on hydra. So, the hard part is always the part one doesn't understand ;) <mark_weaver>davexunit: I do this: ls -ltr /var/log/guix/drvs/*/* | tail -30 <mark_weaver>lfam: if you know how to get to the evaluation page, then the trick is to click the blue "Compare to..." button on the right, and say compare to "master". <lfam>That 10 second timeout is giving me 504. Probably best not to add to the load :) <lfam>Okay, it loaded. Thanks for telling me how to catch my own fish. <mark_weaver>in practice, there tend to be many spurious failures, often due to TCP connections being reset (probably by some pain in the ass firewall in between), which hydra interprets as real failures. so those things need to be restarted <mark_weaver>I'm looking forward to the day when we have better software running on hyudra <ng0>bad news. with my current traffic consumption, at least with one other project, it is hard to find an isp I could go to other than the one I am at now, so getting a guix mirror will happen when I can move my VMs to the first dedicated server with them.. which is anywhere from now to not specified point in the future. <ng0>at that point it will possible not a mirror but a build machine if I can afford it. <ng0>also, does someone know how I accidentally got an unremoveable mark stylized as "*" on a message in Gnus and how to remove it? <mark_weaver>ng0: that means the message is "cached". you probably typed "*". to remove it, type M-* <mark_weaver>see section 3.13 (Persistent Articles) of the Gnus manual <ng0>that's harder to type than i thought with this keyboard <mark_weaver>well, you need the shift key to get *, so on my US keyboard it's M-S-8 <ng0>i tried M * and it doesn't go away, but i'll try again <mark_weaver>M * is different. do you know the emacs way of describing key combinations? <mark_weaver>M-* means hold down the Meta key (often labelled "Alt") while typing * <mark_weaver>so, on a US or UK keyboard, that means to hold down both Meta and Shift while pressing 8 <ng0>no, apparently i don't know it yet :) <mark_weaver>see section 2 (User Input) of the Emacs manual for more on how key combinations are described. <davexunit>mark_weaver, phant0mas: I built avr-gcc manually in a guix environment and it looks correct. <ng0>okay, thanks :) I'll try to remove it somehow <davexunit>I think it might be best to avoid the normal cross-gcc stuff <mark_weaver>ng0: "A" means that you have "answered" that article, i.e. replied to it. anyway, this is not the right channel for basic questions about Gnus. <ng0>no, the marks are just wrong in this case. but you are right. <anthk_>will gnome-maps be in guix soon? <efraim>i don't think i've seen a patch for it on the mailinglist <rain1>anthk_, i think lfam is working on it <davexunit>phant0mas: very strange stuff! I can't reproduce the build I saw within 'guix environment --container' when doing a real package build. <davexunit>I overrided the package arguments so that it only passed the flags that I used for my successful build, but alas, there's still only one libgcc.a <davexunit>in the environment container, I configured with ../configure --prefix=/tmp/avr-gcc --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp <davexunit>the environment itself was created with 'guix environment --container xgcc-avr' <davexunit>strip: Unable to recognise the format of the input file `/gnu/store/1jvqmwimw5b8n1v30mkkkmwd914jhy44-avr-gcc-4.9.3/lib/gcc/avr/4.9.3/libgcov.a(_gcov_execvp.o)' <ng0>gnome keyring daemon was not completely functional, i guess "unsupported or unknow ssh key algorithm: ssh-ed25519" is known? <phant0mas><davexunit> strip: Unable to recognise the format of the input file `/gnu/store/1jvqmwimw5b8n1v30mkkkmwd914jhy44-avr-gcc-4.9.3/lib/gcc/avr/4.9.3/libgcov.a(_gcov_execvp.o)' <davexunit>but from examining the build log, it seems that 'make install' didn't even install the files I'm looking for <phant0mas>davexunit: that's why it says it's unable to recognize the format :-) <phant0mas>which configure flags does guix pass to avr-gcc configure? <davexunit>I overrided them to the exact set of flags I passed in the environment <phant0mas>how can we remove those when building avr-gcc? <davexunit>phant0mas: could it be this? --build=x86_64-unknown-linux-gnu <davexunit>configure flags: ("CONFIG_SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "--prefix=/gnu/store/sc4lxipzpgh1y8v8w0jb5720w1v4fnhz-avr-gcc-4.9.3" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--target=avr" "--enable-languages=c,c++" "--disable-nls" "--disable-libssp") <phant0mas>davexunit: isn't avr-gcc supposed to run on x86_64? <davexunit>phant0mas: yes. just grasping at straws here <phant0mas>could you try passing the same to your non-guix avr-gcc? <phant0mas>it's our only option..we have to nitpick everything until we find what's wrong <davexunit>phant0mas: building with the same flags (sans prefix) <davexunit>I feel the closest I've ever felt to having a working avr toolchain <davexunit>if this reproduces the problem, then at most 2 more build permutations should reveal the bad flag <rain1>im having some problems with my git checkout <mark_weaver>gst-libav is fairly important, because it's needed to watch most videos with gstreamer <rain1>this is new to me: guix build: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux' <rain1>i wan to try building it and see if i can fix it <mark_weaver>rain1: sounds like you didn't run "make" in your git checkout <mik_>I've got a laptop with a hi ppi display.I've tried providing a slim-service with xorg-start-command describing extra-config of the monitor. Is that the best way to go about it? <mark_weaver>mik_: or maybe pass #:resolutions instead of #:extra-config, but yeah. <mark_weaver>mik_: although xorg-server aims to do the right thing without extra config these days, so maybe something needs to be fixed upstream. <rain1>thank you! confirmed not compiling <rain1>bumping gst-libav to the most recent version 1.8.0 lets it compile sucessfully <rain1>I will try building things that depend on ffmpeg and this, and if it all works shall I send a patch with this version number increase? <phant0mas>but the libraries are not getting built at all <phant0mas>maybe there is something in the path of the non guix avr-gcc <rain1>hm what is the command to list packages that depend on a packgae? <phant0mas>davexunit: can you compare the config.logs of the two? <davexunit>hmm not sure how to get the config.log of the guix one <davexunit>phant0mas: I diffed them, they are nearly identical <davexunit>there's just some minor file name differences because 'guix environment' makes a profile <phant0mas>the prefix shouldn't play any role, I have installed a avr-toolchain on my home dir and it still worked <rain1>must gst-plugins-bad depend on qt? ("qt" ,qt) <phant0mas>davexunit: thank you, I am looking at it now <mik_>mark_weaver: my display size isn't getting picked up correctly. The configuration file that gets built looks correct, but I seem to be doing something wrong as every time I reboot the display size isn't correct <mark_weaver>rain1: I don't know about gst-plugins-bad, I didn't add it and I don't use it <rain1>I just saw it in reverse dependencies <rain1>this seems to hang for me, which is odd because it downloaded fine from a browser <rain1>i wonder if anyone uses mplayer though, given mpv <rain1>what about removing mplayer? <ng0>trying to build whois, the style is currently not okay, but I need an advice on why it might fail to continue building: https://ptpb.pw/QkiM <rain1>I have a patch that gets it building sucessfully, will submit it now <phant0mas>davexunit: the only differences are that guix passes CONFIG_SHELL and SHELL and that the environment uses the profile <phant0mas>we have to find how gcc decides when to build the avr libs <mark_weaver>rain1: thanks for the quick updates. I've tested both on i686, and pushed them. <rain1>I'm adding tips to my notes about: check reverse deps with guix refresh -l and to check hydra <davexunit>phant0mas: just sharing in case you wanted to hack anything :) <phant0mas>there must be something that it doesn't get printed in the config.log <davexunit>'guix environment --container' is pretty damn close to what 'guix build' makes... <ng0>oh. nvm the last question, there might just be no ./configure in the dir <lfam>Just wiped the partition table of my "stereo" computer in preparation for installing GuixSD :) <rain1>kyamashita, how did you get around that weird download link? <kyamashita>But it depends on Debian's wmbattery source tarball. <rain1>I was going to suggest yesterday: Why not just take that big repo and make a new repo for each subcomponent? <lfam>I think we've had to do that a few times before <lfam>Use Debian as a source, that is <kyamashita>I contacted them and that was the solution that they said Debian and Gentoo had come up with. <kyamashita>So what should I do with my patch? Is using Debian as a source acceptable, or do we have to come up with something better. <ng0>rain1: can you patch the Makefile or any occurence of /bin/cp ? <davexunit>kyamashita: we have at least one other instance of using a source tarball from Debian <ng0>something like (/bin/cp) (which "cp") or something <kyamashita>Okay. I've sent the patch to the guix-devel mailing list. We'll see how things go. <rain1>I'm having runpath problems when trying to create a package <rain1>it's the bootstrap binary for the mlton SML compiler <rain1>it wants libgmp but i give it that as an input and RUNPATH fails at the end <rain1>would it be wrong to turn off validate-runpath? <rain1>the only purpose of the package is to build mlton from source <civodul`>validate-runpath returns issues with installed binaries, so most likely "real" issues <rain1>yeah it is a real issue, cannot get the binaries towork at all <rain1>I wish it would tell me more than: No such file or directory <mark_weaver>rain1: let's try to avoid patch elf. it basically only works on intel systems <rain1>I might be out of luck on this one <rain1>i just don't realy have an idea how to make it run <mark_weaver>rain1: better to arrange to add "-Wl,-rpath=/gnu/store/.../lib" to LDFLAGS, or something along those lines. <rain1>i think that i can't do that because these binarie were already compiled without that <rain1>maybe I could make my own binaries with that on a different OS (that already has this program) <mark_weaver>ld-wrapper takes care of this automatically in most cases. it would be interesting to know why that didn't work here, but manually adding those flags would be okay <mark_weaver>rain1: to run binaries compiled elsewhere, you could set LD_LIBRARY_PATH before running the binary <rain1>I had a go with LD_LIBRARY_PATH but no success <rain1>this program dynamically links to libc libm and libgmp <rain1>so I tried LD_LIBRARY_PATH=/gnu/store/...-gmp-6.1.0:/gnu/store/...-glibc-2.22 <ng0>if the time for compiling until some programms fail wouldn't be so short, this would be good to read into the sourcecode of the programm.. or read a book.. or do something else.. <ng0>ACTION hits arrow-up + enter for the 30th time this hour