<janneke>ah.. it seems twice in %desktop-services <janneke>when i comment-out all services and %desktop-services also, no error <mark_weaver>janneke: (elogind-service) is included in %desktop-services. are you also including another copy of 'elogind-service' elsewhere? <janneke>mark_weaver: not that i know (i did not know file-systems created services) <janneke>mark_weaver: i now have: (services (cons* %desktop-services)) <civodul>there must be two elogind services or something <mark_weaver>janneke: can you show us an OS config that leads to the error? <dvc>rekado: I once debugged some C on a verilog riscv core using gtkwave to read instructions. I felt pretty badass xD Until I figured out that my interrupt handling was crap =P <janneke>mark_weaver...sure, cleaning out some cruft <brendyn>mark_weaver: Should I run guix package -r guix now that I'm using the git repo? <mark_weaver>brendyn: you still need a 'guix' in your PATH or else you'll need to run ./pre-inst-env <brendyn>I didn't realise 'guix' was 3 lines of shell script <brendyn>But that goes to /gnu/store/4w989lrxsh2pvk8z95lbjg3ysahnw0id-guix-0.11.0-1.4420/bin/.guix-real <sneek>lfam, efraim says: I remember you said before that borg is faster than attic. Over the same data set on this machine it's 3-5 times faster <mark_weaver>brendyn: that's a wrapper created by 'wrap-program' in the 'guix' package within Guix. search for 'wrap-program' in gnu/packages/package-management.scm <brendyn>I suppose this guix is in the store, but it comes from the git repo after I ran guix package -u? <mark_weaver>brendyn: not including those wrappers, which merely arrange to set environment variables, the actual 'guix' script is in scripts/guix in the guix source tree <mark_weaver>brendyn: that will be a somewhat older version of guix than the one in your git checkout. typically the newest 'guix' package within guix will be bound to the 'guix-devel' variable in gnu/packages/package-management.scm <mark_weaver>unfortunately, for technical reasons, every 'guix' contains a 'guix' package that is older than itself. <janneke>sneek: later tell civodul, seems file-system-/run/systemd is twice in %desktop-services <mark_weaver>the reason is that every package definition in guix includes a SHA-256 hash of the source code for that package <janneke>ACTION -> zZzzz more on rottlog service tomorrow... <mark_weaver>suppose we wanted 'guix-0.11.0' to include a package for 'guix-0.11.0'. we would need to include the SHA-256 hash of guix-0.11.0.tar.gz within that same file. <brendyn>I see, so you've secretly broken the sha256 algorithm <mark_weaver>yeah, it would involve solving an equation of the form x = sha256(compress("prefix" ++ x ++ "suffix")) <brendyn>Ok, so do you have to do something special when you commit new versions of guix? like make a commit with a real change, then make another commit with nothing but the hash changed so guix can package it's self with only the minimal hash change? <mark_weaver>having said that, I can think of various ways to work around this issue, but it's a bit messy and I haven't gotten around to implementing it. <mark_weaver>brendyn: as long as you have the ~/.config/guix/latest symlink pointing to your working tree, it doesn't matter <brendyn>Unless you make changes to the wrapper script? <mark_weaver>look at the actual 'guix' script, in scripts/guix (guix.in for the true source file) <mark_weaver>it looks for that symlink, and if it exists, it sets the load paths accordingly before running any other guix code. <mark_weaver>so, in practice, the 'guix' script will use the code pointed to by the symlink. <mark_weaver>brendyn: I don't understand your comment "<brendyn> Unless you make changes to the wrapper script?". the wrapper script is in /gnu/store, which must never be mutated in any way. <brendyn>Ok so effectively the wrapper script is so simple it will never be updated? <mark_weaver>the wrapper scripts are automatically generated to refer to the precise store paths, as part of building the package in guix. <mark_weaver>brendyn: it would help to understand why you are motivated to think about changing the wrapper script. what problem are you trying to solve? <brendyn>Ok but suppose I've just finished running `make', guix isn't yet in the store. <brendyn>I don't want to modify it, I'm just trying to figure out what is actually running on my computer <brendyn>For example, I still have an old version of the daemon running, but it has had no issues yet <mark_weaver>brendyn: when guix is not installed, you can run both 'guix' and 'guix-daemon' by prefixing the command with ./pre-inst-env <brendyn>So I run guix package -u and presumably that finally puts my version of guix into the /gnu/store <mark_weaver>brendyn: when you install or upgrade the 'guix' package, it will use the latest version of 'guix' that is in your available package definitions. and typically that's the package bound to the 'guix-devel' variable in gnu/packages/package-management.scm, which we only update very occasionally. <mark_weaver>so, that 'guix' will use old packages, *but* only in the absense of ~/.config/guix/latest <brendyn>Ok, so by default guix will know that there has been no change <mark_weaver>when ~/.config/guix/latest exists, the 'guix' script arranges to use the code from there, which in this case will be your guix repo. <brendyn>That is, the /gnu/store/.../guix script arranges that <mark_weaver>right, the 'guix' package will not need to be rebuilt very often <brendyn>guix will check the the derivation and conclude it already has the same version unless I run guix build --check guix ? <mark_weaver>the 'guix' script was carefully written to avoid loading any modules from 'guix' until after the load path has been modified. <kingcons>rekado: That did the trick. Thank you! (Boy, I was away for a while..>) <mark_weaver>brendyn: right, the 'guix' package will only need to be rebuilt when we update the 'guix-devel' package, or some package that 'guix' depends on is updated. <mark_weaver>brendyn: right, although the true source code is in scripts/guix.in <mark_weaver>the ./configure script generates scripts/guix from scripts/guix.in, substituting @prefix@ et al <brendyn>Would it be better to have guix output the --help output when `guix' is called with no arguments? <kingcons>Hey folks. Did a system reconfigure and happily have wifi going. :) <kingcons>The pulseaudio package is installed systemwide now but doesn't seem to be running. I couldn't find any documentation about a service that needed to be installed. Is there some documentation I misesd? <kingcons>The only other problem I'm having is that XFCE login only works for the root account, not my added user. Passwd has been set and login with my user works in a tty. ¯\\_(-.-)_/¯ <lfam>kingcons: I don't really know how pulseaudio works but, for me, it gets started on demand when I play something in MPD <lfam>And, can you send a message to bug-guix@gnu.org about the XFCE issue? <kingcons>Hmm. Yeah, I need to turn in but I'll send a message tomorrow morning. <kingcons>One other question lfam, do you know if many folks manage config files with guix or just git and copy dotfiles here and there? <lfam>kingcons: You mean like personal dotfiles? <kingcons>I figure most people are still managing dotfiles manually but wanted to double check. <lfam>I use git and symlink them into place <brendyn>Is there a way to have "optional" dependancies of a package? Is this done with outputs? <mark_weaver>brendyn: we have no concept of optional dependencies, but sometimes we provide more than one variant of a package, e.g. emacs-minimal vs emacs-no-x vs emacs-no-x-toolkit vs emacs, or qemu-minimal vs qemu, etc. <mark_weaver>and typically we use the 'inherit' mechanism to reduce the duplication between the package descriptions <brendyn>mark_weaver: Hmm ok, I'm packaging duplicity and it has a lot of options like python-dropbox <mark_weaver>outputs can be used to reduce the amount of stuff a user needs to install when using binary substitutes <brendyn>It seens that rsync shouldn't need to be a dependancy since it's just using it like via POSIX calls or something like that? <mark_weaver>but when actually building the package from source, all outputs are always produced. <mark_weaver>brendyn: nothing like 'rsync' is available in POSIX itself. <mark_weaver>I'm not sure I understand why you think it wouldn't be needed. <brendyn>I mean, rsync can use ssh, but ssh isn't a dependancy of rsync <mark_weaver>although I confess I don't know (or remember?) if duplicity uses rsync <mark_weaver>ah, yes, sometimes programs find other programs by searching for them in PATH <mark_weaver>sometimes that's legitimate, e.g. that's how 'emacs' finds most of the programs that its various packages will sometimes make use of. <brendyn>Quite a lot. Most people will only use one or two. Why structure do you recommend? Just make people install everything? <mark_weaver>however, in order to help ensure that if a program works today, it will continue working tomorrow and be relatively insensitive to the other packages you have installed in your profile, etc, we often prefer to add explicit inputs and to arrange for programs and libraries to find their dependencies by absolute file name in /gnu/store/... <brendyn>So with outputs, will there just be some things that a package will fail to find if the substitute is used because they weren'd installed? <mark_weaver>I would advocate arranging for duplicity to find its librsync (or rsync?) via absolute file name <mark_weaver>brendyn: examples of extra outputs are 'doc', which contains large documentation files for some packages, and 'debug' which contains the debugging information for some libraries. <mark_weaver>our git package has 'gui' and 'svn' outputs, which allows the transitive closure of run-time dependencies to be greatly reduced when you don't need those. <brendyn>And they shouldn't have dependancy problems since git isn't ever going to call git-svn on it's own accord? <mark_weaver>what I know is this: if a program tries to find other programs by searching in PATH, then guix makes no guarantees that the program it looks for will be there, and we try to avoid this mode of programs finding other programs. <mark_weaver>if program A accesses program B by absolute file name in /gnu/store, then guix will *ensure* that program A cannot exist in the store without program B being there as well. <brendyn>Well I'll just do the best I can given time and then post patches to the mailing list <mark_weaver>if it uses librsync, then I guess it will be automatically handled <mark_weaver>guix automatically adds rpaths to linked programs, referring directly to its shared libraries by absolute file name. <brendyn>ACTION is reading Stallman learn about Docker on the Emacs mailing list ***tschwing_ is now known as tschwinge
<rekado>I currently have gcc-arm-none-eabi without a libc, then use that to build newlib and newlib-nano. <rekado>The next step seems to be to build gcc arm-none-eabi with newlib as its libc, but this fails with: configure: error: cannot compute suffix of object files: cannot compile <rekado>the sans-libc arm-none-eabi compiler seems to work when compiling small stuff <alezost>brendyn: hi, what problem do you have using "guix.el" from a git checkout? <rekado>I’ve been using it to build “patches” for the Axoloti. But building the firmware (using ChibiOS) fails. <ng0>this email hoster bug is weird.. i now receive email from one list… gnu.org, gnupg.org and everyone else is still not showing up -.- <ng0>they are in the same timezone.. i hope this resolves today. <rekado>I'm trying to update an older GuixSD installation. When I do "make clean && ./configure --localstatedir=/var && make" I get an error about GUIX_CONFIGURATION_DIRECTORY being undefined. <rekado>Does anyone know what this is about? <rekado>oh, needed to re-generate the configure script. <efraim>guix build -S foo --check is MUCH faster on a spinning harddrive than `guix gc -d foo; guix build -S foo' <gunoob1>hi there, i am pretty unfamiliar with guile/scheme, but i encountered the following problem: <gunoob1>in the documentation there is a suggestion to use the following syntax to remove the avahi service: <gunoob1> (eq? (service-kind service) avahi-service-type)) <gunoob1>but with the vanilla config file avahi-service-type is not defined <gunoob1>searching around i found that avahi-service-type gets defined in services/avahi.scm <gunoob1>when i use that module, the syntax above works <gunoob1>but i guess that is not the right way <gunoob1>also... i needed to use the module (use-modules (srfi srfi-1)) to get that running <rekado>gunoob1: no, I think you're right. <rekado>srfi-1 provides list editing procedures like "remove" <rekado>(use-service-modules ...) is needed to load the definitions. <rekado>we should make this clear in the manual. <rekado>would you mind sending this to bug-guix@gnu.org, so that it won't be forgotten? <gunoob1>maybe it is useful to include such things in the template... <gunoob1>anyway.. just started with guix and it terrific <gunoob1>i will post a report on bug-guix@gnu.org . cu & bye ***contrapumpkin is now known as copumpkin
<davexunit>does anyone here have a vested interest in openblas? <davexunit>guix refresh said that 86 packages would be effected <davexunit>at least one of which being my own custom package that we dont' need to worry about <davexunit>it causes libreoffice and julia to be rebuilt. should it be applied to core-updates or master? <bavier>but if it rebuilds libreoffice, it should maybe go on core-updates? <davexunit>I'm checking if libreoffice even builds currently <davexunit>I've never been able to successfully install it <davexunit>it builds on x86_64 only, according to hydra. <bavier>so, I tried adding -DBUILD_SHARED_LIBS=TRUE to cmake-build-system's default configure flags <janneke>ACTION finally gets vm boot messages to console/emacs shell buffer :-) <bavier>mostly it helps output size of llvm, clang, allegro-4, and bullet <bavier>but... it breaks blender, ctl, minetest, aseprite, conky, and withershins <bavier>for llvm and clang, output size is reduced by 80% <bavier>I think most of the other 115 packages that use cmake-build-system default to shared libs on their own <davexunit>bavier: maybe jsut add that flag to llvm and clang for now? <davexunit>btw, I don't know if I publicized this much here, but my company is now using Guix to build and deploy some complicated software on production servers. <davexunit>and so far it's been a big success. server build times are down from an hour to ~10 minutes because the complicated custom software is now being built and served from another build machine running 'guix publish' rather than being built from source on each node. <bavier>davexunit: yeah, I'll probably go that route <davexunit>the reason I was asking about openblas earlier is because openblas is an integral part of the stack <bavier>but it was nice to survey the terrain <davexunit>the consultants we are working with try to make us use ATLAS <davexunit>but I got everything to work with OpenBLAS instead. yay for determinism. <bavier>davexunit: ATLAS is in most cases vastly inferior <davexunit>there was just one gotcha with openblas. we had to set an environment variable so that it wouldn't use multithreading in an already multithreaded application <davexunit>we saw big performance problems and profiling revealed that those problems didn't exist with the atlas version built without guix, so I got worried that all of my work was going to be thrown away. <bavier>davexunit: sure. There's a build option to disable multithreading if that would be more useful <davexunit>the environment variable was nicer, I think, because you don't need a separate build. <lfam>davexunit: That's awesome! 1 hour to ~10 minutes! <janneke>davexunit: nice! i'm in the process of transferring to guix builds in my company after having used it myself <davexunit>lfam: of course, using .deb packages would have accomplished the same goal, but the tools for making and building packages are comparatively terrible <davexunit>and this software is complicated. using guix made it soooo much easier to have a reproducible build. <lfam>Right, there are lots of ways to avoid building everything from source every time, but Guix is a pretty good way! <davexunit>I should be able to upstream a few things from this, like packages for Kaldi and OpenFST <lfam>Just like that other k*di package? ;) <davexunit>we're using forked versions of them, but it should be easy enough to use the upstream sources. <lfam>Bad luck to name things with that pattern ;) <davexunit>I also have some packages for the edinburgh speech tools <lfam>Any end-user facing speech synthesizers? <lfam>AFAIK we don't have a speech synthesis tool yet <davexunit>I'm pretty ignorant of this stuff, honestly. <jmd>lfam: Isn't emacsspeeak packaged? <lfam>Festival looks really interesting: "it offers full text to speech through a number APIs: from shell level, though a Scheme command interpreter, as a C++ library, from Java, and an Emacs interface." <davexunit>bougyman: like Guix, it is also written in Guile Scheme. <jmd>davexunit: Somebody ought to come up with a utility called "Sheep Gnuherd" <lfam>davexunit: If you have packaging for festival that is not yet ready to be merged in Guix, but can be shared, I'd love to look at it :) <lfam>I found espeak really hard to build from source. I should take another look at it, but since you already have this festival thing, I'm eager to try it :) <davexunit>lfam: let me just review and make sure there's nothing I can't share in here... <bougyman>davexunit: do you have a ps aux|head -2 handy? <lfam>I have to go, but feel free to email me :) <davexunit>bougyman: sorry, I'm not on a GuixSD machine right now. <bougyman>trying to see how it compares with runit, footprint and feature wise. <bougyman>USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND <bougyman>root 1 0.0 0.0 1044 4 ? Ss Sep04 0:04 runit <davexunit>my guess is that shepherd will use more resources <jmd>There's a speech synthesis package somewhere that makes a very good job of emulating a large number of different accents. <jmd>I can't remember what it is called. <bougyman>It looks like runit could go on guixsd just fine to replace shepherd. <davexunit>so replacing pid 1 would require rewriting lots of stuff <davexunit>the big one being that shepherd services are Scheme code <davexunit>which we can easily manipulate programmatically in guix <jmd>If somebody really wanted, I suppose there is no reason why they couldn't device a shepherd service to run <their-favourite-sysinit> , and then use that for most services. <davexunit>jmd: yes, that would be possible, but different. <jmd>They could make a namespace where it was PID 1 !! <jmd>"In the universe that I have created for myself I am the greatest of all!!" <brendyn>Would it be possible to map deb packages onto /gnu/store so debian can be installed within GuixSD allowing one to run any debian package with all it's debian dependencies? <davexunit>brendyn: it's theoretically possible, you could use a container for such a purpose <davexunit>couldn't say what the implementation details would be <jmd>I suppose it could be used as a selling point to entice debian zealots. But I think it would be a lot of hard work. <davexunit>it would be easy enough to make a derivation whose inputs were a bunch of .debs and the relevant apt tools and whose output was a debian file system tree <davexunit>from there you could use a container to make that output directory the root directory and run your debian stuff <jmd>But I think there are enough people who despise systemd that they are clammering to get off the debian boat. <brendyn>Does GNU shepherd purport to be superior in design? <davexunit>shepherd needs lots of love still, but it's got the right foundation <davexunit>I like using shepherd because I can write actual code for my services <davexunit>I run a shepherd instance as my "dave" user on my machines for managing things like gpg-agent, emacs --daemon, offlineimap, mpd, etc. <jmd>brendyn: In other words, davexunit is saying "No is doesn't *purport* to be superior. It just *is* superior." <davexunit>I also use it at work to manage all of the development servers I have to run <davexunit>it is superior in this way, but it *does* lack features that systemd and others have <jmd>davexunit: What does it lack that you would like to see? <davexunit>but systemd and co. will never have the programmability that shepherd has, but shepherd can have the features that they have. <jmd>... by which you mean ... ? <davexunit>I want Guix to get more institutional adoption so I can become a consultant and be my own boss. :) <jmd>I just want to win lotto and not have to work again. <jmd>Unfortunately, my current strategy of not every buying any lotto tickets, hasn't yet paid off. <brendyn>Why was it decided to put packages together in single files based on topic? Would it not be better to have a file per package? <brendyn>jmd: Don't worry, the lottery is all abuot /hope/, but you don't need to pay for that, just hope anyway <jmd>It's a fine line to call. Some packages are trivial. In those cases a file per package would be silly. <brendyn>I wonder if it is possible to not have to do lots of #:use-module, if it was just automatic <jmd>But I agree. The current arrangement is perhaps suboptimal. <brendyn>There is talk about aleviating the mailing list and moving to bug tracker type system. Having individual files might help with that <brendyn>Anyway, basically every other package manager ever uses individual files <jmd>Suggest it on the mailing list. <brendyn>I think I'll just go passive aggressive and package so many things that the mailing list gets conjested and we have no choice <bavier>there's overhead to individual files <nckx>brendyn: please do! :-D Everybody wins. <efraim>i've thought about packaging debootstrap, all the downloaded .debs get stored in /var/cache/apt/archives <brendyn>nckx: I've been analysing the git repo. I'll built up a collection of packages and wait for peak hour on Saturday and BAM! <davexunit>efraim: but if you downloaded debs with that it would have to be a fixed output derivation, which seems unknowable <efraim>ah, but I could just package debootstrap, not package a debian base system <efraim>debootstrap iirc is just a perl script <brendyn>alezost: Well I just have the issue that when I try to build a package I get things like license:gpl2 possibly undefined, and so I have to go round looking for scm files definining them and run geiser-eval-buffer untill I finally have every available to compile my package <alezost>brendyn: ah, you are trying to build your package from a file which does not define module, right? <brendyn>alezost: It has a define module. maybe it lacks all the needed use-module ? guix build <package> works file but C . b often doesn't <alezost>brendyn: is it your module? what is its name? <alezost>brendyn: try this: "M-x run-guile" and ",use(<your-module>)" there <brendyn>*sigh*. Everything seems to start working only after I ask someone for help <alezost>brendyn: I didn't get it, does ",use(<your-module>)" work in a usual guile repl? <brendyn>It seems I didn't properly evaluate the define-module part <brendyn>I need to do geiser-eval-buffer instead of just C-M-x <brendyn>How can I do C . b but add options --check --rounds=2 ? <alezost>brendyn: you can use "C-c . u" to use the current module; "C-c . b" is very simple, it does not provide any additional options <brendyn>Ok, but it outputs ,run-in-store (build-package par2cmdline #:use-substitutes? #t #:dry-run? #f) <brendyn>So I should be able to modify that to do it? <alezost>well, you can try to use #:rounds, not sure if it would work though <alezost>in theory it should support the same keywords as 'set-build-options' procedure from (guix store) module, but no one ever used it <alezost>I mean you'll be the first person who will try to use any additional keywords :-) <brendyn>Oh lord, how for have I strayed from the path? <brendyn>I generally can't understand guix code. All this monad stuff and SRFI's I've never seen before <alezost>I've never even tried to understand monads :-) <brendyn>Interesting. Looking at the code, it's like the stuff I'm trying to do simply hasn't been coded yet <brendyn>But --check exists, so that must be understood somewhere <alezost>--check option is handled by (guix scripts build) <davexunit>brendyn: there is a procedure for setting the build options <brendyn>Yes I'm currently reading the definition for it <alezost>if I understand it right, "--check" leads to calling 'build-derivations' with 'build-mode' <brendyn>It seems like it should be a common problem. guix won't build a package that's already built without it <alezost>brendyn: by default, 'build-derivations' is called with a 'normal' build mode, while if --check is specified, it is called with 'check' build mode <efraim>cve-2016-714[23] are about incorrect SASL authentication <brendyn>Right, but build-package makes no reference to that. <efraim>should we be checking gsasl and cyrus-sasl? <alezost>brendyn: look at %options in (guix scripts build): "--check" adds 'build-mode' argument, then it is handled by 'guix-build' procedure <alezost>guix-build is a procedure in (guix scripts build) module, isn't it? <brendyn>Ok but none of that means anything to me <brendyn>I suppose I should continue going through SICP <davexunit>if you want to call build-derivations and do the equivalent of 'guix build --check', then the third argument needs to be (build-mode check) <brendyn>Ok well maybe I'll figure it out one day. <brendyn>Infact even the command line version is odd. guix build --check --rounds=3 par2cmdline only compiles once. <catonano>brendyn: it takes some time. I understand your frustration <catonano>finishing the SICP is a good idea indeed <brendyn>catonano: yep. I want to make basic usage of guix as simple as pacman. <catonano>as for the interaction between Emacs and Guile, I messed around with Emacs-Live (or maybe it's called Overtone) for a while. It's an Emacs layer for interacting with clojure <catonano>the fundamental ways of interacting with an "inferior" interepreter are the same but are better illustrated in the clojure community <brendyn>I've looked at Clojure but not really got into it. Decided I'd rather make software on the guile vm than Java vm <catonano>right. I see the attractiveness. I was just illustrating a learning path. <brendyn>But at the same time it's like there are all these theoretical advantages that I've yet to actually figure out how to use, like stepping through code. and guile error messages are difficult because it'll be like "clusterfuck in ice-9, you suck" <catonano>the java vm is heavy and the clojure community at large is not as sensible towards freedom issues. But technically they hhave something to say <catonano>well, error messages can be frustrating in the cloure world too ;-) <brendyn>What language tends to have good error messages? <catonano>for example I don't know how to step through the code with Guile, never attempted <catonano>but don't take my word for it. I'm not an expert <catonano>in fact a series of screencasts demonstrating Guile scheme and Geiser would be extremely helpful <janneke>i need a web proxy for automated testing <janneke>it seems that we have tinyproxy and polipo <janneke>tinyproxy does not support authentication, which I would like to include in my tests <janneke>polipo does but its web page states that it's obsolete and not maintained <taylan>I just did guix pull and `guix package -A | wc -l` says exactly 4000 :D we're past that according to the ML though, wonder what that's about. <davexunit>maybe ludo had some stuff on $GUIX_PACKAGE_PATH <janneke>demotri: we don't have wwwoffle yet and neither has debian? <mark_weaver>janneke: it can be configured to disable filtering for selected URLs, so you could surely disable filtering globally if desired. <janneke>any idea why none of these proxies in guix comes with a service? <efraim>bavier: don't forget your mlocate patch <davexunit>janneke: because no one got around to writing one? <janneke>davexunit: OK...packaging is probably most of the job <janneke>although if you do all that effort to package it and not use it yourself...just wondering <bavier>efraim: thanks; I can push that part of the patch series; I was wanting to write some tests for the "tomb" package before pushing that <demotri>janneke: Sorry, thought you are willing to add a new package, if it's worth it. And didn't know that it is no longer in Debian. When I used to use Debian and I had a modem, it definitely was there :-) <janneke>demotri: np, i am considering it. currently i'm using squid on ubuntu, but i'm not too happy with that and hesitant to package it. <bavier>I wonder if debian thought wwwoffle was dead <janneke>demotri: i'd rather not package something new esp. if we already have better alternatives. <bavier>just a 3.5 year stretch between last two releases <janneke>ACTION has some ambivalent feelings about the > 4000 cheers <demotri>It was the first time since years that I was on Bischop's site again and was surprised that after years there is a new release. <ng0>:me has started packaging the way towards USD by pixar :) <rekado>I know I wrote this yesterday already, but this time it’s actually done: the arm-none-eabi compiler really does work now. <rekado>the problem was two missing configure flags: <rekado>"--with-multilib-list=armv6-m,armv7-m,armv7e-m" and "--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm" <rekado>now I wonder if I should update the compiler or if we should keep multiple versions. <rekado>instead of taking their sources I took the exact same SVN revisions from upstream. <rekado>unfortunately, an official package for the Axoloti patcher will have to wait a little longer. <rekado>the latest version comes bundled with a couple of jar archives that I first need to build from source. <rekado>(jars for bindings to git and libusb) <davexunit>ACTION watches rekado tumble down a rabbit hole <mark_weaver>rekado: I think our main compiles shouldn't be configured for multilib <mark_weaver>we have our own (superior) approach to multilib, and because of the way we patch gcc to find the dynamic linker, etc, multilib wouldn't work properly without more work anyway. <mark_weaver>but IMO it's best avoided in Guix, at least for the main toolchain. <rekado>the arm-none-eabi cross compiler is for building bare metal binaries; it doesn’t use glibc but newlib. <mark_weaver>note that at present, we explicitly pass --disable-multilib in our gcc package <mark_weaver>sure, for specialty cross-compilers, it's fine of course. <rekado>we re-enabled multilib for the avr gcc for similar reasons <rekado>I never attempted to build GCC before Guix. <davexunit>I realize that I take guix for granted a lot now <davexunit>there are many things that I can just do easily that I would have never attempted before <ng0>i think big studios and projects know why unbundling is good.. haven't looked closely at all of it yet, but for example the dependency produced by ILM does unbundle itself into modules. :) <ng0>I'll probably leave it up to one of the people with more knowledge in licenses to figure out what we have to drop and cut out.. and then to figure out if the end product, USD, is still usable. how free is their free ;) <dtluna>Every time I install any package "substitute: warning: failed to install locale: Invalid argument" is always printed <dtluna>How do I fix this? glibc-utf8-locales is installed <demotri>dtluna: I think I solved it by calling 'guix package -i glibc-locales' <demotri>Then add 'xport GUIX_LOCPATH=$HOME/.guix-profile/lib/locale ' to your bashrc <demotri>See section "2.6.1 Locales" of the Manual. <dtluna>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <rekado>also make sure that this is set in the *daemon’s* environment <dtluna>rekado: how do I check if it is? <rekado>depends on how you start the daemon <dtluna>rekado: I have started it with "systemctl start" <rekado>there’s a tarball now, but it’s at a URL that doesn’t include the version, so I’ll stick to the git checkout. <rekado>dtluna: does the systemd unit file contain an “Environment” line? <rekado>does /root/.guix-profile/lib/local exist? <dtluna>GNU Guix should step up its game <ng0>hoho. intel does not like plaintext, at least for anything other than README. they use html for instructions etc :) that's a first for me. 