IRC channel logs


back to list of logs

<apteryx>civodul: if you're still here, the entrypoint script I made was:
<apteryx>it could by Guilified
<apteryx>and this entrypoint was used in the Docker image generated with this dockerfile:
<apteryx>I believe we could add this entrypoint programmatically as part as guix system docker-image
<apteryx>the nice thing with this, is that your can run any command of your choosing (in my case the default command is simply "bash"), like `docker run -it the-image-tag some-command`
<civodul>apteryx: the problem here is that 'boot', and thus 'shepherd', are running as PID 2, not PID 1
<civodul>so i think this wouldn't work well
*civodul -> zZz
<civodul>good afternoon! :-)
<jje>good day to you all! i have an atheros AR9271 that i am trying to get to connect to a router using wpa2-psk, it will connect to an open network but not when attempting with wpa2-pskk. am i missing some depenency of network-manager or wpa_supplicant? thanks in advance for any help you folks can offer.
<jje>the error from wpa_supplicant is WRONG_KEY but i have tried with quoted password and with pre-shared key.
<nckx>jje: Hullo! ath9k should work out of the box. Which user interface are you using to connect? Could you paste any errors you get (including dmesg) to I don't think I've ever owned that chip; does it need extra firmware to work (well)? We have ath9k-htc firmware, but I think it's installed by default.
<nckx>jje: Have you tried with sudo nmtui?
<jje>yes i tried with nmtui and it just keeps aking for the password over and over. do you want all of dmesg or just the relevant portion?
<vagrantc>there's an incompatibility with network-manager and the ath9k in some cases...
*vagrantc tries to dig up a bug report
<jje>ah ok
*nckx is curious too, having used NM + ath9k for years without issue.
<vagrantc>i don't recall if i had to set that when using it with guix ... mostly used guix with wired ethernet
<jje>i will try that and return in a while thanks again!
<vagrantc>not sure how to add arbitrary configuration for network-manager in guix ... but hopefully it's possible
***jonsger1 is now known as jonsger
<guixsd-1st-test>Though I'd try guixsd
<guixsd-1st-test>ran into then found the bug report :/
<guixsd-1st-test>You are forced to add a non-root user during install.
<guixsd-1st-test>That document (after system upgrade) is not clear what user should be running `guix pull`. root or the user?
<guixsd-1st-test>I did an install via the graphical installer and unselected NSS certs to navigate around previous mentioned bug (35541)
<guixsd-1st-test>so that's an XFCE install that boots to XFCE which sets the login to the user
<Marlin1113>Is there a way to make rofi see guix's packages?
<guixsd-1st-test>only 'generation' says it needs root
<guixsd-1st-test>Coming from a apt/apt-get world that always needs root or sudo it would be helpful to make it obvious
<guixsd-1st-test>is it that the user can do all the `guix` stuff then just run `sudo guix system...` to deploy?
<guixsd-1st-test>the first run of 'sudo guix....' as in after system installation complains that root hasn't run guix pull
<guixsd-1st-test>which makes it unclear
<guixsd-1st-test>(even though the user has done guix pull)
<ison[m]1>Marlin1113: You mean it can't find binaries to run? Or are you asking about using it as a menu for displaying packages you can install through guix?
<Marlin1113>i mean being able to launch packages guix installed using rofi
<ison[m]1>Marlin1113: It should work by default. I'm currently using rofi and it can see all my installed software. Have you sourced /etc/profile and ~/.guix-profile/etc/profile ?
<ison[m]1>Marlin1113: Also, how are you launching it? Try "rofi -show run"
<marlin1113[m]1><ison[m]1 "Marlin1113: It should work by de"> On bash? Ye
<marlin1113[m]1><ison[m]1 "Marlin1113: Also, how are you la"> Same
<bt>hello, I've been attempting to install GuixSD on my Librebooted X60s but it seems no matter the config many critical service fail to start including numerous file-system services and getty responding something along the lines of `service failed to start' the only other errors I get are ACPI errors. Have any of you experienced something like this?
<dftxbs3e>samplet: hi, I had to destroy the server, I saved your data, the log file said that -mfloat-type thingy was incorrectly spelled
<dftxbs3e>I saved the screen buffer to a file
<samplet>dftxbs3e: Ah shoot. Oh well. Thanks. How is 0.13.0 going?
<dftxbs3e>samplet: it successfully bootstrapped :D
<samplet>dftxbs3e: \o/ So you are running Guix on the Talos then?
<dftxbs3e>samplet: I recompiled version 1 with bootstrap binaries filled in, but then it meets the same issues because it's trying to compile stuff with glibc 2.28, and the bootstrap compiler is gcc-5
<dftxbs3e>but otherwise it works
<dftxbs3e>samplet: - powerpc64le branch is version 1 patched, and powerpc64le-bootstrap can cross compile bootstrap binaries
<dftxbs3e>I hosted the bootstrap binaries on a server, I should re-host them on gitlab
<dftxbs3e>with git lfs
<dftxbs3e>samplet: I don't think it's wise to send a patch about this to guix master, because when gcc-7 (or later) will work properly for cross compiling bootstrap binaries then everything will just work
<dftxbs3e>all I have done is not proper I think
<dftxbs3e>It works but it would be better to just get gcc-7 or 8 to work
<dftxbs3e>which is pending on core-updates
<dftxbs3e>it's not usable because anything with glibc 2.25+ will not work
<samplet>dftxbs3e: Fair enough. I am still plugging away at the core-updates build. I have made some progress, but hit a dumb snag with the GMP patch when compiling static GCC. I fixed it, but it meant rebuilding a lot of stuff on a slow computer.
<ison[m]1>bt: Have you tried installing without the graphical installer? Apparently there are some bugs with it which will hopefully be resolved by the next release
<dftxbs3e>samplet: I don't really have fast x86 hardware, the server was rented on Digital Ocean cloud service, it costs $960 a month, so I kept it for few hours that's all
<dftxbs3e>or a day almost, we kept it
<dftxbs3e>I have fast ppc64le hardware
<samplet>dftxbs3e: Yeah. That’s fine. I’m patient. It will take a month or two before core-updates is ready to merge.
<dftxbs3e>I guess with my bootstrap binaries, I could now use ppc64le hardware
<dftxbs3e>to re-bootstrap on core-updates
<dftxbs3e>if you want to save them locally, just in case
<samplet>dftxbs3e: Thanks.
<bt>sorry ison[m]1 I left for a moment, I only tried without the graphical installer.
<bt>I tried several different configurations including one as close to nothing as I could.
<dftxbs3e>samplet: - hosted them on git
<dftxbs3e>samplet: and made guix fetch them from gitlab as well:
<samplet>dftxbs3e: Did you have any luck running core-updates on PowerPC? I imagine quite a bit would work.
<dftxbs3e>samplet: maybe you could ask for remote access to a powerful machine from GNU Guix staff
<dftxbs3e>I havent tried
<dftxbs3e>I tried version 1
<dftxbs3e>the issue is that it tries to get running from bootstrap binaries but bootstrap binaries contain gcc 5, and it tries to compile glibc 2.28 with it, which fails.. because it requires gcc 6.2 due to that 128bit float issue
<dftxbs3e>in commencement.scm
<samplet>dftxbs3e: Oh right. You would need to have an intermediate GCC using the old Glibc for that to work. Shoot.
<dftxbs3e>samplet: here:
<dftxbs3e>inherit glibc means glibc 2.28
<dftxbs3e>I tried to change that for glibc 2.25 but then it fails for some symbol versioning errors, "locpath" thing
<dftxbs3e>Theoretically, Guix supports using older glibc versions, since there's alternate package definitions for glibc 2.25 etc
<dftxbs3e>samplet: maybe it's possible to add that intermediate gcc thing, but it feels dirty
<dftxbs3e>bootstrapping can only be dirty anyways
<dftxbs3e>it's such a mess to go from version to version
<samplet>dftxbs3e: It looks like it should build “glibc-final-with-bootstrap-bash” using the newer GCC, not the bootstrap one. (Both compilers are in its inputs, but old one looks like it is only used for bootstrapping the HURD.)
<dftxbs3e>samplet: sorry that branch was modified already, I think
<dftxbs3e>hm no it wasnt
<samplet>dftxbs3e: Either way, I was looking at my own copy. :)
<dftxbs3e>Version 1 is different maybe
<samplet>I’m looking at the core-updates commencement module.
<dftxbs3e>I mean, I was reading version 1 myself
<samplet>Ah okay.
<buenouanq>is btrfs ready yet (;-___-)
<brendyyn>buenouanq: doesn't it already?
***daviid is now known as Guest78344
***Guest78344 is now known as daviid
***palica1 is now known as palica
***slyfox_ is now known as slyfox
<g_bor[m]>Hello guix!
<g_bor[m]>I have noticed tha icedtea-3.7.0 does not build for me. It seems that while building hotspot it fails an operating system check. Can anyone confirm?
<g_bor[m]>I am pulling right now, then will do a system reconfigure, and check again.
<brendyyn>Firefox sync doesn't work for me in Icecat. It just says "working" when I try to sign in or make an account. Has anyone else tried this?
<rekado>g_bor[m]: on Berlin we have a successful build on e54a6543a09fe785824f7bdf47a6a8a7721190ce (May 8)
<g_bor[m]>rekado: thanks for checking. I will have a look at why it fails here. My first guess is that it fails to check the kernel version.
<rekado>I remember someone reporting this some weeks ago, roptat maybe.
<roptat>yes! same with icedtea@2
<roptat>g_bor[m], ^
<roptat>oh, ocaml seems to not be reproducible... my local hash is different from the hashes of berlin and hydra (both are identical)
<g_bor[m]>rekado, roptat: There seems to be two ways to solve this. Either we can patch the file to allow some other version, or we can use an environment variable to disable this check completely. I think I would go for disabling the check completely. This seems more future proof, and we don't carry a patch/make a substitution. Wdyt?
<rekado>g_bor[m]: either way is fine for me. The test seems a little silly. Why doesn’t it just check for a minimum kernel version?
<rekado>(if it depends on kernel features directly, that is)
<g_bor[m]>ok. I will test if disabling works, and if its ok, then I will push a fix.
<roptat>g_bor[m], disabling the test completely sounds good
<cbaines>rekado, by the way, the seems to be down. I'm getting a 504 Gateway Time-out.
<rekado>I restarted cuirass just now.
<rekado>does it still time out?
<cbaines>it's back now
*rekado doesn’t have enough memory to start a browser now
<rekado>thanks for reporting
<rekado>the next step for Guix on Hurd is to build the bootstrap binaries with debug symbols so that I can run them in gdb.
<rekado>rpctrace is too detailed and too coarse at the same time
***daviid is now known as Guest78595
<roptat>guix environment doesn't honor --system=...?
<dutchie>what does it mean when I run guix package -u and it says that a package will be updated to the same version it already is?
<roptat>that's because it's updated to a newer variant of the same package (probably dependency updates)
<Aurora_iz_kosmos>Is Rust taking ages to compile for anyone else?
<brendyyn>Isn't that normal?
<Aurora_iz_kosmos>Probably. I'm just wondering if there's something wrong for the substitutes server not to be done yet.
<roptat>there are substitutes for icecat (and its rust dependencies) for a version of guix from may 6th
<brendyyn>I'd like to have the ability to guix pull to the latest version the build server has finished building everything it can.
<Aurora_iz_kosmos>That'd probably be a neat feature.
<dutchie>somewhat relatedly, is there a way to see which guix versions have substitutes for a given package
<Aurora_iz_kosmos>dutchie: I seem to recall there is mentioned in the manual somewhere.
<pkill9>i don't think it builds everything available, it just builds something when requested
<brendyyn>Seriously? I thought it was looping through everything.
<brendyyn>Doesn't sound right.
<dutchie>there's guix weather but that's not really what i want
<pkill9>it builds guix itself as soon as the git repository is updated, but packages are only built when requested
<roptat>packages are all built as soon as guix is updated
<roptat>however substitutes (nar files) are only backed after they are requested once
<pkill9>oh ok
<Aurora_iz_kosmos>dutchie: There doesn't seem to be a more finely filtering one.
<dutchie>(i'm mostly asking about qtwebkit)
<pkill9>roptat: what do you mean "backed"?
<roptat>compressed as a nar file that can be transferred, from the corresponding item in the store
<roptat>it's not the same as guix pack
<pkill9>oh, so packages are first built, and then they're processed into substitutes when requested
<brendyyn>I know, it just wasn't clear what backed meant.
<roptat>I meant baked, not backed
<pkill9>i thought "baking" referred to the building of the package
<roptat>there are some weird failures on berlin:
<pkill9>roptat: how did you get to that log from the frontend? (frontend meaning
<pkill9>now i can see the log for chromium failing to build
<dutchie>guix build gives it to you
<roptat>from, then select guix master, latest evaluation, failed build and selected a random log from the list
<roptat>it's from evaluating 59e72ac
<Aurora_iz_kosmos>I think I may have a slight problem.
<roptat>have you installed nss-certs?
<roptat>like described here:
<pkill9>roptat: I dont see a button for "failed build"
<pkill9>s/button/button or link/
<Aurora_iz_kosmos>roptat: I may have, but hadn't set the variables.
<roptat>click on the red button with the number of failed builds
<Aurora_iz_kosmos>Is it unadvisable to have two `guix install` commands running at once?
<roptat>I think one of them will eventually be ignored
<pkill9>ah, thanks
<Aurora_iz_kosmos>Guess I'll wait until it finishes then.
<roptat>when I do "guix environment -s i686-linux --ad-hoc foo", I get foo for x86_64, not i686, is that expected?
<roptat>oh, it's actually a different version from "guix build foo" and from "guix build foo -s i686-linux"
<roptat>mh.. but when I use -n, it's the same as the x86_64 version...
<dutchie>is there a way to see which package has propagated something?
<Aurora_iz_kosmos>dutchie: Propagated?
<dutchie>listed as propagated-inputs
<dutchie>so they show up in the profile even though they weren't explicitly installed
<Aurora_iz_kosmos>dutchie: `guix graph` might do some of it.
<Digit>1.0.0., i just heard. :) congrats on 1.0.0., folks. :) yay guix! :)
<dutchie>hmm, maybe
***jonsger1 is now known as jonsger
<Aurora_iz_kosmos>...Damn, the graph for icecat is ridiculous.
<Aurora_iz_kosmos>It makes me very happy for package managers like Guix. (dat depency hell)
***emacsen_ is now known as emacsen
<nobuffalo>Hi there. I'm a developer at a company doing web things (PHP, d'oh). We are at a waypoint going from on premise to "the cloud" and I'm in a position to pick the tools and processes
<nobuffalo>I'm eying kubernetes but everytime I try to set up a cluster something goes wrong and it's all very complex, complicated. The ads say "get the app running in 5 minutes" but they forget the 5 months/years preparation
<nobuffalo>so, naturally, I remembered guix looming. I've used it in the past but never as daily driver. Would you recommend me evaluating guix(sd) as an alternative to kubernetes? All the building blocks seem to be there, including os containers
<amz3>afaict it is not ready to replace kubernetes, even k8s is complicated.
<Aurora_iz_kosmos>That was obnoxious, but Rust & Icecat are finally done compiling. :)
<Aurora_iz_kosmos>They do two different things @ nobuffalo
<Aurora_iz_kosmos>Guix is a good package manager. You can use it in a container. It doesn't replace containers on its own.
<Aurora_iz_kosmos>(Nor container orchestration)
<nobuffalo>so guix would be better on premise hosting also with some hacking tools for development, no? the whole VM privisioning will have to be developed or done semi manually via ansible or other tool
<pmikkelsen>hi, is anyone in here using docker? I seem to have an issue when following the guide at
<pmikkelsen>There comes network issues
<Aurora_iz_kosmos>nobuffalo: That's a viable way to set it up. It has a bunch of useful tools for development environments.
<Aurora_iz_kosmos>nobuffalo: It just won't do automated container/VM provisioning setup/takedown on its own.
<Aurora_iz_kosmos>nobuffalo: (It can takeover setting up all the stuff you want in said VMs though just fine once it's started.)
<nobuffalo>Aurora_iz_kosmos: It sounds very compelling. I'll have to get an existing app running, see how it goes. Maybe, maybe I'll be able to convince that provisioning be contributed
<nobuffalo>but even if not provisioning maybe GUI hacking tools, providing project based development. How's the status on (non emacs) GUI tools?
<nobuffalo>there was a web frontend at some time
<str1ngs>guix publish --cache=/var/cache/guix does not work for me. on the server end I get this error.In procedure fport_read: Connection reset by peer
<apteryx>maybe a permission issue?
<apteryx>you could try strace -f -e open on the daemon when issuing that command
<apteryx>you can also attach strace to it using its pid IIRC.
<str1ngs>full log back trace is
<str1ngs>I don't think it's a permission issue. /var/cache/guix is owned by nobody publish server uses default nobody user
<nobuffalo>ah, I'm just seeing the 2018 GSOC page with "Remote machine deployment" on it
<apteryx>str1ngs: yeah, that backtrace only tells us it failed reading a socket
<str1ngs>which is might be normal. because it send 404 which might close the client socket
<str1ngs>stat("/var/cache/guix/gzip/30ss9cl431rrw47pbmwnqs99m2w3i5vh-util-macros-1.19.2.nar", 0x7ffce436f8f0) = -1 ENOENT (No such file or directory)
<str1ngs>also normal because it had not prodoced cache file yet
<str1ngs>here is relevant strace -f
<str1ngs>it seems just not to que the cache after 404 error
<another-user>how can i package ? it says that it uses gradle as build system but guix doesn't support it i think
<apteryx>str1ngs: just a guess: I'm wondering if it could be related to OpenSSL 1.1.1
<str1ngs>apteryx: I'm not use https for the publish server right now
<apteryx>OK. I don't know then :-l
<str1ngs>I just think the background process is not being triggered
<str1ngs>Conversely, when --cache is used, the first request for a store item (via a .narinfo URL) returns 404 and triggers a background process to bake the archive
<str1ngs>I guess I won't use --cache for now. but it really neuters the publish server. since requests are now CPU and IO bound
<apteryx>yeah, this ought to be fixed
<str1ngs>also I'm used a foreign disto. so could be related to that
<apteryx>str1ngs: do you have a simple reproducer; I could try on my Guix System.
<apteryx>just this: `guix publish --cache=/var/cache/guix' ?
<str1ngs>one sec I'll give you the full daemon command
<str1ngs>guix publish --user=nobody --port=8181 --cache=/var/cache/guix --workers=4 --ttl=1m
<str1ngs>also you need to import the publish server public key on the client.
<str1ngs>well authorize I mean
<apteryx>the error is triggered by attempting to fetch somethnig from the publish server?
<str1ngs>I think the error occurs after 404 http error . which is probably normal
<str1ngs>ie server sends 404 and client closes connect. now socket is gone.
<str1ngs>after 404 error the publish server though should bake the cache file. subsequent nar requests will server the baked nar
<str1ngs> see --cache section
*sirgazil 's membership to help-guix has been disabled again :(
<sirgazil>"Your membership in the mailing list Help-Guix has been disabled due to excessive bounces"
<str1ngs>apteryx: basically setup a publish server. authorize on the client. use the new substitute server to get nars. then turn on caching after 404 errors nars should be baked. but in my case nothing happens after server sending 404 error
<nckx>sirgazil: That usually happens because *your* mail server rejected too many list messages, not because *your* messages were rejected, no?
<nckx>sirgazil: Was there an attachment? Could you send it to your previous thread on this issue?
<sirgazil>nckx: No attachments.
<nckx>I guess those are sent to the list owners only.
<nobuffalo>sirgazil: I was on the savannah-hackers list once and my mail server went south. After a few days I had it back up running and when I tried to write to savannah-hackers got the same error
<sirgazil>nckx: And "my mail server" is not mine. I use Zoho mail, and this issue seems out of my control...
<nckx>nobuffalo: This is hosted mail tho' (Zoho), they should know what they are doing.™
<nckx>sirgazil: Sure, I know, but Zoho is still your mail server.
<apteryx>str1ngs: do you run 'guix publish' as root?
<str1ngs>apteryx: yes, though It also runs as a systemd unit
<str1ngs>I believe it context switches to user nobody
<nckx>pkill-9[m]: Which reminds me: I run a (SMTP + IMAP) mail server entirely on Guix System; the hard part isn't configuring the software, it's setting up all the little DNS records and signatures required to deliver mail in 2019 and keeping them up to date. It's certainly doable.
<nckx>The *really* hard part isn't following the standards, it's dealing with those that don't (cough
<nckx>str1ngs: Just so you know, that's not a context switch, just a… switch ☺
<str1ngs>that's semantics :P
<nckx>sirgazil: The *your* was ephasised for contrast, not to blame you in any way. ☺
<apteryx>str1ngs: my /var/cache is owned by root:root
<apteryx>and doesn't have read permissions for "others" so I guess using nobody might be problematic here?
<str1ngs>apteryx: stat /var/cache/guix for me is Access: (0777/drwxrwxrwx) Uid: (65534/ nobody) Gid: ( 999/guixbuild)
<sirgazil>nckx: Yeah, I know. And I wrote "my server" to let others know I don't run my own server :)
<str1ngs>I manually made sure the permissions are most permissive to ensure it was not a permission issue
<nobuffalo>nckx: there is a relatively young dns provider that's doing the security stuff for you and providing a REST api, if you're interested
<Aurora_iz_kosmos>Oh, sorry about that.
<nckx>nobuffalo: Thanks! I try to avoid managed solutions; running my own mail is a goal in itself. I also only see DNSSEC (→ DANE); which isn't actually hard compared to the DMARC/DKIM/MTA-STS/… mess that requires active server participation. Most servers will automate it for you… but then I'm not their target audience. At all.
<nckx>Hm. Actually I might have a use for them after all, even though I can't ‘trust’ them. Thanks nobuffalo!
<nobuffalo>nckx: good, email needs less centralization. btw, there is a non profit involved in desec iirc and they should be seeking others to join the network
*nckx oscillates wildly between ‘e-mail's fucked abandon ship’ and ‘all the rest is even worse’.
<nckx>Enlightenment is accepting both are true.
<nobuffalo>too true, but as long as you don't cave in and go into the woods ;-)
<Aurora_iz_kosmos>All the rest is worse, so far.
<nckx>nobuffalo: Even then, e-mail's *awesome*: sync your mailbox when connected, retreat to sanity, compose your replies, repeat. s/caves/the open road/ & I do this already.
<Aurora_iz_kosmos>Offline-first is the only reasonable way.
<nckx>A thousand times yes.
<Aurora_iz_kosmos>"Is it meant to be used on something I know will be in a 99.9...% uptime datacenter?" No? Then offline-first.
<atw><3 git
<nckx>To retroactively make this on-topic: I've noticed that Guix is very demanding when it comes to link quality. Some well-placed packet loss and it dies fiery. I wonder if this could be simulated and tested somehow. Is network fuzzing a thing?
<atw>nckx: that rings a bell, I think jevans wrote about using a tool to do that, lemme look...
<nckx>atw: Thanks. I'm looking at iptables (-m statistic --mode random --probability 0.xx -j DROP), but I'm not exactly a networking expert.
<atw>which shows network deterministic slowness
<mbakke>rekado: What purpose does python-future-fstrings serve? Can it be removed?
<nckx>Heh. Julia Evans is one of those names one keeps seeing over the years.
<lafrenierejm>I'm looking to add a package to Guix, and I'm currently running Guix System. I've been following the "Contributing" info pages, but running `make check` gives me an error "Cannot run tests because file name limits would be exceeded.".
<Aurora_iz_kosmos>nckx: ?
<Aurora_iz_kosmos>nckx: This seems to be what you're looking for.
<nckx>Aurora_iz_kosmos: Hey, I've heard of that before! If I paid attention, it's fuzzing turned up to the max: it actually kills whole systems/services in a redundant environment; quite the opposite of Guix's current infra, I'm afraid.
<nckx>Aurora_iz_kosmos: I'll check out LM, though. Thanks.
<nckx>(That's ‘production systems/services’, for those not already impressed/terrified.)
<atw>lafrenierejm: hello! I have not seen that error before. Does make check give that error even when you git stash your changes?
<nckx>lafrenierejm: I'm impressed that we (or maybe autotools) handle that so well. Are you building Guix in an unusually deep/long subdirectory?
<nckx>lafrenierejm: I see that it also produces a "Look for 'length' in the 'config.log' file for details." line under the one you pasted. Did you do so?
<kmicu>nobuffalo: GuixOps is WIP but for now you could use NixOps or Disnix
<nckx>[Just… don't ask…] Is anyone successfully running Java applets in Guix System's IceCat?
<nobuffalo>kmicu: thanks for the pointers. I'll take a look at that wip-deploy branch
<nobuffalo>regarding nix: sounds like the effort would double if I were to first settle on nix and later on guix, with the different language, tools, ...
<nobuffalo>and guix would be very sad if I chose nix over it, no? ;-)
<g_bor[m]>hello guix!
<g_bor[m]>nobuffalo: there is a very promising GSoC proposal targeting guix deploy, so it might be in the not too distant future.
<g_bor[m]>there is also a very well working, but ad-hoc system that is in production on our build farm. You can look at the configurations at the maintenance repository.
<nobuffalo>g_bor[m]: great, I'll have a look at the repo. the proposal is on guix-devel?
<nobuffalo>seems like I could focus on the hacking GUI, granted the proposal is accepted and something delivered
<g_bor[m]>I don't believe so. I think it should be on the GSoC site. Will have a look around.
<g_bor[m]>I will have to ask around, I did not yet get the info if we were granted a seat. I believe we should have received the communications already, should ask the org admins.
<g_bor[m]>I might take a while, as we are under the GNU unmbrella, so the communications are indirect.
<g_bor[m]>I will leave you a message here :)
<nobuffalo>your effort if appreciated, I'll hang around
<nckx>openjdk: *** This OS is not supported: Linux localhost 5.0.0-pf8-X230 #2 SMP PREEMPT 1 x86_64 GNU/Linux
<nckx>Is this a known bug or is it choking on my kernel version?
<Blackbeard[m]>anyone else having trouble to do guix pull
<PotentialUser-49>Heh, I just joined to ask the same question.
<Blackbeard[m]>oh ok
<atw>what sort of trouble?
<PotentialUser-49>When I run it as root I get a trace (can't get to it at the moment to paste in) that ends with Wrong type to apply: "/root"
<OriansJ>more precisely
<PotentialUser-49>Thanks, @OriansJ, that's the same error I get.
<OriansJ>it occurs as regular users as well
<Blackbeard[m]>yeah same error I am getting
<Blackbeard[m]>yes I am getting the error as regular user
<PotentialUser-49>My wild guess is that this commit is related to the problem: I don't know Guile or Guix very well, but since the last line of the error references the $HOME of the user running the command, and that commit was earlier today and sets up that env var... lo
<PotentialUser-49>oks like they're connected.
<nckx>This is caused by commit 48d498c2c39 but I can't for the life of me see why.
<OriansJ>and it occurs even on new installs
<nckx>Use ‘guix pull --commit=e247244’ to work around it for now.
<nckx>PotentialUser-49: Yes.
<nckx>I had the same suspicion.
<PotentialUser-49>Thanks for the workaround! Awesome.
<nckx>Now if anyone can stare at that commit and tell me how HOME is being applied…
*nckx knows little of The Monad.
<nckx>Mail sent to civodul.
<nckx>Oh, now I see the obvious.
<Blackbeard[m]>nckx: thanks :)
<Blackbeard[m]>hopefully the issue will be fixed soon
<nckx>Oh, no, I don't, herp.
<nckx>Counting brackets can be hazardous to your vision.
<OriansJ>nckx: rainbow brackets in emacs really comes in handy
<nckx>OriansJ: I tried to set that once, it didn't immediately work, I lost interest. I'm quite bad that way.
<nckx>That was rainbow-delimiters though.
<OriansJ>nckx: think of it as a chance to integrate a new step into your process of setting up new things in emacs. Try, setup and add notes to your setup
<OriansJ>nckx: actually I think there are several packages that do similar things in this regard, use whichever you like
<Formbi>I have «(use-package rainbow-delimiters :ensure t :config (add-hook 'prog-mode-hook #'rainbow-delimiters-mode))» and it just works™
<nckx>Formbi: I'm fine with M-x'ing it only on demand. Now I see the issue: I was using emacs in non-GTK (16-colour) mode and I guess the default rainbow palette needs All The Colours to be of much use. Makes sense. Looks great in graphical mode.
<nckx>Would still be nice to ‘fix’ it with custom colours (I use -nw a lot) but not urgent.
<nckx>OriansJ: Are you one of those cool folks whose .emacs is an org doc?
<Formbi>I have st with 24 bits and rainbow delimiters work
<Formbi>hm, with 256color too
<nckx>Formbi: I have, what, 4 bits? So yeah, TODO.
<nckx>Now they're coloured in groups of 3. Better than nothing.
<OriansJ>nckx: Actually I am one of those wierd folks who bootstrap in tiny environments running SET
<nckx>Hmm, no, my termite can handle (at least) 256 colours just fine, it's just emacs.
<nckx>Formbi: Will bookmark for when time, thanks.
<OriansJ>and yes that is a 1,072byte large text editor that runs natively on hardware
<nckx>OriansJ: Sorry, I forgot for a moment whom I was talking to. Of course you do!
<g_bor[m]>nobuffalo: yes, the proposal was accepted, you can have a look at this thread on the mailing list:
<dalz>Can someone remind me the command used to get a package definition?
<amz3>dalz: guix edit emac
<dalz>amz3: thank you very much!
<nckx>Formbi: I cheated and skimmed it anyway. Is it implying that my problems stem from running emacs as a daemon and not directly in the terminal? Because that would make sense; I do.
<apteryx>str1ngs: OK, I think I have a setup to try it
<nckx>Not sure what else to make of those complicated instructions involving screen(??)…
<Formbi>can't you run it normally with «(server-start)»?
<apteryx>my nobody user doesn't have permissions to write to /var/cache/guix; let me fix this
<nckx>Formbi: I run it from The Shepherd.
<amz3>g_bor[m]: that is good news.
<nckx>Saves me a few seconds of mu4e spinning before I can read my mail after login.
<Aurora_iz_kosmos>OriansJ: That's some next-level minimalism.
<nckx>Aurora_iz_kosmos: The eventual plan is to use OriansJ's (and others') awesome work to bootstrap Guix. How cool is that.
<Aurora_iz_kosmos>nckx: Neat, though I'm not sure where in the bootstrap sequence that fits.
<Aurora_iz_kosmos>(Mind, I'm mostly unfamiliar with the low-level details of GuixSD)
<nckx>Aurora_iz_kosmos: The very beginning. Imagine human-readable ‘binaries’ that bootstrap your entire system from source.
<Aurora_iz_kosmos>That's bizarre. I'll be curious to see what that looks like.
<amz3>it looks like code :)
<nckx>Aurora_iz_kosmos: Some links in human-readable language that should be able to bootstrap understanding:,
<Aurora_iz_kosmos>Ah... I see the idea.
<Aurora_iz_kosmos>That's very neat.
<g_bor[m]>hello guix!
<nobuffalo>g_bor[m]: that looks very promising, really looks like something tangible is on it's way
<g_bor[m]>The whole set of icedtea packages are failing to build on recent kernels. We are above the staging limit, with around 400 packages depending on icedtea. What would be the best course of action here?
<nckx>g_bor[m]: Ah, thanks (even if it wasn't in response to my question above).
<g_bor[m]>nobuffalo: yes, really nice. This is one thing I was really waiting for ever since I've seen guix :)
<nckx>g_bor[m]: I'd say that ‘rebuilds’ that finally build failing packages for the first time aren't really ‘rebuilds’ but that's just me…
<g_bor[m]>nckx: the problem is that we still have a few days old successful build on berlin, I guess the build farm is using another kernel version...
<g_bor[m]>I will try to check the substitue coverage, but I believe we have most of the packages also...
<nckx>g_bor[m]: Ah, so the very latest versions are still being built fine on berlin?
<g_bor[m]>But as soon as the kernel gets updated there, this will become a much bigger problem...
<g_bor[m]>rekado told me we have a build from May 8th.
*nckx is a little surprised that ‘guix weather PACKAGE’ doesn't work.
*nckx echos > m; guix weather -m ~/m but this seems unideal.
<nckx>OK, I guess as long as berlin is building these packages (with considerable delay) I retract my previous opinion about master vs. staging.
<nckx>But it's not a nice feeling to being one unexpected reboot away from losing them.
<nckx> is unreachable for me (HTTP 504).
<g_bor[m]>nckx: I would still vote to push these to master, as a kernel update on the build farm would cause serious problems very soon. Wdyt?
<nckx>g_bor[m]: You have my vote, FWIW. 😛
<nckx>Staging/master/etc. is about prioritising, not a rule for its own sake, and this is a priority.
<g_bor[m]>nckx: ok.
<g_bor[m]>Now I have the fix for icedtea-6, I guess the same thing works for all of them.
<g_bor[m]>I will build them one locally, and if everything seems fine, then I will push.
<nckx>g_bor[m]: Is this issue fixed upstream? Does upstream consider it their bug? If not, can we just disable this unnecessary check entirely? (Maybe that is your fix, IDK.)
<nckx>Sooner or later, nonsense like this is going to drive us towards making guix-daemon an full VM… Enjoy overhead-free building while you can, folks.
<g_bor[m]>nckx: This is a known, and recurring problem. The same thing happend on the switch from linux 2 to 3. I did not check the upstream status, as there is an environment variable, that disables this particular check, and after discussing this with rekado, it seemed to be more future-proof to disable it completely.
<reepca>for what it's worth, there's already an impersonate-linux-2.6 option for the daemon.
<OriansJ>Aurora_iz_kosmos: the discussions about bootstrapping usually occur on #bootstrappable and if you are interested we can explain the full bootstrap of guix/guile/gcc from a 250byte bootstrap binary on bare metal. Not to mention libre hardware is always a fun topic of dicussion for those who want to help out.
<nckx>reepca: Isn't that related to the ‘personality’ split, and not something we could arbitrarily add to?
<Marlin1113>Are there any gui frontends for guix?
<nckx>Marlin1113: Hi! Nope.
<reepca>nckx: aye
<Marlin1113>i think you can use it with emacs, right?
<nckx>Marlin1113: Oh, yes, there is emacs-guix.
*nckx has been burnt by ‘that's not a GUI!!!’ reactions :-/
<Marlin1113>i'll try it out
<Marlin1113>how do i use it on emacs? heh
<Marlin1113>i don't really know how to use emacs
<reepca>Marlin1113: C-h t will get you the emacs tutorial (that's "press h while holding down control, release both, then press t")
<reepca>and C-h i m "emacs-guix" RET will get you the emacs-guix manual
<anon12345>hello, i just made a fresh install with the following config and im getting the following error any ideas?
<anon12345>sorry and i get this error when trying to guix pull after my install is complete, thanks for your time.
<PotentialUser-49>Hello anon12345, I can't speak to the other error but the first error is from a bad commit to the Guix repo. As a temporary workaround you can do guix pull --commit=e247244 (thanks again for that, nckx!)
<PotentialUser-49>Err... second error, on the guix pull. Not the first.
<anon12345>okay ill try that thank you!
<nckx>anon12345, PotentialUser-49: civodul seems to have taken a well-deserved evening off; I've reverted the offending commit for now. Plain ‘guix pull’ should work again.
<anon12345>okay, thats great to hear!
<apteryx>str1ngs: I can't seem to reproduce the bug.
<apteryx>The only problem I had was with trying to run the guix-daemon as root, it refused to do operations such as guix-download