IRC channel logs


back to list of logs

<rain1>kyamashita, yeah I think that will work
<rain1>although it has everything in one repo?
<rain1>that's not ideal
<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>Each dockapp must be built invidually, though.
<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>At least from what I know about Guix.
<kyamashita>I'll be back eventually. Hopefully with a solution.
<rain1>what package provides mount?
<rain1>i guess it's util-linux
<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>what're you compiling?
<rain1>musl libc
<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
<marusich>I'm not sure, I'm afraid
<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>thanks anyway :)
<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!
<rain1>yeah emacs is wonderful
<civodul>Hello Guix!
<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.
<jemarch>civodul: ping
<rain1>for some reason I can't use ldd
<rain1>oh it works on other files, nevermind
***Basstard1 is now known as Basstard`
<anthk_>hello from GuixSD and Gnome :)
<rain1>hi :)
<civodul>hey :-)
<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
<civodul>sunny day, uh? ;-)
<anthk_>civodul, na, it's spring here
<anthk_>(celsius-fahrentheit 36)$1 = 484/5
<anthk_>idk how to convert rational to integer in scheme , btw
<anthk_>or float
<civodul>or (* x 1.)
<anthk_>oh, nice
<paroneayea>morning / tzag!
<paroneayea>(time zone appropriate greeting)
<civodul>hey hey!
<civodul>oh, "tzag"
<paroneayea>"tzag" was popular on the federated social web for some time :)
<civodul>heh :-)
<mahmutov>is there any guix iso with xfce4 desktop
<mahmutov>it writes on distrowatch with xfce4
<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.
<mahmutov>it is bad news
<mahmutov>have you any config file
<mahmutov>that includes any desktop
<bavier>mahmutov: there are multiple examples in the manual
<bavier>including examples with xfce
<mahmutov>also can i fetch binary packages
<davexunit>mahmutov: here is an example of a config with both XFCE and GNOME sessions available
<bavier>mahmutov: see the 'Substitutes' section in the manual
<mahmutov>ok let me loo
<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.
<mahmutov>yes i installed usb image
<mahmutov>i run isp
<mahmutov>at now i am in console
<davexunit>did you use the 0.10.0 image?
<davexunit>(which isn't an ISO, btw)
<mahmutov>usb image
<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
<davexunit>the MOTD should have told you about it
<mahmutov>an xfce4 desktop how much time rsumes to end?
<davexunit>I don't understand the question.
<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
<davexunit>should take way less time than that
<mahmutov>yes i mean that
<mahmutov>a few hours is much time to test a system isnt it?
<davexunit>should be
<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
<mahmutov>if xorg packages are strong
<mahmutov>we can make lightweight desktop
<mahmutov>with openbox+tint2
<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
<mahmutov>for test yes it is boring
<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
<mahmutov>oh it is why it?
<mahmutov>it is the main reason
<davexunit>the mailing list archives surely have something on this subject
<mahmutov>have you ever hear "dracut" initrd maker
<rain1>ill look it up
<davexunit>it's not out of sheer forgetfulness that we don't provide ISOs
<mahmutov>off course
<davexunit>I think a lot of people aren't used to seeing a distro start from scratch these days. ;)
<davexunit>ACTION pines for a working AVR toolchain
<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>that is what troubles me a lot
<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>huh, looking at, libao 2.0 is not even mentioned. the latest stable version that is shown there is 1.2.0
<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>mark_weaver: okay, I will try it.
<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
<davexunit>lfam: thanks
<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
<davexunit>mark_weaver: thank you
<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".
<mark_weaver>lfam: or, more generally, compare any two evaluations with a URL like this:
<lfam>The evaluation page being something like >
<lfam>I mean, ?
<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
<pxc>lbuffer cear
<pxc>whoops lol
<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 :)
<ng0>now it's "A" .. hm
<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
<phant0mas>davexunit: can it link?
<davexunit>I think it might be best to avoid the normal cross-gcc stuff
<davexunit>phant0mas: need to check
<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.
<mark_weaver>maybe try #emacs or #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>whereas my good build has 16
<mark_weaver>davexunit: you removed the post-configure phase?
<davexunit>mark_weaver: yes
<mark_weaver>oh well
<davexunit>completely replaced the arguments field
<davexunit>in the environment container, I configured with ../configure --prefix=/tmp/avr-gcc --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp
<davexunit>per the official avr-gcc documentation
<davexunit>and that worked
<davexunit>the environment itself was created with 'guix environment --container xgcc-avr'
<phant0mas>is the avr-gcc produced from guix stripped?
<phant0mas>davexunit: ^
<davexunit>phant0mas: perhaps that's the culprit!
<davexunit>ACTION looks
<davexunit>something seems to be happening
<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>stuff like that
<ng0>gnome keyring daemon was not completely functional, i guess "unsupported or unknow ssh key algorithm: ssh-ed25519" is known?
<phant0mas>davexunit: which strip is using?
<davexunit>I don't follow
<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>was avr-strip being used?
<davexunit>phant0mas: no
<phant0mas>davexunit: that's why it says it's unable to recognize the format :-)
<davexunit>sure, makes sense.
<davexunit>but it's not the main problem
<phant0mas>yes :/
<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
<davexunit>although guix adds a few more
<davexunit>so maybe those are problematic
<phant0mas>I think the same :-)
<phant0mas>how can we remove those when building avr-gcc?
<davexunit>override the configure phase
<davexunit>I will try it
<mark_weaver>hmm, something recently has broken gst-libav
<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")
<mark_weaver>oh, it's probably the ffmpeg update
<rain1>gst-libav doesn't build?
<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?
<davexunit>will try
<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
<phant0mas>ACTION crossing fingers
<davexunit>if this reproduces the problem, then at most 2 more build permutations should reveal the bad flag
<mark_weaver>rain1: apparently so. see <> and <>
<mark_weaver>(failures on x86_64 and i686)
<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'
<mark_weaver>videos using the most widely used codecs, that is
<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
<mark_weaver>rain1: np!
<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?
<davexunit>phant0mas: damn. the build is *fine*
<davexunit>16 libgcc.a
<phant0mas>it's something else
<davexunit>using the same exact configure flags
<phant0mas>something in the build system
<davexunit>but what????
<mark_weaver>rain1: sure, sounds good, thanks!
<phant0mas>that's the thing I cannot understand...
<phant0mas>but the libraries are not getting built at all
<phant0mas>that is what confuses me the most
<phant0mas>maybe there is something in the path of the non guix avr-gcc
<phant0mas>which isn't in the guix one
<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?
<rain1>ah guix refresh -l
<davexunit>phant0mas: yeah I can try
<phant0mas>davexunit: it's going to be messy..
<davexunit>hmm not sure how to get the config.log of the guix one
<davexunit>that build was successful
<phant0mas>delete it and start building it again
<phant0mas>and before it finishes stop it
<phant0mas>guix gc -d
<phant0mas>guix gc -d /path/to/...avr-gcc
<davexunit>phant0mas: and use -K, right?
<davexunit>phant0mas: I diffed them, they are nearly identical
<phant0mas>davexunit: only the paths different?
<davexunit>there's just some minor file name differences because 'guix environment' makes a profile
<davexunit>and the prefix is different
<davexunit>once again, I am at a loss.
<phant0mas>the prefix shouldn't play any role, I have installed a avr-toolchain on my home dir and it still worked
<davexunit>the differences seem insignificant
<phant0mas>can you send me the two logs?
<davexunit>phant0mas: yes
<rain1>must gst-plugins-bad depend on qt? ("qt" ,qt)
<davexunit>phant0mas: sent you an email
<phant0mas>davexunit: thank you, I am looking at it now
<mik_>mark_weaver: I thought I could follow these directions described in the arch wiki:
<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: mplayer also failed to build
<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
<mark_weaver>rain1: iyzsong added gst-plugins-bad
<rain1>guix download
<rain1>this seems to hang for me, which is odd because it downloaded fine from a browser
<efraim>1.3.0 has been out for a bit
<rain1>guix is still using 1.2.1
<rain1>i wonder if anyone uses mplayer though, given mpv
<rain1>seems troublesome
<rain1>what about removing mplayer?
<rain1>that scared it into working
<ng0>trying to build whois, the style is currently not okay, but I need an advice on why it might fail to continue building:
<mark_weaver>I'd prefer to keep mplayer for now
<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>everything else is the same
<phant0mas>that cannot be it
<phant0mas>we have to find how gcc decides when to build the avr libs
<davexunit>the rabbit hole goes deeper
<davexunit>phant0mas: for the record, this is what I'm working with in the (gnu packages avr) module:
<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
<phant0mas>davexunit: they seem perfectly fine to me
<phant0mas>the problem is with avr-gcc
<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
<phant0mas>davexunit: thank you :-)
<davexunit>it's gotta be something silly
<davexunit>but it's baffling me.
<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 :)
<kyamashita>So I have a working definition for wmbattery.
<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.
<rain1> does anyone know what to do here? the install target wants /bin/cp
<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
<davexunit>it may be OK
<rain1>I'll try that
<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
<rain1>maybe I have to do this 'patch elf'
<rain1>seems scary
<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
<mark_weaver>you need to add /lib to those paths
<rain1>oh i did try that too
<rain1>thats my actual command
<rain1>+ package so far
<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