<civodul>rekado: the xgcc-armhf is what mark_weaver used to cross-compiled the bootstrap binaries, so it's capable <rgrau>Hi. I have a question regarding updates on guix. let's say there's some emacs mode (it's derivation depends on emacs). and current emacs is 24.5. all is good. I have both installed. Then, emacs 25 comes out, and the derivation is updated. A new emacs mode is created, and now, the derivation depends on 25. What happens if I install that new emacs mode? I'll get emacs 25? and , will emacs 25 see the old mode? <rgrau>I don't know if I made myself clear <rgrau>but the same would happen with ruby gems or perl modules when new ruby/perl comes out <iyzsong>rgrau: install the new mode doesn't install the new emacs into profile, but if substitutes is not used, as emacs-no-x 25 is required (but not install) to build the new mode, it will be download or build. <rgrau>ooks, but then, put it in mysqld and mysqlclient. I install mysqld, it gets a new version, mysqlclient gets repackaged, and then I 'package -i mysqlclient' . It can lead to a non-working mysqlclient... right? <rgrau>(the same with emacs mode, but modes are less likely to fail, but compiling against one version or another...) <lfam>mark_weaver: Again, I'm sorry for the mess :( <NiAsterisk>hm. installing guix on the first debian server, guix package -i glibc-locales pull linux-libre-headers , this is an almost untouched debian system with GNU/linux not linux-libre, what are the header files needed for? <NiAsterisk>or, would this be not pulled in when I had linux-headers on the system? <iyzsong>guix packages don't use system libraies at all, and glib-locales have depends of linux-libre-headers.. <NiAsterisk>in other words, does linux-libre-headers and debian-linux collide, or don't they care? <NiAsterisk>I was just a bit puzzled about linux and linux-libre <NiAsterisk>I wished I could just use guixsd. well, maybe when I switch from vservers to colocation. <NiAsterisk>btw, anyone at fosdem? I might go saturday if booking trains are still inexpensive next week. <rekado>I'll be at Fosdem (still need to book train tickets). There's a Guile and Guix devroom, so many of us will be there to give talks. <NiAsterisk>I've seen those, that's what I'm mostly interested in, sunday had some talks which read alright, but so far not enough to make me book a bnb or something <NiAsterisk>hm. is there some function with apt-get/cache debian to list all installed packages, like the world file in gentoo? <NiAsterisk>very offtopic, but I seem to not disturb any discussion right now. <efraim>Package polkit was not found in the pkg-config search path. <efraim>Perhaps you should add the directory containing `polkit.pc' <rekado>NiAsterisk: glibc is the interface between libraries and kernel calls. The kernel calls usually don't change much over many releases, so the version difference between the running kernel and the kernel headers usually isn't very important in most cases. <davexunit>help-guix has been... interesting, thus far. <efraim>although it did prompt me to look at redmine again <davexunit>I guess some people just aren't going to understand guix no matter how we try to explain <rekado>"I strongly encourage you and other GUIX contributors to halt all Java packaging efforts immediately." <davexunit>so, you trust a binary that was signed by the author, with no way to actually reproduce that binary <davexunit>but you don't trust a guix-built binary, which can be tested for reproducibility. <NiAsterisk>that's as weird as the people here shooting fireworks and rockets in the sky for hours when the sun is still shinning <davexunit>hey folks, would anyone care to see if they could reproduce an issue with the new version of guile for me? <davexunit>for starters, get a new guile REPL up and running: <davexunit>guix environment --ad-hoc guile-next -- guile <davexunit>(= (sizeof (list uint32 '* int)) (sizeof (list uint32 '* int int))) <davexunit>if you look at those lists of foreign values, you'll notice that they are indeed different <rekado>I don't like that udev rules must be part of the system configuration. <rekado>I'd like to be able to install them with packages. <rekado>maybe it's better the way it is. <efraim>got connman packaged, that leaves writing the service file <davexunit>ACTION attempts to make a docker-compose package <davexunit>finally got all of my year-end donations done <rekado>it would be convenient for us Europeans if we could also donate for Guix through the FSFE. <davexunit>swapping out one broken approach for another! <paroneayea>first I thought they were doing flat dependency list <lfam>Hmm, perhaps my message hurt more than help on help-guix. But I don't think it takes expert knowledge to see that implicitly trusting unreproducible binaries is a bad idea <lfam>It appears that person didn't even understand that how Guix / Nix use the store as CAS with a symlink farm to create profiles. That was the very first thing I learned when I first heard of Nix a couple years ago. It didn't even occur to me that that would be an iusse. Maybe we should take some of those pretty slides I keep seeing used and make a little "cartoon" explainer for the web site <davexunit>lfam: sometimes, there's nothing you can say to help a situation. guix is clearly not what that person wants, and that's OK. <lfam>It may not be what they want right now. They want things to be as they are and we failed to communicate the benefits of our system <davexunit>paroneayea: yeah it's definitely weird, but did you see the part about how now the results of the node_modules directory now depends on the order of dependencies in package.json? crazy! <paroneayea>lfam: yes I think it's true that it's not immediately obvious why guix is interesting to most users coming from another system <paroneayea>(I also think "the emacs of operating systems" is a nice slogan for those of us who love emacs and understand how its a liberating come-and-hack-me system, but it might not be the clearest slogan to most of the world... :)) <lfam>I love that slogan and I don't even use Emacs ;) The point is quite clear to me. But I guess that it's meaningless to professional Java developers. <paroneayea>it won't be clear to people who are in a kneejerk anti-emacs camp. I think it's worth winning those people over but it might not be guix's primary goal :) <lfam>No, that's a bad goal. But winning over everybody else is a good goal! <davexunit>and I totally agree with this about how package management devs always get hassled about how things work on windows: <davexunit>"Why do dev communities have to continually pay the Windows tax? If Microsoft keeps insisting on being an outlier in the world of OSes, shouldn't they be the ones burdened?" <rekado>ACTION upvotes davexunit's comments on HN ***quigonjinn` is now known as quigonjinn
<rekado>I'm trying not to have to install the cross-compiler toolchain. I just want to use it as an input. <rekado>now when axoloti triggers a firmware build the cross-gcc complains about not being able to find a header. <rekado>this is what it says: /gnu/store/klh3ihqx5gln3dzvjpp7ixl9hz1a10bx-gcc-cross-arm-linux-gnueabihf-4.9.3/lib/gcc/arm-linux-gnueabihf/4.9.3/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory <rekado>this header contains this line: # include_next <stdint.h> <rekado>does this mean I need to set some environment variable first? What stdint.h does it need? <rekado>should the cross-gcc for ARM come with its own include/stdint.h? <efraim>does anyone use msmtp? should it have an entry in gnu/services/mail.scm? <efraim>i tried installing it with guix on debian and it looked for /gnu/store/...msmtp/etc/msmtp.conf <efraim>I figured it was a service that didn't work outside of guixsd, but then I didn't see it in gnu/services/mail.scm <efraim>well either way connman builds, but I'm going to need to work on it a bit more to make it actually work on guixsd <rekado>bleh, I hoped to get sound out of the axoloti tonight, but with this compiler error I probably won't be able to do this until next year... <efraim>hmm, looks like I forgot to set sysconfdir=/etc and localstatedir=/var, and then touch-up the makefile <rekado>I assume that glibc's include dir must be in the CPATH <rekado>ah, better; added the cross-glibc include dir to CROSS_CPATH. Now it's stuck with missing fastmath.h, but I'm getting there... <rekado>hmm, no fastmath.h in the whole store. <rekado>argh! "collect2: error: ld terminated with signal 11 [Segmentation fault]" <rekado>ChibiOS compiles but it cannot be linked. <sprang>something misconfigured on their end? <mark_weaver>unfortunately, it seems fairly common for HTTP servers to violate the requirements, and most HTTP clients are permissive. <mark_weaver>it seems likely that guile needs to accept garbage HTTP headers, since everyone else does <sprang>is it something they should be easily able to correct on their end? I'm not very web server savvy. <rekado>also getting this: arm-linux-gnueabihf-ld: error: required section '.rel.plt' not found in the linker script <rekado>I wonder: is this the right cross compiler for this chip? <rekado>trying to build a new cross-compiler for triplet "arm-none-eabi" <rekado>I see that there's a commented definition for xgcc-armel in cross-base. <davexunit>has anyone else noticed the number of people that dismiss nix and guix because it doesn't work on windows? <davexunit>there's no hope of having packaging sanity on a system that you install as a big blob!