<quiliro>kmicu: no...it is the file that is with wrong parenthesis...but i do not know where <kmicu>quiliro: yes, forget a paren after (keyboard-layout keyboard-layout)) <kmicu>(Commented out ‘;; slim-service-type)’ and forget to add it back.) <kmicu>In (set-xorg-configuration… ) ***evhan` is now known as evhan
<quiliro>works now...will reboot when it finishes <quiliro>new xonfig did not work...gui not accessible <quiliro>kmicu: the new file you sent has problems <emsyr>kmicu: I just reported the bug about connman. Hope I did it correctly! <kmicu>quiliro: heh, that could be a broken GDM so it’s time to decide if we should fix GDM or fix ES layout on SLIM. <kmicu>emsyr: Thank you! The first mail can take some time (a day) to show up on a mailing list. <quiliro>i have to go or else i will miss the bus home....kmicu: thank you for your help <kmicu>quiliro: sure, we will try to fix it later. ( ^_^)／ <ngz>Hello. Are we supposed to unbundle fonts when packaging software? There doesn't seem to be much font un-bundling going on in the code base. But it may be because there is not much font bundling… <au>Hello everyone. I'm using Guix as my package manager on Trisquel, and was wondering if anyone ran into any font problems with IceCat. Literally every character is a small box was 4 numbers in it. <polezaivsani>au: you'd need fontconfig, cairo and pango - at least that's how i got rid of those boxes! <au>polezaivsani: Ah, thank you! I'll give that a shot. <bandali>i also remember having to set one or more environment vars <bandali>i think there was a bug report and/or thread about this a few months ago on one of the guix mailing lists <au>bandali: Ah, at least it's not just me. I just installed fontconfig, cairo, and pango and it wouldn't work for me. :( <bandali>let me look through my shell history and see if i can find anything <bandali>au, try setting XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" <bandali>i wouldn’t recommend exporting that for your entire session, but only for when you’re launching icecat <au>bandali: Ah, I'll give that a shot. Thanks again! <dGtlc3>I had same problem, kmicu suggestion fixed it. Install font-gnu-unifont, font-dejavu, font-lato and execute ‘fc-cache -r’ <au>bandali: Unfortunately that didn't work, but I went with dGtlc3's suggestion and that worked for me. :) <bandali>interesting! happy to hear that it works now :) <au>Yep, thank you all very much! <arkhan>but I can not find the executable <bandali>pinentry-rofi.scm *is* the executable from what it seems <Marlin[m]>i'm getting this after having set up the git thing <atw>Marlin[m]: I don't see any issues with your package definition. What command is that output from? <atw>Hmm, I think I've used git-fetch before and that output is not familiar to me <atw>Is that all the output? Does the package install, or is there some error? <atw>I'm trying to figure out how to build fennel because I am not sure if gnu-build-system is the right thing to use. <Marlin[m]>tbh, we should probably get a luarocks thing <atw>I don't see a configure script in the repo, and gnu-build-system is pretty much ./configure && make && make install, so I think something other than gnu-build-system is needed <Marlin[m]>also, if we got luarocks, fennel can be installed like that <atw>also seems like the Makefile does not have an install target. I am not sure but the way to package this might be to make the file that's just called "fennel" be symlinked to from bin. I'm trying to find an example of a package like that, let me see... <atw>can't find a good example, but my methodology is to grep the guix tree for a package that already does a similar thing to what I'm trying to do. re lutris: is it running its tests in its build phase? (I do not know about python packaging) <erudition>nckx: Hey I finally managed to install pithos <erudition>Turns out flatpak isn't completely broken, the segmentation fault only occurs when it's not run as root <kmicu>Glad to here that and good to know that Flatpak in Guix can work. <rekado_>erudition: do you happen to know what causes the segfault when running as non-root? <rekado_>a segfault seems like an upstream bug to me. <bricewge>Is it normal in guix that some packages (here sendmail) put binaries in /usr/bin and /usr/sbin? <bricewge>Similary /gnu/store/...-sendmail-8.15.2/usr/bin/mailq point to /usr/sbin/sendmail, is it normal or a bug? <rekado_>the prefix should neither be /usr nor /gnu/store/…/usr <bricewge>Thanks I'll try to make it my first contribution then. <efraim>find /gnu/store/ -mindepth 2 -maxdepth 2 -type d -name usr <janneke> /me just "released" an untangled emacsy-0.3 <rekado_>“untangled” meaning with the documentation and code separated? No more noweb? <janneke>rekado_: yep, moved doc + api docs to texinfo, cleaned-up the code (somewhat) *janneke feels ambivalent about literate programming <mfg>so updating scipy fails with: Theme Error: An error happened in rendering the page index. Reason: TemplateNotFound. WHat should I do? <erudition>rekado_: I don't know what causes it -- in fact there was no errors shown at all. Just one line "Segmentation Fault". However I'm pretty sure that like Guix, flatpak should be able to install packages unprivileged. Perhaps something about being in /gnu/store makes it not know how to do that. <erudition>rekado_: but it should be reproducible by simply installing flatpak and trying to add a repo without sudo. <rekado_>erudition: are you somewhat familiar with gdb? If so would you like to run it in gdb to see where exactly it fails? <thomassgn>Hi, I've had an idea to make guix system check the 'sudoers-file' with 'visudo --check' before inputting a sudoers file (I was burnt by this some time ago). But I'm not sure where to put such a check. <rekado_>erudition: is there a bug report about this segfault? <erudition>I mean, there was a report about it upstream, for a much older version (like 0.9 - guix has 1.2.4) that seems to be ancient history now but back then someone suggested it seems like a permission issue, which is what gave me the idea to run it with sudo <erudition>As far as a guix bug report, I'm not sure. But it had been suggested here that flatpak was simply broken <rekado_>a permission error should not ever result in a segfault. <erudition>And I still want to install pithos as a user, because I'm not sure how to access the .desktop file now that it's been created by root <erudition>But when I opened the file I found the command to run it, so that works at least <mfg>is magit always that slow? i mean yes the guix repo is relatively large but i literally have to wait minutes ... ***scroll2_ is now known as erno_poliisi
<mfg>hm i must be doing something wrong then ... <janneke>mfg: you may want to `git checkout po' *janneke 's magit is sometimes preparing a very large po diff <mfg>ah yes that worked, thx janneke <civodul>rekado_: i've just turned off cuirass on berlin due to ENOSPC <civodul>dongcarl: most likely due to lack of disk space on the server <Marlin[m]>hopefully i'll get the packages working today <mfg>How do i specify a minimum version for a python dependency? something like python-networkx>=2.1? <dongcarl>civodul: I guess `--no-substitutes` is the workaround for now? <civodul>so hopefully it'll be back in a few minutes <civodul>does anyone have experience setting up opensmtpd or similar on Guix? <civodul>i want the simplest setup that allows me to send email *civodul would like to receive email alerts before we hit ENOSPC ***erno_poliisi is now known as Guest31068
<ngz`>Hello. I'm wondering what is the policy in packaging wrt embedded fonts. Should we unbundle them or not? It seems very few packages in the repository unbundle fonts, but it may due to the fact that the problem is rare. WDYT? <brendyyn>ngz`: i think unbundle them. i think its something people just never got around to doing <brendyyn>for example i left a package for a year or two before i properly unbundled the fonts. <brendyyn>if the fonts are required in a specific location then symlinks can be made, although itd be nicer if the program used the standard paths <brendyyn>i think you are very welcome to contribute unbundling patches <ngz`>When you say "using the standard paths", you mean remove bundled fonts altogether, and propagate expected fonts? <brendyyn>is propagation necessary, or just regular inputs? <brendyyn>yeah, i mean like the calibre package asks for fonts in its own directory instead of /share/fonts/truetype/ <ngz`>No idea. So far, I only used symlinks, because I only found this kind of process in the code base. <brendyyn>i guess it depends how the package chooses to find the fonts <ngz`>calibre uses a symlink, IIUC. <brendyyn>yeah i did that, because calibre is a mess so it was easier than fighting it <ngz`>So, there is not example of proper font unbundling so far. <ngz`>"proper" here only means "without using a symlink", of course. <brendyyn>A "proper" unbundling is where you just delete them and the package automatically finds the system one without issue. <ngz`>Besides, this would require to run fc-cache or some such, wouldn't it? <ngz`>Unless we hard code the path to the TTF in the source code. <ngz`>Yes, but that's my work :) <ngz`>In childsplay, I hard-coded the path, so the application still doesn't find the system fonts automatically. <brendyyn>then i guess your expertise exceeds mine. perhaps you can be the one to think through the Right Way <ngz`>Let me think about it for a sec... hmmmm... No I cannot ;) <brendyyn>@_@ ok ok. which other packages need to be fixed? <ngz`>I'm reviewing freeorion game, and I noticed it includes fonts. Since I don't want to bother too much the submitter about it, I'm going to try unbundling them. But I wanted to know if it was worth the hassle. <brendyyn>ngz`: Ludovic removed the maintainer field from packages in guix for the purpose of preventing people from feeling they aren't allowed to touch somebody elses package. <ngz`>Oh, that wasn't the reason stopping me. It was my own laziness! <civodul>ngz`: i think it's a good idea to unbundle it <efraim>Mupdf bundles fonts, I just noticed recently <bricewge>What is the equivalent to Nix's /run/wrappers/bin/? <civodul>bricewge: is it /run/setuid-programs? <mfg>I keep getting: error: failed to run download program '/home/mfg/Documents/guix/nix/scripts/download': Permission denied <mfg>where does it come from? <pkill9>(that file just inherits the nss package and changes the #:system to "i686-linux") <g_bor[m]>I might be missing something, but after installing font-google-roboto on Guix System, it still does not appear in fontconfig. *mfg is offline for a couple of minutes <nckx>g_bor[m]: Did you run fc-cache -r? What does fc-match Roboto say? <g_bor[m]>nckx: I just did that, and it helped. But if I remember correctly, then there should be a profile hook taking care of that. Is that correct? <nckx>g_bor[m]: You might be thinking about fonts.dir. I don't know (like, literally don't know) if running fc-cache as well is possible or desirable. <g_bor[m]>nckx: It was needed in this case to get this right, but installing the three font packages mentioned in the manual worked just fine without the fc-cache. <mfg>In procedure connect*: Connection refused <mfg>so the problem i not guix, isn't it? <Marlin[m]>gonna get back at getting lutris to work in a moment <nckx>mfg: What does Guix say? <mfg>what i accidentally wrote in three single messages above <mfg>it tries other links and gets 404 because they (obviously) don't exist there <mfg>the package definition was made with guix import pypi bel_resources <nckx>mfg: You trimmed that message, though. I doubt that asterisk was there ☺ <mfg>i got the refused connection when i ran guix build, guix download worked just fine with the same link ... <mfg>it's a bit strange!? <mfg>but hey at least i'm a bit further, thanks <rubic88>Hi nckx. Thanks for educating me about guix system reconfiguration a couple days ago. I want to revisit one comment to ensure my understanding is correct: "Guix doesn't ‘fall back’ to /etc/config.scm or whatever." <nckx>rubic88: I meant to that file name. <nckx>It's ‘guix system reconfigure FILE’, not ‘guix system reconfigure [FILE]’ with a default, was all I meant by that. <rubic88>So I've been running "sudo guix system reconfigure ~/etc/guix/config.scm". But in a moment of inattention one day I run "guix system reconfigure" and neglect to include FILE, it won't reconfigure against /etc/config.scm? <nckx>(Which is good, because I hate the ‘word’ ‘config’ and never use that name 😛) <rubic88>nckx: I'm am one unit smarter than yesterday. *nckx wishes all questions here were so easy to unambiguously answer. <mfg>rubic88: you might want to use sudo -E instead of sudo, because otherwise you might get warnings that root did not run guix pull <nckx>mfg: Really? I thought Guix System set !env_reset by default since forever now. <nckx>rubic88: If you don't mind guinea pigging (it's not harmful in any case), use plain sudo and check whether you get that message. <nckx>But I don't use Guix's sudoers file. <rubic88>No message regarding guix pull. But I didn't make any edits to my config.scm file. <mfg>nckx: i had the problem when i started using guix which was 1 or 2 months ago <nckx>rubic88: Nah, that wouldn't affect it. Thanks for testing! <nckx>Hmm. That shouldn't™ happen. <mfg>i can look if it's gone by now, w8 <rubic88>nckx: My pleasure. If I'm making a rapid series of tweaks to config.scm and testing them, it's not necessary to pull after each edit. Or phrased differently, how often should "sudo guix pull" be invoked? <mfg>sudo guix system reconfigure /etc/config.scm <mfg>guix system: warning: /root/.config/guix/current not found: 'guix pull' was never run <mfg>guix system: warning: Consider running 'guix pull' before 'reconfigure'. <mfg>guix system: warning: Failing to do that may downgrade your system! <nckx>rubic88: It's not needed. Pull only pulls in new (versions of) packages, the .scm on the command line is always used directly, you don't have to ‘apply’ or ‘compile’ it in any way. <nckx>mfg: Hm. OK. I'm going to start up a vanilla Guix System VM before I say anymore about that, but first din-dins. <joshuaBPMan>Hello, how would I delete package generations 10-50? "guix package -d '[1-5][0-9]'" didn't seem to work.... <mfg>should be: guix package -d 10..50 *nckx *munching* f'like git'f format. <mfg>there are inputs, native-inputs and propagated-inputs. inputs are build-time deps, propagated-inputs runtime-deps and native-inputs should be used if the dependiency contains architecture specific code? <mfg>because i'm trying to package a python library which has a runtime dependency on python-requests-file and if i add it to prop..-inputs i have a python-requests version conflict, because python-plotly also propagates that but in another version ... <nckx>mfg: Not really. All *inputs are provided at build time. native-inputs vs inputs is about cross-compilation: native-inputs run (only) on the host, inputs are compiled for the target machine. But in practice, you'll see that build/test-only dependencies will be native-inputs and the rest inputs. <mfg>Hm, then i'm not sure where i should add the inputs <mfg>they don't ge installed when i guix package -i python-pybel <mfg>i get MOduleNotFoundErrors <nckx>Native-inputs shouldn't be referenced in the final package. Both inputs & propagated-inputs may be, but propagated-inputs are forced into a profile even when unfererenced & are basically a hack you should only use if your package breaks without them. When in doubt, don't. <nckx>In the case of Python, unfortunately, propagated-inputs are extremely commen. <ngz`>Another question about packaging: when unbundling /free/ libraries or font, should we delete file in a snippet' or in a phase (possibly the same fixing file names in source code)? <nckx>mfg: So yes, in this case, use propagated-, but don't make it a habit elsewhere ;-) <nckx>Not sure how to solve that conflict. <nckx>That's exactly one of the drawbacks of propagating junk. <mfg>nckx: thx for the explanation. <nckx>mfg: Does the package provide a library or just one or more /bin commands? <nckx>The latter can be wrapped using wrap-program to set PYTHONPATH (plenty of examples in gnu/packages) so propagation can be avoided entirely. <mfg>nckx: it's a library afaik <nckx>Someone with more Python ‘ecosystem’ knowledge than I have (like rekado) is needed. *nckx 's only a user, not a dealer. <mfg>the reason for the conflict might be because i can't guix package -u <nckx>g_bor[m]: You're making me want to switch. <mfg>because scipy fails and i don't know how to ignore that and update the rest <nckx>mfg: So plotly propagates the same version your package would but the problem is your mix-&-match profile? <nckx>Yeah, the only solution to that AFAIK is a separate environment for both. <nckx>This is why I pounce upon unnecessary propagation when I see it ☺ <rubic88>On my foreign distros I'm using volumeicon in my systray (i3 wm), but it's not a guix package yet. What are folks using as an alternative, if any? <mfg>nckx: plotly propagates python-requests 2.21.0 and the library i'm trying to add propagates python-requests-file, which in turn propagates python-requests 2.22.0 <nckx>rubic88: passive i3bar ‘volume’ module and ‘bindsym XF86AudioRaiseVolume’ in i3. <nckx>To call ‘pactl set-sink-volume 0 +5%’ and play a reference sound with ogg123 because I wanna be all fancy about it. <nckx>It's not graphical but it's very i3… <rubic88>nckx: Cool. I've got the hardware buttons working on my laptop, but sometimes like having it handled by the gui. <nckx>mfg: I'm really not enough of a Pythonist to know how that would be fixed without separate envs. Sorry. <nckx>rubic88: Well, it's handled in that the new volume is immediately displayed automatically by i3bar, but I guess you have a different definition. There's nothing to click on, no. <mfg>nckx: then i will use a separate env until someone can show me a better alternative, thx :) <rekado_>civodul: I’ll clean out the qemu images then <rubic88>nckx: Yes, it's displayed on my i3bar and handled by hardware buttons. <nckx>But you want the mousey-slidey. <rekado_>civodul: these disk images fill up the available space very quickly. It would be nice if we could “group” them all and delete them regularly before they pose a problem. <nckx>I don't know of a Guix package that provides it, but then I learnt that i3bar supports a systray 7 minutes ago… I might not be its target audience. <rubic88>nm-applet appears to work well there *nckx seriously wonders if there's any way to make i3 work with a touchscreen, if we're being sacrilegious anyway. <nckx>It would make reading my pdfs in tablet mode slightly nicer. <nckx>But I'm hijacking ur thread. Sorz. <rekado_>nckx: what makes you think I know about Python? I barely even qualify as a Python user! <nckx>rekado_: Scusi. You talk about it a lot. Mainly about fixing stuff just like this. <nckx>Perhaps you're just a masochist. *mfg just notices that he tried to package the wrong library because it has the same name <pkill9>nckx: what tablet/laptop do you use? (since you said "tablet mode") <nckx>mfg: …and so, the problem solved itself? <nckx>pkill9: X230 ‘tablet’ by 2012-with-an-i7 standards ☺ Sorry to disappoint. I love it though. <mfg>nckx: seems like that. we will see :'( <nckx>pkill9: Very much not a hip cool surfacey thing. But beautiful nonetheless. <kmicu>rekado_ is no python user but is getting rid of PYTHONPATH anyway? That’s the spirit! 😺 <nckx>It's exactly what one pictures for ‘Thinkpad tablet’. <pkill9>i have an x220 tablet, then i got an x240 laptop <rekado_>I know some Python users and I my compassion motivates me to ease their plight. <nckx>rekado_: I seriously thought you did *something* with Python, as much as you complained about it. I stand corrected. <rubic88>pkill9: Would like to have a laptop with no build-in keyboard, just a slim hunk of hardware that I could plug in my favorite keyboard. Does your X220 qualify? <rekado_>nckx: I’m “responsible” for PiGx, which uses Snakemake (for no particular reason), which is written in Python. <nckx>rubic88: Think full laptop, but you can close it so the screen's on the outside. That's it. <nckx>rekado_: You touched it so you own it. <pkill9>rubic88: nah, the motherboard is part of the keyboard like a normal laptop, and the screen swivel round such that it can cover the keyboard to be in 'laptop mode' <rekado_>I asked my colleagues if we couldn’t …like… clean up the code and before I knew it I felt the heavy weight of a Python project in my lap. <rubic88>I see the pics now. There probably isn't a market for what I'm looking for, I'd guess. *rekado_ writes a manual for the picture language <mfg>okay so what i really need are the python bindings for openbabel (which is also named pybel) ... <rekado_>civodul: could you stop the GC on berlin? <rekado_>civodul: I’d really like to avoid running GC there, because it shouldn’t even be necessary. <mfg>Hm, but how should this be done? the bindings are built with the normal build system. Is this a case where i would need to use multiple outputs? <nckx>mfg: If the size increase even warrants it. If it's only a few K, don't bother. <nckx>(‘guix size’ before & after will tell you, since the Python bindings might pull in dependencies of their own.) <nckx>(I said K, but it depends on the context. What's a few MiB between hundreds…) <kmicu>(Hundreds MiBs‽ That’s Big Data 🕴) <nckx>Damn, ‘guix size nano‘ doesn't make the punch-line cut. But it's close… <mfg>hm, so i tried building with the bindings and it fails because the builtin tests can't import the module. are there some guixy things which i need to add? *nckx .oO ‘guix size emacs’ is even bigger than I expected. <nckx>mfg: Yep! I think setenv PYTHONPATH to include (getcwd) might solve that. Depends on the exact error. <nckx>So (setenv "PYTHONPATH" (string-append (getcwd) ":" (getenv "PYTHONPATH"))). <nckx>Might need to add a subdirectory before ‘:’, depends entirely on the package. <g_bor[m]>I intend to add the optional dependencies that are still missing tomorrow, and then I will remove waybar from the packaging wishlist. <g_bor[m]>I also intend to share my config, manifest and the sway and waybar configs, as all those are needed to get this working :) <mfg>nckx: and if this works for the tests, if the package is installed do i also need to edit PYTHONPATH? <nckx>mfg: That shouldn't be needed (the module doesn't need to find itself, the tests do) but I can't speak for any specific package. <mfg>hm so if i install that package and write a python script which imports the bindings they get megically found ? <nckx>When you said ‘the builtin tests can't import the module‘, I assume you're talking about the module that was just built? <mfg>i mean the cmake tests which test the binding <nckx>mfg: I didn't say magically 😛 The environment variables should be in place to point your script to that module. And if you'd package that script, well, you'd wrap it or propagate babel. <nckx>mfg: Yeah, that's not uncommon. <rubic88>How does one write portable [*sh] scripts with the #! line? Portable between guix system and foreign distros, I mean. <rekado_>rubic88: you can assume that /bin/sh exists. <rubic88>rekado_: Since we're on the subject of Python ;-) what about portable python scripts? <rekado_>you cannot assume that Python is installed in a global location on a Guix system; even if you could you couldn’t assume that it’s the same version of Python that you’d find on other distros. <rekado_>so for anything other than POSIX shell scripts portability requires configuration. <rekado_>you could, for example, include a Guix builder with your script to ensure that it’s the same on all target systems. <rubic88>Understood. I was thinking of a smaller subset of portablilty -- i.e. my scripts that could be run between guix and non-guix environments. <rekado_>yes, this also isn’t possible, because Guix systems have no “global” programs other than /bin/sh. <rekado_>I suppose you could have a POSIX shell script with a /bin/sh shebang that re-exec’s itself with whatever Python it found using “env”, which should be globally available (just not in a FHS location). <rekado_>this would take only a couple of lines; not quite the same feel as a simple /usr/bin/env shebang, of course. <rubic88>A global 'env' would go a long way to addressing my issues. *nckx suggested adding /usr/bin/env recently (and was probably not the first to do so) but hasn't read the responses yet *backlog shame* <rekado_>“env” is usually available in the global environment, but you can’t use it as a shebang because it’s not guaranteed to be at /usr/bin/env. <rekado_>emacsomancer: have you tried running fc-cache -f? <pkill9>rubic88: i would just put in the configuration a 'special-file' that puts /usr/bin/env in and then use the standard shebang "#!/usr/bin/env python" <nckx>pkill9: Sure, but that's not ‘portable’ ;-) <rekado_>pkill9 sure, this works, but you can’t assume that *other* people’s Guix systems have it. <emacsomancer>icecat can see fonts in ~/.local/share/fonts , but doesn't seem to be able to access fonts installed via guix <pkill9>oh right, portable with other's guix systems <pkill9>i was just thinking between guix and non-guix <rubic88>pkill9: That's what I did when I wanted portablility between Linux and OpenBSD. <rubic88>emacsomancer: Are you running ungoogled-chromium ? <nckx>Your inputs are apparently desired. <emacsomancer>the only solution seems to be to put all fonts I want IceCat to have access to in ~/.local/share/fonts/ <civodul>rekado_: sorry i was away, but my "guix gc -C10G" process completed, and hopefully i didn't remove anything important <rekado_>I’m still running GC on {disk,qemu}-image items. <rekado_>annoyingly, I can’t just collect all of them at once because some of them will invariably be reported as “alive”. <rekado_>so I’m looping over them and collect them in chunks ¯\_(ツ)_/¯ <civodul>did you see the cleanup-cuirass-roots mcron job i committed? <pkill9>why does qemu not save my window settings >.< <rekado_>I read your email, but I haven’t looked at the cron job yet <civodul>ok, i'm hoping that will help, automagically <civodul>but i don't know, the GC might still choose to delete other things <nckx>pkill9: Assuming that's not the job of your WM, maybe something to do with not saving settings? Are other settings persistent? <mfg>nckx: i noticed the python path gets set correctly by cmake so i don't even need to manually mess around ... <nckx>mfg: Oh, cool, but why did you get an error earlier? <rekado_>thanks for taking care of this in my absence <mfg>i don't know the error still persists :D, maybe it's a totally unrelated thing and i just don't see it :| <civodul>rekado_: np! i found about it by chance, so i'd really like to have those email alerts set up <rekado_>yes, there’s little point in having Zabbix monitor things when it doesn’t alert us in time. <civodul>maybe it can do it, but having a simple Guile snippet that does this is easy <rekado_>civodul: can we just relay to the GNU SMTP relay? <civodul>and i don't feel like leaving my credentials on berlin :-) <mfg>maybe you see something <rekado_>civodul: yes, I meant fencepost. Can’t we get a “functional” account with some other form of authentication (e.g. a certificate file)? <mfg>nckx: ah i might have found it! <kmicu>emacsomancer: is that IceCat from Guix, the package manager or Guix, the operating system? <emacsomancer>kmicu: IceCat from Guix, the package manager on a foreign distro that has trouble with fonts, but ungoogled-chromium from Guix (the standalone package manager) does *not* <kmicu>emacsomancer: yeah, you are not the first one with that issue. Could you describe those issues with fonts? (It could be that ugoogled-chromium works cuz is not correct ;). <emacsomancer>kmicu: IceCat from Guix on a foreign distro does not seem to have access to fonts from either the distro or fonts installed via the Guix package manager itself, but only local fonts (i.e. in ~/.local/share/fonts) <emacsomancer>this seems to be the case whether or not I use the foreign distro's fontconfig tools or Guix's <mfg>hm, sadly i didn't :( ... <kmicu>emacsomancer: Do you refresh fonts cache with ‘fc-cache -r’ and restart IceCat? <emacsomancer>kmicu: yes, I've tried doing so, both using the foreign distro's `fc-cache` and Guix's `fc-cache`, and also with `fc-cache -fr` (just in case) <emacsomancer>kmicu: as soon as I put the relevant fonts in ~/.local/share/fonts (and refresh via fc-cache, either the f.d.'s or Guix's), IceCat has access to them <nckx>mfg: Sorry, not available at the moment. I'll take a look later. <kmicu>emacsomancer: Could you remove any pango, fontconfig, etc from Guix, install font-gnu-unifont, font-dejavu, font-lato and, execute ‘fc-cache -r’, restart IceCat and check wheter those fonts are visible in IceCat → Preferences → Fonts&Colors? <kmicu>(You could also try starting IceCat with e.g. XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" but w/o a strace log that’s only guessing.) <mfg>nckx: yeah no problem <kmicu>(As a workaround we could also link fonts from ~/.guix-profile into ~/.local/share/fonts/… ;) <mfg>nckx: so deactivating the tests works and i can try the bindings out, but they are simply to outdated, they use the dl module which is deprecated since 2.6 :|. So i will need to find another way ... <emacsomancer>kmicu: running IceCat normally, those fonts are not visible in IceCat's Fonts&Colours Preferences <emacsomancer>if I run `XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" icecat` then they are <emacsomancer>(though even running the second way doesn't make the foreign distro's system fonts accessible to IceCat) <kmicu>We should add that system fonts location to XDG_DATA_DIRS path too. *mfg is going to sleep zzZ. bye *kmicu thinks that a correclty packaged Guix, the package manager, on a non-Guix System distro should set those envars. So no user intervention would be required. <emacsomancer>kmicu: how does one add the system fonts location to the XDG_DATA_DIRS path? <emacsomancer> `XDG_DATA_DIRS="/usr/share/fonts/:$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" icecat` didn't seem to work <kmicu>emacsomancer: guessing but maybe only /usr/share/ cuz /usr/share/fonts/ could give /usr/share/fonts/fonts/. <kmicu>(In the same way as we use ‘$HOME/.guix-profile/share’ and not ‘$HOME/.guix-profile/share/fonts’) <thomassgn>is there some way to see previous time spent building a package? E.g. I'd like to know long the linux-libre-5.1.6 build spent <emacsomancer>kmicu: `XDG_DATA_DIRS="/usr/share:$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" icecat` didn't work either, unfortunately <kmicu>emacsomancer: I’m out of guesses. You could send an strace log if you want to investigate further.