IRC channel logs


back to list of logs

***modula is now known as defaultxr
<rekado_>Fare: I have a Brother HL-L2370DN laser printer.
<str1ngs>I have a L2550D :)
<podiki[m]>I'm failing at a simple substitute, why is it telling me there is an invalid preceding regular expression for
<podiki[m]>(substitute* ""
<podiki[m]> (("plugindir=${rofi_PLUGIN_INSTALL_DIR}/")
<podiki[m]> "plugindir=${libdir}/rofi/"))
<podiki[m]>trying to replace a line in a makefile
<cbaines>substitute* works with regular expressions
<cbaines>it looks like you're going to need to escape some of the characters in the line you're trying to replace
<podiki[m]>I tried escaping the $ and / with \s, but then guix does nothing (literally, the guix build command just goes back to my prompt)
<cbaines>well, that's probably still less wrong
<cbaines>note that you'll need to escape the \'s when they're in a Guile string
<cbaines>so \$ becomes \\$
<podiki[m]>(could have sworn I saw similar substitute lines elsewhere, but let me try)
<podiki[m]>hooray. \ to $, {, }, and /
<iskarian>only in the first string, mind
<podiki[m]>yeah, first string
<podiki[m]>really thought I saw subs not escaping some of those characters, but must have been me
<the_tubular>Noisytoot don't discourage yourself I know patches can get hanged for a few weeks but it's worth it :)
<muradm>guix environment --ad-hoc weston: problems: a) builds localy b) fails to build localy
<Noisytoot>how can it both build and fail to build?
<muradm>a) i would expect it come prebuilt from substitute b) although not coming prebuilt, it fails to build localy
<muradm>some tests fail
<str1ngs>muradm that could explain why there is no substitute
<bmk>Okay: I've been trying to do this for a while: But how the HELL do I add a polkit rule?
<muradm>strlngs, probably
<muradm> testlog.txt
<bmk>Specifically, the rules for udiskie, but the function for the polkit service doesn't have any documented arguments
<bmk>I've managed to create a file and link it from the store, but I can't figure out how to give it the right permissions?
<bmk>using "extra-special-file" which I just love the name of
***Noisytoot_ is now known as Noisytoot
<Fare>rekado, str1ngs and you just use one of the provided menu entries from brlaser in CUPS?
<the_tubular>How would I mount something with sshfs using my config.scm ?
<bricewge>the_tubular: I would wrote a shepherd service for that.
<the_tubular>Is there any example I could take a look at if I'm a scheme newb ?
<bricewge>Personnaly, most of the time, mounting sshfs should only be accessed by a single user so I would wrote a user shepherd service instead (so not in config.scm, at least not until "guix home")
<the_tubular>Could I just use the "file-system" part of my config.scm ?
<the_tubular>There's just 1 user on this machine so it shouldn't matter
<bricewge>I'm quite sure it doesn't support sshfs
<bricewge>As sshfs mounts is usually user specific, not to be used system-wide
<the_tubular>Go it
<the_tubular>I'll need an example though :/
<bricewge>For a system service ?
<bricewge>(gnu services sysctl)
<the_tubular>Yeah, well one that mounts sshfs
<the_tubular>This doesn't mount anything though
<bricewge>I don't think there is one specific for sshfs, otherwise I would I've shared it whith you already
<the_tubular>I'm but a shceme noob, I barely can read what you sent above :/
<kitzman>is it possible to supply a profile as an input to a package? i.e: (profile-derivation (packages->manifest ...)). the reason i want to do this, is because some includes do not get picked up by cmake, and if i run an environment, then the only include path is the one in the profile
<kitzman>(and building it in that environment works)
<iskarian>kitzman, even if you could, that's almost certainly not what you want to do
<iskarian>are the includes in the correct search path?
<leoprikler>kitzman: it's quite likely that building does not work due to a separate issue, but for stuff that assumes the same include path for separated packages, look at procedures like sdl-union
<iskarian>(you can inspect the 'environment-variables' file in the build directory if you build with -K)
<iskarian>Hmmm... why the heck does touching go-build-system's 'lower' cause a world rebuild???
<the_tubular>I really wish there was a guix wiki...
<bricewge>The equivalent is the cookbook
<bricewge>You can also search the logs or all the mailing lists
<the_tubular>Yeah, I know about the cookbook, but I feel it's very "guix-centric" and once your a little bit off the beaten path then there 0 documentation on what I want to do
<the_tubular>I had to deal with the same exact thing with ZFS
<the_tubular>I've probably been spoiled with Gentoo's wiki, but I think it's a gold standard... Scraping IRC logs and Mailing list to get SSHFS working isn't the most "user-friendly" way of doing it
<kitzman>leoprikler: thank you that solved the issue; i saw qt packages not needing this, but now the package is free of qt errors
<bricewge>the_tubular: I feel you, unfortunatly Guix isn't as "mainstream" as Gentoo
<bricewge>It seems the crux of your issue with sshfs is the same as issue
<avp>FWIW, it seems that returns SSL_ERROR_BAD_CERT_DOMAIN
<the_tubular>True, I wish more people knew about guix :/
<the_tubular>It still a fairly young project, so I hope it's going to pick up steam
<bricewge>avp: This domain isn't used anymore, try
<avp>bricewge: Okay, I didn't know that.
<bricewge>avp: There are some remains about it. probably the dns entry should be dropped or redirecting correctly to
<bricewge>Here is the "depreciation notice"
***csantosb` is now known as csantosb
***csantosb is now known as Guest7817
<leoprikler>raghavgururajan: is there any movement on the gnome stuff? the last commit I see dates back to march
<raghavgururajan>leoprikler: Not much, have been caught up with some stuff.
<raghavgururajan>Trying to consolidate.
*raghavgururajan plans to make atleast one update in gnome, before Monday, to keep the ball moving.
<leoprikler>okay, then I didn't miss anything
<raghavgururajan>leoprikler: I haven't gotten back into gtk4 yet. If you are available for today and tomorrow, I could use your help. :)
<leoprikler>I can't verify any build-related things, but I'm always here for static analysis
<affe2626>whops wrong window
<ArneBab>I’m thinking about building some packages locally with -march=native (because that can give a 10% speed gain for some tools (specifically imagemagick). Is there a best practice for doing that?
<leoprikler>there should be a transformation to add configure-flags
***lukedashjr is now known as luke-jr
<JorgeTern[m]1>Hello, does Guix uses some SotWare or package for the management of the administrative process?
<bricewge>Hello Jorge!
<bricewge>What do you mean by administrative process?
<JorgeTern[m]1>A package for resource planning
<bricewge>Hum, probably but I don't think you will find much with those keywords
<bricewge>You can search for package with "guix search"
<bricewge>Are looking for a calendar, something to manage TODO? Or actually a software to managed shared resource for an organization (such as rooms or cars)?
<JorgeTern[m]1>Like the second but a smaller project
<JorgeTern[m]1>A software to manage the shared resource for an organization
<JorgeTern[m]1>Planning, Organization, Direction and Control
<ArneBab>leoprikler: do you mean there is a transformation to add configure-flags or we should create one? In the info-docs I don’t fing a --with-configuraton-option or so.
<bricewge>Jorge: Sorry I don't know of any, as I never had the need for such software.
<JorgeTern[m]1>Thank you, I will continue looking for
<leoprikler>ArneBab: I'm talking about transformations on source code level, but perhaps I was mistaken about them
<lfam>Interesting article about "code review as a limited resource" for PostgreSQL: <>
***JorgeTern[m]1 is now known as JorgeTern[m]11
<GNUcifer>makes me always wonder on how much the review process can be mechanized
<GNUcifer>linting, coverage/fuzz testing
<roptat>mh.. is there an option I'm missing in clang? I'm getting a build failure because it can't find strerror, which is part of <cstring> or <string.h>, and the program includes only <string>
<lfam>GNUcifer: Yeah, and there is some automation for Guix <>
<roptat>is there an option to make it automatically include <cstring>? or maybe it's a custom version of clang that modified the <string> header
<lfam>I always find the comparison to Linux interesting, because Linux is obviously a big success
<lfam>But the comparison only goes so far because the type of software that Linux is reduces the impact of a difficult contribution workflow
<GNUcifer>lfam: i meant in a more general base
<lfam>Nevertheless, I think there is still something to be said for asking contributors to put some effort in, rather than trying to accept every one-off patch with no followup, no tests, no meta-information, etc
<lfam>GNUcifer: Can you elaborate?
<GNUcifer>well even for contributors it is not easy to figure out the process and rules how to contribute to a project
<ArneBab>short point is already at the start: „postgresql … prefers … centralized“
<GNUcifer>centralized or not doesnt matter *that* much when you want to contribute and your patches eventually be integrated in the mainline
<roptat>oh, libcxx includes <cstring> in <string>, then that must mean I don't use that header at all, so it must come from somewhere else
<GNUcifer>looking at the lua model which is extremely centralized helicopter-driven (they drop releases on the community)
<ArneBab>GNUcifer: it’s not your contribution, but the review-process. They have one responsible person, so they cannot scale up.
<lfam>Lua is really different because the development process is totally private, IIRC
<lfam>It's not really comparable
<ArneBab>GNUcifer: and currently a lot of large groups are moving from oracle to postgres, so pressure will be high to land their improvements.
<GNUcifer>ArneBab: exactly, you need to ease the review process for everyone, but without sacrifice too much (security/rules)
<lfam>I guess my point about Linux is that the changes that land are contributed by people who *really* want them in the kernel.
<ArneBab>but then, in #freenet we have review-head-blocking, too. I hope to ease some of that the next weeks (just started my holiday)
<GNUcifer>thats what i am wondering how much can one really mechanize without makink too much compromises on either side
<lfam>They solve a concrete use case with real business interests behind them
<ArneBab>lfam: and who get paid to land them
<lfam>And it works well for creating a useful piece of softare
<lfam>But, Guix is not in the privileged position of being "The operating system" that everything uses
<lfam>So, we have to work harder to attract contributions
<ArneBab>sufficient pay helps a lot. Example from at work: I tried to land a patch, but had only two days. The reviewer said „we need a test for this specific kind of connected service“. I expected that it would take me a week to figure out how to do that in their infrastructure, but I had only two days, so the pull-request went stagnant.
*ArneBab is sorry for that
<lfam>Did the business suffer as a result?
<GNUcifer>me thinking about some very pedantic/enstensive CI which does all kinds of checks and then a reviewer may not get a 'raw' patchset for review but something annotated by the CI. and eventually if things repeat one may write modules for that CI to mechanize things
<lfam>Are you using the patch internally, ArneBab?
<ArneBab>we can just apply the patchset on top and get the 4x performance increase
<ArneBab>lfam: yes — we just rebase the pull-request
<lfam>So in some sense, your business gained an advantage over everyone else
<lfam>It's definitely a pathological outcome
<ArneBab>not really: everyone else can apply the pull-request, too
<lfam>Sure, but they probably won't find it :)
<lfam>Finding all the cool patches is a lot of work
<ArneBab>it’s an open pull-request on github
<lfam>Then you have to validate them, etc
<GNUcifer>in a rust lib i got a patch merged 1hr after doing the PR .. in another i am considering to fork the project because my fixes laying around for half a years now unmerged
<lfam>Your business already did all that work
<ArneBab>the pathological outcome is that everyone now has to rebase the patch on every release
<lfam>Well yeah, but you probably also save on other expenses due to the perf gains
<ArneBab>it’s even already reviewed, only pending the “needs a test”
<GNUcifer>its understandably that reviewing/merging puts some demands on the maintainer
<lfam>It sounds like a lot of Guix patches, tbh, ArneBab
<ArneBab>but since it does not have a test, it could be broken any time.
<lfam>GNUcifer: I like the idea of the pedantic CI. Guix does have high standards for the codebase in terms of being idiomatic
<ArneBab>the perf gains mean that a once-every-few-months task takes a few days in computing time instead of 2 weeks
<GNUcifer>ArneBab: 'needs a test' is pretty arbitary because one could come up with some test which succeeds but still have some bad things (by accident/malice) got into it
<ArneBab>but back to topic: As contributor I like an automatic CI as first step that I can work against until it passes, and then a reviewer looks at the interesting points.
<GNUcifer>doing something a reviewer would do requires more than most 'normal' CI's do
<GNUcifer>getting past the oter merges->bulld->passes tests CI is pretty much standard nowadays
<lfam>Something I like about the Linux process is this: the patches that get in are presumably contributed by orgs with a serious motivation, and so they will also want them to keep working over time. It's a little frustrating to have to assume the maintenance burden of other peoples' contributions
<ArneBab>stuff like sonar can already take care of a lot:
<GNUcifer>but that wont ease the reviewers job *that* much
<ArneBab>lfam: the other point is that Linux kernel reviewers are paid, too
<lfam>Yeah, for sure
<lfam>That keeps coming up... ;)
<ArneBab>it’s no longer so annoying if you make a living from it :-)
<ArneBab>sonar helps with the basics — all the small stuff you then don’t have to look for as reviewer
<ArneBab>similar to code formatting checks
<lfam>I think of Guix packages as similar to Linux drivers
<lfam>I wonder to what degree are drivers that are contributed by device manufacturers maintained long-term by those contributors? Versus by subsystem maintainers
<lfam>For Guix, I think the ideal is that package contributors assist with maintenance
<ArneBab>In Gentoo there are typically maintainers for groups of packages. A similar setup would be to be responsible for at least one file with packages.
<lfam>It's been suggested in Guix, but I'm not sure that anyone has ever actually said, "Sure, I'll do it!"
<lfam>In practice of course, people do it. But without commitment
<lfam>Like, I do some video package maintenance, but only because I need these programs to keep working
<ArneBab>Sometimes you can’t commit. I can rarely do it.
<lfam>The Debian model is like that, I think
<lfam>I always thought their model was basically a case of path dependence from the tools available in the late 90s
<ArneBab>maybe it’s just something that keeps the most competent people at the task
<ArneBab>(because they know the packages)
***luke-jr- is now known as luke-jr
***GNUcifer is now known as cehteh
<muradm>hi guix
<breathein>Hello there, I installed guix sd on a librebooted X200, and I'm having networking issues. I can use networkmanager to connect to my home wifi, but it disconnects after about 30 seconds
<bricewge>Hello muradm
<breathein>The command I'm running to connect to my internet is `sudo nmcli connection up <mywifiSSID>`
<breathein>After typing in my pass, networkmanager hangs for about 30 seconds, then reports that "connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/51)"
<breathein>If I type `ping` immediately after connection, I get pinged back
<breathein>But I get ~10% packet loss
<breathein>Then, after a minute or so, I try to `ping` again, and I get `ping: unknown host`
<breathein>I test out `ping` on a different machine on the same network, and I get 0% packet loss
<breathein>Is it likely a hardware issue? Or could I have misconfigured something in my GuixSD installation?
<lfam>breathein: Did you replace the wifi card in your laptop? Or are you using the one that it came with?
<lfam>I have an x200 that I use with Linux (not linux-libre) and in the last year or so the built-in Intel wifi card started to exhibit similar symptoms. I don't know if it's just failing due to old age, or if the software support is going stale due to very few people using these things anymore
<philipper905>hello I tried to install a wifi driver 'rtl8812au-aircrack-ng-linux-module' but it failed in the build phase
<philipper905>has anyone experienced this or have any idea why this would happen?
<lfam>philipper905: Can you share the error messages on <>
<lfam>I mean, <>?
<lfam>As for why a package would fail to build... in general, there's a million reasons. The specific answer will depend on the details
<breathein>I bought the laptop from and I'm using the wifi card it came with
<breathein>Which should work without proprietary kernel modules
<lfam>breathein: Try `lspci` to find the name of the device
<breathein>qualcomm atheros ar93xx wireless network adapter (rev 01)
<philipper905>here's the error
<lfam>breathein: Okay, it should work fine. I don't think it's a misconfiguration. You might try using an older kernel version... not sure.
<breathein>lfam: it'd be a shame if this were a hardware issue :/
<lfam>It's probably a software issue
<breathein>Hope so!
<lfam>I would google it. These drivers go bad and need updating fairly often in my experience
<lfam>And if that happens, using an older revision works too
<lfam>Same for you philipper905: Did you google it yet?
<muradm>hello bricewge
<breathein>I'll search for connection issues with atheros?
<lfam>breathein: Yeah, using the specific model number, and looking for reports from the last 12 months
<breathein>great, thank you
<philipper905>lfam: nope I searched guix logs and couldn't find anything for that specific driver, i'll try googling but I'm not really sure what I'm looking for
<lfam>Google the error message philipper905
<lfam>You're looking for other people reporting the same bug
<lfam>Usually there will be some discussion and, hopefully, a fix
<lfam>These things are rarely specific to Guix
<bricewge>breathein: Did you instlled another distro before on that machine?
<bricewge>By any luck are you using Jami?
<philipper905>lfam: hey i found this pull request that seems related to my issue
<philipper905><breathein> I'll search for connection issues with atheros?
<philipper905><breathein> I'll search for connection issues with atheros?
<philipper905>oops sorry for last 2 messages
<philipper905>it hasn't been merged back into master though, is there a way to roll back the kernel version on guix?
<lfam>You can rollback the entire OS:
<lfam>Or, you can choose a different kernel version in your config.scm
<lfam>Try `guix show linux-libre` to check the available versions
<lfam>To use something besides the default (latest), add a line like (kernel linux-libre-$VERSION) to your config.scm and reconfigure
<lfam>That pull request is for a different driver, but maybe it can be applied to the one that you are having trouble with
<breathein>bricewge: I did install parabola first, but I formatted the drive before putting guixsd on it
<lfam>This is the repository that our package is based on:
<breathein>philipper905: thank you! I'm searching as well
<breathein>bricewge: If I am not able to find a solution, I'll try reformatting the drive and reinstalling guixsd on this machine
<bricewge>I'm not sure it would help to reinstall for such issue
<lfam>It's unlikely
<bricewge>Are you using Jami? There was issue like yours before because of it
<jonsger>is Mark H. Weaver in IRC?
<lfam>I don't think he's here now jonsger
<lfam>I think it's been a long time since I've seen him on IRC, unless he changed his name
<philipper905>sudo guix system reconfigure
<philipper905>that's the command to update the system right?
<lfam>You have to do `guix pull` first, to update the list of available packages
<lfam>Then, reconfiguring will reconfigure your system based on that updated list
<lfam>Does that make sense?
<philipper905>Yes, this is a new system, I ran guix pull but I've never run guix system reconfigure on it
<philipper905>so that means my system libraries have never actually been updated or something right?
<lfam>It looks like there were some changes upstream to fix compatibility with Linux > 5.12: <>
<lfam>Yes, that's exactly what it means
<lfam>Also, looks like those updates are in Guix now. So yeah, to benefit from them, you'd need to have run `guix pull` to make them available, and then reconfigure and reboot
<breathein>I am not using jami
<philipper905>lfam: oh ok so have these changes made their way into guix?
<lfam>Yes: <>
<lfam>From May / June
<iskarian>lfam, mbakke: I think the latest master -> core-updates-frozen merge unintentionally reverted 2818c66 (due to the conflict with lfam's reordering of golang.scm)
<lfam>Oh no, that's a different package philipper905
<philipper905>8812 is the one I need I think
<lfam>But I think this commit probably fixes your thing: <>
<lfam>There are several different 8812 drivers
<lfam>iskarian :(
<lfam>Merging is hard
<lfam>Thanks for letting us know
<iskarian>No problem. I'm always surprised on the simple things merges choke on. Like really??
<lfam>Maybe... I'm sure there is room for improvement but I'm not sure how much
<lfam>It's what I would call a hard problem to solve
<lfam>The improvements I have in mind would be for a language-aware revision control system. Like a completely integrated development environment
<lfam>Maybe in 50 years
<lfam>I'll fix it. Who knows what merging core-updates -> master will do...
<lfam>Anyways, it's a common problem with these long-running branches
<lfam>It's why I always use rebasing instead, when I do this stuff on my own
<iskarian>Yeah, without language knowledge the VCS would probably have to save a lot more than just a line-based diff
<iskarian>Rebasing is life
<philipper905>do I need to restart after a system reconfigure
<roptat>usually not, unless you want to run on a new kernel
<roptat>you might have to restart some services if it's a server
<lfam>A bigger problem with merges is that Git doesn't show any changes performed in the actual merge commit using the normal tools
<lfam>So you can make changes in the merge commit that don't appear in `git log --patch`, which is what I always use
<lfam>A good way to sneak things in
<lfam>Which is obviously something you shouldn't do
<otto>Hello, I am trying out GuixSD and having issues with Xmonad. Could someone help me?
<iskarian>Huh. That seems... too sneaky for anyone's good
<philipper905>oh gosh I got another error on sudo guix system reconfigure
<iskarian>I wonder if it makes it harder for tools as well
<philipper905>it failed after/while building ca-certificate-bundles
<lfam>philipper905: Does your config.scm include a line like (locale "en_US.utf8")?
<lfam>The correct name for the locale is "en_US.UTF-8"
<philipper905>yes that's what it's listed as
<lfam>otto: If you'd like assistance, please describe your issues
<philipper905>I haven't changed the config file at all yet
<lfam>Otherwise, it will be difficult to help you otto
<lfam>I recommend changing it then
<lfam>It's definitely a bug that your config.scm was created with the incorrect name :(
<lfam>Can you report it to <>?
<podiki[m]>otto: I'm on xmonad on Guix right now, though I did a custom cabal build. what problems are you having?
<philippe`>oh never mind it's set to utf8 not utf-8
<podiki[m]>lfam: I also have `(locale "en_US.utf8")` (from an installer built from master a in the past few weeks, but no certificate issues)
<philippe`>also config.scm is read only, am I supposed to edit it somewhere else or just use sudo priveleges?
<lfam>So, if the locales are not set up right, you *will* have trouble with ca-certificate-bundles. That package includes files with names that require proper unicode support
<lfam>So, maybe it's a problem with locales in the environment your working in; that's supposed to get set up automatically on Guix System
<lfam>That's the file to edit philippe`
<lfam>However you like
<lfam>What is the result of `echo $GUIX_LOCPATH`?
<otto>I have a manifest file that contains "(specifications->manifests '(.... "ghc-xmonad-contrib" "xmonad" ...))" so that after running `guix package -m manifest` I have the xmonad binary. However, `xmonad --recompile` fails because it cannot find Xmonad contrib modules. I have checked other peoples configs and they do the same. Don't know what is wrong. Have not tried cabal yet.
<philippe`>lfam: /run/current-system/locale
<lfam>That's correct
<lfam>Does anyone else have any ideas?
<podiki[m]>otto: there was some discussion recently about the wrong ghc version being used, I think you need to explicitly install ghc-8.6 (do a quick search on guix issues site)
<philippe`>lfam: well I'll try adding the '-' and see if that changes anything
<podiki[m]>re: locale so we should have utf-8 (with the -)?
<podiki[m]>`locale -v -a` show both with utf-8 character set, not sure the difference
<philippe`>lfam: also I should add that I get 'warning: could not determine provenance for current system' as the first message when running guix system reconfigure
<lfam>That's expected the first time
<philippe`>locale -v -a
<lfam>It's far from ideal... but it's expected
<lfam>The provenance system will be created during the first reconfiguration
<philippe`>I really need to make emacs look less like the terminal i keep trying to run commands on irc :)
<podiki[m]>looks like utf-8 is more correct
<otto>podiki[m]: Thanks, I think I found the issue. But specifying ghc version ("ghc@8.6" vs "ghc" in manifest file) does not work for me - it now reports "gch: can't find a package database at ..."
<philippe`>locale not defined on my system not sure if that matters
<lfam>otto: Try "ghc-8.6"
<lfam>iskarian: Fixed (I hope)
<otto>lfam: it says "unknown package"
<podiki[m]>so from a quick wikipedia reading, "utf8" isn't technically correct but happens enough it is recognized. but we should be most correct and use "utf-8"
<lfam>It's definitely a package that exists otto. Can you share your entire manifest file?
<lfam>On <>?
<podiki[m]>my manifest has "ghc@8.6" but that is from an export, I haven't tried to use it directly
<otto>Sure, in a second lfam
<philippe`>utf-8 actually isn't defined on my system, I checked the error logs and it didn't recognize it
<philippe`>i switched back to utf8 and it seems like it might be working now
<philippe`>pretty strange
<otto>My config:
<lfam>otto: And also, the commit named in `guix describe`?
<otto>commit: 6243ad3812f8c689599a19f0e8b9719ba14461f2, savanna repo
<lfam>At that commit, the ghc-8.6 package exists
<iskarian>lfam, thanks! Hopefully that should be enough to (re-)fix all the go dependents in CI
<lfam>Someone who is more experienced with manifests will have to explain how to specify this, otto. My use of manifests is too simple...
<lfam>I use something that looks like the output of `guix package --export-manifest`
<lfam>Anyways, you can always do `guix install ghc@8.6`
<lfam>The imperative way
<otto>hmmm wierd then.. I will try suggestions other from the issue
<otto>Yeah, ghc@8.6 installs, but fails on `xmonad --recompile` for a different reason (cannot find some database now)
<raghavgururajan>lfam: I tried something today,
<lfam>I suspect some miscompilation, disk / RAM error, obscure software bug, etc
<raghavgururajan>I'll retry reconfigure after gc.
<lfam>Oh wait, I confused your case with somebody else's
<lfam>I thought your boot stopped earlier
<lfam>Your system does boot, but then something goes wrong
<raghavgururajan>Yes, when shepherd about to start.
<lfam>Shepherd never starts? Are you able to confirm that somehow?
<lfam>I would guess some stale cache related to GNOME stuff, but I don't have any specific advice for debugging that
<raghavgururajan>The stuck happens after entering LUKS key and succesfull decryption.
<lfam>If shepherd doesn't start, then maybe it is a weird nondeterministic bug like a miscompilation
<lfam>I just don't see what else it could be, considering that nobody else has reported a similar problem
<raghavgururajan>I think the warning is connected to this.
<lfam>The error in finalization thread message?
<lfam>Or the warnings from your reconfigure process?
<lfam>Those warnings are definitely suspicious. The finalization thread thing is normal
<lfam>I mean, it sounds like reconfiguration failed for you, but the error wasn't handled properly and the process was allowed to "finish"
<lfam>I guess somebody will have to try reconfiguring based on your config.scm
<podiki[m]>otto: do chime in on any xmonad issues on the tracker, would be handy to have. haskell packages are in need of an upgrade and move to more recent ghc
<iskarian>Is there any way to get diffoscope to ignore store paths in binaries when comparing?
<iskarian>--diff-mask doesn't seem to help with binaries
<podiki[m]>anyone have any luck with python gtk packages and running into issues opening the x display? e.g. key-mon
<dstolfa>iskarian: --exclude takes a glob
<podiki[m]>I'm hitting the same with python package for autokey
<dstolfa>ah nvm that's for filenames
<otto>podiki[m]: ok, I will add my comment. Solution in the issue also did not work for me. (in this issue:
<podiki[m]>otto: thanks. we have a new wip-haskell branch with changes to the haskell build system too, not sure if that would help here, but good to document
<podiki[m]>the error I"m getting from python not knowing the protocol of the display is....opened in a graphical window on the display
<dstolfa>iskarian: i guess one way to do it is to just to pipe it to `grep -v`
<dstolfa>i can't find any options in diffoscope that would do what you want
<lfam>iskarian: You could copy the directories somewhere else in order to change their names
<lfam>Oh, you said "store paths in binaries". that's different
<lfam>You should ask the diffoscope people
<iskarian>the strings are broken up on multiple lines, so looks like grep -v doesn't always get it. looks like manual inspection is the way to go.
<otto>podiki[m]: Okay, actually, specifying the version worked, I just needed to relogin... I did source the profile, but that was not enough or something
<lfam>Could be a nice feature to add to Guix, iskarian
<lfam>Guix-aware diffs
<raghavgururajan>lfam: From reconfigure process
<lfam>Those messages are definitely weird
<iskarian>it would be nice to have a way to compare the effects of a change to a package modulo baked-in store paths; it would help verify that changes that shouldn't change the output don't, even if they do change the derivation
<philipper905>lfam: I'm trying to change the kernel as you were telling me about in config.scm. 'linux-libre-5.10.140
<lfam>I wonder, can you reproduce the bug raghavgururajan? Like, roll-back, delete the bad generation, garbage collect, and then try again?
<philipper905> ' seems to not be working though is that the wrong syntax?
<lfam>philipper905: (kernel linux-libre-5.10)
<lfam>You are named a Guile Scheme variable here, and the variable is called linux-libre-5.10
<philipper905>oh it's not a string??
<philipper905>i see
<lfam>Right, it's not a string
<lfam>I meant to write that "You are naming..."
<lfam>We make these variables for each kernel series
<podiki[m]>ah! the python xlib issue is an authority thing, `xhost +` allowed the program to connect to X and run. so what is the proper fix?
<lfam>So, linux-libre-5.10 is the name of the variable, at the code level. It's distinct from linux-libre@5.10, which is how we specify packages with versions in the user interface
<lfam>Like, the command-line user interface
<philipper905>I see
<philipper905>it's having trouble finding it do I need to import a MODULE
<philipper905>sorry for CAPS
<lfam>At the top of your config.scm, there is probably a place where package modules are imported
<lfam>Do you see it?
<lfam>Or does it need to be added?
<lfam>It's the linux module
<philipper905>yes (gnu packages linux)
<philipper905>I had to add it
<lfam>gnu is the namespace of all the packages and services in the "GNU system" (a pet name for Guix), packages are the packages of course, and then linux is the linux package module
<lfam>Actually, the GNU system is not just Guix. But Guix is main GNU project that creates a full OS based on the GNU system
<lfam>GNU claims all free software as being part of its system
<philipper905>haha that's quite bold
<dstolfa>lfam: reading it like this, i do understand why a lot of people are really confused on what the GNU system, GNU project and GNU software means
<lfam>GNU has always been bold :)
<lfam>Yeah, who can blame them
<lfam>That was to dstolfa
<lfam>Like, how can you claim a free software project that has no formal affiliation to GNU?
<lfam>But with a free license, anyone can take it and make it their own, in a sense
<lfam>At the beginning of Guix, "GNU System" was actually proposed as a name for the full operating system based on Guix, but this was rejected
<lfam>So instead it was named GuixSD, and then later renamed to Guix System
<KittyOwO[m]>Its weird to me how many of the same programs could be run on either some BSD and one not running GNU coreutils ect. and something like Guix System using a lot of gnu components and linux-libre.
<KittyOwO[m]>most people outside of here wouldn't exactly call something not using anything GNU by default GNU, which to me really begs the question of what even do we call these things the community(ies) built?
<lfam>Ultimately, BSD and linux are both Unixes
<dstolfa>KittyOwO[m]: that's because a lot of them just use standard functionality of libc and POSIX-y (but not quite POSIX) things that are common across the kernels :). sometimes minor ifdefs are required but it's just that -- minor
<KittyOwO[m]>true, but, libre-unix-like-os-with-ok-posix-compliance doesn't roll off the tongue lol
<KittyOwO[m]>or rather semi-libre-to-libre-like-os-with-ok-posix-complicance :P
<lfam>It's easy to lose sight of how little diversity there actually is at this point, in terms of operating system design. Besides Unix and Windows there isn't anything
<podiki[m]>does anyone know specifics about guix's x server authentication set up? running into an issue where an `xhost +` which disables that check, is what is needed for a program to connect to X server
<lfam>Oh, there is also iOS
<KittyOwO[m]>lfam: Templos :P
<dstolfa>lfam: well there are academic toys, but not much more outside of that
<lfam>I mean, in terms of things that actually have a userbase
<lfam>And maybe iOS is basically Unix deep-down
<dstolfa>also... iOS is basically a unix-like system
<dstolfa>it is :P
<otto>Haiku is probably the biggest one that is not Unix or Windows
<KittyOwO[m]>yknow, on this topic, doesn't Guix have some tools for spawning VMs? I kinda want to play with whatever has been made for Hurd at this point some time lol (shame the official site contains little information, and outdated info at that lol)
<lfam>High-level introduction here:
<lfam>And the tools for making VMs:
<lfam>Basically, `guix system vm` for an immutable system, and `guix system image` for something that can be changed
<KittyOwO[m]>yknow, I read the childhurd blog a while back, but not the april fools one, Hurd really needs to make their website more up to date and higher quality, while also showing off more pictures ect. and being more transparent about any progress various branches or whatnot have made, rather than only hearing about anything through Guix System website lol
<KittyOwO[m]>thanks for the links btw uwu
<lfam>Well, I think the news is on our website because that's where things are happening these days
<KittyOwO[m]>yeah, maybe the Hurd website just needs to link to the Guix System website and there be a Hurd section on guix system website if it comes down to it lol
<lfam>Probably the best place to keep up with the Hurd is on their mailing list:
<lfam>It's the case for a lot of GNU projects
<leoprikler>I just read that URL as "threads are a bug in Hurd"
<lfam>It seems to be a standard that the first mailing list for any GNU project is 'bug-$name'
<lfam>And they only add the others if bug-$name gets too busy
<KittyOwO[m]>lfam: Yeah, it is a bit of an issue imo tho that most people wanting to learn about the hurd sees the Hurd site rather than things with real somewhat up to date knowledge lol
<lfam>Definitely. I think that a big factor in Guix's success is the web site
<lfam>You have to attract contributors who want to do the web site
<dstolfa>lfam: it really is imo. it's to the point and easy to understand
<KittyOwO[m]>yeah, the site is great
<KittyOwO[m]>while mailing lists might be helpful for people already deep in the project, new people should be able to just go to the site and see
<KittyOwO[m]>the progress being made, and real pictures of it working
*dstolfa awaits the day when he will be running a microkernel on everything without various modules panicking his system when things get weird
<KittyOwO[m]>rather than saying "lol maybe we will do 64 bit someday idk?" they should be shown that "yo someone is working on this in this branch, here is some photos of the things they have played with"
<lfam>The thing that makes it hard is that motivation is not fungible
<leoprikler>but that makes them perfect for NFTs
<lfam>It's not easy to redirect your energy from the thing you are excited about to some other thing (making a web site)
<leoprikler>buy my motivation for 15$/hour
<KittyOwO[m]>yeah, that is a very good way to word it, will def use that quote when people start saying "Why are these people investing in X technology when they could be saving these children!" that being said
<KittyOwO[m]>for something like a website it shouldn't be too hard to
<KittyOwO[m]>yeah lol
<lfam>leoprikler 😭
<lfam>Oh, thought you were making a joke about fungibility
<KittyOwO[m]>just find someone to pay a bit of money to either make the site more similiar to guix, or even port Hurd to a project under the guix system website.
<leoprikler>It's a double joke
<KittyOwO[m]>NFTs are already a joke to begin with :P
<lfam>Even before "making the web site" is "project administration". Not every programmer wants to do that
<leoprikler>point taken
<lfam>There's a lot of different roles to be played in an organization
<KittyOwO[m]>in fact, most of the crypto space is, save a few exceptions of projects like Monero which at a glance look less like a joke.
<KittyOwO[m]>very curious what history and names are behind why Guix System seems to be managed so much better than projects like Hurd
<philipper905>lfam: hey I'm back it turns out the current version of guix
<philipper905> doesn't have the commit required for 5.12 support yet for the
<philipper905> rtl8812 drivers
<lfam>Oh alright
<lfam>Can you give some details?
<philipper905>the last commit is from back in january
<lfam>Do you know exactly which Guix package to look at?
<philipper905>rtl8812au-aircrack-ng-linux-module, if you're talking to me
<lfam>I can try updating it on a branch you could pull with `guix pull --branch=foo`
<lfam>Or, you could try it yourself, if you want to set up a development environment: <>
<lfam>That's outlined in the first two sections of that chapter
<philipper905>I'll definetely set that up in the future
<philipper905>but right now I'm still confused as I rolled back to 5.10 for the kernel and I still get that error
<lfam>That's definitely weird
<lfam>You see the expected thing in `uname -a`?
<philipper905>are there some header files I need to update too or something like that
<philipper905>yes 5.10-stuffs
<lfam>Huh, maybe the change got backported. It's a risk with 3rd party modules
<lfam>I'll set up that branch
<philipper905>thanks lfam
<philipper905>guix install darktable
<philipper905>oops sorrrryy
<podiki[m]>thumbsup for darktable
<lfam>philipper905: When you say that you were still having trouble after booting with 5.10, do you mean that the package failed to build?
*lfam testing the build now
<philipper905>the same error
<lfam>That's expected because the version of the kernel that is used to build the package is not the one used in the build
<lfam>Or like, it's not about versions, but those two "kernels" are simply not related at all
<lfam>This type of package is built using the linux-module build system, and that build system includes the latest version of linux-libre we have packaged for building the modules
<lfam>I was able to test it myself so I pushed a fix, philipper905: <>
<lfam>You should be able to do `guix pull` and try your failing command again
<philipper905>alright I'll give it a shot, fingers crossed
<lfam>Let us know if it doesn't work
<philipper905>lfam: should I install as a system package or just using guix install?
<lfam>I don't know how to use kernel modules on Guix! Anybody?
<maximed>Maybe the kernel-loadable-modules field of operating-system
<philipper905>maximed: what about the 'firmware' section of operating-system?
<philipper905>it says that's where the atheros and broadcom packages are located
<maximed>That's for firmware, not kernel modules (though some modules may need corresponding drivers ...)
<the_tubular>Anyone know how to use SSHFS on guix ?
***lukedashjr is now known as luke-jr
<philipper905>maximed: alright i'll try sticking it in kernel-loadable-modules
<maximed>ath9k-htc-firmware wold go into 'firmware'