<axd-v>hey, is there a GNU Ring client packaged? I'm trying to find it, but it's not in the repo. <axd-v>or at least not under a name I can pinpoint. <pkill9>is it possible to have packages compiled for different targets side-by-sdie in the same profile? <vagrantcish>ok, so i'm dropped to "scheme@(guile-user)>" from the initrd ... i've never used scheme as a shell before ... <vagrantcish>any quick guide for the rank beginning in how to do things like read files and so on... presuming /proc is mounted <axd-v>btw found something called next-browser today which is written in common lisp and tries to be the emacs of browser. I think people should check it out. http://next-browser.com/ <ngz>odd. "guix pull" raises an error : ./guix/build/compile.scm:132:21: ./guix/build/compile.scm:132:21: In procedure variable-set!: Not a variable: (#<syntax new-sym?> #<syntax y> #<syntax sk2> #<syntax fk2>) <axd-v>vagrantcish: it seems to be an official gnu package, so might as well be on the gnu os ringht. Can't keep using irc forever heh. From what I have seen it has improved considerably. Just in the last month a new notification system was added and peer-to-peer file sharing implemented. <ngz>A second "guix pull" goes smoother apparently <ngz>axd-v: I used it a while ago on my old phone. It would be nice to have it packaged in Guix. <vagrantcish>apparently, i need to play whack-a-mole to figure out what modules to add to the initrd ... <vagrantcish> (initrd-modules (cons "ahci_imx" %base-initrd-modules)) <lfam>vagrantcish: Something like (initrd-modules (cons* "ahci_imx" "foo" %base-initrd-modules)) <lfam>The asterisk lets you add more than one item to the list <vagrantcish>ACTION really ought to do some basic reading on scheme/guile, probably <vagrantc>this was a very involved way to test a little patch series :) ***fkz is now known as Guest11239
<zybell>rekado_:licesense:It is the djb licence.you ditribute src unmod + patches, user builds. ***krkini is now known as kini
<efraim>marusich: might want to take a second look at the files included in your last commit :) <marusich>Are you referring to guix/packages.go.134WZR ? <marusich>I've fixed that by removing the offending file in 27ba9760e04019cc3ed3457199194088f4b45486 <marusich>Sorry about that; I'm not sure how that extraneous empty file made it into the commit. I checked my changes about 5 times before pushing... If you have any suggestions for how to avoid that sort of gaffe, I'd be most appreciative. I'll take heart in the fact that I'm not the only one who has accidentally included changes they did not mean to commit. ;) <divansantana_>Hi all. Guixsd laptop bombed out. Clueless as to why. Slim when trying to login says failed to exec login command <divansantana_>Yesbasically it does exec dbus-launch --exit-with-session I3 <marusich>If you temporarily move your ~/.xsession to ~/.xsession.bak, can you successfully log in? <marusich>That would tell you whether or not the custom ~/.xsession is the cause. <marusich>Alright. Did you change that file recently? <marusich>Glad I could help. :-) For what it's worth, I also use a custom ~/.xsession, but I do something more like "ssh-agent "$@"' <marusich>Sorry, i didn't mean to hit enter so fast <marusich>Glad I could help. :-) For what it's worth, I also use a custom ~/.xsession, but I do something more like 'ssh-agent "$@"' in order to launch whatever session was requested, but in an environment where all the relevant SSH agent environment variables are set (by ssh-agent). I'm not sure what you want to do with your custom ~/.xsession, but now you know that it's interfering somehow. <marusich>Is there a reason why you are not execing the session provided via the arguments to ~/.xsession? <marusich>Guix passes the "session" (i.e., the program and arguments it would have invoked normally, if you had not defined a custom ~/.xsession) as arguments to the ~/.xsession file when it exists. <marusich>If you want to see what those arguments are, you can do something like 'for i in "$@"; do echo _${i}_; done > /tmp/out; exec "$@"' in your ~/.xsession file. The arguments will be stored in /tmp/out. I think the ~/.xsession file needs to be executable, by the way. <divansantana_>marusich: thanks again. Was a life saver. I'm very new to guixsd and have a new job too. Lol. Have to push the boundaries sometimes else I'll never learn guix. <divansantana_>I linked in a dotfile config from arch which broke it. I'll save my dotfiles now. :) <divansantana_>marusich: cool. I'll look into that. Ideally I want to do away with slim and just use something like xinit. Though I havent seen an example config for that. <marusich>I'm glad you were able to fix it! You could do that. I'm not sure how well documented it is, but the basic gist of it is that any desktop session with a .desktop entry will be avaliable via the slim login scren. <marusich>So, if you want to launch some other desktop environment, you "just" need to arrange for .desktop file to appear in the same place where the GNOME and xfce .desktop files are showing up. <marusich>For details, you probably need to look at places like gnome-desktop-service and xfce-desktop-service, and examine how they are adding their .desktop files to the "right" place. <marusich>If you do "grep -r define.*gnome-desktop-service ~/.config/guix/latest" you can see where the gnome-desktop-service-type and the gnome-desktop-service are defined, and then you can follow that to see how it's used. <marusich>The manual also may discuss some if this. If you search for "desktop-service" you'll probably find something. <marusich>Hm. Apparently the mechanism comes from the slim-service-type. If you look up "slim-service-type" you'll find a reference in section (guix) X Window of the manual which explains it. <marusich>Looks like gnome-service-type and xfce-service-type probably arrange for their .desktop file to show up in /run/current-system/profile/share/xsessions by extending the profile-service-type with a package that includes, in the package's output, a file such as share/xsessions/gnome.desktop. <marusich>So if you wanted to launch another desktop environment, your plan of attack would probably be to (1) define a package that builds the necessary .desktop file in its output at a path like $output/share/xsessions/gnome.desktop, and (2) either create a service like gnome-desktop-service-type or xfce-desktop-service-type that installs your new session in the right place, or install your package directly into your system's profile by directly adding <marusich>it to the list of packages in your operating system declaration. <civodul>bavier: did you see the changes to fftw that Mark made? <rekado>civodul: I saw the email discussion between bavier and Mark on guix-devel. ***abbe_ is now known as abbe
<soundtoxin>if I have pulseaudio installed, but not running, what should I do to check for issues? I think it was working a few weeks ago. I've made various changes to my config to set up ssh and mpd. I don't know exactly when it stopped working. Most applications just silently fell back to alsa, but I needed to change my sound output to a TV instead of my internal speakers recently and noticed pavucontrol and <rekado>soundtoxin: applications that are “aware” of pulseaudio should be able to start it automatically <soundtoxin>Okay, if I open htop and search for 'pulse' I do see something running alrady. <rekado>I have never run pulseaudio from the shell. It is started automatically as needed. <soundtoxin>it stopped working recently and I'm just trying to troubleshoot <soundtoxin>so I killed pulseaudio from htop and then opening pavucontrol and all is well. <soundtoxin>but if this was persisting across reboot, it might happen again. what should I look for? <rekado>you haven’t told us what isn’t working. <rekado>you say “it stopped working” — what is “it” and what are the symptoms? <soundtoxin>firefox gave an error saying I may need pulseaudio to get sound in my browser, pavucontrol displayed an error instead of the proper thing, pulsemixer said its connection to the daemon was refused <soundtoxin>I had reason to believe pulseaudio wasn't even running, but then I checked and it WAS running, to my surprise <soundtoxin>so now after killing it and opening pavucontrol (which launches pulseaudio as you say if it wasn't running) <soundtoxin>but I wonder what the issue was, any why it persisted across reboots. I now wonder if it's launching improperly for some reason, and how to check this <soundtoxin>apologies if my attitude seems poor, I just woke up and it felt a bit like you were toying with me, but I probably just wasn't clear <rekado>with sound problems it’s always good to provide more context because there are so many moving parts and layers. <rekado>the behaviour you describe sounds like the first pulseaudio process got stuck; it would be useful to see why. <rekado>unfortunately, I don’t think it keeps meaningful logs. <wigust>soundtoxin: What ‘sudo lsof /dev/snd/*’ will show? <rekado>wigust: do you suspect that some plain ALSA process occupied the sound card and made pulseaudio wait? <rekado>if that was the case killing pulseaudio alone wouldn’t have helped. <rekado>soundtoxin: it may be interesting to see the output after rebooting, when pulseaudio doesn’t seem to work. <soundtoxin>that's a good point, I'll give that a go in a sec ***Steap_ is now known as Steap
<wigust>I'll test and push it in 3 days. <rekado>wigust: oh, that’s good. I missed that. <rekado>soundtoxin: this looks okay to me. <soundtoxin>anything else I should check while pulse isn't working? <pkill9>is there a way to run commands after waking up from suspend? <roptat>I created a recipe for a python package, and after installing it, I tried to run it and got "pkg_resources.DistributionNotFound: The 'dateutil' distribution was not found" <roptat>I've put python-dateutil in the propagated-inputs of that package though <pkill9>roptat: you may need to put it in 'inputs' instead of 'propagated-inputs' <pkill9>is your package using python 2 or python 3? <wigust>roptat: Could you share a recipe? <wigust>roptat: There are problems with a build system (setup.py) in upstream. I think it's better to ask upstream for a fix. <roptat>and I don't really know how to make a python package <roptat>I don't really know how to test except by trying to install it with guix <roptat>I have a guix profile from which I can run the software, but I'd like to install it properly <roptat>anyway thanks for trying. I need to go. I'll be back in one or two hours <pkill9>is gksudo in any of the packages? <pkill9>no worries, thought of a workaroudn anyways, i just set the shortcut to open in terminal and i can enter the password <mbakke>Huh, librsvg requires cairo 1.15; but IIUC cairo uses the same even/odd stable/development cycle as GNOME. <efraim>Doesn't newer librsvg also need rust? <mbakke>Heh, not the error I expected from building latest librsvg: "error: the listed checksum of `/tmp/guix-build-librsvg-2.42.4.drv-0/librsvg-2.42.4/vendor/libc/ci/dox.sh` has changed: [...]" <mbakke>Oh no. librsvg vendors 59 Rust libraries. <catonano>mbakke: on Mastodon I follow Federico Mena Quintero and another Gnome developer. They are working on porting to Rust frantically. They write about this every day and they have been doing so for several months now <mbakke>Aaaaahhh the checksum mismatches is because of shebang patching. Excellent.. <mbakke>davexunit: What are the downsides of Rust? My impression from reading the news is that Rust will solve all computing problems. <catonano>in fact they seem to be enthusiastic about the Rust progreesses over c/c++. I don't understand all of that, though <jackhill>ACTION is also interesting in hearing/reading somewhere else about downsides of Rush <davexunit>rust is an island that doesn't fit in well with distros <davexunit>building rust programs without using their own special package manager is difficult <jackhill>ah, so Rust-the-environemnt not Rust-the-language? <davexunit>the conflation of a programming language and a package manager is a fatal flaw, to me. <rekado>davexunit: is this an insurmountable problem? <mbakke>Hmmm `./.libs/librsvg-2.so: undefined reference to `cairo_tag_end'`. Getting closer. <rekado>mbakke: are you using the expected version of Cairo and linking with it? <mbakke>Nowadays you'd be hard pressed to find a language that does not come with a package manager though. <mbakke>From my very superficial research Cargo does not seem worse than Python or Haskell in this regard. <mbakke>Perhaps it's linking to a propagated Cairo 1.14 or something. <mbakke>Right. There are two Cairos now in librsvg. <mbakke>How can I delete a propagated input? <davexunit>rekado: the rust devs don't seem to care, so I think it's a people problem. <davexunit>rust, like go, also places an emphasis on static linking <rekado>I consider *that* to be a worse problem than offering a custom package manager. <davexunit>so while they may support dynamic linking, that's not what most people are doing and therefore it isn't the happy path <davexunit>there's allegedly workarounds for the package manager issue for distros <rekado>mbakke: where does the other cairo come from? <jackhill>As I understand it, Haskell likes static linking too, but I think there is a technical reason (cross module inlining). That's why the .hi files are so important. <catonano>I myself have managed to build my Tryton module in a Guix environment rather than in an env made with Pipenv or Virtualenv or Venv <mbakke>Ooh, 2/171 test failures. So close. <mbakke>Actually it's just one test that fails. But it really produces a corrupt image. <rekado>mbakke: if Pango propagates that variant of Cairo it should be modified to use the latest Cairo as well. There’s no good way to have two variants of a library in a dynamically linked environment. <mbakke>rekado: Yes, the current situation is far from ideal. I had to use a custom Pango input using the development Cairo; and librsvg propagates Cairo. So all librsvg dependents may end up with two versions of Cairo in their closure :/ <mbakke>Anyway I'll bounce the current effort off guix-devel; this will hit Guix in 'staging' at best and the next 'core-updates' at worst. <mbakke>Building the latest librsvg was surprisingly easy (apart from the Cairo dependency); the main issue now is that gnome.scm cannot import (gnu packages rust)! <rekado>is it not feasible to update all users of Cairo to use that new variant of Cairo instead? <civodul>hmm the overdrive turned itself off at some point, and now its front LED blinks when i try to boot it <mbakke>rekado: That would have to be in "core-updates", but I really want this in the next "staging". Also the Cairo 1.15 branch is not really "stable" (although Arch uses it). <mbakke>Perhaps Guix should error out when using (add-after 'foo 'bar) when 'foo does not exist, instead of silently "swallowing" the phase. <rekado>mbakke: I don’t think it is safe to have more than one variant of a library in a package closure. <rekado>we only register the directories in the RUNPATH, but the libraries are still looked up by name, IIUC. <efraim>civodul: nope, but mine does sometimes turn itself off, haven't double checked that the power supply provides at least the same amperage <civodul>rekado: i don't know why it turned it off, but i can't check since it refuses to boot now <civodul>well i'd need to investigate further but i'm trying to focus on other things now <rekado>civodul: I asked because it might still be too hot to boot. (If it turned off recently.) <civodul>it probably turned off a while back already <civodul>but berlin just went on with the 2nd overdrive (phheeww) <vagrantcish>i can't seem to successfully build guix-build-guix-0.14.0-11.ab85cf7.drv-0 on armhf <efraim>Oh, you were wondering about the armhf builders before, they're also novenas <davidl>after putting all system fonts in a user profile, i get the following error when starting a terminal with the user profile: "urxvt: unable to load base fontset, please specify a valid one using -fn, aborting." <davidl>I have run fc-cache -f to load the fonts <davidl>Im just really wondering why profiles can't have their own fonts reliable loaded by applications. <efraim>I think the fc-cache command is documented in the manual <davidl>the fonts page in the manual recommends fc-cache -f <vagrantcish>ACTION is working on getting the u-boot configuration for novena submitted, and is stuck getting a working guixsd on the novena <efraim>I think it's because the font cache lives outside the store or the .guix-profile dir <davidl>efraim: so maybe I should try a reboot? <efraim>My plan for the pine64 was to try to extend the u-boot definition for it to also build the boot scripts since it seems related enough <efraim>I don't think rebooting should matter <pkill9>efraim: i don't think you need to reboot <davidl>the weird thing is that if I remove all fonts, and then gradually install in user profile, I get better output, so they are partially loaded. <vagrantcish>efraim: the extlinux menu generation should be sufficient for pine64 <vagrantcish>and then you at least get a menu, rather than just a boot script <efraim>vagrantcish: I meant a boot.scr or something similar <davidl>pkill9: =) there was 1 person in the help-guix also, explaining a similar problem. <vagrantcish>efraim: i've been slowly trying to transition debian away from the boots.scr stuff ... it's kind of inflexible. especially in the context of guix where you'd want to be able to roll-back to an alternate system configuration <pkill9>i had a similar issue with fonts as well a while back, i think i also used fc-cache and it worked that time <vagrantcish>efraim: i find the boot menu generated by using extlinux-style configurations to generally work better <pkill9>unfortunately fish is glitching up for me so i can't find out if i used `fc-cache -f` <vagrantcish>efraim: is there something specific you had in mind for a boot script? <vagrantcish>(and with the added bonus of already apparently supported in guix) <efraim>It might also be good if I actually attached my debug cable to the board <davidl>pkill9: hmm. Do applications have their own "font-cache" or something? <vagrantcish>efraim: if you need to edit the device-tree, then you'd need a boot script <davidl>like they cache the link to the font, and then it can only load that font-path until cache is emptied through reboot for example. <vagrantcish>efraim: but i use extlinux-style menu's for booting pine64 on Debian, and it allows more easily to select a different kernel and such <pkill9>i do notice a lot of software generating it's own cache when it displays warnings of conflicts <vagrantcish>efraim: gnu/system/install.scm gnu/bootloader/u-boot.scm seem to be required in addition to gnu/packages/bootloaders.scm when adding a new board <efraim>My last attempt I flashed uboot separately and then booted with grub <vagrantcish>yeah, i've been experimenting with u-boot's EFI support to load grub-efi lately ... <vagrantcish>though it tends to get into issues if there's a mismatch between u-boot's device-tree and the kernel's device-tree <vagrantcish>you can configure grub to load a device-tree, too, though <ngz>Hello. I'm trying to use `minify-build-system' on a simple source where there is a single ".js" file located in "src/" sub-dir. However, it generates an empty minified file in store. How can I debug this? <efraim>I don't remember seeing that yet <rekado>ngz: the build system takes an argument javascript-files <rekado>ngz: but the defaults should be fine. It uses (find-files "src" "\\\\.js$") by default. <ngz>hmm I hadn't noticed I was offline... <roptat>I was wondering, since I'll have to buy a new laptop, could someone recommend one that works well with guixsd? <ngz>So, if someone has any clue about the `minify-build-system', I'm back :) <pkill9>roptat: the old thinkpads are considered gold standard for linux support <pkill9>not sure the newest thinkpad that is included in that category however <pkill9>I know it's atleast thinkpad x220 <efraim>I've heard the t series is also pretty good <soundtoxin>I have a swapfile but it doesn't enable on boot. Anyone know how to fix that? <soundtoxin>I can just run swapon and it shows up in htop, but it's not happening automatically <rekado>ngz: did you see my comments about the minify-build-system? <ngz>rekado: No sorry, I was disconnected. <rekado><rekado> ngz: the build system takes an argument javascript-files [21:59] <rekado><rekado> ngz: but the defaults should be fine. It uses (find-files "src" <rekado> "\\\\.js$") by default. [22:00] <ngz>Yes, I tried both with (arguments `(#:javascript-files '("src/FileSaver.js"))) and without. <rekado>roptat: if you can find someone to pay the laptop for you the Librem 13 works fine with GuixSD. <ngz>To no avail: the minified file is 0bytes <efraim>soundtoxin: you can specify the swapfile as a swap device <rekado>ngz: all that build system does is to run uglify on the js files and redirect the output to a new file. <rekado>ngz: you could try to do this manually to see if this actually works. <efraim>Sbcl for aarch64 is still on my todo list <ngz>rekado: Sure, let me try it. <ngz>"Unexpected token 'VAR'. (line 16, character 7)" <ngz>So, basically, it fails. <ngz>Which would explain why there is no output. <ngz>Incriminated line is: "export var saveAs = saveAs || (function(view) {" <ngz>I can uglify it if I remove the "export" keyword. Also, this keyword is not present in the minified version of the file another project is using. <ngz>Time for a fix-phase... <rekado>roptat: yeah. I didn’t personally pay for mine. <dustyweb>is there a way to manually run the certbot command set up by the certbot service? <efraim>Something about a cryptographic module <rekado>“trusted platform module”, I think. <rekado>(it wasn’t available at that time) 