<nckx>Yeah, diffoscope can do *a lot* of work sometimes. More than most people need. <nckx>Glad it was just that though! *nckx will also quit exit, and probably sleep for 2 full days. Good night all. š“š¤ <pineapples>A keyboard-driven Internet browser written in Lisp :') <hwpplayer1>Can we have Emacs included for the next build or commit <stuebinm>pinapples: we do! i use it quite a lot ā be prepared for it to occasionally crash on you (and afaik anything with webrtc/video conferences doesn't work rn), but apart from that i really like it <drakonis>it would be weird to not have emacs, as it is a staple of any distribution <pineapples>stuebinm: Ill install it as soon as I'm at my PC. Thnks for sharing your experience with me! Where has this browser been all this time when I needed a replacement for Chromium? <stuebinm>pineapples: I think it's pretty new ā I only found it a couple months ago (there was a talk at fosdem iirc), and even in the time I've used it it's gotten noticably better, so now i just use that and keep a backup icecat install around for video calls and stuff (at least on my laptop, which runs guix ā i also have a NixOS machine, where I never really got it working beyond showing a blank window ***lukedashjr is now known as luke-jr
*GNUtoo finally got a system with an LUKS + LVM rootfs booting under qemu <GNUtoo>I'll try on real hardware (with a free version of Coreboot and GRUB) soon (I need to reboot for that) <dsmith>Heya all. Currently, the bot can be on only one server. <dsmith>Leve it here, or back to freenode? <roptat>dsmith, we prefer to have it here, but what about the other channels that use sneek? <gry>can they run their own copy of the bot? ***parnikkapore is now known as Parnikkapore
***Parnikkapore is now known as parnikkapore
***parnikkapore is now known as Parnikkapore
***Parnikkapore is now known as parnikkapore
***parnikkapore is now known as Parnikkapore
<apteryx>one quick thing: you can alreadystop addin #t at the end of phases; soon core-updates will get merged, which obsoletes this fully. <apteryx>and in the meantime, it doesn't do much harm to drop them already. <raghavgururajan>apteryx: Ah yes. I just kept it for testing purposes. I will be removing them in the final patch. <apteryx>I'll try to look at it more closely tomorrow, it's late :-) ***Parnikkapore is now known as parnikkapore
***parnikkapore is now known as Parnikkapore
<leoprikler>raghavgururajan: I wouldn't merge this before finding out what keeps tests from failing and dropping #:tests? #f <leoprikler>I'm also not sure what ffmpeg and gstreamer are supposed to do there. Perhaps you need to break a bootstrapping cycle? <spikot> /msg NickServ VERIFY REGISTER spikot C18PChb6GcQAfHMc ***Parnikkapore is now known as parnikkapore
***parnikkapore is now known as Parnikkapore
***rekado_ is now known as rekado
***Parnikkapore is now known as parnikkapore
***Mysterio` is now known as MysteriousSilve`
<civodul>taeaad: it's unlikely, in part because Guix is not fully usable there yet <cbaines>checking on substitutes from bayfront this morning, looks like there's no backlog of x86_64-linux or powerpc64le-linux builds now <cbaines>x86_64-linux substitute availability is 96.5% (at least for the revision I'm looking at) <cbaines>powerpc64le-linux substitute availability is 63.8% <civodul>it's building on the OSUOSL machine? <cbaines>no, I have a Talos II machine which I'm using <cbaines>so I've managed to get that far in just a week <cbaines>it shows up in Linux as having 64 cores, so on that metric, it's the machine with the largest number of cores that I've been able to use the Guix Build Coordinator on <cbaines>which has definately revealed some things to work on in terms of effectively loading the machine <civodul>cbaines: yes, i hope it can be merged soon ***roelj` is now known as roelj
<civodul>note there's a workaround in (guix http-client) <civodul>GNUTLS_E_AGAIN should be quire rare in practice <civodul>cbaines: oh, great that you have a Talos II! <civodul>mothacehe: ah, i see; IWBNā¢ to display both, maybe with a symbol or highlighting indicating which one changed <civodul>(a colleague of mine is asking how to reproduce a build failure locally) <mothacehe>yeah that would be nice indeed! hydra has some sort of button "reproduce this build" locally. That could be a nice feature. <mothacehe>that would do "guix pull -C /tmp/evaluation-123-channels && guix build my-build.drv" <civodul>it could be as simple as displaying the command(s) to run <civodul>usually one can run "guix build ....drv" and the .drv itself gets substituted <ekaitz>hey civodul the other day you told me how to compile using guix build with --target <ekaitz>how can I create an environment with a GCC toolchain for riscv target? <ekaitz>i'm checking (cross-gcc "riscv64-linux-gnu" ...) but IIRC i had issues with that <civodul>ekaitz: hey! there's no easy way to use 'guix environment' for cross-compilation, i think <civodul>you could do "guix build guile --target=riscv64-linux-gnu -K", interrupt it, and go to the build directory <ekaitz>but... what's the build process doing further than loading some packages and setting some env-vars? <civodul>well it runs the build phases, but that's about it :-) <civodul>i don't remember if there's a good reason 'guix environment' lacks --target <ekaitz>but (cross-gcc ...) should work right? <ekaitz>yeah that was what I was talking about <ekaitz>make a manifest with cross-gcc, cross-binutils and cross-libc ? <ekaitz>I'll try that again and if I find issues I'll come back to *you* <roelj>I sent a patch to fix LDC to guix-patches yesterday. Normally I can simply wait a week for a response, but I'd like to migrate more packages to the "guix-science" today which needs a working build of sambamba, which needs a working build of LDC. Would anyone be able to review the fix today? It's bug #48541. :) <civodul>roelj: hi! i review this one and you review another one; deal? :-) <roelj>Is there an overview of patches not reviewed yet, ordered by date? Or should I simply reverse the sort order of the guix-patches mailing list? <leoprikler>the mumi interface is nice and all, but sadly it cuts off at a certain point :( <efraim>would gdc work? we do have a gdc-toolchain <rekado>roelj: thereās also a list of āforgottenā issues which you can only find on issues.guix.gnu.org <roelj>efraim: GDC to build sambamba? <roelj>rekado: I'm going through the priority bugs now. <efraim>no idea if it would actually work <roelj>that would be really great in the long run, but sambamba seems to be very critical on how it is compiled ;) ***maddo is now known as maddovr
***maddovr is now known as Mad_Hatter
***Mad_Hatter is now known as ACatIsFineToo
***ACatIsFineToo is now known as maddo
<ecbrown>not sure if Maxim Cournoyer hangs here but i'd like to thank/confirm that qtbase@6.1.0 builds with small modifications of patch. 64-bit qt containers and i dont have to compile it myself :-) [bug#47684] <apteryx_>ecbrown: did you share these modifications on the tracker? <ecbrown>not yet, i thought i'd inquire whether there's a plan <ecbrown>"a plan" for qt6 migration. it's a biggie <apteryx_>nope, the way it's made it can go to master when it's ready <ecbrown>i have a mind to try to compile the other stuff with qt6's qt5compat classes <apteryx_>we can migrate things progressively, following their upstreams ***apteryx_ is now known as apteryx
<apteryx>eh. I don't recall it's that heavy, if you stay away from qtwebengine (which is chromium under disguise) <ecbrown>well, i am looking at it, may give it a shot. don't know how much cmake would need to be written (my patches are pretty trivial but i will send them in asap) <ekaitz>civodul: I promised I was going to come back to you <ekaitz>tried to make the riscv development environment and i'm missing some includes <stikonas>bone-baboon: you probably have to sort out proprietary raspberry pi firmware first before you can install guix <stikonas>other than that I guess it should work), might be worth first installing u-boot for rpi... <ekaitz>civodul: <linux/limits.h> not found :( <roptat>isn't that part of linux-libre-headers? *lfam tests the update to linux-libre 5.12 <ekaitz>roptat: I added it to the environment and nothing <cbaines>is the relevant linux-libre-headers bit showing up on the relevant search path? <roptat>I think the relevant variable is $C_INCLUDE_PATH <roptat>interestingly "guix edit gcc" points me to deprecated-package in (guix packages) <ekaitz>this exists: $GUIX_ENVIRONMENT/include/linux/limits.h <roptat>according to the native-search-path of gcc, it should really be C_INCLUDE_PATH, not INCLUDE_PATH <ekaitz>and it works but fails: riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory <roptat>you'll need LIBRARY_PATH I suppose :) <roptat>don't you already have gcc in your environment though? It should set all that for you <ekaitz>and it's not setting any of this <roptat>oh, it's in native-search-path, so it would only work for a native compiler, I guess <lfam>I checked out the keyring branch and set it to track origin/keyring, but `guix pull --url=/path/to/guix` still complains: cannot locate remote-tracking branch 'origin/keyring' <roptat>that might be wise actually: the environment has a mix of native and non-native packages <ekaitz>also when you create a cross-gcc you can add a libc, right? but is it installing it? <roptat>it would depend on that libc at least (with a reference) <roptat>you'd need the complete gcc-toolchain for that <Carcaj0u>civodul: Yes I do have a locale warning in guix-installed guile : `guile: warning: failed to install locale <Carcaj0u>warning: failed to install locale: Invalid argument` <ekaitz>well and I need to show my manifest too <Carcaj0u>My guix-installed emacs GUI does not recognize my dead keys but the terminal version accepts them correctly it seems. <Carcaj0u>So I'm not too sure if this is locale related or keyboard related anymore. <Carcaj0u>(sorry, for the sudden interruption, I'd need to work on my IRC etiquette I suppose ^^"" ) <ruffni>i'm looking for the font called "Monospace". does anybody know whether it's in guix packages (`guix search Monospace\W` returns nothing)? it's ruther difficult name to search for (since every monospace font has this string in the description) <lfam>Look at every line starting with "(name " <roelj>ruffni: perhaps font-liberation :) <ruffni>Carcaj0u: yes, i think that's the one! <ruffni>it might already be installed (there is visible changes when i comment it out in .Xdefaults); though `fc-list | grep Monospace` returns nothing.... <Carcaj0u>returns /home/user/.guix-profile/lib/locale <lfam>What about the other users' profiles? <lfam>E.g. /home/Carcaj0u/.profile <Carcaj0u>`GUIX_LOCPATH=$HOME/.guix-profile/lib/locale` in /root/.profile <Carcaj0u>I did not add it. I added it to my .zshrc , it could be the problem <lfam>Check the man page for zsh, in the section "STARTUP/SHUTDOWN FILES" <lfam>It will tell you which files zsh uses <lfam>(It doesn't use ~/.profile) <lfam>You have to use ~/.zprofile for zsh <lfam>In my zprofile I have this line at the end `test -e ~/.profile && emulate sh -c '. ~/.profile'` <lfam>That way I can use ~/.profile and move seamlessly between bash and zsh <ekaitz>roptat: any idea of what I may be doing wrong? <Carcaj0u>lfam: good idea, so that way you can pull your dotfiles on a new system with guix and have all of it working out of the box. I love it. <lfam>Right. It doesn't matter if you only use one computer, but if you are getting shell accounts on different servers it can be convenient <Carcaj0u>lfam: Why have the emulate at the end and not at the top, wouldn't it override the zsh specific exports and such? <lfam>I guess that depends on what else you have in the .zprofile file <lfam>I would only put shell-agnostic stuff in ~/.profile. And then shell-specific things can go into ~/.bash_profile and ~/.zprofile <lfam>It may be overcomplicated. Maybe it's better to just get comfortable using the defaults <Carcaj0u>Yep, it would only pose problems if zsh used a different value for variable defined in the .profile too. <Carcaj0u>And the separation shell-agnostic - shell-specific is a cleaner approach, I agree. <mothacehe> civodul: do you think we could have an "all-guix-tests" procedure similar to "all-system-tests" but for Guix unit tests? The idea would be to add them to the CI to detect breakage as soon as possible. <civodul>mothacehe: that'd be great; it's a bit of work though because we'd have to translate the makefile/test-env machinery to Guix <ruffni>why does `guix show python2` show a package (which is supposed to be defined in (gnu packages python)) but when i try to build or even import the module in the repl i get "error: python2: unbound variable"? <ruffni>it works when i substitute for package "python2-called-python", but still. is this a bug? <lfam>There is a package named python2, but the Scheme variable is named python-2.7 <lfam>Look in (gnu packages python), it's the first package <lfam>Anyways, if you are working in Scheme, you need to use the variable name, which is different from the package name <civodul>i think it's still ~half of the previous number of people <cwebber>civodul: that's a quicker "repopulation" than most places I've been in still :P <lfam>The freenode channel had >300 people <Carcaj0u>cwebber: Do you mean since you moved to Libera.chat? <cwebber>hm yeah okay maybe it's a lot less ;) <lfam>I think it helps that our channel is active and helpful <cwebber>channels where people talk regularly seem to be migrating fastest <lfam>This channel is pretty crucial for Guix <roelj>civodul: I repaid my debt by reviewing/applying three patches! It would be really really great if someone could take a look at the LDC fix ;P <civodul>i replied to the ldc fix earlier today <civodul>though maybe not in a sufficiently definite way :-) <roelj>I replied with logs. Did I miss a message after that? <sneek>Welcome back mdevos, you have 1 message! <sneek>mdevos, nckx says: keo[m]1: the build fermette behind guix.tobias.gr is on holiday, although it still serves older stuff from cache. <mdevos>ok, not sure why I got that message though <nckx>mdevos: Because you mentioned it. <roptat>ekaitz, sorry I had something else to do and didn't follow. from the look of the manifest, you're installing a cross gcc, but a native libc and linux headers, so crti.so is going to be the wrong architecture IĀ think <nckx>sneek: sneek sneek sneeky botsnack sneek! \o/ <roptat>sneek, here's a pile of botsnack, don't leave us <nckx>This place is #guix again. <ekaitz>the libreheaders are the normal ones (how can I get the riscv ones? aren't them always the same?) but the libc looks like the good one <mdevos>Does anyone kno why I can't change my nick? /nick maximed (and /nick mdevos-test) gives: #guile Cannot change nickname while banned on channel <roptat>ekaitz, ah, indeed, I didn't pay attention to the let <roptat>mdevos, you need to leave #guile first, or register this nick <tissevert>we did remain at the same place by moving, indeed : ) <ekaitz>roptat: yeah... I don't know whats going on then... I'll try to dig on this during the weekend... thanks for your time ***maximed is now known as maximed-test
***maximed-test is now known as maximed
<roptat>ekaitz, what does "file $GUIX_ENVIRONMENT/lib/crt1.o" tell you? <ekaitz>/gnu/store/bv20ddrf1w3p225szrwx6qcx21dgdb00-profile/lib/crt1.o: symbolic link to /gnu/store/8n3cdnafvlpg0m68gz4spns4lx87x1sf-glibc-cross-riscv64-linux-gnu-2.31/lib/crt1.o <ekaitz>/gnu/store/8n3cdnafvlpg0m68gz4spns4lx87x1sf-glibc-cross-riscv64-linux-gnu-2.31/lib/crt1.o: ELF 64-bit LSB relocatable, UCB RISC-V, version 1 (SYSV), for GNU/Linux 2.6.32, with debug_info, not stripped <nckx>I think comparing user counts is misleading. There are 266 users left in old #guix. At *least* 72 of those are Matrix users, and the Libera Matrix bridge is still āunder construction but coming soonā. Probably more, since I just grepped for [m] :) Worse, ~146 of those 266 haven't said *anything* in 2021. There are users like ānckx[m]ā who never will. <nckx>Honestly, we've just... moved. <nckx>I didn't actually expect it to work either āŗ <nckx>The remaining few are out summering in Barbados and will turn up in good time. <roptat>ekaitz, looks like you actually need CROSS_LIBRARY_PATH, CROSS_C_INCLUDE_PATH, etc for a cross compiler <ekaitz>is there a way to set that up in the environment? <ekaitz>that is not just calling export? <lfam>How do we get the new manual built for the website? I pushed the changes to the version-1.3.0 branch yesterday, but the online manual is still referring to Freenode <ekaitz>roptat: still failing with the CROSS_ set, i'll leave it for today, but thanks for the help, seriously, I appreciate the effort <ekaitz>some days we win, others we lose <roptat>lfam, it should be automatic, but maybe it's failing? <lfam>I'll check the cron logs on berlin <lfam>Indeed, it's failing (again) <lfam>The derivation /gnu/store/6d42q7svvpc2y27xg47m6czbs9jf5njx-guix-translated-texinfo.drv fails to build for a long time now <lfam>I think we have to build the derivation "by hand", maybe single-threaded <civodul>lfam: that's for master or version-1.3.0? <civodul>ok, i think the switch to libgc/disable-munmap on master solves that <lfam>Or, these changes are for version-1.3.0. I don't know which branch this derivation corresponds to <lfam>I just glanced on mcron.log <civodul>cbaines: BTW, i think for guix-data-service on master you should rely on libgc/disable-munmap rather than libgc@7 <lfam>Anyways, that drv segfaults during build. I'll try again with cores=1 <tissevert>(out of curiosity, is that the same website repos Luis Felipe mentioned in his recent mail on guix-devel ?) <lfam>This is the manual, not the website itself <lfam>They are built with different tools and then cobbled together <tissevert>are the corresponding repos public ? someone here asked questions about submitting proposals for the website's theme <cbaines>civodul, I think it already does, since it just uses the same Guile as Guix. The only thing I see using guile-3.0/libgc-7 is Cuirass. <lfam>That's the repo for the website <lfam>The manual is part of guix.git <lfam>Testing changes to the installer by running `make check-system TESTS=gui-installed-os`, it plans to build all the bootstrap derivations and then fails to build the Python-3.5.9 tarball :/ <ruffni>ekaitz: don't let it get to you! you're doing great work! missed your stream again, but i'll eventually make it ;) <ekaitz>ruffni: I didn't know I was that famous :) <ruffni>do you have your work mirrored online? i'd like to type along/explore on my own :) <ekaitz>hm... yeah the work on lightening is my gitlab, but what I'm doing on bootstrap-seeds is not online yet <tissevert>you arrived a few minutes left, I've just learnt the location of the repository which existence I was assuming yesterday <tissevert>so you can first retrieve it locally and learn to build it, then test your change for good, and if you're satisfied with the result submit a patch maybe ? <roptat>trying to run "guix environment -C", I get "In procedure getpw: entry not found", any idea? <hwpplayer1>tissevert: I am also good testing my hardware, finally I am able to run EXWM <roptat>ah, that's probably because I don't have a local account: my user is not in /etc/passwd <tissevert>roptat: that sounds familiar, I've seen this already in containers missing stuff <roptat>no, that's definitely an exception in guix, there's a guile backtrace <tissevert>like default shell being bash but only sh being available <roptat>I'm running the command directly, like "guix environment -C -m manifest.scm -- make", so if make is not found, I'd expect "make: no such file or directory" or something similar? <roptat>I'll try with root. it has a local account and its default shell is bash. If my theory is correct, it should work, if yours is correct, it shouldn't. fair? :) <roptat>oh well, I get a permission denied :/ <roptat>not sure if that's before or after getpw, so the experiment is inconclusive <roptat>ahah, running that in root's home worked \o/ <roptat>so, I think the issue is really that my user is not local to the system <roptat>I think I broke something badly, /etc/passwd now contains a single entry, outside the environment <tissevert>or was it a missing exec permission on something ? <tissevert>surely guix system reconfigure can save the day ? <roptat>I had thankfully printed its content before, and had a root terminal open, so I managed to fix that <roptat>although, I'm not sudoer anymore <lfam>Make sure the root user has a password and then it should be safe <lfam>`passwd root` and then `su -` to test <tissevert>you've fixed things, like can you log back in from a tty console ? <roptat>... do not ever, EVER --share=/etc when running as root :/ <lfam>written like that, it sounds reasonable <tissevert>sorry, I meant that I know what happened to roptat could have happened any time to me, but in spite of this, once formulated like roptat did Ā«don't share /etcĀ», it sounded quite Ā«obviousĀ» <tissevert>the kind of Ā«obviousĀ» any one misses a couple times on a daily basis <pineapples>I've been wrestling with auditd to read my `audit.rules' for the last two days, and I've discovered that the daemon itself doesn't read the `.rules' files; it has a helper program for that purpose <lfam>Fetching which patchsets from where? <Digit>:D i keep joining chans on libera, half expecting to be the first, and keep finding the exodus is well ahead of me. :) wtg guix. :) [ guix getting praise in other distro chans, regarding its hosting solutions and their freedomness, which is nice. :) ] <civodul>lfam: from issues.guix.gnu.org; leoprikler: i think you just need to add /patchset to the URL? <lfam>The ungrafting jobs are failing due to a lot of "cannot build missing derivation" errors <cbaines>(or rather issues, as I think there are issues with both the client and server sides) <lfam>I've seen those errors, too. In these cases, it looks different (maybe same root cause?) <lfam>The derivations themselves are missing <lfam>And indeed, I just checked one of them, and it's not preset on berlin.gnu.org <cbaines>so I'm probably wrong, it's probably a different issue <lfam>I guess we should restart the job <civodul>texlive question: does "!pdfTeX error: /home/ludo/.guix-profile/bin/pdflatex (file fir_7gpamp.enc): can not open encoding file for reading" ring a bell? <lfam>I'm going to rebase the branch and push it agian <maximed>Speaking of texlive, does this ring a bell (pdflatex output)? Package babel Warning: No hyphenation patterns were preloaded for the language `Dutch' into the format. Please, , [...] *maximed searches the web again <samplet>civodul: Your approach for getting the SWHID should be fine. However, if you like, I could release Disarchive 0.2.2 with an āofficialā way to list the addresses. <maximed>dutch, german, swedish in \usepackage[$LANGUAGE]{babel} makes no difference <maximed>Did someone here at one point successfully use babel with language != english on Guix? <samplet>I also wanted to communicate that Iām working on a thorough-going way to check the archival coverage of Guix (with the intent of ensuring everything back to v1.0.0). <jackhill>samplet: that's awesome, thank for working on that! <maximed>seems like I need to install texlive-latex-hyph-utf8 (will do that now) <samplet>Iām using inferiors to build a database of sources. Then, I can run checks over that database. This includes computing the SWHID of a source and checking if SWH has it. ***Server sets mode: +Ccntz
<cbaines>it seems like there's a performance problem though, as it's really slow to load <samplet>For āgit-fetchā and āurl-fetchā, it doesnāt matter, but for the other downloaders, the derivation does not contain enough information to see whatās being downloaded. <cbaines>samplet, yeah, the Guix Data Service currently is missing some fluff in the middle regarding packages <cbaines>it has some of the metadata, and a good record of the derivations, but nothing about inputs or origins <cbaines>(next on my list is tracking package replacements) <civodul>samplet: hi! re Disarchive, an official way to get the IDs would be nice, too <samplet>I could use the Data Serviceās historical list of fixed-output derivations to guide how to track down the origin metadata (itās expensive, so pruning the list of commits would be helpful). <civodul>i initially thought it's best to avoid the dependency on Disarchive <civodul>well yeah, we can assume Guix already depends on it ***jonsger1 is now known as jonsger
<samplet>civodul: But itās officially an āoptionalā dependency, right? Wouldnāt you have to load it opportunistically and skip the lint check if itās not there? <civodul>optionality is very relative though :-) <civodul>the current brute-force approach will always work, i guess <samplet>civodul: Itās a pretty approach, yup. <maximed>Does anyone know what one is supposed to install to install texlive? There is texlive-base, texlive, ... <maximed>I'll try texlive-union from a manifest *maximed does not use xmonad <acksys>First morning with guix! I'm new to guix and nixos and trying both. I'd like to move my laptop over to one of these. <bavier>Junwei: I haven't used xmonad in a while, but the last I recall is that the xmonad "reconfigure" process doesn't quite work with Guix's package. <roptat_>oh, IĀ think the remaining issue is with /etc/group, it's down to two groups, and I don't have a backup of that file <roptat_>ah, there was a copy of the file as /etc/group-, so it's all fixed now I think ***roptat_ is now known as roptat
<maximed>Lately (past ~2 days), my computer screen occassionally temporarily (2-5 seconds) becomes bright (as in white, not referring to (energetic) intensity) and seems to dither or something. Any ideas what even is happening? <maximed>Also, did someone ever encounter that on non-Guix System? <joshua>Hey guix! I've found a bug in the way that Gajim is packaged. I'm running sway and some of the Gajim icons are not loaded. Should I report this bug? <vagrantc>the icons show up when running X ? or do you just not have the right font packages installed? <joshua>vagrantc: I am running sway...let me see if Gajim is running under X or wayland... <joshua>vagrantc: gajim is running in X. <joshua>I see the icons for people in the main gajim buffer. <roptat>maximed, never seen that before, maybe try to load a previous generation of your os, or something? see if that's linux/some package update? <joshua>I DO NOT see the "closed" button icon in the chat screen. <vagrantc>joshua: sounds like a bug somewhere, then, given it works under X but not under sway <joshua>vagrantc: let me try starting gajim from a terminal to see if it shows any bug messages. <joshua>I did get an error message...just a second and I'll post it. <maximed>roptat: problem is it only happens rarely (two times a day or so) and I don't have much time to debug things. (Difficult assignment with deadline in ~10 days). But yes, that seems a reasonable course of action <vagrantc>fwiw, i haven't used gajim on guix, but gajim running under sway on Debian works fine <vagrantc>wonder if there are different XDG_* environment variables set <joshua>vagrantc: Yeah it works fine to chat with people. and send messages and such. Just one icon doesn't seem to load. That pastebin says something about a missing icon. <joshua>vagrantc: possibly. let me go list those... ***taylan2 is now known as taylan
<joshua>vagrantc: is there a font I should install to test things? <vagrantc>well, clearly you have the font in there somewhere, if you see it in X <joshua>gotcha. :) I'll file a bug report with a picture! Thanks! <cbaines>ah, just realised I'm wanting to use Sqlite features that aren't in the sqlite version in master... <acksys>Never heard of that. I'll take a look. <apteryx>are workspaces guaranteed to start from scratch every time? <apteryx>I seem to accumulate cruft between builds replay / fresh builds? (my stash now has 3 tarballs instead of one?) <maximed>Is anyone able to use polyglossia (a texlive package for xe(la)tex)? I get File `polyglossia.sty' not found. even though I added polyglossia to the manifest ***Noisytoot_ is now known as Noisytoot
***taylan is now known as Guest6817
***taylan2 is now known as taylan
***Server sets mode: +Ccntz
***roptat_ is now known as roptat
***Noisytoot_ is now known as Noisytoot
***irfus- is now known as irfus
<rjwiii> C==/_o|^|o_\ /!\ IRC.LIBERA.CHAT IS THE BEST IRC NETWORK /!\ <rjwiii> | _\ ) /!\ THE JEWS HAVE TAKEN OVER FREENODE, CHATS HAVE MOVED TO IRC.LIBERA.CHAT /!\ <rjwiii> \ .--- / /!\ THIS CHANNEL HAS MOVED TO IRC.LIBERA.CHAT #LIBERIA /!\ <rjwiii> _/`-. __.'_ /!\ JOIN #LIBERIA TODAY. THIS CHANNEL HAS MOVED TO IRC.LIBERA.CHAT #LIBERIA /!\ ***ChanServ sets mode: +o civodul
***rjwiii was kicked by civodul (Kicked by civodul)
***ChanServ sets mode: -o civodul
<jonsger>looks like a northwest german spamer... ***Mark___ is now known as Mark_
***lukedashjr is now known as luke-jr
<raghavgururajan>leoprikler: raghavgururajan: I wouldn't merge this before finding out what keeps tests from failing and dropping #:tests? #f <raghavgururajan>leoprikler: That's correct. I was planning to get help to fix tests first. The patch had to be published for others to try and test. :) <raghavgururajan>leoprikler: Regarding ffmpeg and gstreamer, they are for media backends. I haven't enabled them yet. They may or may not be cycles. <drakonis>the author has updated the readme and now it has more details on why it exists ***lukedashjr is now known as luke-jr
<lfam>Alright, I'm still working on updating the web-based manuals <lfam>Neither the "1.3.0" manual nor the "devel" manual are building successfully on berlin <lfam>Currently I'm building guix-translated-texinfo.drv <civodul>lfam: did you try building it with --cores=1 --no-offload? <lfam>I'm using cores=1. If it fails I'll try with --no-offload too <lfam>I thought that I did this earlier today but maybe the derivation changed from what I saw in mcron.log. I'm not sure <lfam>Alright, /gnu/store/5rl0vwzrmhh3rn19476ccadzzl6psqpd-guix-translated-texinfo.drv has built <drakonis>hmm, how doable is it to build a dependency that explicitly needs rust-nightly? <drakonis>would i need to build a newer rust version for that? <lfam>It's kind of at odds with the Guix model, drakonis <lfam>We always explicitly declare dependencies. There's not an easy way to make a Guix package that doesn't do that <civodul>lfam: i'm trying "sudo su - static-web-site -c /gnu/store/1bn4gkis572255izmih8j4ld5mpbkgd6-update-guix-manual" <lfam>Ah, it's nice to have a high-level command like that civodul <civodul>lfam: i got it from "herd schedule mcron" *lfam learns something new <drakonis>something is wrong with what i'm doing to build <drakonis>because it shouldnt be having issues here <lfam>drakonis: Maybe you could take inspiration from the guix.scm model, where you use Guix tools to build a project that you're developing <drakonis>i installed orjson on a container while using rust 1.50 and it worked fine <lfam>Hm, does anyone have a nice example of the 'guix.scm' way? <drakonis>i am curious about the potential to do something like an augmented guile script that interacts with guix libraries <drakonis>i'm not sure why it was trying to use rust for building it lol <drakonis>maybe its something i was doing incorrectly <civodul>not sure if that's what you're looking for <lfam>I thought of it because it's a way to use Guix that can handle "changing" sources (i.e., your own source code) <lfam>Maybe it's just inspiration <drakonis>worth pursuing for using guix for more elaborate things <drakonis>just going to set up a guix vm for experimentation, as i'm currently fiddling with my nixos install while i'm not done moving my vps <drakonis>how viable is a nix-shell-ish setup with guix? <drakonis>besides not using it in the same way as the nix folks do, which has led to a lot of weird hacks for software compatibility <drakonis>do manifests replace that in some way or another? <drakonis>i'm ready to admit that i want to escape nix now *lfam reads about nix-shell <lfam>It sounds similar to `guix environment` <drakonis>but you invoke functions to generate the environments <lfam>I guess we don't have anything like the shellHook, unless I've just missed that <drakonis>its a lot of hacks for dealing with the language's inadequacies <dstolfa>or is linux-libre not supporting it due to non-free blobs <lfam>It's not support dstolfa, sorry <lfam>People are surely using it via custom kernel packages, but support is not included in GNU Guix <dstolfa>lfam: yeah, guess i'll have to build my own kernel, which i don't mind doing but still sad times that linux-libre doesn't support it <civodul>cbaines: does the Data Service have an API to map a .drv to the corresponding channel commits? <lfam>There's not many different wifi chips with free firmware. It's basically just 802.11n Atheros (ath9k) and then there is 3rd party firmware for some chips via the aircrack-ng project: https://github.com/aircrack-ng/ <lfam>I actually don't know the full set of what's supported by aircrack-ng. I just learned about it recently <dstolfa>i'll look into aircrack-ng, maybe it has some of the stuff i need <ArneBab>My computer spent the past 30 hours or so on guix system reconfigure --no-substitutes ā it now arrived at rust 1.30.1.drv and itās crazy to think that it will still have to walk up to rust 1.44.1, version by version. <lfam>ArneBab: Do you mean to build it from source? Or could you wait a little while for substitutes? <ArneBab>Iām building it from source, because building from substitutes is broken for me (I do not know why ā I reported a bug) <lfam>It's incredibly expensive to build Rust things from source due to the bootstrap chain <ArneBab>yes, and I really do not understand why they do that ā can it be so hard to limit themselves to basic rust for a compiler-core? <sundbry>I presume he means they have to use the new rust features in the rust compiler itself <ArneBab>If rust 1.44.1 needs the whole chain from 1.27.1 upwards it means that 1.44.1 cannot be compiled with 1.27.1 ā but I would hope that they could define a minimal core of the compiler that suffices to build the rest and write that compiler in rust 1.27.1 <lfam>One would hope for that, but it seems the Rust people have chosen not to :( <lfam>They've basically made all the worst choices from the perspective of functional package management <demotri>ArneBab: For Java/OpenJDK, the boot-chain gets also longer ever 0.5 years. I think it is mainly because of a mixture of lazyness, unawareness of bootchains and new cool features to use. <lfam>It's pathological for us <sundbry>I gave rust a shot for a little while... I was not impressed by the language bloat. <lfam>I hope that in 5 years things will have stabilized and their values will shift a little bit <ArneBab>itās like with all the cool things the basics are getting lost <lfam>Maybe it would have been like this for C if Guix was created in 1980, for example. Although that would have been impossible since cryptographic hashing did not exist and computers were too slow for such hashes anyways <lfam>We are roughly at that stage of Rust development, compared to C <ArneBab>didnāt they still standardize their languages back then? <lfam>My understanding is that C wasn't standardized at all at that point <ArneBab>ā¦ well, there were an awful lot of proprietary compilers <lfam>I've read some C code of that era and it looks totally different <lfam>I wasn't even born, so what do I know? :) <ArneBab>so something like guix would have been impossible back then simply because there existed too few fully free toolchains. <lfam>Yeah, for many reasons, my comparison was very abstract <lfam>No toolchains, no cryptography, extremely slow computers, etc <ArneBab>Iām just two years older than GNU Emacs :-) <lfam>Go has similar problems as Rust, but it's improving in this regard. <vagrantc>i'd wager you have millions of years of evolution ahead of emacs <ArneBab>But back then they already had 3d design with proven constraints for designing bridges. And they did language experiments that seem like new today. <lfam>True, but merkle trees were impossible <lfam>And that is the crux of the whole Guix thing <lfam>For similar reasons Git could not have been invented any sooner <sundbry>I like the new go-modules. Makes it much easier to package go programs on guix now. <lfam>Sure, but what cryptographic hash could have been used? <lfam>I think it was somewhat abstract in 1979 <lfam>There was not even a decent understanding of cryptographic outside of the military at that point <lfam>Even in the 1990s, people were only just beginning to understand <lfam>Hence the legacy baggage of PGP <lfam>I'm going to read the patent. I'm curious how much hand-waving is there <ArneBab>did yoou manage to access the patent? <ArneBab>in the publication at 1987 Merkle used DES as an example <lfam>Click "Original Document" <lfam>It references Diffie et al <lfam>Heh, yes, as crypto began to ooze into the civilian sphere <lfam>The Promethean story of our time <ArneBab>just imagine where wwe would be today without Free Software activists working for the past four decades to keep it accessible and understandible in the civilian sphere. <drakonis>as it turns out, it is trying to compile a rust dependency that in other distros, it does not need to <ArneBab>drakonis: python venvs need rust now? <drakonis>there is a dependency called orjson that needs rust nightly <drakonis>installing it in another distribution fetches the wheel correctly <ArneBab>drakonis: arenāt wheels binary blobs? <drakonis>i've been trying to get that out of the way ***stikonas_ is now known as stikonas
<drakonis>the wheel doesnt seem to support python 3.8