IRC channel logs


back to list of logs

<bavier`>g_bor[m]: icedtea seems to build fine on my system now, thanks!
<nckx>g_bor[m]: ++!
<g_bor[m]>:) thanks.
<g_bor[m]>I will push a fix for the version string tomorrow.
<bavier`>I'll try to put a bug report together for arduino ide too
<OriansJ>is there any particular reason why guix edit doesn't actually work? As in By changine the version and hash; guis still uses the old definition.
<bt>I'm sorry to be such a bother but I suspect this will be my last issue. Is there any special configuration that needs to happen to start xorg on a librebooted x60s, I've been using nomodeset since even in the installer because otherwise half my screen turns to static and it reboots, or it spams error messages indefinitly too quickly to read.
<bt>I'm going to continue trying things I suppose, I'll likely be back later though either to report on my success or to solicate assistance.
<jackhill>kmicu, nckx: thanks. I last used btrfs a few years ago (maybe three at this point, wow). At the time, my biggest complaint was that perfomance seemed slow, but I never benchmarked, so it could have just been a slow disk.
<jackhill>at least Guix will make re-installing fairly painless ☺
<PotentialUser-84>Does GuixSD not use ls to list directories? I'm playing around with 1.0 and am getting "command not found".
<buenouanq>there is a problem with the graphic installer
<PotentialUser-84>I have GNOME working. Do you mean that during the install, some utils like ls and cat are not installed?
<PotentialUser-84>Okay, thank you
<PotentialUser-84>I appreciate your help! :)
<buenouanq>there should be an official announcement regarding this
<buenouanq>there will hopefully soon be a v1.0.1 that takes care of this
<buenouanq>installing the old `manual' way works
<PotentialUser-84>I'll keep my eyes open. I'll also start looking at the mailing list archives. Read about the 1.0 release on Hacker News and am excited about guix
<PotentialUser-84>Okay, I'll give the manual approach a try then
<PotentialUser-84>Thanks again for your help!
<apteryx>Nare there any known tests failures currently?
<dongcarl>apteryx: you mean by running `make check`?
<dongcarl>last time I checked there were many tests that were failing, can check for you right now
<apteryx>ok! I got 3
<apteryx>on a recent master
<apteryx>I'm retesting on origin/master without my last changes to see if I'm guilty of breaking some ;-)
<dongcarl>Hmmm, does Guix have any kind of CI process?
<dongcarl>Ideally the tests should never fail...
<apteryx>not currently I believe
<apteryx>but there was some effort in that direction IIRC.
<dongcarl>apteryx: Do you know where I can find more info on that?
<apteryx>guix-devel probably
<apteryx>I think it was Christopher Baines which was investigating some pipeline based of patchworks, but I don't quote me on that
<apteryx>based on*
<apteryx>I don't get how the Namazu search tool works, if I searh a 2nd time I always get 0 results
<apteryx>I need to go back in the browser and search from there (gnu mailing list archives search)
<apteryx>well, it's not much it seems, or at least I can't find it anymore.
<apteryx>so, I get this to fail on master: tests/
<apteryx>which means I broke tests/containers.scm and ests/, eh
<dongcarl>apteryx: 3 fails for me too
<dongcarl>FAIL: tests/
<dongcarl>FAIL: tests/
<dongcarl>FAIL: tests/
<bt>my graphics issue was worse than i thought something about dma and stolen memory resulting in memory corruption a deleting of my passwds and my network going down.
<bt__>it actually corrupted several applications from the looks of it.
<g_bor[m]>Hello guix!
<g_bor[m]>I've just pushed the fix for the openjdk version string problem.
<g_bor[m]>On the issue tracker page, the recent activity subwindow gateway timeouts for me. Anyone else noticing this?
<rekado>g_bor[m]: it doesn’t time out for me, but the fact that it can is a problem that I’d like to fix eventually.
<rekado>it waits for debbugs for a long time and I’d rather not have it do that.
<g_bor[m]>rekado: ok, thanks for having a look.
<g_bor[m]>I am walkin through the priority bugs list, and I came across this:
<g_bor[m]>It seems that most of the actionable items on this bug was resolved already. I belive we could close this, and open a new bug with what remains to be done.
<rekado>g_bor[m]: I don’t think it’s fixed. We don’t verify any commit signatures on guix pull.
<g_bor[m]>rekado: Ok, thanks for having a look. The thread is so long, that it was hard to follow. I guess I missed that :)
<civodul>Hello Guix!
<g_bor[m]>hello civodul!
<g_bor[m]>Any idea why I am building linux-libre?
<rekado>maybe because it has been updated recently and hasn’t been built on berlin yet?
*rekado prepares slides for a Guix intro at work
<g_bor[m]>rekado: yes, I see it was updated 1 day ago.
<g_bor[m]>Is there any way to give priority to the most used packages on the build farm?
<rekado>there is no mechanism for that, but it’s not impossible.
<rekado>want to join the Cuirass hackathon…? :)
<g_bor[m]>ok, it was just a question. Yes, I am willing. I still have some annoyances with the web interface :)
<rekado>me too
<rekado>it needs some love
<g_bor[m]>Also I just saw that the savannah repository for cuirass misses a description. How can that be fixed? Is it administered by us, or do we have to request a modification?
<g_bor[m]>berlin web interface also gateway timeouts for me :(
<rekado>that’s not good. Same thing happened the day before yesterday.
<rekado>I again restarted cuirass.
<g_bor[m]>rekado: do we have performace metrics on what is happening there? I was experiencing slow responses sometimes. Any idea what is the bottleneck?
<civodul>rekado, g_bor[m]: i think it occasionally happens when Cuirass takes too long to respond
<rekado>I don’t know.
<civodul>in that case it won't really help to restart it
<rekado>but it’s back up now
<rekado>In my opinion it would be nice to decouple the web interface from the backend, so that we can restart them independently.
<g_bor[m]>civodul: yes, I was under the same assumption. Do you know why that might happen?
<g_bor[m]>rekado: good idea.
*rekado -> afk
<civodul>g_bor[m]: that's due to the database scalability issues we discussed at the Guix Days
<g_bor[m]>civodul: ok, I remember that.
<roptat>hi guix!
<civodul>hi roptat!
<civodul>yay, the гикс manual now works :-)
<civodul>roptat: i'll let you commit the updated *fr.po files :-)
<sirmacik>do we have anything besides iptables to manage firewall in repo?
<sirmacik>(there is ufw under gplv3 or shorewall under gplv2+)
<sirmacik>but seems not to be packaged so far
<civodul>sirmacik: i don't think there's anything else
<sirmacik>then I'll prepare package at least for ufw in the near future
<sirmacik>it's about time to get started with it (;
<sirmacik>I want to try guix out on the server but I'm gonna need things like ufw and fail2ban first
<sirmacik>the list to package so far is: ghostscript the arch way, tor browser, ufw and fail2ban (;
<sirmacik>I have also a question on: how to write my own services and include them on my system during install in config.scm?
<sirmacik>meaning: can they be defined in other files and included in config or should they be provided as packages. Or should they be typed somewhere in config.scm?
<roptat>sirmacik, you can create guile modules that can be included in your config, and these modules can contain service definitions
<roptat>I have my own systems under version control here: and the "modules" directory contains module definitions that are used by some systems
<roptat>(no new service definition, but you get the idea)
<roptat>similar to what guix uses for its own servers:
<roptat>civodul, should we make a page to link to people's configurations (if they're willing to share it) on the website? I think it would help users a lot to have such a list of "real-life" examples
<civodul>roptat: i see the need, but i think it would need to be structured to be really useful, no?
<civodul>otherwise people get the same result by typing "guix system config" in their search engine
<roptat>I guess we could highlight some points about why people should read the configuration?
<sirmacik>roptat: awesome, thank you!
<sirmacik>something like awesome-guix repo (;
<sirmacik>that'd we bery usefull since google/ddg and others aren't very good ad returning links to users configs
<efraim>I have a simple custom service, , I'll see if I can remember who had a more complex one
<sirmacik>efraim: thanks!
<sirmacik>another one, how important for packages is to be done from source? Or can i for ex. get binaries published by tor and just unpack them?
<roptat>it's not going to work directly, you'll have to use patchelf to change paths to the interpreter and libraries
<roptat>and that's never going to be accepted as a contribution to guix
<civodul>re Tor, it's safer from a security viewpoint to use the package definition available in Guix
<civodul>because it's built from source, you can challenge substitute servers, etc.
<sirmacik>but tor browser isn't available
<sirmacik>and that's somethng I think is vital to have
<sirmacik>binaries or source it'll need path patching
<roptat>but on the same time, it's different version of the browser than what tor provides, so it's less private I guess?
<sirmacik>same wat as Icecat
<civodul>IceCat comes with the Tor Button by default, but i understand it's still a different beast
<civodul>someone tried to package the Tor Browser a while back, not sure what happened
<sirmacik>sometimes in gentoo and arch AUR you get *-bin packages
<sirmacik>can it be done in guix?
<sirmacik>or this way it won't get anywhere?
<sirmacik>like providing regular compiled tor-browser and one unpacked from official binaries?
<dongcarl>civodul: Hey, thanks for helping with my patches. I'm wondering what happened in 04a3ecc so I know Guile a little better?
<civodul>dongcarl: that bit of code in (gnu packages base) was referring to 'gcc' "from the top level"
<civodul>that means that, when loading (gnu packages base), you'd first need that 'gcc' variable from (gnu packages gcc)
<civodul>but since (gnu packages gcc) imports (gnu packages base), that cannot work
<dongcarl>civodul: Ohhhhhh......
<civodul>does that make sense? :-)
<dongcarl>It's a circular dependency thing...
<civodul>it's a corner case of how we use Guile's module system
<dongcarl>Aha! Thanks Ludo!
<dongcarl>Someone should take a look at perl-io-socket-ssl, whose test suite is failing. An annoying failure as it is a dependecy of `git`.
<str1ngs>did you volunteer dongcarl ?
<dongcarl>str1ngs: Haha I'm trying... But I don't know perl well at all...
<str1ngs>not even ther perl monk's do :P
<dongcarl>I'll give it a go!
***vup2 is now known as vup
<quiliro>newly updated to 1.0
<quiliro>it looks good up to now
<quiliro>thank you very much
<arshin>jonsger: it's broken no one can hear you :)
<jonsger>arshin: not as bad as I expected
<mouldysammich>does guix package dotnet-core ?
<amz3>?! guix package -s dotnet
<amz3>mouldysammich: no
<donofrio_>no mono for guix?
<amz3>there is mono tho
<donofrio_>dotnet core should be around?
<amz3>why is that?
<donofrio_>core is what m$ released for cross platform development and use.
<mouldysammich>amz3: thanks!
***aminb is now known as bandali
***marlon__ is now known as Marlin1113
<sirgazil>Hi. Do you have sound in the game alex4?
<nckx>sirgazil: No.
<sirgazil>nckx: Thanks. I'll report a bug.
<g_bor[m]>Hello guix!
<nckx>No std{out,err}, no -h, no --help, no --version, no -v, no --debug, very disappointing game.
<nckx>(To debug anyway; game itself looks cute!)
<g_bor[m]>I've just pulled on one of my systems, and bumped into the can't make/remove session error, unable to log in from console. I remember seeing something about this on the ml, but can't find the thread. How can I fix this?
<apteryx>civodul: is it known that tests/ fails on master?
<apteryx>dongcarl: thanks for sharing your test failures. the and are suspicious as I don't have these
<sirmacik>yay, I can now connect to wifi at my work! (I wasn't able on friday). It's great to see guix getting better and better so fast
<apteryx>rekado: all of the gcc packages are now hidden, per your commit d78010b81ee6ef4fd8803082e2f401b9e55b44db. Was this intended?
<roptat>I think so, because people kept complaining gcc didin't work, but you actually need gcc-toolchain :)
<roptat>now they can't install gcc, so they won't complain about it :p
<apteryx>rekado: at least, guix install gcc can't find it
<apteryx>as can be seen by tests/
<brendyyn>if that is a valid reason to hide gcc then it's a valid reason to hide the guix package
<civodul>apteryx: not to me :-)
<apteryx>maybe my master is slightly outdated, but 'guix install gcc' fails
<apteryx>this causes the test to fail
<apteryx>roptat: yeah, that makes sense... except 'guix search '^gcc$' can still see those
<apteryx>and tests/ fails (not for civodul :-)
<civodul>apteryx: oh, that's because we made "gcc" a hidden package
<civodul>(i just said i didn't know, i didn't say the test succeeds :-))
<apteryx>ah, I see, eh!
<apteryx>I'll change gcc into whatever else smallish package then
<apteryx>maybe zile, the goal of that test is to test multiple package installation
<civodul>apteryx: in, you can replace "gcc" by "zile" or "gcc-toolchain" or whatever
<apteryx>yep, that's what I was thinking about
<apteryx>although, what about 'guix search '^gcc$'; is this a bug related to inheritance?
<apteryx>also, a question about the sh tests: how does it know about a failure? is there a 'set -e' somewhere to fail on a command's non-zero exit status?
<apteryx>I see 'set -e' being set for other test scripts such as, but doesn't have it... so I'm wondering if there's a test driver setting that.
<apteryx>or otherwise, how is the final pass/fail value decided?
<apteryx>brendyyn: true, maybe 'guix' package itself should be hidden
<civodul>apteryx: i don't see 'guix search '^gcc$'', where is that?
<apteryx>you don't see gcc@4.7 appear in its results?
<apteryx>there's a lot of stuff, but use less and look at the first pages
<apteryx>you'll see the gcc entries that are supposed to be hidden in the results
<dutchie>I get ";;; [2019/05/13 16:08:14.094180, 0] write_to_channel_port: [GSSH ERROR] Remote channel is closed: #<input-output: channel (open) 2adf5e0>" when trying to do guix copy --to=...
<civodul>apteryx: if i do "./pre-inst-env guix search '^gcc'|grep name:", i don't see any "gcc", only "gcc-toolchain" and a couple of other things
<civodul>dutchie: could you check whether 'guix' is in $PATH on that other machine?
<civodul>namely, could you try: "ssh MACHINE guix repl --version"?
<dutchie>that works
<dutchie>(although it complains about locales for some reason)
<roptat>do we have a notion of "optional service extension"? like only extend that service if it exists, otherwise ignore the extension?
<roptat>I'm thinking about fun user services that would go like (service terminal-color-scheme-service-type %guix-terminal-color-scheme) and (optionally) extend every possible terminal config that was declared in the service field for that user
<roptat>like if you have (service xterm-service-type my-xterm-config), you will get an extension for it, but not for xfce4-terminal for instance
<roptat>I don't know if I'm clear and if that makes sense...
<civodul>roptat: it's not possible to do that currently, and that'd need discussion
<civodul>to see what the exact semantics would be
*civodul has to go
<jje>having some trouble locating how does one go about locating this library or what package do i need to install? i have installed gcc-toolchain.
<roptat>hey, it's in gcc:lib
<roptat>but gcc is hidden now, so I wonder if we can still access it?
<jje>i need it to compile emacs. is gcc:lib a package or a location in the filesystem?
<str1ngs>jje: gcc:lib is libstdc++ libraries etc. its one of the output's of the gcc package
<jje>ah i see
<str1ngs>jje: think split package
<janas>jje: I think you could also use 'guix environment' to pull in all of the emacs dependencies
<janas>But I'm not 100% sure how the command is formatted
<jje>ok i can try that i will experiment some. got any rough guesses as to the command format?
<roptat>"guix environment emacs" will get you every dependency needed to build emacs
<jje>ah thank you kindly
<str1ngs>maybe not everything, you might need gcc-toolchain, make etc?
<roptat>I think it gets you everything
<jje>got those already
<str1ngs>it's going to be enough to get started anyways. I agree
<str1ngs>also, another way to do this is. to inherit the emacs package. depending on what you are trying to achieve
<roptat>yeah, I just tested and it pulls in make and stuff
<str1ngs>environment has less barrier to entry though
<roptat>hm... it did download make, but it's not available actually, so you were right
<str1ngs>yeah, make etc. are probably pulled in with the build system. they are not actual input's
<roptat>mh... actually it's in $GUIX_ENVIRONMENT/bin, but $PATH was not updated
<str1ngs>maybe, native inputs in some degree?
<roptat>I don't know, that's weird
<str1ngs>I'm still wondering about this. if you were to just do guix environment emacs. would it download gcc, make etc. seems kinda expensive just for an emacs environment
<roptat>it works in a --pure environment
<roptat>it's not an emacs environment, it's an emacs-building environment
<roptat>if you only want emacs, you can do "guix environment --ad-hoc emacs", then you don't have make, gcc etc
<str1ngs>ah that makes more sense now, thanks
<roptat>need to go, see you later :)
<davexunit>sometimes I think 'guix environment' should default to what we call --ad-hoc
<str1ngs>is it possible to rename the default profile generation. or to reset the increment atleast?
<g_bor[m]>davexunit: I believe that the guix environment was designed with a different use-case in mind. Now it works like: I would like to develop package x and additionally have y tool at my disposal. I believe that makes sense. Wdyt?
<davexunit>g_bor[m]: it does make sense, but most of the time I specify packages on the command line I want to use --ad-hoc.
<davexunit>otherwise I make a guix.scm file in the root of my project repos and use -l or -m to load an environment based on that.
<davexunit>the one exception being 'guix environment guix' when I want to hack on guix
<g_bor[m]>davexunit: Do you think we could propose an alternative alias instead, that basically does that?
<g_bor[m]>I feel guix environment in its current form is too deeply embedded in the ecosystem already. Wdyt?
<davexunit>I think that would be confusing.
<davexunit>I think it's just best to leave it be
<davexunit>just reflecting on things a bit.
<davexunit>if I knew then what I know now I would have designed the interface differently.
<davexunit>I do think that there could be some conventions we could introduce to make certain use-cases easy. for example, I think running 'guix environment' should search for a file that contains all the environment config and do what it says.
<davexunit>so you could clone a git repo and just run 'guix environment' with no arguments and get the environment that the project developers have already configured.
<g_bor[m]>davexunit: it's interesting to see how things evolve. I believe it has an nice inteface :) , but if we could come up with a backwards compatible way, that would be nice.
<g_bor[m]>That might well work :)
<Marlin1113>can't seem to launch minetest from guix on debian
<davexunit>there's a whole other layer of the tool I never implemented. I wanted 'guix environment' to fill the role of 'docker compose'.
<g_bor[m]>I believe it might be similar to how some projects already have a guix.scm file with a package definition. We might simply reuse that, don't we?
<g_bor[m]>That might be a good first step.
<davexunit>I want guix environment to handle services, too.
<davexunit>so that if you work on a project that needs a database connection, it would start up a database service as well using a shepherd instance running as the current user.
<davexunit>we could reuse system services and user namespaces to make it happen.
<g_bor[m]>That would be great. I also believe that this file might contain some recommended set of ad-hoc packages, and give a command line flag for the user to choose if they need those or not.
<davexunit>maybe! in general guix doesn't do the "optional dependencies" thing, though.
<davexunit>and honestly I like that
<davexunit>because it's easy to extend objects with a little bit of extra scheme code
<davexunit>all this extra stuff might merit a whole new subcommand, dunno. 'guix develop' or something.
<apteryx>i'd like guix environment --debug that would pull in the debug outputs
<davexunit>apteryx: that would be pretty easy to add, I think.
<davexunit>since we have an established convention of naming the output "debug"
<apteryx>sweet! I should look into it.
<apteryx>for now trying to fix tests/gexp.scm. Is it failing for someone else on master?
<apteryx>a derivation invoking guile fails with the later complaining: Unrecognized switch --no-auto-compUsage: guile [OPTION]... [FILE]...
<apteryx>so guile exists but the args passed to it were either corrupted or not understood.
<rubic88>I just installed guix on my ubuntu 18.04 laptop using The installation appears to have worked, but I'm getting "guile: warning: failed to install locale" messages.
<str1ngs>rubic88: guix package -i guix-locales then set the environment variable.
<g_bor[m]>davexunit: I also believe that sharing some code with the channels would benefit both worlds here. Wdyt?
<str1ngs>rubic88: err glibc-locales
<str1ngs>rubic88: glibc-utf8-locales does not resolve that for me, for some reason. though it should if you use utf8.
<davexunit>g_bor[m]: channels are a little "after my time", if you will.
<davexunit>I'm not familiar with the code at all.
<davexunit>so, maybe?
<rubic88>@strings: Afterward the envvar I want to set is GUIX_LOCPATH?
<str1ngs>rubic88: right
<str1ngs>though I wish glibc-ut8-locales would work, since the package is smaller :(
<str1ngs>err utf8
<str1ngs>rubic88: also do you use from git? because if you don't it does not install version 1.0
<str1ngs>from my limited testing the from the tarball won't install version 1.0 . only did limited testing on that.
<rubic88>strings: export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/ <- works, thanks
<rubic88>I installed it from the page
<str1ngs>what does guix --version output?
<rubic88>guix (GNU Guix) ccabb664ed55d44767e037bb73169be2ecf9449d
<str1ngs>how about /usr/local/bin/guix --version ?
<str1ngs>if the script is from git, then it should be version 1.0
<rubic88>guix (GNU Guix) 1.0.0 :-)
<str1ngs>great, looks good then
<rubic88>awesome, thanks
<str1ngs>no problem
<str1ngs>I'd still like to figure out why , glibc-utf8-locales does not work :P
<g_bor[m]>str1ngs: my first guess would be that it misses some locale needed by your system. IIRC the only difference is that the utf8 one is a bubset of the other.
<str1ngs>g_bor[m]: right, I believe my system uses en_US.utf8 . which should be part of glibc-utf8-locales I would think
<apteryx>str1ngs: there's a bug logged against glibc-utf8-locales, saying it doesn't include C.utf8; maybe that could be the reason?
<str1ngs>it's possible, maybe guix does not use the host locale and defaults to C.utf8 locale?
<apteryx>str1ngs: For the daemon I think it enforces some locale, I don't know which, maybe en_US.utf8
<apteryx>for reproducibility
<str1ngs>yeah, that's the other thing the guix-daemon locales could be an issue as well
<str1ngs>glibc's locale shows en_US.utf8 though
<str1ngs>using guix version of locale anyways
<apteryx>do you have the problem if you use glibc-locales instead (the full package?)
<str1ngs>no glibc-locales works fine
<apteryx>ok; so it seems you are hitting some locale that doesn't exist
<str1ngs>also strangely if I remove glibc-locales it continues to work . weird
<str1ngs>I'm just trying to replicate the issue
<apteryx>maybe the locales are cached somehow
<str1ngs>my guess is on foreign distro's this is related to the guix-daemon locales
<apteryx>try a fresh shell, maybe
<apteryx>are you on a foreign distro or a Guix System?
<str1ngs>both at times, but this happens on foreign distro
<str1ngs>I'm sure if I wipe /gnu and /var/guix . reinstall guix . it will do it again
<str1ngs>on foreign distro of course
<apteryx>so you are running the guix-daemon as root, and using a systemd unit file? which sets the GUIX_LOCPATH env var?
<str1ngs>I'm using systemd unit yest
<apteryx>I don't think wiping those directories will help
<apteryx>seems my gexp test problem was a false positive
<apteryx>it passes in another source tree
<str1ngs>I think this has to do with the fact you need to install the locales with this profile. GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
<str1ngs> source $GUIX_PROFILE/etc/profile
<str1ngs>that resolves the guix-daemon locales
***jonsger1 is now known as jonsger
<bt`>I was just being incompetent yesterday when I thought I corrupted my system, I turned acpi=off for debugging purposes and that broke my system as you'd expect. Oddly after my system initially crashed due to the graphics issue and it rebooted I was able to login using slim and load up emacs-exwm while acpi=off was though.
<tune>can I update just one single package? I keep getting unrelated stuff that needs to be built when doing an update
<tune>and how do I check which package a dependency is from? I can't stop libtorrent-rasterbar from updating by listing it, so I think I have to list what needs it
<tune>similarly I couldn't stop rust from building directly, had to tell icecat not to upgrade
<nckx>What ‘unrelated stuff’ are you talking about, and how are you updating single packages now?
<nckx>‘guix package -u PACKAGE’ won't update unrelated packages, but Guix's notion of related might not match yours.
<nckx>(You can't hold back dependencies, and it might be hard to hold back dependencies of the resulting new profile, I haven't yet tried to do that.)
<dongcarl>rekado: I think your hide gcc commit breaks `cross-base`
<dongcarl>Not sure how to fix right now...
***jje_ is now known as jje
***jje_ is now known as jje
<rekado>dongcarl: do you have a reproducer?
<dongcarl>yeah gimme a sec
<dongcarl>This used to be able to produce a `gcc-cross-aarch64-linux-gnu`, but I'm guessing the hidden package messes with it somehow?
<g_bor[m]>Hello guix!
<dongcarl>I'm guessing the philosophy of what you're doing means that we'll instead have a procedure `cross-gcc-toolchain` that produces `gcc-toolchain-cross-aarch64-linux-gnu` instead?
<g_bor[m]>It seems to me that in the documentation we have the name of the php-nginx-location procedure wrong. It is correct in the example, but not correct in th headline. How should we correct this? I believe that simply changing the headline in the doc would do, as it would not break existing configs.
<rekado>dongcarl: propeller-gcc uses cross-gcc as well and it is indeed hidden. But propeller-toolchain which uses (and propagates) propeller-gcc is not.
<rekado>in any case, you can unhide the package by overwriting the “properties” field with '() or '((hidden? . #f))
<dongcarl>rekado: Ah okay I see what you're saying
<rubic88>Is there a guix command to export current package installations to a manifest? I'm aware of 'package --list-installed', but I'm looking for something that could be used as input for package installation on another system and put under version control.
<str1ngs>how do I modify the guix-configuration, I need to add additional substitute servers.
<nckx>rubic88: No. Pierre Neidhardt posted a Guile script for that to the list (which list? guix-devel or help-guix) mere days ago but I can't find it ☹
<rubic88>nckx cool, thanks for the confirmation I wasn't overlooking anything.
<bavier>rubic88: no specific command, thought you could use awk/sed to dump package names for inclusion in a 'specification->package' list
<rubic88>bavier: yep, but before I rolled my own (simple) script, just checking that I wasn't overlooking something ... since my guix experience can be measured in minutes ;-)
<bavier>rubic88: for sure
<bavier>rubic88: this may or may not work: echo "(specification->package (list"; guix package -I | awk '{printf "%s:%s\n", $1, $3}' | sed 's/:out//;s/.*/"&"/' | fmt | sed 's/.*/ &/'; echo " ))"
<rekado>this is the Guile script I posted:
<bavier>ah, yeah, should be "(map specification->package ...)"
<rekado>(use-modules (guix profiles) (ice-9 match) (ice-9 pretty-print))
<rekado>(match (command-line)
<rekado> ((_ where)
<rekado> (pretty-print
<rekado> `(specifications->manifest
<rekado> ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
<rekado> (_ (error "Please provide the path to a Guix profile.")))
<nckx>rubic88: I feel like a voyeur, but I sniffed through their dotfiles and lo:
<nckx>Judging by the ‘Thanks’ comment, that's the version I remember from the ML.
<rubic88>nckx: :-)
<civodul>we should prolly provide that functionality
<civodul>even if it's approximate
<str1ngs>I need to modify the guix daemon service. but I do not know the identifier bound to the body of that service.
<str1ngs>how do I find out what the identifiers are?
<str1ngs>here is my code, I need to know what IDENT should be.
<str1ngs>also (inherit config) uses the variable as well
*nckx wants to help but cannot.
<samplet>str1ngs: IDENT is whatever you would like. It gets bound to the value of the service (which is usually its configuration record). As a convention, this variable is usually named “config”.
<str1ngs>hmm I misunderstood how that worked then. though when I use config. I get error: config: unbound variable
<samplet>str1ngs: You are missing the list of services to modify after “modify-services”. It should be “(modify-services %desktop-services ...)”.
<samplet>(Or “%base-services” or whatever.)
<str1ngs>yes that is write thank you . I overlooked the service arguement
<samplet>You’re welcome!
<str1ngs>you know just when I think I grok scheme, I realize I don't grok scheme lol
<str1ngs>I think it's safe to assume this is a %base-service lol
<samplet>str1ngs: Macros can make learning Scheme a little tricky, for sure.
<str1ngs>I wrote my first macro a couple of weeks ago. and I still not sure 100% what it does lol
<samplet>str1ngs: I know that feeling! :)
<str1ngs>that cool thing is it replicates interactive procedure like elisp. I'm using it to define command procedures for a emacs like web browser
<str1ngs>which now builds on guix after many weeks of hacking lol
<str1ngs>here is a screen shot of M-x:
<samplet>That looks super neat!
*samplet goes AFK
<civodul>str1ngs: looks pretty cool!
<civodul>do we have a package yet? :-)
*civodul -> zZz