<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 paste.debian.net? 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.
<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>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>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>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
<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
<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 berlin.guixsd.org seems to be down. I'm getting a 504 Gateway Time-out.
<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.
<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
*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?
<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 lists.gnu.org).
<nckx>str1ngs: Just so you know, that's not a context switch, just a… switch ☺
<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>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.
<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.".
<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?
<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
<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.
<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.
<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!)