IRC channel logs

2021-05-25.log

back to list of logs

<drakonis>pineapples: it should go inside games/doom
<drakonis>fm_banks and soundfonts
<sharlatan>Hi
<pineapples>drakonis: Right. But where do I obtain a copy of fm_banks from?
*pineapples goes to sleep
<drakonis>from building gzdoom
<pineapples>I'll just wait for your fix then. This workaround is nowhere trivial as I initially thought
<pineapples>Still, I appreciate your willingness to help me :)
<roptat>oops, trying to update josm lead me to update more stuff...
<roptat>I found a new dependency cycle
<roptat>the newer log4j-core depends on the log4j adapter from commons-logging, which depends on log4j-1.2-api, which depends on log4j-core
<roptat>to be fair, commons-logging actually depends on log4j-api@1.2, which we haven't packaged because we have log4j-api@2
<roptat>1.2 is EOL since 2015, but the last release of commons-logging is from 2014
<sharlatan>/?
<roptat>just venting my frustration, don't pay attention ^^'
***Exagone313 is now known as Exa
<joshua1>Hey friends! so I am running sway, firefox, emacs, gajim...I am noticing the system becoming a little unresponsive...how do I figure out what is causing the slowness? top ? Anything else?
<pkill9>htop
<pkill9>it's a little better than top
<dstolfa>perf is also pretty good
<dstolfa>perf stat/perf top
<joshua1>thanks!
***taylan2 is now known as taylan
<joshua1>looks like I'm using a lot of swap...
<dstolfa>the next question is what is causing you to use a lot of swap? :)
<dstolfa>something probably needed a lot of memory to be paged in, what is it?
<joshua1>top process in htop is gnu/store/sanehsnatehant-guile-3.0.2
<joshua1>My guess is it's probably firefox. I bet if I close firefox things will smooth out.
<joshua1>just closed firefox. I just saw the CPU usage drop dramatically!
<joshua1>am I reading this right? "GiB Swap: 20.0/0.5" ?
<joshua1>Am I using 20 GB of swap?
<joshua1>df shows that my / is 89% full.
<drakonis> https://guix.gnu.org/manual/en/html_node/Networking-Services.html#index-WebSSH this one's a little weird
***yjftsjthsd7 is now known as yjftsjthsd
<Guest42>Hello, I am the one that posted the video of guix logging me out after a guix pull. I ran "guix pull 2>&1
<Guest42>"guix pull 2>&1 | tee guix_pull.log" and checked the output, but all it shows is that it attempts to download the files
<drakonis>hmm, okay so i've got a weird bug here where the guix daemon is looking at /nix
<drakonis>its outputting an error that isnt even in the codebase
<drakonis>in the guix daemon's source
<drakonis>this makes absolutely no sense
<drakonis>i have no idea why the build is trying to invoke the nix command
<drakonis>oh nevermind
<drakonis>this is just doom emacs being weird
<drakonis>carry on
<drakonis>ahhh its building again
<drakonis>will have it ready tomorrow
***samis is now known as CompanionCube
<solene>hello
<tissevert>hi guix
<solene>Please, could someone update https://guix.gnu.org/manual/en/guix.html#Submitting-Patches with information about adding copyright in a file? I didn't know it was required and I don't really understand why it's needed.
<efraim>whoops, I left mips64 there when I removed support
<tissevert>solene: I think this change would go to doc/contributing.texi in the main guix repository but I don't know we would go about translating the added string to other languages
<efraim>the translations are handled through weblate https://guix.gnu.org/manual/devel/en/html_node/Translating-Guix.html#Translating-Guix
<tissevert>but how does that interact with the code versioned in the repos ? are the various translations automatically generated by pulling from weblate while somehowe «interpreting» the versioned documentation ? I've seen translated versions directly in the repos, like contributing.de.texi
<efraim>They get translated in weblate and then manually synced back to the repository
<solene>to send a patch I use git format-patch HEAD~ and include the generate 000* file in a mail in my mail client, seems fine?
<vats>Hello. Would applying a manifest to a profile delete the packages not listed in the manifest (but were installed with guix package -i command)?
<nckx>Yes vats.
<nckx>solene: That's one fine way.
<tissevert>solene: that's what I did and it worked (assuming you have only one commit)
<solene>tissevert: HEAD~~~~ could work if you have more commits :P
<tissevert>exactly
<tissevert>or simply the hash of the commit from which you want to compare, to avoid off-by-one errors
<vats>I haven't been using a manifest. And now my current profile is polluted with outdated packages which guix gc is unable to clean. I can't update the profile because it's taking up most of the space in the root partition. I was wondering if I make another profile with a minimal manifest, and set it as current profile, would guix gc clean up all the packages from the previous profile (which are not in the current profile) from the store?
<tissevert>I think you'd need to first release hold of those packages by deleting previous generations of your profile to allow the gc to consider removing them, but yes
<vats>Thanks tissevert
<solene>what's the process to update patches in a package? I wanted to bump gnutls which fixes a new CVE but it has patches that doesn't apply anymore. I have no idea how to start working on the patch updates
<solene>on OpenBSD which I'm familiar with, I would extract the build, make changes and use "make update-patches" to regenerate patches from differences between files which has a .orig file and it automatigcally works :D
<vats>And...thanks nckx too.
<tissevert>vats: I may be confused but by «outdated packages», do you mean that you have several older versions of those large packages ?
<nckx>solene: That sounds fancy IIUC (the automatic diff differ upper?) and also like something we don't have. I just: extract the sources in /tmp, twice (rsync-x.y, rsync-x.y.orig), make changes in one, then cd /tmp && diff -Naur rsync-x.y* > the original patch and commit it together with the update.
<nckx>Low tech perhaps, but straightforward enough.
<vats>tissevert: yes.
<tissevert>well then you don't need to make yet another generation by using a manifest, you could start right away to delete old generations of your profile and check that guix gc frees space accordingly, or am I missing something ?
<nckx>vats: If you delete old profile generations (guix package -l) with guix package -d, otherwise they will all remain live and protected from GC.
<nckx>guix package -i and guix package -m both just create another new generation, neither delete older ones, that's separate.
<solene>nckx: I see ^^'
<vats>nckx: How do I delete all the packages of a profile? IIRC, cookbook mentions that deleting the symlink is enough to delete a profile. How do I proceed to delete the packages installed in that profile from the store?
<vats>tissevert: I have deleted all the old generations. There is something that depends on those packages in my profile, or the system packages.
<vats>I can't figure out how to find those dependencies.
<tissevert>ahhh, well if it's in the system, then yes I don't see any way to make guix gc delete them
<tissevert>(I suppose you have also skimmed through the old generations of the system ?)
<vats>Oh, I didn't think about generations of the system. Does that mean listing generations as the root user?
<tissevert>no, the guix system does that
<tissevert>*command
<vats>Let me look into guix system help. Thanks
<tissevert>I hope you don't have «user packages» from the root account ?
*nckx AFK sorry.
<vats>tissevert: nothing of substance as far as disk space goes.
<tissevert>just like guix package really, except it's not an option but a subcommand there : guix system (list|delete)-generations vs. guix package --(list|delete)-generations
<vats>Thanks
<vats>Okay, I do have many older generations around, need to clean them up. Thank you.
<vats>I'll be back in a short while.
***to-hu1 is now known as to-hu
<tissevert>starting to worry that vats crashed their system while cleaning their old generations
<pkill9_>guix is more of a platform than a distribution/OS, or a package manager
<paul_j>Morning all!
<solene>I updated gnutls to fix latest CVE however the guix refresh --list-dependent gnutls list is > 3000, following https://guix.gnu.org/manual/en/guix.html#Submitting-Patches I should commit it to core-updates branch which is merged twice a year, which is very stupid for security updates
<solene>what should I do?
*dstolfa makes a mental note to check back every so often to see what the answer to this question is
<solene>I'll just send it on master and see how it goes. It's a minor update
<PurpleSym>solene: Usually you’d cherry-pick the patch that fixes the CVE and graft the package on master.
<dstolfa>heh, i've just been reading this https://guix.gnu.org/manual/en/html_node/Security-Updates.html
<dstolfa>that's a pretty cool way to do it, i like it
<aocusr>where can i read about guix inner workigns ?
<pkill9_>aocusr: the source code and the docs
<pkill9_> https://guix.gnu.org/manual/en/guix.html https://git.savannah.gnu.org/cgit/guix.git/tree
<pkill9_>idk if there documentation on the inner workings much tbh
***bsima1 is now known as bsima
<mange>I just saw that magit has a new release, and I'm trying to use it with --with-commit=emacs-magit=v3.0.0 which works great. However, I also use emacs-magit-todos, and it complains about a conflict because it has emacs-magit as a propagated input and it's trying to bring in the Guix-packaged version of magit.
<mange>Is there some incantation I can use to be able to install both emacs-magit and emacs-magit-todos with magit version 3.0.0?
<mange>A specific command that fails for me: guix install emacs-magit emacs-magit-todos --with-commit=emacs-magit=v3.0.0
<ggg>Is it possible to use a macro inside the operating-system declaration? It seems like the record macro throws a syntax-violation as nested macros don't get expanded
<NieDzejkob_>(operating-system (my-macro)) won't work, but (operating-system (some-field (my-macro))) should
<ggg>That sucks, I was trying to make a "prepend" macro to add values to fields cleanly. Something like (prepend packages curl wget) instead of having to mess around with cons* and getting the current value
***betelgeuse6 is now known as betelgeuse
<apteryx>is --with-source=package=some-https-url supposed to be cached, or is it expected to always fetch the archive anew from the network?
<civodul>apteryx: hi! it always fetches anew
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, wingo says: that shepherd bug looks interesting :) surely a problem with 8b994be59fc4d9d23d8fad546deca3dbb2d29df7 somehow
<civodul>it can't cache because it doesn't know what it's gonna get
<civodul>source is like a box of chocolate
<civodul>(--with-git-url & co. cache a checkout of the repo, but the repo contents still get copied to the store every time)
<zap>hello guix!
<zap>Is it okay to set 'guix channel to local guix checkout?
<zap>I'll need to "make authenticate" and use --disable-authentication this way
<vats>tissevert: Aww, thanks for caring enough. No, I didn't crash my system. I cleared up 7GB of obsolete packages. Got a total of 15GB freed and left my system to build the manifest I generated from the current ephemeral profile. It's still building stuff.
***attila_lendvai is now known as attila_lendvai_
***attila_lendvai_ is now known as attila_lendvai
<tissevert>vats: that's great news !
<vats>Yeah
<vats>Finally sorting out the mess my system has become.
<tissevert>: )
<GNUtoo>Hi, is it possible to use guix to produce some ARM toolchain?
<GNUtoo>For instance if I want to build an ARM static binary, and that I've a Makefile, is it possible to get a toolchain that does that by using guix package -s ?
<GNUtoo>Or do I need to write an scm for the package to build?
<GNUtoo>s/package/software/
<zap>GNUtoo: are you looking for gcc-toolchain package?
<GNUtoo>Something like that yes, but for a cross target
<GNUtoo>Basically it's for building a userspace program with 0 dependencies
<zap>maybe arm-none-eabi-toolchain?
<GNUtoo>the issue there is the -none
<GNUtoo>It's for building an userspace program, so the -none won't work
<GNUtoo>Unless I'm mistaken on what that does
<GNUtoo>(which is also possible)
<GNUtoo>I need something with a libc
<GNUtoo>toolchains without libc can still build things like u-boot and Linux as they have their own replacements for the standard lib functions as far as I understand
<GNUtoo>But for instance printf won't work without a libc
<GNUtoo>It probably needs some code too for the crt0.S and similar setup code to run the binary in systems with a Linux kernel
<GNUtoo>arm-none-* uses newlib@3.0.0-0.3ccfb40, so it looks fine for u-boot linux and microcontrollers but not for userspace
<zap>GNUtoo: ha, I cant help you with this then :) Seems like I've touched thesese things very long time ago
<GNUtoo>The idea in my case is to have fast tunrnaround times for testing, and given that the code is quite self contained, I probably can use glibc even if static linking is not officially supported
<GNUtoo>The other option is to build that code in Android so that's kind of slow
<GNUtoo>ok, thanks anyway, it probably means that there is no standard package for that and that I probably need some more advanced tricks to get that
<GNUtoo>like using guix build to build a cross toolchain and reusing the toolchain somehow (with PATH for instance)
<GNUtoo>I could try with hello
*GNUtoo tries guix build --target=arm-linux-gnueabihf hello
<GNUtoo>though I'm unsure how to find the compiler for that
<GNUtoo>ah it gives a derivation, and I can grep it in the .drv in /gnu/store
<GNUtoo>so I'll probably find it in this way
<soheil>Hello!!
<GNUtoo>Hi
<GNUtoo>Though for some reasons I don't find it
<GNUtoo>$(guix build --target=arm-linux-gnueabihf hello) -> 14wsng24qaj4xi882h1z2ia70h4dv2mk-hello-2.10.drv -> /gnu/store/5kqv5dal13b45ngdh1jr949fvxxc9snb-gcc-cross-arm-linux-gnueabihf-7.5.0.drv
<GNUtoo>With the command I've a path, which I grep and gives me the first drv, and I grep for gcc and it gives me the third drv
<GNUtoo>which has ("out","/gnu/store/6qx8iqqsx9qcx832q5fb3vvw3syxvn1a-gcc-cross-arm-linux-gnueabihf-7.5.0")]
<mothacehe>GNUtoo: to use the same cross compiler you can: "guix build --target=arm-linux-gnueabihf hello -K --check" then "cd /tmp/guix-build-hello-2.10.drv-0" and ". environment-variables"
<GNUtoo>but I've ls: cannot access '/gnu/store/6qx8iqqsx9qcx832q5fb3vvw3syxvn1a-gcc-cross-arm-linux-gnueabihf-7.5.0': No such file or directory
<mothacehe>you can then run arm-linux-gnueabihf-gcc
<GNUtoo>Thanks I'll try that
<GNUtoo>Wow -K looks really nice
*GNUtoo has been using crazy tricks to get the build directories
<mothacehe>this is a hack though, we should provide a way to create such an environment in a more controlled way
<GNUtoo>What is strange is that "ls /gnu/store/*/bin/*arm-linux-gnueabihf*" doesn't find the compiler, I've only binutils and some sans-libc versions of gcc
<GNUtoo>Though I've a binary that does run on my host through qemu
<mothacehe>i have it under /gnu/store/xxx-gcc-cross-arm-linuxgnueabihh-7.5.0/bin/arm-linux-gnueabihf-gcc
<GNUtoo>That's indeed where it's supposed to be but I've only /gnu/store/mnj8h01b4r7151irmpzzpdq40d5j1nna-gcc-cross-arm-linux-gnueabihf-7.5.0-lib
<mothacehe>look in /tmp/guix-build-hello-2.10.drv-0/environment-variables
<GNUtoo>with only libraries inside AFAIK
<GNUtoo>ok, I've to finish for the toolchain to complete the rebuild (--check)
<mothacehe>you should have PATH=<compiler-path>\
<mothacehe>the rest
<apteryx>civodul: OK, thanks for the info :-)
<GNUtoo>btw, thanks for the help
<mothacehe>yw :)
<GNUtoo>Ahh maybe what could have happened is that guix gc could have removed the toolchain while keeping the hello binary....
<GNUtoo>That would make sense
<GNUtoo>So when I "rebuilt" it with the command I used first, it just pointed me to the result (after some computation for other things like computing the drv and so on)
<mothacehe>if the guix build command downloaded a substitute for the cross-compiled hello package, the cross toolchain probably never made its way to your machine
<GNUtoo>And the --check probably will yield me a working toolchain
<GNUtoo>oh ok
*GNUtoo didn't think there were substitutes for that
<mothacehe>with --check you are forcing the build to happen locally hence the cross toolchain download
<GNUtoo>(When I tried more obscure targets like mingw (too see how capable was Guix) there were no substitute)
<mothacehe>You can have a look to the (gnu ci) file for more details
<mothacehe>in particular the %cross-targets variable
<GNUtoo>Thanks
*mothacehe has to go!
<mothacehe>bye
<solene>bye
<GNUtoo>That's probably where I found the list indeed
<GNUtoo>I even tried to add armv4t but my hello binary ended up doing illegal instructions...
<GNUtoo>So adding a new cross target is probably way more work than adding a new tripplet for things like armv4t
<solene>I don't understand why guix build synapse triggered a whole build involving llvm... instead of downloading derivations
<GNUtoo>Things like that happens, and I'm unsure why,
<GNUtoo>It could be because thre are no upstream build for the llvm you want to use
<GNUtoo>As I understand things improved somewhat recently with substitute availability by changing the architecture of the software used by the builders,
<GNUtoo>And it might be possible to check that somehow in theses builders as there is probably some public web interface to monitor what they do
<GNUtoo>Another option would be that for some reason your guix daemon comupted a different derivation than what there is in the builder(s)
<GNUtoo>Or maybe the builds could also fail for some reasons
<GNUtoo>solene: https://ci.guix.gnu.org/ might have some clue
<GNUtoo>As for llvm specifically I had the issue when using older versions of llvm
<GNUtoo>I mistakenly fixed the version, so I updated guix and so the dependencies changed and I cound't use prebuilts anymore because the builders didn't build older llvm for new dependencies
<GNUtoo>So I did something like that to fix my issue (which could be different from yours):
<GNUtoo>- ("clang" ,clang-10)))
<GNUtoo>+ ("clang" ,clang)))
<solene>I prefer not to tweak much before I know what I'm doing =)
<solene>it's building since hours so I don't know what hapened at first
<solene>I wonder where those logs are
<bone-baboon>Maybe this would be useful for #guix@Libera and #guix@Freenode. Parabola is using bridging bots to bridge between Libera and Freenode. <https://git.parabola.nu/~bill-auger/bridgin.git> (AGPLv3). libera-bot is relaying messages from #parabola@Libera to #parabola@Freenode. freenode-bot is relaying messages from #parabola@Freenode to #parabola@Libera.
<bone-baboon>One small downside of the bots relaying messages that I have noticed is that I can not tab complete a username for a someone who is only on Libera if I am only on Freenode or vice versa. My IRC client is not aware of user on the other network. However the IRC client I am currently using is Circe an Emacs IRC client so I can use `dabbrev-expand` with `M-/` to expand their username. So that is not problem for me. I would expect other IRC
<bone-baboon>clients also have some kind of auto completion capabilites.
<GNUtoo>solene: Since guix can be used for a lot of things, I can't really tell if it makes sense or not for you
<GNUtoo>In the case I described above I used guix for building a library I'm working on with different compilers to check if it built fine before pushing commits
<GNUtoo>So that diff came from the guix.scm I used to do that
<GNUtoo>(so it's not part of guix)
<GNUtoo>And for the record that library is not generaly useful yet to be in guix since it still depends on smartphones vendor kernels (I'm actually working to fix that)
<GNUtoo>bone-baboon: I applied for #replicant probably 4 or 5 days ago but I only got an automatic response, do you know how much time it took for #guix and #parabola ?
<aocusr>gnutoo: i use docker for that
<GNUtoo>In my case it was just to do compilation tests
<GNUtoo>Runtime tests are done along the way with make check but I can't test much on my computer as it requires a specific modem to test it
<GNUtoo>Docker looks nice though
<bone-baboon>GNUtoo: I am not sure what your question is. #replicant is in the alis output for both Freenode and Libera. I think volunteers for all the free and open source software focused IRC network currently have an increased number of support requests right now so that could explain the delay in response.
<GNUtoo>ok
*GNUtoo hopes that people will not forget about the migation because of that
*GNUtoo will certainly try to help channels migrating when he can
<stikonas>are there still things happening on #guix@Freenode? I thought everybody had switched
<civodul>i think #guix has Officially Switched™
<solene>using a bridge would be harmful IMO
<GNUtoo>stikonas: yes, when you joint, there is a message that tells you that everybody has switched to this channel at libera.chat and there are probably 4 people left
<GNUtoo>*join
<bone-baboon>stikonas: I am not sure about the activity in #guix@Freenode. `/names` on #guix@Freenode outputs a list that I would estimate roughly at 200 names.
<tversteeg>Is there a way to see what files are installed as part of a package, similar to `dpkg --listfiles ..`?
<stikonas>well, number of names is not necesserily important, some people might linger there for a while
<solene>tversteeg: find /gnu/store/$package/ , I'm not sure there is something integrated to guix... :(
<tversteeg>But that assumes I'm looking for a specific thing which I know the name of, I want to see a list :)
<stikonas>tversteeg: you can get the list too... Just run find /gnu/store/*$package/
<tversteeg>That works, thanks!
*apteryx is seeking feedback on https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41625#20, which handles a potential EOF during offloading.
***Server sets mode: +Ccntz
<tissevert>tversteeg: depending on whether the package you're considering is for a given binary util or library package, etc., it's usually possible to retriev the precise hash of the version you're interested in
<tissevert>for instance if it's a binary, readlink `which <some-tool-in-PATH>` will show you where it is in the store
<tissevert>it'll point to a file one directory too deep (in the bin/ subdirectory), but you'll be able to see the parent directory which is what you're looking for
<solene>readlink `which <some-tool-in-PATH>` | cut -d '/' -f 1-4
<aocusr>how is a hash of a package calculated ?
<tissevert>yeah, it can of course be automated like solene suggests
<tissevert>and this applies to other things than binary provided you do something else than «which»: to find what's installed in the ghc-xmonad-contrib
<tissevert>I would echo $GHC_PACKAGE_PATH, find this particular package to be available at /run/current-system/profile/lib/ghc-8.6.5/ghc-xmonad-contrib-0.16.conf.d and then readlink that
<tissevert>aocusr: I have no idea ^^ but I think cbaines has some good resources on that
<tissevert>c.f. https://www.cbaines.net/projects/guix/freenode-live-2017/presentation/#/
<bone-baboon>solene: Based on stikonas point about use I do not know if a bridge between #guix@Libera and #guix@Freenode is needed. However I am currious why you think bridging #guix@Libera and #guix@Freenode would be harmful.
<stikonas>well, it can be harmful if there is spam...
<tissevert>first it requires us to be present at 2 places and moderate both of them
<bone-baboon>Okay
<tissevert>then, we moved out from Freenode out of security concerns about the handling of data, based on insights from the then-fleeing admin team, so letting people interact with us from Freenode would lure them into believing they'll have the same experience, safe on a personal-data level
<tissevert>which I think is currently harder to assume on Freenode than on Libera, hence the change
<aocusr>which security concerns ?!? it's irc
<dstolfa>aocusr: hostile takeover of accounts, servers, etc
<tissevert>IRC has email adress, ok, not big but still annoying for people who can't create temporary adresses at will, but also private conversations
<dstolfa>just because it's not end to end encrypted, it doesn't mean that you can't have levels of trustworthiness in between
<dstolfa>i trust libera admins that i personally know to not take over people's accounts. i can't say the same about freenode anymore.
<solene>bone-baboon: there are no direct threats but it adds maintenance, a SPOF, the bridge has to be trusted, you can't trust people from the other side, it brings really litle benefit to use a bridge, people will appear as "bridge_user: solene: hello!"
<solene>keeping the community split by using a bridge doesn't help IMO
<dstolfa>agreed solene
<solene>switching IRC server is like modifying 2 lines in your configuration file of the client
<solene>as many projects are moving to many servers, people will have to deal with multiples servers in their clients anyway
<solene>this is good against centralization
<bone-baboon>dstolfa: It would be nice not to have to trust a central administration of an IRC network to be benevolent. I explored peer to peer and federated IRC alternatives and shared my findings in this thread. <https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00339.html>
<dstolfa>bone-baboon: i mean you're convincing the wrong person, i'm a strong believer of end to end encryption and decentralized internet
<bone-baboon>Thank you for the comments explaining the down sides of bridging IRC networks.
<lfam>I think a lot of us already were on multiple networks, since OFTC hosts a lot of major projects
<solene>bone-baboon: SSB isn't meant for the kind of use, IPFS doesn't handle messaging, Jami could work, retroshare is unreliable and hyper bloated and most distribution I know can't keep it up to date because it's a huge mess
<solene>xmpp or matrix would make sense as an IRC replacement
<dstolfa>+1 for XMPP, +0.5 for matrix just because element is hot garbage at the moment
<dstolfa>matrix itself is fine, i just wish there were better clients
<drakonis>you can use weechat-matrix or another cli client
<solene>the servers are not really mature yet though
<drakonis>or nheko maybe
<dstolfa>drakonis: you "can", but it's not that easy if you want full support for end to end encryption in rooms and cross-homeserver things
<dstolfa>i've tried... didn't go too well
<drakonis>ah, alright.
<dstolfa>solene: i haven't noticed any issues with the server, but then again my matrix homeserver isn't very big
<dstolfa>there's going to be a MirageOS-based matrix server released soon, maybe that'll be a bit more stable than the python thing they have now
<solene>dstolfa: it receives updates very very often IMO, which mean it's not really stable yet, the data size grow very fast and doesn't know how to automatically clean/purge/prune old data
<dstolfa>solene: ah yes...
<dstolfa>my matrix homeserver vm has a very "pretty" crontab for this very thing solene
<bone-baboon>solene: What did you mean by "you can't trust people from the other side" of a bridge?
<dstolfa>they probably meant that freenode is controlled by a person who has taken over at least one channel so far, so who's to say that it's really them? not to mention how many people dropped their accounts on freenode that can be taken over by anyone at this point
<solene>dstolfa: irc is bad at trust, but for people in a single channel you could at least have an idea if that's the real person you know (registered, always there etc..) but with a bridge you would need to be on the other side
<solene>look, I could connect to freenode and name myself bone-baboon and speak
<dstolfa>yeah... that too :). i guess the channel could be "registered users only", but even then with how many people dropped their accounts, it means nothing
*lfam prepares nginx update
<lfam>Uses the handy `make check-system TESTS=nginx`
<bone-baboon>solene: Thanks for explaining that. `/msg nickserv set enforce on` does not solve that because it is opt in.
<bone-baboon>dstolfa: Thanks
<solene>that would be nice to have something like that for guix: https://cachix.org/ , everytime someone build a new derivation it could be uploaded in a central server and people could reuse it. That would be opt-in for use. Because of challenges it could be possible to regularly test contributors
<solene>that would save CPU time
<lfam>Any reuse of built artifacts is worth pursuing
<lfam>Trust is a problem
<solene>how do you manage version number when you need to add a patch to a non changing version?
<lfam>For gnutls?
<lfam>solene ^
<nckx>bone-baboon: There isn't any conversation in Freenode's #guix to bridge, anyway. /names aren't meaningful.
<lfam>solene: In general, you don't do anything regarding the version number when adding a patch. The commit I linked to for graphviz can be used as an example
<nckx>solene: You don't. Just keep it.
<solene>lfam: no, for lz4
<bone-baboon>nckx: Thanks
<lfam>Anyways, it's likely the same. If you are adding a patch file to a package's source, you don't change the version number
<solene>ok
<lfam>The only time we do special things with version numbers is when we have to update a package for a graft, and the new version number is a different length. The store path must be the same length when grafting
<lfam>Take a look at a9f84f93b45db712b3bd30943361a267cb85cf79 (libx11 security update) for the standard solution
<lfam>(We truncate the version and add the letter 'A')
<solene>oh, fine
<lfam>I have to go
<lfam>I'll be around later
<lfam>Thanks for working on these things!
<nckx>solene: A Guix version change always reflects an upstream update. We don't do ‘revbumps’ &c. like some other distributions.
<solene>nckx: unfortunately it's still not upstream but a pending merge request not merged contains a fix for a CVE in lz4 that is already deployed in many OS
<nckx>That also applies to the Guix-specific ‘revision’ used in some packages built from Git: it still represents an upstream bump, it's not incremented when you e.g. fix a phase.
<nckx>solene: Thanks for taking care of it.
<nckx>So no, no version change.
<solene>nckx: I'm only looking at backported OpenBSD security updates for now ^^'
<solene>is there such thing as /etc/security/limits.conf on guix?
<solene>I'd propose to use it to give a nice 20 to guixbuilder users, that wouldn't reduce the build speed but would make the system more usable while building
<dstolfa>haven't checked, but maybe in $GUIX_PROFILE/etc/security/limits.conf?
<solene>maybe not 20 but 5 or 10 could be good enough
<solene>dstolfa: nothing there :(
<dstolfa>no clue then, sorry :(
<drakonis>hmmm
<nckx>solene: Yes, the pam-limits-service-type creates that file on Guix.
<nckx>Why not ‘just’ renice the daemon?
<solene>nckx: you would have to always renice it, if you use limits.conf that would be a default for everything spawned by those users
<nckx>Not manually.
<solene>oh ?
<nckx>Why not start the daemon with nice 19? (20 is not a thing, but maybe it is on BSD 😉)
<solene>nckx: it could be started with nice 5 or 10, that would allow to use nice > 10 for even less priority processes
<solene>where would you change that setting? I'm curious ^^
<nckx>This reminds me of Paludis's ‘Rationale: Learn how to use nice. There's no GCC_NICENESS or VIM_NICENESS either.’, but Guix makes it impossible to just ‘nice guix build foo’ that it doesn't really apply.
<nckx>solene: There is no setting for it.
<nckx>It was just an idea.
<nckx>An alternative to using limits.conf to do effectively the same thing.
<solene>I've set the pam limit, I'm waiting for a build to finish to restart the builders, I'm curious ^^
<nckx>So'm I. If it works, we should document it (or cook it in the book).
<solene>I was thinking at proposing it as a default :P
<solene>gaaah, mysql tests take forever
<solene>this didn't work as expected
<solene> https://pastebin.com/HpMKFZj9 that looks fine right?
<solene>oh, it seems guix system reconfigure failed and I didn't notice
<solene>nope, doesn't work. #sadness
<solene>interesting, I used * 'priority 10 to set the nice level to 10 for EVERYONE, it works for my user but builders are still at 0
<solene>so, I guess there is something hidden :D
<nckx>(Paste deleted upon my return but was probably not relevant anymore?)
<solene>nckx: paste still fine here
<nckx>Weird, refreshing worked.
<nckx>Thanks for the hint.
<solene>I don't really understand how the pam limit works. If i use dd if=/dev/zero | gzip -f -c > /dev/null it's correctly niced to 10
<solene>but if I ssh to my own account locally and do dd if=/dev/zero | gzip -f -c > /dev/null, it's not niced to 10 but has a normal nice 0
<nckx>solene: I was thinking about this while AFK, and I don't think this approach will work for you anyway. limits.conf isn't some universal thing, it's specific to the PAM log-in framework, and PID 1 doesn't start after you log in. Nor do build users log in.
<solene>:/
<nckx>Completely separate: it's weird that SSH isn't using PAM though. It can. Maybe we're missing a bit.
<nckx>...we set ‘UsePAM yes’ in sshd_config...
<nckx>I'm not qualified to speculate.
<solene>cbaines: do you think this would be possible to add a --nice parameter to the guix build-daemon? that could be configured from config.scm, the idea would be to run the builders with a high nice level than the user to reduce the impact of a compilation load over a laptop/interactive workstation
<solene>I see you contribute to https://git.cbaines.net/guix/build-coordinator/ and it seems the right place for such things ^^'
<cbaines>solene, the guix-build-coordinator is quite different from the guix-daemon, which is what's actually performing the builds at the moment
<cbaines>regardless, I'd like to see some potential convergance in features, and features like being able to set niceness
<cbaines>part of why the guix-build-coordinator exists though is that the guix-daemon is harder to hack on, at least that's my perception
<raghavgururajan>Hello Guix!
<nckx>Hi Raghav and Bumblehorse.
<Bumblehorse>Hello
<Bumblehorse>When I remove the gdm service and replace it with slim, I loose most of my gtk icons. Every button in nicotine+ is a picture of black monitor. Would anyone know how to fix this?
<raghavgururajan>Bumblehorse: Perhaps add hicolor-icon-theme, adwaita-icon-theme and dconf in config.scm?
<Bumblehorse>adwaita-icon-theme fixed it, atleast for nicotine
<Bumblehorse>thank you
<Bumblehorse>Does this deserve a bug report?
<raghavgururajan>Bumblehorse: the gnome meta-package should be propagating those things.
<raghavgururajan>If you don't use gnome-desktop-service-type, then you would have to add those 3 packages manually in your config.scm.
<Bumblehorse>I see
***iskarian is now known as Guest2927
<ss2>hello
<drakonis>hi
<ss2>I'm reinstalling my system again, and have selected btrfs partitioning. The only problem now is, that the installer fails while selecting btrfs
<ss2>just downloading the latest build, and will see if this happens again.
<lfam>How does it fail?
<ss2>with a long error message. Just rebooted. How can I store this error message?
<lfam>I guess you could photograph the screen
<ss2>will do. Preparing the installer.
<ss2>so, where to post?
<lfam>Wherever you like
<ss2>mtp://Android_Android_R28F40C20TV/Internal%20shared%20storage/DCIM/Camera/IMG_20210525_213317.jpg
<ss2>ups, wron
<ss2>g
<ss2> http://0x0.st/-ehN.jpg && http://0x0.st/-ehq.jpg
<ss2>better now.
<ss2>so, this is after selecting Btrfs.
<lfam>Hm, hopefully somebody can debug it
<ss2>and this is coming from the latest build: mtp://Android_Android_R28F40C20TV/Internal%20shared%20storage/DCIM/Camera/IMG_20210525_213317.jpg
<Bumblehorse>Sorry to interupt but does anyone know why guix system reconfigure tells me that that sddm-service-type is unbound even though I am using the (gnu services xorg) module?
<ss2>not again.. sorry about this. Copypasta is failing me at the moment.
<ss2>another try: the latest build I'm trying is 4y1j755gzrmvgqly49q7m51z9qglpxk2
<ss2>I'll just go back to good old ext4
<drakonis>so i'm trying a hurd vm now
<lfam>Bumblehorse: sddm-service-type is from (gnu services sddm), not (gnu services xorg)
<ss2> oh.. this isn't about the installer. Even ext4 is failing.
<lfam>:(
<lfam>Did you use the automatic partitioning? Or manual?
<drakonis>wonder if it might be your own hardware?
<ss2>manual
<lfam>I wonder if it's working as expected
<lfam>You might have set it up incorrectly, idk
<drakonis>wrong uuid?
<lfam>Yeah, something like that
<drakonis>you cant actually copy mtp things into irc
<ss2>no, this is the root partition, which I prepartitioned, and then select. This I've done this more often that I should be doing lately.
<Bumblehorse>lfam: thank you it worked, but I don't think that is in the manual
<ss2>drakonis: that was my kill ring I incorrectly used.
<Bumblehorse>atleast not when I access it via emacs
<nckx>Bumblehorse: See ‘guix system search’ in (guix)Invoking guix system.
<nckx>→ location: gnu/services/sddm.scm:310:2
***lukedashjr is now known as luke-jr
<Bumblehorse>nckx: so every one of those scheme files is its own (gnu services MODULE)?
<nckx>Yep.
<nckx>Like gnu/packages. Guile modules are named after their location, or located after their name, whatever you prefer. They must match.
<Bumblehorse>It was just confusing because the sddm service is under "X Window" in the manual and it at the top it says to use (gnu services xorg) for X window support with no mention of any other modules like the sddm one.
<Bumblehorse>gdm and slim both being in the xorg modules but not sddm made it even more confusing
<Bumblehorse>thanks anyways, I will go restart and see what sddm is like
<drakonis>sweet i got a new user :V
<ss2>I really wonder why the installer is failing. I went down to the previous rc1, which failed as well. Having to resort to installing Debian, unfortunately. :/
<ss2>And I did install the same machine with rc1 just recently.
<lfam>You should verify that the disk is partition as you expect
<nckx>Can you not install manually, ss2? The installer's helpfulness comes at a very high complexity cost.
<ss2>I haven't done this yet. Just completing Debian ^^
<ss2>might brake it off. Don't want to go there.
<ss2>lfam: what do you mean? as in selecting the correct partition?
<ss2>there aren't many to choose from on it.
<lfam>Is the disk actually partitioned in the way that your config.scm expects? Are the UUIDs correct?
<lfam>Things like that
<lfam>Since you partitioned manually, it's possible that you made a mistake
<ss2>I never get to the config.scm, It fails right after saying, "yes, I want to continue partitioning my disk"
<ss2>or so.
<ss2>sorry, then I wasn't clear about where it failed.
<ss2>and I tried it with letting the installer format the partition -- without success.
<nckx>Did you ever post a screenshot? I was out a while, but the last link I saw from you was to your telephone on your LAN :)
<drakonis>are you kde or something :V?
<drakonis>on kde?
<ss2>nckx: shortly before, I posted /valid/ links around 21:39
<ss2>drakonis: sorry?
<nckx>Well that error message is suboptimal.
<ss2>I left kde behind a long time ago. ;)
<ss2>well, not that long actually.
<civodul>nckx: howdy! we have homework: approving the purchase of a Honeycomb LX2 board :-)
<civodul>(i just replied by email)
<nckx>I only saw a ‘what to buy’ thread.
<nckx>...and it is in the ‘what to buy thread’.
<nckx>I wouldn't have read that otherwise JSYK.
<nckx>ss2: I doubt it will contain anything obvious, but could you share the output of sfdisk -d /dev/sda ?
<ss2>in a sec: backing up!
<rekado>nckx, civodul Sorry about burying my request in that thread. I did put the financing alias address in Cc, but I guess that doesn’t make filtering for emails like that easier.
<solene>cbaines: I get the idea
<solene>good night everyone, I had a happy day hacking on Guix :-)
<nckx>rekado: Not in the follow-up with the final price, but I didn't mean that you did anything wrong.
<nckx>Night solene.
<jorge-58>Saludos,no puedo superar este problema guix pull:error git: error inflating zlib stream
<ss2>nckx: what is it you're hoping to see from this output? Could it be that some tables are not updated after partitioning?
<drakonis>we need international channels dont we?
<rekado>drakonis: this /is/ the international channel
<drakonis>apologies
<drakonis>i meant language specific channels
<drakonis>my spanish is very rusty atm
<rekado>eventually, perhaps. But so far our strategy has been to just see how it goes.
<drakonis>jorge-58: try using guix pull again
<cbaines>rekado, regarding the Honeycomb machines, do you know when they might arrive?
<rekado>no
<rekado>I haven’t heard from Solidrun yet.
<rekado>I got the order confirmation, but nothing beyond that.
<cbaines>Ok
<nckx>ss2: For now I hope something will jump out at me.
<nckx>rtorrent: error while loading shared libraries: libtorrent.so.21: cannot open shared object file: No such file or directory
<nckx>That's not good, Guixwise.
<ss2>okay, can't reboot quite yet.
<civodul>rekado: yup, np! i was lagging behind on the guix-sysadmin folder
<civodul>now i've spammed y'all
<civodul>cbaines: should we consider a blog post to introduce Canan, the Outreachy intern?
<civodul>(is Canan on this channel?)
<cbaines>civodul, I think that's a good idea
<cbaines>I think they have been on IRC, but I can't remember their nick/don't know if they're online now
<nckx>...I think I got my libtorrent from a certain substitute server that boycotts /lib directories in store outputs.
<nckx>Yep, that's it.
<civodul>cbaines: coolio; i'm happy to review or give a hand when you think is a good time
<civodul>nckx: uh, sounds like an interesting feature
<nckx>(It was guix.cbaines.net, which isn't advertised as the bestest substitute server everyone should use, so that's OK.)
<cbaines>nckx, I'm not sure the issues with some store items can be described as boycotting /lib directories, I mostly observed onlying including doc directories
<ss2>nckx: can we carry on tomorrow? It's getting a bit late and need to catch up a bit. Thanks for your help still.
<cbaines>anyway, those spoiled outputs are mostly why I've stopped it serving substitutes, that and getting something better setup around bayfront seems quite close
<nckx>cbaines: include and lib are missing, only share is present.
<nckx>It's so similar that I'm going to blame you and not investigate.
<nckx>😛
<nckx>ss2: Sure. Don't get your hopes up. Debugging this kind of thing remotely is very inefficient.
<nckx>But I can try to reproduce it if you keep things untouched.
<cbaines>on the subject of substitutes, I want to sort out more of the configuration this week
<cbaines>there was discussion of naming in https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00332.html
<cbaines>I was going to use bordeaux.guix.gnu.org as a working name until someone suggests something better, but I don't know if you have any thoughts civodul, nckx ?
<civodul>cbaines: "bordeaux" sounds good to me!
<civodul>(and sorry for not following up!)
<nckx>cbaines: That name's fine. I don't think it needs to be future-proof. Most people use the defaults, those that don't, care, and will notice the error messages after a while.
<nckx>(‘guix substitute: warning: bordeaux.guix.gnu.org: connection failed: Connection refused’ on every operation.)
<cbaines>Great, I'll try to make some progress with getting things configured over the next few days :)