IRC channel logs


back to list of logs

<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. 😴💤
<stikonas>well, they say third time is a charm
<hwpplayer1>hi people!
<hwpplayer1>I need help for GNOME
<hwpplayer1>or a WM
<pineapples>A keyboard-driven Internet browser written in Lisp :')
<pineapples>Do we have it packaged?
<drakonis>we do
<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>hwpplayer1: just install it idk
<hwpplayer1>:) cool of course
<drakonis>emacs is already available
<hwpplayer1>I know which one do you offer ?
<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?
<drakonis>as well as 28
<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
<drakonis>NixOS is a topic.
<drakonis>most certainly a topic.
***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>sneek: botsnack
<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?
<dsmith>It's just #guile
***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
<raghavgururajan>leoprikler, roptat, nckx, lfam and apteryx: GTK v4 --> #48554
<apteryx>raghavgururajan: wow!
<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
<leoprikler>spikot yeah, your password now got leaked
<civodul>Hello Guix!
***Parnikkapore is now known as parnikkapore
<tissevert>hi guix !!
***parnikkapore is now known as Parnikkapore
***rekado_ is now known as rekado
***Parnikkapore is now known as parnikkapore
<taeaad>Do any of you guys use Hurd?
***Mysterio` is now known as MysteriousSilve`
<civodul>s/guys/people/ :-)
<civodul>taeaad: it's unlikely, in part because Guix is not fully usable there yet
<civodul>but not just
<spikot>go 3
<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>cbaines: nice!
<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
<cbaines>I'm really excited by this as "Resource temporarily unavailable, try again" errors connected with write_to_session_record_port are one thing that slows the Guix Build Coordinator down
<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: hi! displays only one channel even though there's a second one involved; does that ring a bell?
<mothacehe>civodul: hey! I think its because the only channel displayed is the one with a new input. This evaluation displays two channels because they "moved" at the same time.
<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
<leoprikler>you also need cross-binutils "riscv..." IIUC
<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
<civodul>as a rough approximation...
<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
<civodul>ah wait
<civodul>you can use a fancy manifest!
<ekaitz>but (cross-gcc ...) should work right?
<ekaitz>yeah that was what I was talking about
<civodul>ah sorry
<civodul>got it now :-)
<ekaitz>make a manifest with cross-gcc, cross-binutils and cross-libc ?
<civodul>hmm cross-gcc may not be enough
<civodul>something like that
<ekaitz>I'll try that again and if I find issues I'll come back to *you*
<civodul>heh ok :-)
<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>civodul: Hah, deal!
<civodul>awesome :-)
<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?
<civodul>i recommend either C-u M-x debbugs-gnu guix-patches RET or
<leoprikler>the mumi interface is nice and all, but sadly it cuts off at a certain point :(
<leoprikler>hmm, is:open seems to work, nvm
<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
<roelj>efraim: GDC to build sambamba?
<roelj>rekado: I'm going through the priority bugs now.
<efraim>roelj: no idea
<efraim>er, that'd be the idea
<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]
<rekado>apteryx_: ^^
<ecbrown>thanks rekado
<apteryx_>ecbrown: that's me :-) nice!
<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
<ecbrown>qt makes my i9 cry
<ecbrown>the build, that is ;-)
<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)
<apteryx>OK! sounds good
<bone-baboon>Has anyone got Guix running on a Raspberry Pi? I do not want to run the Raspberry Pi OS on my Raspberry Pi hardware because of this <>. Someone commenting about it <>.
<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>guix does not ship it...
<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
<lfam> <>
<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>let me test but...
<ekaitz>this exists: $GUIX_ENVIRONMENT/include/linux/limits.h
<bone-baboon>stikonas: Thanks
<ekaitz>and if I set $INCLUDE_PATH
<ekaitz>it still fails
<roptat>according to the native-search-path of gcc, it should really be C_INCLUDE_PATH, not INCLUDE_PATH
<roptat>(and CPLUS_INCLUDE_PATH too)
<ekaitz>oh ok good, I managed to add it
<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 :)
<ekaitz>yeah right?
<roptat>don't you already have gcc in your environment though? It should set all that for you
<ekaitz>it's a cross-gcc
<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'
<lfam>Any advice?
<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>but not propagate it
<roptat>you'd need the complete gcc-toolchain for that
<ekaitz>let me show you something
<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 ^^"" )
<lfam>No worries
<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>ruffni: You could look for it here:
<Carcaj0u>ruffini: Do you mean ?
<lfam>Look at every line starting with "(name "
<roelj>ruffni: perhaps font-liberation :)
<leoprikler>sure it's liberation and not dejavu?
<civodul>Carcaj0u: could you install locales and define GUIX_LOCPATH as per ?
<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>civodul: I did and
<Carcaj0u>echo $GUIX_LOCPATH
<Carcaj0u>returns /home/user/.guix-profile/lib/locale
<Carcaj0u>Maybe I put it in the wrong files?
<Carcaj0u>I put it in the /root/.profile like so:
<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>In /home/Carcaj0u/.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
<Carcaj0u>lfam: Yes! .zprofile was the one :)
<Carcaj0u>Thanks a lot
<lfam>Great :)
<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>For me it works
<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
<civodul>not insurmountable though
<mothacehe>great, thanks. I'll keep that in mind :)
<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
<cwebber>hi hi
<cwebber>wow, #guix sure repopulated fast
<civodul>hey cwebber!
<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
<cwebber>hm yeah okay maybe it's a lot less ;)
<lfam>I think it helps that our channel is active and helpful
<cwebber>yes that's true
<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>roelj: well done, thanks!
<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?
<civodul>oh i hadn't seen
<civodul>lemme see
<hwpplayer1>hi finally I run Emacs EXWM on a Qemu VM
<hwpplayer1>I need to work on it
<nckx>Good morning Guix.
<hwpplayer1>Good morning nckx
<Carcaj0u>Good morning
<sneek>Welcome back mdevos, you have 1 message!
<sneek>mdevos, nckx says: keo[m]1: the build fermette behind is on holiday, although it still serves older stuff from cache.
<mdevos>ok, not sure why I got that message though
<hwpplayer1>Can I run a server for you ?
<hwpplayer1>This is a bot mdevos
<mdevos>I know
<nckx>mdevos: Because you mentioned it.
*mdevos checks logs
<nckx>True. I could be lying.
<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 is going to be the wrong architecture I think
<lfam>sneek: botsnack
<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
<ekaitz>(cross-libc ...)
<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>that's a good question
<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
<ekaitz>so it looks correct
<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>oh come on I'm that stupid?
<ekaitz>(don't answer)
<roptat>I'm with you :)
<ekaitz>is there a way to set that up in the environment?
<ekaitz>that is not just calling export?
<ekaitz>i mean some guix magic
<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
<roptat>oh well :(
<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
<lfam>I'm trying it now
<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
<civodul>lfam: ok
<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
<civodul>cbaines: ah ok, we should fix it
<tissevert>thanks !
<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 :/
<lfam>I don't understand this
<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 :)
<hwpplayer1>hi people!
<ruffni>ekaitz: lol
<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>hwpplayer1: hi !
<tissevert>you arrived a few minutes left, I've just learnt the location of the repository which existence I was assuming yesterday
<hwpplayer1>tissevert: hi how are you doing ?
<tissevert>if you wanna submit your patch for graphical improvement, it's at
<hwpplayer1>I will work on the artwork
<hwpplayer1>A better implementation
<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 ?
<tissevert>I'm doing good thanks. how about you ?
<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
<hwpplayer1>I need to work on it from the ground
<roptat>ah, that's probably because I don't have a local account: my user is not in /etc/passwd
<ruffni>ekaitz: nice, thanks!
<tissevert>roptat: that sounds familiar, I've seen this already in containers missing stuff
<tissevert>I thought it was the shell though
<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
<tissevert>permission denied ?
<tissevert>but why ? by what ? ^^'
<roptat>uh oh
<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>outside the… ? ^^' ow : /
<tissevert>surely guix system reconfigure can save the day ?
<roptat>it's a foreign system
<roptat>I had thankfully printed its content before, and had a root terminal open, so I managed to fix that
<tissevert>oh nooo : /
<tissevert>that sure is lucky
<roptat>although, I'm not sudoer anymore
<roptat>I'm afraid of rebooting now ^^'
<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>yeah, I can login from a tty
<roptat>... do not ever, EVER --share=/etc when running as root :/
<efraim>perhaps you meant --expose
<tissevert>written like that, it sounds reasonable
<Noisytoot>sneek: botsnack
<lfam>What does that mean?!
<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
<leoprikler>what's the syntax for fetching patchsets again?
<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; leoprikler: i think you just need to add /patchset to the URL?
<civodul>if in doubt, check the code ;-)
*vagrantc waves to Digit
<lfam>The ungrafting jobs are failing due to a lot of "cannot build missing derivation" errors
<cbaines>it's a known issue
<cbaines>(or rather issues, as I think there are issues with both the client and server sides)
<cbaines>this is the issue
<lfam>I've seen those errors, too. In these cases, it looks different (maybe same root cause?)
<cbaines>ah, yeah, I may be mixing things up
<lfam>The derivations themselves are missing
<lfam>And indeed, I just checked one of them, and it's not preset on
<cbaines>maybe it's been garbage collected
<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
<lfam>Some out of tree kernel modules broke with Linux 5.12:
<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).
<maximed>\usepackage{hyphsubst} has _no_ effect (suggested on
<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)
<maximed>* texlive-hyph-utf8
<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.
<vagrantc>is softwareheritage still git only?
***Server sets mode: +Ccntz
<cbaines>I did even add a page to expose all the fixed output derivations linked to packages for a revision
<cbaines>it seems like there's a performance problem though, as it's really slow to load
<drakonis>ahoy friends
<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.
<drakonis>lots of activity here
<drakonis>dstolfa: nice seeing you here :v
<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>that could be improved though
<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>but it's already there anyway
<civodul>well, not quite
<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>samplet: yeah...
<civodul>optionality is very relative though :-)
<civodul>i'm fine either way
<civodul>the current brute-force approach will always work, i guess
<samplet>civodul: It’s a pretty approach, yup.
<samplet>pretty safe approach
<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
<Junwei>Hi, is anyone using xmonad?
<Junwei>I could not compile it on guix.
<maximed>compile == "guix build xmonad"?
*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_>I can sudo :)
***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?
<maximed>(happend four times last two days)
<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?
<joshua>Or is that not a valid 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>xeyes to the rescue!
<joshua>vagrantc: gajim is running in X.
<vagrantc>and the icons show up?
<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...
<joshua>my environmental variables:
***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...
<cbaines>it was an excuse to use the Guix Data Service page that shows package versions in different branches though
<acksys>I'm looking into options for managing dotfiles. I found and I know of GNU Stow. I also think I could build a dotfile as a package in guix store and symlink it into my home directory. Are there other good options?
<cbaines>I use vcsh, well, kind of
<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?)
<apteryx>eh, wrong channel, sorry :-)
<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
*maximed afk
<jackhill>acksys: there's also chezmoi and
***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> /)))))))))
<rjwiii> //) __ __\
<rjwiii> C==/_o|^|o_\ /!\ IRC.LIBERA.CHAT IS THE BEST IRC NETWORK /!\
<rjwiii> /` \`'-,._./|\
<rjwiii>/ \ /`\_/\/ \
***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.
<BluePhoenix-t> /)))))))))
<BluePhoenix-t> //) __ __\
<drakonis> just quickly linking this again
<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?
<civodul>i think that's what i did last time
<civodul>yeah, that's terrible
<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"
<drakonis>oh no its the split, its striking again
<lfam>Ah, it's nice to have a high-level command like that civodul
<civodul>lfam: i got it from "herd schedule mcron"
<civodul>dirty tricks...
*lfam learns something new
<drakonis>hmm nvm
<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
<lfam>Do you know that way?
<drakonis>i installed orjson on a container while using rust 1.50 and it worked fine
<drakonis>no i haven't
<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>so i can do some more elaborate stuff
<drakonis>i'm not sure why it was trying to use rust for building it lol
<drakonis>so weird
<drakonis>it installs fine without needing rust
<drakonis>maybe its something i was doing incorrectly
<civodul>drakonis: is a 'guix.scm' used as some sort of a makefile replacement
<civodul>not sure if that's what you're looking for
<drakonis>oh nice.
<drakonis>that'd be good
<lfam>I thought of it because it's a way to use Guix that can handle "changing" sources (i.e., your own source code)
<drakonis>its not quite there but its a start
<lfam>Maybe it's just inspiration
<drakonis>that'd be a good thing
<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>yes it is
<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
<dstolfa>is anyone using AX201 on guixsd?
<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
<dstolfa>lfam: sad times :(
<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:
<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?
<lfam>What do you mean?
<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.
<ArneBab>(re pathological)
<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
<lfam>About 10 years in
<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.
<ArneBab>me neither :-)
<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.
<ArneBab>vagrantc: :-)
<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.
<ArneBab>merkle trees were patented in 1979
<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
<vagrantc>some things never change
<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
<ArneBab>DES was “published as an official Federal Information Processing Standard (FIPS) for the United States in 1977. ”
<ArneBab>lfam: thank you!
<lfam>Heh, yes, as crypto began to ooze into the civilian sphere
<lfam>The Promethean story of our time
<drakonis>perhaps using venvs will be a pain
<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.
<ArneBab>drakonis: what are venvs?
<maximed>I read <> -- it appears the polyglossia issue is a known issue
<drakonis>python venvs
<maximed>I'll go back to babel & latex then
<ArneBab>drakonis: ah, yes
<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?
<ArneBab>(I know Mercurial uses it)
<drakonis>there is a dependency called orjson that needs rust nightly
<drakonis>installing it in another distribution fetches the wheel correctly
<drakonis>i'm wondering why this is happening
<ArneBab>drakonis: aren’t wheels binary blobs?
<drakonis>hmm, they're prebuilts
<vagrantc>pregenerated binary blobs?
<ArneBab>by the uploader
<ArneBab>so reproducibility isn’t checked.
<drakonis>oh i know
<drakonis>i'm doing a migration here
<drakonis>the only hold up is orjson
<drakonis>i've been trying to get that out of the way
***stikonas_ is now known as stikonas
<drakonis>hmm i see why
<drakonis>the wheel doesnt seem to support python 3.8
<drakonis>hmm how would i get a newer release?
<drakonis>python 3.9 might work