***jonsger1 is now known as jonsger
<Marlin[m]>What are the differences between guix and nix? <str1ngs>Marlin1113: guix uses scheme for package expression, nix uses its on expression syntax <sirgazil>I'm getting a "No prompt found!" error when I try to connect Geiser to Guile like this: <sirgazil>1. In a terminal, run "$ guile --listen=/tmp/guile-socket" <sirgazil>2. In Emacs, "M-x geiser-connect-local", then "guile", and finally "/tmp/guile-socket" <sirgazil>When the Guile REPL start in Emacs, I get a "No prompt found!" in the echo area, and the prompt in the REPL looks like this: <sirgazil>And then, the Guile REPL running in the terminal says: <str1ngs>sirgazil: works for me. what version of guile? <str1ngs>I'm not using geiser from guix myself <str1ngs>0.10 seems old. I'm using geiser from git. via straight <sirgazil>str1ngs: That's the version of the Guix package. <sirgazil>One of my goals is to use Guix to install packages that I used to installed with language-specific package managers. <str1ngs>let me try with emacs-geiser from guix <str1ngs>emacs with no config, and useing emacs-geiser from guix connect to repl no problem <str1ngs>though maybe test with no emacs, config <str1ngs>also this seems suspect Tubería rota <str1ngs>ah thank you. that's not suspect now <sirgazil>str1ngs: Using no ".emacs", and I get the same problem. <sirgazil>The one that the system install itself. I haven't touch that. <sirgazil>It seems. When I was going to activate readline support (as I used to do in foreign distros), I was surprised that there was already a .guile with readline support and colorize. <str1ngs>hmm I wonder if it is colorize issue. <str1ngs>try backup ~/.guile see restart repl <str1ngs>I'd love to know how gieser detects the prompt. it's no trvial task to do. since you cant just read to EOF <str1ngs>I've created my own terminal repl client. and detecting the prompt is PITA <str1ngs>seems /etc/skel/.guile adds the skel file I assume <sirgazil>str1ngs: It's the frigging .guile file. Thanks! <str1ngs>also INSIDE_EMACS=y guile --listen=/tmp/guile <str1ngs>I wish guile had some magic bit to detect at end of prompt! <bt`>The closest I was able to get to a functioning Xorg on my Librebooted X60s was with acpi=off. What would happen is that my system would try to load slim hang with multi-color static over the screen or black screen and reboot but this time succeeding. I can't seem to get any further than this. The two messages that seem relevant in the logs are a ACPI warning about a SystemIO range overlapping with a Opregion and intelfb failing to <bt`>reserve the FB region. https://arborescent.tk/messages.txt https://arborescent.tk/config.scm As I mentioned this is probably the last thing I'll need assistance with, because I've already migrated my data and reinstalled my user applications and when I was able to login they seemed to function correctly. As always thanks for your time, and unlike other times I feel like I've tried everything I know to so I won't be rebooting to test <bt`>things for some time. <reepca>bt`: looking through your config, haven't spotted errors yet, but note that you could replace (comma-seperated strings) with (string-join strings ",") <bt`>Oh, it's standard too! I need to read through the srfi's still there are many I'm not as familiar with as I should be. <bt`>okay, that much has now been corrected. <reepca>bt`: what does /var/log/Xorg.0.log look like? <bt`>I looked and was under the impression that it didn't make one. <bt`>It's possible it was just over-written though by my system after the reboot. <bt`>It looks like it's the right error log actually, I'll upload it, one moment. <bt`>okay that's it, the `:b' was me failing with evil mode, which happens sometimes. <bt`>If that doesn't seem right or if you've not got any other ideas I setup a config without X to boot into after I try with the crash one to make sure the log isn't overwritten, what I've been doing is just setting modeset to zero in grub to boot. <reepca>bt`: IIRC leaving the drivers field of xorg-configuration blank will cause xorg to automatically pick one. What happens if you change your config to not specify drivers? <bt`>I get the same fault, also if I manually set it to vesa, I can get logs for these as well if they'd be helpful I remember there being a little more going on in the Xorg.log when the driver is unset. <bt`>When I was booting with nomodeset the error with Xorg was that it couldn't find the fbcon module if that's helpful (I suspect it's no though) file2019-05-14.log matches <reepca>M4R10zM0113R: guix edit, somewhat contrary to the name, is mostly useful for locating and reading package definitions, not really for editing, because the package modules installed by, for example, 'guix pull' will all be in the immutable store. <reepca>bt`: I'm no expert regarding kernel and xorg sort of things, what I personally would try is reconfiguring with a bog-standard config.scm, like the example desktop one, to see if it works / how it fails (assuming you haven't already). <reepca>It might also be a good idea to check in other channels that are more specialized in these sorts of issues. For example, #xorg might be able to give you more feedback on the log file. <bt`>The closest I got to that was the installer, which I also had to add nomodeset for to load (which is odd because it just looks like a curses application) I'll strip down my config (including the fs stuff) and see how it goes I might wait until the morning though. Thanks for your help, again. <bt`>For sure, I'll check out #xorg, and #libreboot if stripping things down doesn't work. <reepca>M4R10zM0113R: sort of depends on what you mean by "overriding". For example, if you want to override "gcc" in the entire package dependency graph, you'd want to use channels to specify a customized guix repository. If you just want installing gcc to install a tweaked version, you could put a module containing that tweaked version in GUIX_PACKAGE_PATH. <reepca>see section 6.1 of the manual ("Package Modules") for more info <M4R10zM0113R>Would it be monumental to do, say, make everything try not to use pulseaudio? would that be applicable on config.scm? <M4R10zM0113R>Or would I have to make every single package in the entire dependency graph? <reepca>'guix graph --type=reverse-bag pulseaudio | dot -Tpdf > pulseaudio-dependents.pdf' will give you everything that depends on pulseaudio in graph form. That should give you an idea of how much would need to be changed. Note, though, that it could be changed programmatically (see section 7.1.2 "Package Transformation Options" for an idea of what's possible). <PotentialEnergy>is anyone aware of an existing map of guix package names to debian / ubuntu package names or vice-versa? <reepca>section 14.4.2 of the manual, "Package Naming", gives guidelines for naming. Presumably debian and ubuntu have their own guidelines. I know it's possible to go from the upstream name to the guix name, but I don't think the inverse is true (guix lowercases the name). I'm not aware of any concrete mapping already made, though. <PotentialEnergy>Yeah, from what I can tell guidelines won't do it, there's just enough inconsistency to still necessitate a curated map <PotentialEnergy>e.g. `apr` in guix is `libapr1-dev` in ubuntu, but used to be `libapr` in guix a few years back <PotentialEnergy>it's ok, I just thought I'd see if anyone who was around knew of something like that. thanks, reepca <brendyyn>PotentialEnergy: i think it would be a good project to write a program that analysed guix and debian repositories to generate such a map <buenouanq>I've considered putting various dotfiles in my config.scm, then editing that and system reconfiguring when I want to change something. <buenouanq>But I'm not sure that's the best way to go about it, so I haven't tried yet. <str1ngs>while on the topic environment. what does GuixSD use to set X11 session environment variables <str1ngs>also GuixSD X11 does not read .Xresources on login. <reepca>civodul: did you get a chance to look at the questions I emailed? <roptat>does anyone knows if there is an api to get the latest release of a software when they come from a cgit? <roptat>also I have a question about guix pull <roptat>from the work I did to generate translated manuals, it seemed to me that the complete guix repository is an input to the guix-manual derivation <roptat>so we end up rebuilding a new derivation when someone updates a package, even though the manual and translations didn't change, am I right? <roptat>is it also the case for all the other derivations built by guix pull? <manzerbredes>Hi! I am trying to run "guix --install-from-file=myfile.scm" (I define my package in myfile.scm) but nothing append. And nothing is installed. Actually, <manzerbredes>myfile.scm contains an existing package definition that I found on the guix package repo <roptat>you probably have something like (define-public ... (package ...)), you could add a line with the name of the package at the end of that file, so the file evaluates to the package, or you could remove the (define-public ...) wrapping around (package ...) <reepca>or you could run 'guix -L myfile.scm --install <package-name>' <roptat>yes, so that file doesn't evaluate to a value, but it defines a value that is assigned to the variable 'notmuch' <reepca>actually perhaps it should be 'guix -L . --install <package-name>' <roptat>I don't think that will work unless you make that file a guile module <roptat>manzerbredes, try to add "notmuch" at the end of that file (without quotes) <reepca>sorry, forgot the package part. Should be 'guix package -L . --install <package-name>' <roptat>define-public linked the package value to the variable 'notmuch', so to return that value you can simply return the variable <civodul>reepca: not sure! i started integrated your patches for (guix store files) etc., and then stopped, because i realized that if we expose 'make-derivation' then we make it possible to create invalid <derivation> records <reepca>civodul: perhaps the references in (guix derivations) should be changed to use (@@ (guix store derivations) make-derivation)? <manzerbredes>I am a bit in trouble with guile even if I come from Common Lisp but anyway I'll give a chance to guix <puoxond>I was wondering why I had to build linux-libre even though it was updated 3 days ago. So I checked the build farm and it turns out the build failed (the log suggests the build machine ran out of space). <civodul>reepca: that's a possibility, but it's kinda ugly <civodul>another option would be to move the "canonicalization" work to make-derivation <civodul>anyway, the (guix store files) part is definitely acceptable, but i think both were in the same patch <civodul>so we first need to separate that bit out <manzerbredes>using local-file but when I'm trying to install build it, guix says: "no code for module (hello-world)" <reepca>manzerbredes: aye, it needs to be defined as a guile module when used that way. So at the top put (define-module (hello-world)). <puoxond>What's up with Cuirass failing to build substitutes for guix pull (guix-modular-master) on armhf-linux and aarch64-linux since around commit c2974d1 (12 days ago). It looks like they all say "Dependency failed". <manzerbredes>In package definition, how can I tell gnu-build-system to use only the make phase ? <roptat>manzerbredes, you can use (arguments `(#:phases (modify-phases %standard-phases (remove 'configure))) to remove the configure phase for instance <kdtsh>hello everyone! is it appropriate to ask for support questions here? <kdtsh>thanks. I've been attempting a 'guix pull && guix system reconfigure /etc/config.scm' after having installed guix 1.0.0 to a VM and making a change to config.scm to include %base-packages in the packages list (after having used the graphical installer to install guix 1.0.0). I've been getting stuck at the stage when linux-libre-5.1.1 builds but nev <kdtsh>er seems to complete. The spinning cursor turns over periodically so I'm not sure the process has stalled, but I've tried leaving it for a day and it hasn't been able to finish <kdtsh>Is it normal that it should take this long? I've tried to find a way of turning on some extra logging for 'guix system reconfigure' but can't find a verbose or trace option. It never seems to fail either so it may just be taking a long time. My VM is running in qemu and I've apportioned it 2048M of memory <manzerbredes>roptat: thx, but there is several phases that I don't need and I was wondering if it is not possible instead of deleting phases, to just specify the one I want to use <roptat>manzerbredes, I don't know of any way, because you'll want more than that phase: decompressing, probably patching shebangs... <roptat>maybe you want to use the trivial-build-system instead and define your own build procedure? <roptat>it's a bit difficult to use though... <rekado_>kdtsh: we don’t have a binary for linux-libre 5.1.1 at this point. <rekado_>kdtsh: it’s now being built and hopefully you’ll be able to fetch it instead of having to build it locally. <rekado_>building the kernel can take some time. <kdtsh>@rekado_ Oh right I see. If there's a binary currently being built then I'll wait until it's released and I can fetch it rather than building myself - thanks for that <kdtsh>While I'm here, is there any flag to show more verbose logging when running 'guix system'? - or is it simply not necessary/useful? <civodul>i say "transient" because berlin has no build logs for these <civodul>that happens sometimes when offloading fails <civodul>i think the next evaluations should work <rekado_>the x86_64 build also was a cached failure. <rekado_>I cleared the failure and restarted the build. <rekado_>kdtsh: what kind of things would you like to see logged? <rekado_>kdtsh: all Guix commands used to be very noisy and we tried to make them less noisy by default. <rekado_>you can get at all the noise with some verbosity options, though <kdtsh>rekado_ I suppose in reality I'd be happy with some kind of noise as a sanity check. I can see how build logging would be fairly pointless - but if I can see that *something's* happening it'd be useful. Knowing that this is just part of the fact that the kernel takes a while to build is helpful though <rekado_>FWIW linux-libre for x86_64 is now built. After requesting a binary it may take 5 minutes for the substitute to be “baked”. <brendyyn>why does it take so long for it to do that <rekado_>the TTL of the “not found” response is 5 minutes <rekado_>plenty of time to fill the cache with a substitute archive. <rekado_>archetyp: the build, but not baking the substitute. <roptat>maybe we could have a verbosity level where we show what command is being run (through invoke for instance) <roptat>it could be a good intermediate level between silent and very verbose? <amz3>imo guile needs a logging facility. <brendyyn>Good to see a system call srfi being produced. maybe guix's syscall can be switched for a librry too <sirmacik>you can turn on tor in tor browser button but traffic isn't routed despite notification on succesfull connection <sirmacik>it works on arch with the same version of icecat <g_bor[m]>I have an idea, but first I would like to check if you think it would. Can we use the grafting code to modify hardcoded self-references in our outputs? I believe yes, but I am not very familiar with it. <g_bor[m]>I was thinking about making content addressable store a thing :) <roptat>g_bor[m], it must be possible, but grafting creates a new derivation <efraim>IIRC the grafting code looks for exactly /gnu/store/32-characters <roptat>can't we already do that with a fixed-output derivation? <boristhespoon>Hello all, what package now contains libstdc++? Previously, it was gcc:lib, but now it is <g_bor[m]>roptat: maybe we can... I belive this is just a composition of a build and this reference rewriting. The result is essentially a fixed output derivation. How would this look using a fixed otuput derivation? <g_bor[m]>What provoked my thinking was that commits like disabling a test will not change the output, so we can avoid rebuilding in this case. <rekado_>g_bor[m]: how can we be sure that disabling tests does not change the output? <roptat>I'm a bit uneasy with fixed-output derivations, they are a bit magic... and we have issues when something in changed in-place but the old version was already cached... <roptat>like what happened with github tarballs <rekado_>g_bor[m]: running tests is often done via “make check” and that may cause the tests to be compiled, which can lead to new files being generated that might end up in the output. <g_bor[m]>rekado_: no way, but by checking the output it is obvious if it does. I meant we could avoid rebuilding the reverse deps, no the single involved package itself. <roptat>so we need something else than a fixed-output, if we have to rebuild the package, otherwise, the declared output will ensure that the package itself is not rebuilt, even if the recipe changed <g_bor[m]>if it still changes the output, that is unfortunate, but in the cases where it does not, then it's a pure win. <rekado_>g_bor[m]: we can’t check the output before having built both variants. <g_bor[m]>yes :) that is true, but we are building both variants anyways. <rekado_>and even then: the inputs differ because the package definition differs in whether the tests are enabled or not. <roptat>but in that scenario, the input is the same because it's a fixed-output derivation <roptat>but it doesn't work because the old build is cached, so we need something slightly different <g_bor[m]>Ok, so let me restate my points: if we are in the situation, that when we build a package, and then another variant of the package, and the relocation of the variant to the prefix of the original results in the same output, then we can content address the original package. <roptat>I think the issue here, is how do we build dependents <roptat>if their input is the non-content-addressed package, we didn't win anything <roptat>because the derivation is different <roptat>but, unless we build the dependency, we have no way to know what the content-hash will be, so we cannot build a derivation for dependents... <g_bor[m]>roptat: I would say to include the content-address in the package, so that we can still use way we do it right now. If a package does not provide a content address, we simply fall back to the current behavior. If it does, then we try to use that. It needs some logic, but I feel it might worth it. Wdyt? <g_bor[m]>My only problem with this solution is that we should make sure, that the content address is in sync with the definition. <rekado_>mbakke: generally, I don’t mind. I wonder about the changes to python2-pbcore (and others like it) that would have Python 3 and Python 2 things in the build environment. Is this a problem? <g_bor[m]>roptat: do you have any idea how we could do better? <roptat>maybe nix people have already thought about that problem? <g_bor[m]>roptat: maybe. One thing I was thinking about, if this is a trust problem, or more of just a workflow problem. If we say that the user using a channel trusts the channel, then this is not a security problem, so we don't need to worry about someone maliciously injecting values there. Then maybe we just need to come up with a good workflow and tooling, that makes sure that it gets updated. <roptat>I don't think it's a trust issue <mbakke>I don't think it's worth holding on to python2-sphinx just for pbcore though, we can figure out some workaround if it turns out to be a problem. <g_bor[m]>roptat: so, maybe we could come up with a good workflow suggestion... <g_bor[m]>One of the simplest thing would be to fail the build on mismatch <roptat>that's what fixed-output derivations do too <roptat>I'm more concerned about what happens when we built another variant of the same package that declared the same output, but the new variant actually results in a different content <roptat>I think that's the only difficult case <roptat>oh, and maybe that case: A is modified and has a new behavior. B depends on A, but its output has the same content as before. C depends on B, and B actually calls A's binaries using $PATH, resulting in a different content in C's output <roptat>(using $PATH is the reason why there was no change in B) <roptat>can we make sure that C is rebuilt if it doesn't directly depend on A? <roptat>wait, that's stupid, because in that case A is not in the build environment of C... so no issue here <sirmacik>It's cold and raining outside, seems like a perfect day to roll-out guix on my work machine (; <mbakke>rekado: Actually, pbcore uses Sphinx for tests and fails with the Python 3 variant. <mbakke>However the latest versions appear to have Python 3 support.. Could you try updating it? <mbakke>I notice some of the python2 transformation packages are also failing... So I'll try to reinstate python2-sphinx for now. <g_bor[m]>roptat: I believe that the issue is that a variant is pushed, it fails to build on the output check, and the dependent resolves to the old version. <devilishtype>I just installed guixSD for the first time, I used the guided install and selected AwesomeWM. Everytime I go to restart awesomeWM while I mess with my config it knocks me back into GDM login screen. <roptat>devilishtype, there's a known bug about that... I think the manual has a fix for it <devilishtype>I already installed coreutils and such, that has something to do with awesome kicking back to the login? <roptat>I think it's because you're missing '%base-packages' in your config (but it might be something else) <devilishtype>I installed openbox too, lets see if reloading config in openbox does the same thing <devilishtype>if I disable desktop service in my config.scm I'll just boot into a tty? <devilishtype>I installed to a VM so I dunno why I'm asking not like I can't rollback a snapshot :P <rekado_>devilishtype: whenever you change the config file you need to reconfigure the system. <rekado_>changing the file alone has no effect at all. <roptat>so did you run "guix system reconfigure ..."? <devilishtype>I'm doing multiple things at once here I'm going to reboot it here in a sec. <devilishtype>I dunno if I didn't do something right the first time, but this time it's barfing out all the drv updates. <rekado_>mbakke: pbcore 1.7.1 aborts when building with Python 3, saying “pbcore requires Python 2.7” <mbakke>rekado: OK. It seems we need to hold on to python2-sphinx for a while anyway. <ruffni>guix system reconfigure raises a "Did you forget a use-modules form?". how do i find out what modules contain my packages? <rekado_>ruffni: “guix package -A my-package” lists the package and the name of the file containing its definition. <rekado_>ruffni: the file name matches the module name. <rekado_>e.g. gnu/packages/bioinformatics.scm —> (gnu packages bioinformatics) <ruffni>is it safe and/or recommended to edit /gnu/store/hash/config files? or should this be done via config.scm? <g_bor[m]>roptat: very nice indeed, and I feel that their discussion came to similar conclusions. I will write a proposal to the ml with a summary of this discussion. <ruffni>because it will be overridden at reboot/reconfigure? <rekado_>ruffni: the store should never be modified. <rekado_>ruffni: Guix assumes that only the daemon changes the store. <rekado_>by modifying things in the store you violate that assumption and things can go wrong. <ruffni>makes sense :) so how do i change stuff in there? via config.scm definition? <rekado_>ruffni: what is it you’re trying to change? <rekado_>(not even the guix-daemon changes things in /gnu/store; it usually just adds new things or collects garbage) <ruffni>i'm trying to figure out how all of this works. but for now, i'd like to start nethack in wizard mode from my user. my user has group "wizard" (already figured out that much). so i'd like to change the "WIZARDS" value to * or to include my username <rekado_>I’m sure the name is intentional, though. <civodul>how does one create a FAT16 partition with parted/mkfs.fat? <nckx>I know so many useless things. <nckx>Always nice when they suddenly, briefly, become useful. <civodul>so i managed to create a fat16 partition, but somehow the installer still thinks it's fat32 <nckx>civodul: Sounds like ‘fat16’ is the partition type, not based on (but probably matching) the actual file system's FAT size. <nckx>I never liked parted because it completely confuses all this stuff presumably in the name of user-friendliness… <nckx>civodul: How about ‘mkpart primary fat16 …’? *jonsger is sad about the fact that Guix 1.0.0 is still not accepted in Tumbleweed :( <nckx>civodul: Hm. I wonder what ‘sfdisk -l /dev/sdx’ returns on both systems. <jonsger>civodul: no, they are just slow at handling requests at the moment... <nckx>civodul: Hum? That sounds wrong. I'm going to try it, too… <nckx>civodul: Oh, that's the table that does work even though it shouldn't, right? <nckx>I just read the linked report. <civodul>well apparently the installer reads the current partition table, sees "fat16", and then breaks <civodul>but i couldn't reproduce this particular issue <nckx>And your ‘7’ (MS Basic Data) read as fat32. Got it. <nckx>civodul: The code used by gdisk &c., never mind. I just saw Danny pushed something adding fat16 to the installer, though. <nckx>(The UUID for MS Basic Data is, well, a long UUID, but parted seems to map (see: yech) it back to legacy partition type 7 for some reason.) <str1ngs>civodul: I do have have package for my web browser, though I had to create a module qtwebengine. which still needs some polish. which I hope I can send to guix-patches eventually *nckx .oO is QtWebEngine Free? <str1ngs>it's as free as ungoogled-chromium at qtbase <mbakke>efraim: Have you looked into Qt 5.12 yet? <str1ngs>aye, qt could also use a bump to 5.12.3. and the module qt packages could use some work. <nckx>str1ngs: mbakke posted it in a conversation, not the patch tracker. <nckx>I guess they have their reasons. <str1ngs>I understands, thanks for the reference though <nckx>‘I haven't fully audited the source yet’ probably being that reason. <str1ngs>also I have a fix for the QtWebengineProcess issue that qutebrowser experiences later in the thread. <mbakke>civodul: The actual fat-ness is set by the "mkfs.fat -F" argument. <str1ngs>this package is still very much WIP. and requires some odd hackes to get some locales working <mbakke>We can probably get away with treating fat16/fat32 as the same, and leave figuring out the best fit to "mkfs.fat". <str1ngs>nckx: my plan, is to polish qtwebengine. then move it to qt.scm and send it to guix-patches. <nckx>mbakke: We already tried that, though. <civodul>mbakke: well Danny already added FAT16 support to the installer, so i think we're fine now :-) <str1ngs>also do inputs automatically get added to runpath? <str1ngs>and is it possible to manually add something to runpath? <str1ngs>in regards to elf dynamic section runpath I mean <efraim>mbakke: I haven't looked at it yet, I've been really busy <efraim>With 5.11 the qt update got its own branch with 400(?) dependent packages <mbakke>efraim: Right, no worries. I might try it out in a couple of days. <boogerlad>" Note that there is no xorg-service procedure. Instead, the X server is started by the login manager, " What if I don't want to use a login manager? Unnecessary bloat for a single user machine ***marlon__ is now known as Marlin1113
<str1ngs>boogerlad easiest way would be to use %base-services instead of %desktop-services. alternatively you can modify %desktop-services, though I don't know how you would remove gdm that way <str1ngs>if you use %base-services you'll have to specify what packages you install. like X11 etc <str1ngs>also xinit if you plan to say use startx <str1ngs>also you could just tell herd to not start xorg-server? <boogerlad>I would like to use xorg though. If I wrote a "xorg-service" procedure, would it be accepted into guix? or does that service not exist intentionally? <str1ngs>xorg is not a service on it's own. it requires a display managar <str1ngs>without a display manager generally you invoke it with say startx. which is not a service either <str1ngs>so if you don't want to use a display manager, my suggestion is to use startx. aka xinit <str1ngs>if you were to just start X from a custom service, it would run as root user. so that's not good <str1ngs>with startx it atleast requires a user login via virtual terminal <str1ngs>also I don't how well xinit would work with GuixSD but it's a better approach to what you want to do. IMHO <boogerlad>how would I automate the login process as well? <str1ngs>with xinit not easily. I would use GDM for that <str1ngs>gdm-configuration has a auto-login field <boogerlad>seems mingetty-configuration has a auto-login field <sirgazil>I had working bluetooth before installing the GNU system with Guix, but I don't know if the previous system (Ubuntu) had non-free things installed to make it work. <mbakke>sirgazil: That means Linux-Libre failed to load a (presumably non-free) firmware file for your BT adapter. <sirgazil>mbakke: I see. Do you know any way to know the make and model of my bluetooth adapter? <mbakke>sirgazil: Check 'lspci' and 'lsusb'. *sirgazil can't tell which device provides bluetooth... <nckx>sirgazil: One should have ‘[Bb]luetooth’ somewhere in the output; otherwise paste the output of both to paste.debian.net. <PotentialUser-52>I couldn't get guix to boot. I successfully copied it to the usb disk. My laptop is librebooted. I get a menu whenever it starts up about booting a usb but when I try to I just get a lag and then nothing happens. <sirgazil>h-node doesn't know most of this devices... <nckx>sirgazil: Hm, AR9565 seems to have bluetooth capabilities. <nckx>(Or does it? Everyone saying so on the Internet is very confused themselves, disregard :p ) <nckx>So that's your Bluetooth card found. <nckx>It needs a firmware blob, sorry. <sirgazil>nckx: Thanks :) And what would be a "certified system". This machine is from Dell and it came with Ubuntu 16.04 preinstalled. I bought it because most Dell machines I've used tend to work with libre distros too... <nckx>sirgazil: I don't know, I just used that link to find out what that strange 0cf3:e005 communications device was. <nckx>sirgazil: I'm now certain that the firmware is proprietary. Sorz. <nckx>Well, I found the licence, but I can't link to it without pointing to the blob too; but it's also in Debian's ‘non-free’ repository, for example (their copyright link is broken though). <nckx>I'd point you to a firmware-free alternative if I knew of one. *nckx owns no BT hardware 🤷 <rekado_>I only know of USB dongles that work with Linux libre. <nckx>What's stupid is that these are all internally-connected USB devices to begin with. <sirgazil>rekado_: Those things are usually hard to get where I live, though. <rekado_>my old X220S had a built-in bluetooth thing that worked with Linux libre. <rekado_>unfortunately I can’t use it in any of my other laptops. <sirgazil>I don't use bluetooth devices often, but I was hoping to try using a gamepad as a mouse... <str1ngs>rekado_: does the wifi module work though? <str1ngs>rekado_: I have x220 and I can't use the libre kernel <rekado_>on the X220S I flashed Libreboot and then I changed the Wifi card. <str1ngs>ahh that gets around the wifi whitelist issue <sirmacik>str1ngs: I've flashed whitelisted bios and changed wifi card <sirmacik>my option is less dangerous if something goes wrong <rekado_>wait, I had the x200s, not the x220s <sirmacik>but ultimately I'm going to flash coreboot/libreboot <str1ngs>I would like to flash libreboot or atleast the whitelist bios <str1ngs>though I don't want to brick it in the process <sirmacik>for now only coreboot is supported and I'm gatering all the parts needed (clipchip and so on) <rekado_>on the S flashing the chip is tricky as you need to disassemble everything; on the others x200 it’s not too complicated if you have a clip. <rekado_>some people offer a flash service for a fee. <str1ngs>actually I was thinking of getting a x1 <sirmacik>hmm, I've just watched rms speech from libreplanet2018, what's the name of the free software decompiler he talks about? <sirmacik>maybe someone knows from the top of his head <sirmacik>because it's name is not mentioned during the talk on somewhere in the notes <g_bor[m]>I would like to extend the nignx-php-location procedure a bit. I would like to expose the uri, with the default it has right now, and add support for passing to tcp, as it now only works for unix sockets. Wdyt? <nckx>I just got an ‘In execvp of bash: Operation not permitted’ error while toying with the installer; sounds familiar; this has been reported, right? <rekado_>I wanted to add certs for guixwl.org and various guix.gnu.org things, but certbot doesn’t let me. <rekado_>“Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.” <rekado_>I tried the standalone method (stopping and restarting nginx before and after) and the webroot method, but neither work. <rekado_>the internet suggests that, but this doesn’t seem to be the case <lfam>I can try updating it now <rekado_>it seems to work fine when using the old API <lfam>What method is it configured to use by default? <rekado_>I don’t know about the defaults; how can I see them? <rekado_>(I picked the standalone method while nginx was stopped) <lfam>There should be a configuration file in /etc/letsencrypt that is created based on how certbot was run initially <lfam>Yes, there should be a per-domain file under /etc/letsencrypt/renewal <lfam>I just pushed a commit that updates certbot to the latest <rekado_>they all have different settings; for some it’s standalone via the v02 API, for the guixwl.org domains it’s standalone via the v01 API (which is not surprising, because that’s what I told it to use just now) <lfam>Well, we just got ourselves 90 days to figure it out :) <rekado_>every 90 days I’m confused about this all over again. <lfam>The ideal setup would be a daily cronjob, meaning it would actually renew every 60 days <puoxond>It looks like Cuirass is still failing to build guix on armhf and aarch64 (According to the web interface). <rekado_>puoxond: I’ve just cleared the cached failure for armhf-linux <nckx>lfam: LE themselves [used to] recommend running it twice daily, even. <puoxond>rekado_: I thought civodul had already done that. <rekado_>for aarch64-linux the “guix” package has already been built. ***apteryx_ is now known as apteryx
<apteryx>a guix channel doesn't help distributing binaries, rigth? <dmarinoj>apteryx: A channel is a git repo with some scm package definitions so it is orthogonal. That doesn't mean that the git server where the channel is hosted can't double as build server <dmarinoj>Actually I kind of want to set up a desktop I have as a git server/build server <apteryx>does user applicatiosn make use of the system d-bus service? <apteryx>for example, is jami-client-gnome able to start automatically its daemon over d-bus because of the system's dbus service? <bavier>roptat: we've been on that page for quite a while, though we should ask them to update the logo <rekado_>we still have a GuixSD logo on ci.guix.gnu.org, but not for long. <rekado_>I already changed it in the repository, but we still have an older version installed <rekado_>the build of “guix” on armhf-linux failed again. <rekado_>looks like it was killed because compilation used up too much memory. 