IRC channel logs


back to list of logs

<lfam>The instructions on using it are here: <>
<KE0VVT>So I need to re-download the binary?
<lfam>The SELinux policy file (guix-daemon.cil) is contained in it
<lfam>So, if you want that file, you should download the binary tarball again
<rekado_>the cil file was written for an old version of Fedora
<rekado_>well, it was reasonably fresh at the time
<rekado_>but by now it sholud be horribly outdated.
<lfam>I see
<the_tubular>Is this me or shepard is blazingly fast compared to other init system ?
<the_tubular>I've never seen a system boot as fast and the specs of this system are pretty dated
<KE0VVT>the_tubular: Shepherd was slower than systemd last time I booted GuixSD with GNOME.
<char>the_tubular: I don't know if it is shepherd, but I have also noticed that guix starts very fast.
<jgart>Hi guix!
<jgart>Is this define-public here redundant?
<jgart>Since it is already included in the exports
<jgart>In other words should it be changed to define instead of define-public and just exported?
<jgart>s/Since it is already included in the exports/Since it is being exported from the module and using a define-public form
<the_tubular>char maybe you are right, it could be irrelevant to guix
<the_tubular>Maybe the fact that it uses linux-libre ...?
<the_tubular>irrelevant to shepherd *
<char>the_tubular: I'm not usig libre due to hardware issues, so it isn't that either
<iskarian>jgart, yes
<GNUtoo>apteryx: guix build --sources=all git-repo gives me that: /gnu/store/3bpy0k170ls57j7iaka035d2ad2vqhvw-git-repo-2.4.1-checkout
<GNUtoo>I'll try with --manifest
***califax- is now known as califax
<jgart>iskarian, Ok, I'll send a patch to update that
<the_tubular>What does that mean when I guix pull : listing Emacs sub-directories... ?
<hwpplayer1>hi people
<jgart>I tried this the other day. Quite comfy with broot:
<jgart>`broot $(guix build bitmask)`
<jgart>just wanted to share in case it's useful for anyone else
<jgart>The usual is to use `tree $(guix build bitmask)` or `ls $(guix build bitmask)`
<apteryx>GNUtoo: oh, sorry it seems it rather should be: guix build --sources=transitive git-repo
<apteryx>'all' seems to mean to take both the source of the package as well as any other input used as source
<apteryx>it only looks at the current package; transitive looks at its closure.
<KM4MBG>jgart: thanks for the hint. broot looks cool, but not packaged for guix yet. Something for the list!
***KM4MBG is now known as jackhill
<jackhill>ah, no wonder, it's a rust app
<jgart>KM4MBG: Definitely, definitely
<jgart>here's another rust app I'm excited for:
<jgart>I use this one regularly also:
<jackhill>I am curious about the origin of the name now.
<jackhill>Cool, so many nice things!
<jgart>tig and git-interactive-rebase-tool make nice tools in the git toolbelt
<jgart>jackhill, origin of aparte?
<jgart>if so, it's spanish
<jackhill>still thinking of broot
<jgart>ohh ok
<jackhill>oh to aparte, oh, cool xmpp :)
<jgart>the ui looks nicer than poezio, imho
<jgart>but no omemo yet. They're working on it in a branch
<jackhill>cool, I've been using profanity for my terminal xmpp needs
<jackhill>and have been more of less happy
<jackhill>I've been using it with a guix pack on a non-guix system actually. Something I have to investigate there, it doen't like non ASCII. Maybe a locale is missing in the pack?
<jgart>what guix pack output are you using?
<jackhill>jgart: relocatable tarball
<jgart>what system were you using it on?
<abcdw>hi guix!
<jackhill>jgart: Debian buster
<jgart>hey abcdw
*jackhill waves to abcdw
<jgart>jackhill, have you tried the deb archive output yet?
<jackhill>speaking of rust softare to package, another one for the list: (may need to do something about the hardcoded use of cloudflare DNS though )
<jackhill>jgart: I have not, but it's on my list to try. Looke neat! Not approprate for this system though, as I don't have root.
<jackhill>What's more likely is that we actually get guix going on it though.
<jgart>ahh, ok that makes sense
<dragestil>is the guix info manual available for downloading somewhere?
<dragestil> only has html and pdf
<dragestil>ah found it
<dragestil>hmm, but makeinfo complains about missing files like version.texi
<civodul>Hello Guix
<mothacehe>hey civodul!
<civodul>hey, what's up?
<mothacehe>not much, trying to have a few more packages to build on core-updates :)
<civodul>ah, that's good :-)
<civodul>i haven't done much in this area over the last few days
<civodul>is anything important broken?
<mothacehe>there's some work left yes:
<mothacehe> should fix lisp packages
<jgart>Hey Civodul! I saw you released a new version of guix-jupyter.
<jgart>Have you tried/tested launching a notebook preconfigured with the guix kernel as default instead of selecting the guix kernel when it launches?
<civodul>mothacehe: the Common Lisp patch LGTM!
<mothacehe>great, thanks :)
<civodul>jgart: i haven't tried that, it'd be interesting
<jgart>civodul, would you like me to upgrade guix-jupyter in guix? I could use the upgrade too in upstream since I'm testing things with it.
<civodul>i already did that :-)
<civodul>(to 0.2.2)
<civodul>let me know if it works for you!
<jgart>oops, I missed the commit
<jgart>I see it now :)
<jgart>The default kernel to load by jupyter can be specified in a config file:
<jgart>MultiKernelManager.default_kernel_nameUnicode takes a string
<jgart>it's set to python3 by default
<civodul>i don't think we should change the default in our "jupyter" package because that'd make it behave differently than those of other distros
<civodul>and i'm not sure upstream would be interested in changing the default :-)
<civodul>but i guess that's a useful tip for the personal config of those who use Guix-Jupyter
<jgart>yup, I also think that wouldn't be a good idea for general jupyter users
<jgart>civodul, were you familiar with this project by tweag?
<jgart>declarative and reproducible Jupyter environments - powered by Nix
<jgart>I discovered it today. I'm just studying it a bit to see how it works
<jgart>> In practice, a Jupyter environment is defined in a single shell.nix file which can be distributed together with a notebook as a self-contained reproducible package.
<civodul>jgart: no i didn't know about this one, i don't think it existed back when we started working on Guix-Jupyter
<civodul>but it's a different beast
<civodul>AIUI, it's akin to running "guix environment --ad-hoc jupyter python-ipykernel ...", no?
<civodul>so it's still non-self-contained notebooks
<civodul>(actually, i wonder why they need something special at all to achieve that, weird)
<brendyn>There is also version 5.23.0 since 20 days ago so im not sure why you updated to 5.21
<vivien>Hello, I’m trying to get date->string from srfi-19 to return the locale date (without time). Is it even possible?
<vivien>(the date according to the locale)
<jgart>> "guix environment --ad-hoc jupyter python-ipykernel ...",
<jgart>yup, but with nix-shell. I haven't studied the internals of how nix-shell works. I imagine it's similar to `guix environment ...`
<jgart>not considering the cli goodies that guix has, of course ;)
<civodul>jgart: maybe the reason they need this library is because Nix doesn't figure out JUPYTER_PATH automatically or something
<civodul>vivien: hi! yes, data->string returns the date in the current locale
<civodul>is that not what you observe?
<vivien>civodule, it also returns the time
<vivien>I don’t want the time
<civodul>ah, then check out the various format strings for date->string
<civodul>you can choose what to output
<civodul>maybe more of a topic for #guile actually :-)
<jlicht>hey guix!
<civodul>hey jlicht! how's everything?
<vivien>I haven’t found any format for that
<civodul>vivien: you sure? :-)
<civodul>there are quite a few flags to choose from
<tissevert>hi guix
<vivien>Yes, but I know some locales have the day and day number swapped and I’d like to use the locale information for that and not compose that format myself.
<civodul>oh i see
<vivien>~c does it automatically, but it’s the only one to do it, and it has the time
<civodul>hmm ok
<civodul>does locale data actually have info regarding d/m/y order? not sure
<civodul>maybe you have to use strftime instead of date->string
<vivien>Oops, ~c has the order backwards too
<jlicht>civodul: all great, pretty excited about the next round of core-updates coming to master Real Soon (tm)
<civodul>jlicht: it's gonna be awesome
<vivien>OK I’ll go with strftime
<civodul>vivien: see also locale-date-format in (ice-9 i18n)
<civodul>looks like what you want
<mothacehe>rekado: hey! r-minimal is broken on core-updates:, does it ring a bell?
<rekado>hmm, that’s a LaTeX error.
<rekado>l3backend-pdftex.def not found
<rekado>that’s … pretty fundamental
<rekado>gotta check tlpdb to see what package should provide it, but I’m guessing that it’s a core part of the base LaTeX installation
<vivien>civodul, OK locale-date-format works
<rekado>mothacehe: I’m setting up my clone of core-updates, and will then fetch the tlpdb from texlive-bin on core-updates, and then search for that file.
<civodul>it could have to do with the recent TeX Live upgrade
<civodul>we could put Thiego in the loop
<mothacehe>rekado: thanks for your help, I'm quite a TeX Live noob.
<mbakke>bauermann: ^
<mbakke>on a related note, 'parted' on core-updates reaches an infinite loop due to a util-linux regression:
<mbakke>the latest version fixes it, OK to update?
<bricewge>Hello Guix!
<bricewge>Would be a bad idea to "modify-services" by name in addition to type?
<mothacehe>mbakke: sure :)
<bricewge>ATM modifying "set-xorg-configuration" is very awkward, being able to modify a service by name would made this simpler.
<bricewge>But "service-type-name" field state it's "for debugging".
***califax- is now known as califax
<rekado>mothacehe: hah, me too.
<rekado>unsurprisingly, the l3backend package should contain the file.
<rekado>our texlive-latex-l3backend does include the file
<rekado>it’s not propagated anywhere, which I feel is a mistake.
<rekado>but for the time being we should be able to fix this particular problem by including texlive-latex-l3backend in the texlive union for r-with-tests
<rekado>I’m giving this a try now.
<rekado>more changes are needed.
<rekado>we’ll need to package grfext as well
<vivien>Removing linux-libre 5.12 broke the project that must not be named.
<rekado>vivien: report it to them instead
<vivien>That’s donoe
<rekado>mothacehe: I have two commits to fix this. Should this go to core-updates and then cherry-picked to core-updates-frozen?
<mothacehe>rekado: oh great! yes that would be perfect.
<rekado>okay, pushing to core-updates now
<rekado>…and pushed the two commits to core-updates-frozen
<GNUtoo>apteryx: thanks a lot, I'll try it now
<bauermann>rekado, thanks for fixing this! I’ll look into propagating texlive-latex-l3backend today.
<bauermann>mbakke, thanks for tagging me here
<GNUtoo>apteryx: that seems to work
<GNUtoo>I've many /gnu/store/* that look like source code
<mbakke>rekado: I don't think you have to push to both branches, I suppose we'll merge -frozen into core-updates regularly.
<mbakke>...not that it matters much :)
<mbakke>speaking of merges, we should get 'master' into 'core-updates-frozen' for the PHP update... I can probably give it a go later today.
*mbakke developed a habit of pushing core-updates fixes through 'master' when appropriate
*civodul embarks on pytorch packaging as a silly way of procrastinating
<guil>Hello! I'd like to contribute to the main guix channel. I've made a package for vimpc, a TUI mpd client like ncmpcpp.
<dstolfa>guil: hi! thanks for the interest & your work :). this might point you in the right direction:
<dstolfa>if you have any questions, feel free to ask here, i'm sure plenty of people here are happy to help
<rekado>civodul: good luck!
<guil>dstolfa: Thank you!
<rekado>mbakke: okay. I’m not very familiar with the new process.
<rekado>bauermann: oh, are you working on TeX Live things in Guix?
<mbakke>bauermann is our new TeX Live hero :-) thanks for the 2021 update!
<bauermann>rekado, I did the update to TeX Live 2021, for better or worse :-)
<dstolfa>oh, is this merged to master?
<dstolfa>i need to pull!
<mbakke>dstolfa: not yet, but you can beta test by running 'guix pull --branch=core-updates-frozen' ;-)
<mbakke>you may want to wait a few hours for the build farm to catch up first
<dstolfa>mbakke: will give it a try later today, thanks!
<pineapples>I see that a Mesa patch hasn't made it into core-updates in time :-(
<bauermann>mbakke, you're most welcome. I enjoyed working on the update
<civodul>rekado: luck is exactly what one needs when packaging this kind of stuff
<civodul>that and patience
<guil>Should I only use tarballs or Am I allowed to use git repositories as well?
<rekado>bauermann: excellent!
<rekado>bauermann: for the next core-updates cycle it would be great if we could review the existing packages and ensure that they include all files that texlive.tlpdb mentions.
<rekado>we also need some improved tools and abstractions
<rekado>the simple-texlive-package, for example, still requires a lot of manual overrides, which I’d like us to get rid of in the future
<rekado>(especially for the easy case where a dtx file is supposed to be unpacked and files are to be installed into a well-known directory)
<bauermann>rekado, nice, those sound like interesting projects. I added them to my notes and will look into the simple-texlive-package easy case “soonish” :-)
<bauermann>rekado, one thing that is on my mind is switching texlive-bin to build from the SVN tag rather than the tarball. that way we would pick up post-yearly-release fixes. there are a few patches on the newer 2021.x tags already. what do you think?
<bauermann>guil, AFAIK you are allowed to use git repos because some existing packages do that, but I’d also like to know about whether there’s any preference in the Guix community between tarball vs repo.
<civodul>guil: hi! yes, packages can take their source in Git repositories; see
<civodul>hey bauermann :-)
<bauermann>hi civodul!
<mothacehe>the CI is much happier, thanks rekado!
<mothacehe>fixing build-system issues allows to have thousands of packages fixed with a single commit, quite satisfying.
<rekado>bauermann: taking the source for texlive-bin from SVN sounds like a good idea.
<rekado>bauermann: an example of a package that would benefit from a revamping of simple-texlive-package is the new texlive-grfext
<civodul>mothacehe: plus, it looks like a left quite a few such "satisfaction opportunities" :-)
<rekado>I had to override quite a few arguments and even then there are too many files that are installed.
<mothacehe>civodul: hehe, yes any java or go experts around :p ?
<bauermann>rekado, nice example. thanks.
<rekado>the Honeycomb boards I ordered in May are delayed even further.
<rekado>I asked SolidRun about the status (previously delayed to “end of July”); now they say they will be delayed until the end of August.
<civodul>rekado: uh, that inspires confidence
<roptat>mothacehe, java "expert" here :)
<mothacehe>roptat: oh nice :) The java builds on core-updates-frozen are not doing great. Looks like the "classpath" build failure here: is part of the issue.
<roptat>uh, the cuirass website doesn't like my typos "sytem:x86_64-linux" returns an empty page
<mothacehe>roptat: regarding the Cuirass issue that might deserve a bug report :)
<roptat>even a 500
<apapsch>me to boss: "I need to publish this guix channel under gpl" boss: "why?" me: "guix itself is gpl licensed and I don't have to fiddle with git authentication" boss: "just do it!"
<apapsch>music to my ears
<rekado>my license recommendations went similarly smoothly
<roptat>mothacehe, it's not classpath failing, it's ant-bootstrap
<rekado>there’s also the other side of it: want to make a commercial product out of this? You can! It’s all free software, so you have the rights to turn it into a commercial service without having to ask anyone for permisssions.
<rekado>my boss was very happy about the simplicity of it all.
<apapsch>rekado: it's great there's a big mountain of free software and I'm happy to add to it. The argument against publishing is often "competitors might copy it and succeed before we succeed"
<muradm>hi Guix
<muradm>i'm trying to use pam-mount-service-type as explained here
<muradm>here is snippet
<muradm>and I get this while reconfigure
<muradm>any clue, hint?
<muradm>this is pam_mount.conf.xml from above config
<muradm>maybe <lclmount> and <umount> should be specified explicitly?..
<muradm>config specifies <cryptmount> and <cryptumount> only
<roptat>it looks like the issue is after generating the rule file, when creating the content of the etc directory
<roptat>I suppose /gnu/store/sx6vcxa2lpk156mn72id2l3f0a778ccm-* corresponds to the rule file?
<muradm>yes, contents are
<muradm>name is /gnu/store/sx6vcxa2lpk156mn72id2l3f0a778ccm-pam_mount.conf.xml
<minikN>roptat: I fixed my issue with the WSL script finally. Thought to let you know.
<roptat>how did you fix it?
<minikN>The issue was actually simple to fix once I realised it: In my base-system.scm I used stuff from other channels, but I never declared the channels I used (for the reconfigure command). So what I ended up doing was to simple add this ( to the shell script invoking the command
<muradm>from gnu/services/pam-mount.scm it looks like cryptmount/cryptumount are hardcoded and mandatory although i'm not going to use them
<muradm>and there is no lclmount/umount at all
<roptat>minikN, I see, that's why it was working well for me: I simply removed the stuff that depended on that channel because I don't have it
<roptat>muradm, I don't think that's the issue: the rule file was generated after all
<minikN>Yeah I never thought about that because the error was about something completely different
<nefix>Hello! I've built a derivation in a server, exported with `guix archive` and then imported it into my laptop. It appears in the store, and I can install it through `guix install /gnu/store/path`. However, if I try to use it in a `guix environment`, it tries to build again the whole derivation. Am I missing something? Thanks! :)
<civodul>nefix: hi! does 'guix build the-package --no-grafts' show the same derivation?
<civodul>the same as the one you copied
<nefix>civodul: in my laptop it tries to build it entirely
<civodul>ah sorry, i mean "guix build the-package --no-grafts -d"
<nefix>Oh, it's different!
<nefix>Makes sense xD
<nefix>I guess that with `git pull`ing both it will work out, right?
<nefix>Also, is there a way to specify `guix environment` arguments? I'd like to execute something like `guix shell` and then automatically jump to my environment with everything. Is a shell script the answer?
<muradm>roptat: any idea what to look at?
<nefix>And a third question: is .bashrc always sourced? (even with the `--pure` argument?)
<nefix>Thank you! :)
<roptat>not really, I'd look at the etc-service-type, that generate the etc directory, to see what can result in "permission denied"
<roptat>maybe there's actually another service that has already created a rule file previously, and it doesn't have permission to overwrite it?
<leoprikler>nefix: yes, so don't put bs into it
<nefix>leoprikler: thanks! :)
<muradm>roptat: i had pam-limits-service also, when i move it before pam-mount-service-type i get "In procedure symlink: File exists"
<roptat>interesting, so the two services are not compatible?
<muradm>this way i get permission denied:
<muradm>this way i get file exists:
<muradm>looks not very functional... :)
<muradm>limits are: /etc/security/limits.conf
<muradm>pam mount is: /etc/security/pam_mount.conf.xml
<muradm>both create /etc/security/ directory which is conflict point?
<rekado>the collapse of the wave function is where functional beauty is translated to state
<muradm>roptat: one or the other works, not both
<the_tubular>minikN So you have Guix working on wsl ?
<the_tubular>Would you mind helping me?
<minikN>I can try, sure.
<the_tubular>You are using WSL2 correct ?
<the_tubular>Guix is install, but I can't start the guix daemon right now
<minikN>WSL2 yes.
<muradm>roptat: looking at the code, I would say that problem is with pam-limits-service-type gnu/services/base.scm:1385, this is where limits.conf is defined in let, it calls mkdir directy. while pam-mount-etc-service defines its config as "security/pam_mount.conf.xml"
<minikN>Are you trying to install the package manager or guixsd?
<minikN>Okay so I found this gist which I followed: it works for me
<muradm>roptat: so, i would be fixing gnu/services/base.scm:1385
<muradm>pam-limits should not own "security" but "security/limits.conf"
<the_tubular>That's also what I followed, minikN It worked like for 1 day, then it stopped wroking after I got a blue screen (Gotta love Windows...)
<minikN>Maybe try invoking the script again with the given command
<the_tubular>Yes, let me show you the error.
<muradm>roptat: I mean in this snippet from gnu/services/base.scm where (lambda (limits-file) ...
<the_tubular>minikN, It seems to work ... ? I have no clue what I did differently
<muradm>should not do mkdir, but do it like pam-mount-etc-service gnu/services/pam-mount.scm
<the_tubular>Mind if I send you a PM?
<minikN>Was the error you had before this: guix system: warning: while talking to shepherd: No such file or directory ?
<roptat>muradm, would you mind sending a bug report? I can't act on it right now
<cwebber>I pushed origin/wip-setuid with a rebased version. It looks like we've (including bricewge) done all the changes civodul requested earlier.
<cwebber>is there any problem with me pushing to master?
<cwebber>I guess I'll update the issue saying just that
<bricewge>cwebber: Yes, you can push it.
<bricewge>Thank you for rebasing it!
<cwebber>bricewge: okay whew
<cwebber>doing so now!
<cwebber>now the next thing to figure out
<cwebber>is what's needed to get postfix up!
<bricewge>Is there an issue already tracking postfix status in Guix?
<cwebber>#35619 it looks like
<cwebber>then there was some conversation on guix-devel on the "wip-postfix" and "Setuid programs" threads
<cwebber>(actually I said earlier that the tests all pass; I mis-saw my terminal, they're still running. Letting them run before I merge this one in.)
<cwebber>grabbing food while the tests run
<cwebber>ok they pass :)
<muradm>roptat: done
<muradm>me leaving
<raghavgururajan>Hello Guix!
<raghavgururajan>brendyn: Ah, sorry, I missed that patch-set as it was closed. I updated to 2.21 because versions after that seems to require newer sqlite.
<leoprikler>for the record, what's the state of sqlite on cu-frozen?
<cwebber>oh shoot
<apteryx>bricewge: heya! Thanks for the setuid work! Unfortunately it broke 'guix pull', it seems.
<vivien>I have found a bug
<vivien>(oh sorry it looks like what apteryx is writing)
<apteryx>there's a missing dependency error for (gnu system setuid) in (guix modules)
<apteryx>used during guix pull
<vivien>Previously a reconfigure messed with my system user ids
<vivien>Is it related?
<apteryx>I don't think so
<cwebber>apteryx: I just fixed it
<cwebber>sorry sorry sorry
<apteryx>OK :-)
<cwebber>somehow when pull in in the patch series (which had hit a conflict)
<cwebber>this got dropped
<cwebber>it was in my checkout without being committed.
<cwebber>so everything had seemed fine here.
<apteryx>OK! no worries, thanks for the prompt resolution.
<GNUtoo>Ah we just need to guix pull then, thanks for the fix
<vivien>So I have a specific user to run a service, and the shepherd service creates a bunch of directories in /var/cache, /var/lib and /var/log
<vivien>But it seems that that system user got a new ID because the old files are owned by a mysterious "968" user
<vivien>I can fix it easily with chown though
<vivien>Maybe it was a bug in my service though
<GNUtoo>It's also part of the tradeoff with rolling release (more risk of breakage but very recent software, more people wanting to contribute to get the result of the contribution immediately, etc)
<jorge[m]>Hola,por favor al que pueda colaborar de revisar estos 2 reportes en paste 1205873 y 1205874.
<zacchae[m]>Anyone do any machine learning on guix? Most ML uses CUDA which is proprietary, but there seems to be a push to support for AMD/ROCm, which, correct me if I am wrong, is free software.
<zacchae[m]> * Anyone do any machine learning on guix? Most ML uses Nvidia/CUDA which is proprietary, but there seems to be a push to support for AMD/ROCm, which, correct me if I am wrong, is free software.
<civodul>zacchae[m]: hi! that would be great, because NVIDIA is so terrible
<civodul>i don't know AMD/ROCm though
<civodul>perhaps we should start by packaging it?
<zacchae[m]>I'm actually still trying to verify that it is free software. I have heard that AMD is much more free software friendly, but I want to make sure everything is gucci
<vivien>Maybe it’s just PR
<zacchae[m]>This seems like a pretty important thing to address. Machine learning/AI is becoming a larger and larger part of society, so there really needs to be a free software path to using ML/AI
<zacchae[m]>I see the kernel driver is distributed under a modified GPL licence
<zacchae[m]>seems legit to me
*civodul crosses fingers
<civodul>i agree not having proper ML support is becoming more and more problematic
<civodul>yet, i wonder about the extent to which ML applications are "good for society"
<civodul>i'm biased because i'm mostly concerned about its application to surveillance
<civodul>but still
<leoprikler>It's not just surveillance, which is dangerous.
<leoprikler>For the record, more recent COPYING states it's GPLv2 only:
<zacchae[m]>civodul: I think the point is that ML/AI are here to stay, so better for it to be free and open than in the hands of a select few.
<zacchae[m]>Though as an AI/ML researcher, I may be a bit biased :P
<leoprikler>Even if you make all of it free, those who have more hardware can do more stuff with it while you're still trying how to best breed your anime pfp.
<vivien>Not necessarily, it’s also about the data.
<leoprikler>I think we can safely agree, that governments and tech giants have more space for data (as well as more data) than you could hope to amass individually.
<vivien>There are legitimate use for machine learning. Have you noticed how tedious it is to always tag your activitystream activities? Well, you could do a lot of it with ML.
<vivien>leoprikler, yes, Amazon has a lot of fake reviews, facebook has a lot of bots to learn from.
<vivien>That does not necessarily improve things ^^
<vivien>But all jokes aside, solving big corporation having a lot of data is a different fight
<leoprikler>Even when there is a legitimate use, ML suffers from the fact that it's by design about as obscure as proprietary software.
<leoprikler>Like, even if you understand the maths behind it (FSVO "understand"), you can typically not 1. introspect the state of your AI at any given moment 2. reason about it meaningfully.
<vivien>That’s for a very specific type of machine learning though.
<leoprikler>Well, it's the "very specific type of machine learning" that people typically mean when talking about machine learning.
<leoprikler>Safe to say I'm not talking about L*
<vivien>So, let’s not do that and let’s do more useful machine learning with guix.
<leoprikler>What exactly do you think about when you say "more useful machine learning"?
<vivien>Well, knowledge extraction that you can do with reasonable hardware and reasonable data :)
<zacchae[m]>leoprikler: Useful applications of AI: brain-machine interfaces, especially for the differently abled (blind, unable to use certain limbs). Text to speech for various reasons. Home security systems. Any and every medical diagnosis ever can probably be better done with AI
<zacchae[m]>More and more medical diagnoses are made with AI as they beat out human doctors. Brain machine interfaces, as scary as that sounds, will probably become one of the most integral pieces of society.
<vivien>Also we would use the fast linear algebra systems just like people doing non-AI things, like fluid dynamics simulations and so on
<zacchae[m]>My point being, that yes, the free software community should really care about enabling free development of AI/ML tools
<leoprikler>I find it hard to believe that a society that lets homeless people starve to death will somehow produce brain machine interfaces for the masses under ethical circumstances.
<vivien>Well, a society that lets homeless people starve to death invented the internet
<leoprikler>I'll grant you TTS/OCR, that is useful and can be done reasonably well even with bad data.
<vivien>Not to glorify it
<vivien>So who knows
<leoprikler>Different applications.
<zacchae[m]>leoprikler: I'm not sure about the production being "ethical", but I nor any reasonable person is going to attach things to their brain unless they are convinced that it is safe. Yes, people don't care much when it comes to things like phones, but you can bet I'm not letting any proprietary software near my noggin
<zacchae[m]>phones aren't as obviously connected to your brain
<leoprikler>Will you be given the choice, though?
<leoprikler>I know it's a meme that the medical system in the US is fucked, but even in the enlightened countries of Europe there's lower tier healthcare.
<zacchae[m]>I live in the US where not even vaccines are mandatory during a global pandemic. So yes, I will have a choice. Admittedly, I can't really say for future generations
<leoprikler>I mean a choice between a free software implant and a proprietary one, not between a proprietary one and "go fuck yourself"
<zacchae[m]>For any current designs, the brain machine interface is more of a relay than a computer sending (an sometimes recieving) arbitrary sensor data. The free software part would come into play on the external device that is controlling it. So yeah, free software is on the table.
<zacchae[m]>The design of the physical sensor would need to be relatively transparent if people are going to use it anyway
<leoprikler>So I take it your hospital has already upgraded to Windows XP. If not, I struggle to see your enthusiasm, we are masters at gating hardware behind proprietary drivers.
*civodul has xnnpack \o/
<zacchae[m]> * For any current designs, the brain machine interface is more of a relay than a computer, sending (and sometimes receiving) arbitrary sensor data. The free software part would come into play on the external device that is controlling it. So yeah, free software is on the table.
<leoprikler>Commas are important, but I don't think I misunderstood you based on a lack thereof.
<leoprikler>How that arbitrary sensor data is relayed to other machines is very important and we both know that there are ways to make it difficult for free software to access properly.
<apteryx>civodul: what is xnnpack?
<zacchae[m]>leoprikler: I forgot that in IRC, it repasts the whole comment. In matrix, I can edit in-place. For context, Neuralink uses a standard bluetooth connection. Based on my success with bluetooth on guix, I'm relatively confident that I can freely get the data to python (and from there, the world!)
<leoprikler>Well, apart from the thing that publishing health-related data to the world is probably a bad idea, that may be fine.
<zacchae[m]>I was going more for a "tap into the matrix"/"mad scientist" vibe, but yeah probably won't be broadcasting raw data like that
***iyzsong- is now known as iyzsong
<leoprikler>Well, call yourself a mad scientist, but German criticism speculates about a "brain cloud" collecting your thoughts, so…
<leoprikler>(taken straight from Wikipedia, so apply a grain of salt)
<zacchae[m]>leoprikler: "brain cloud" sounds like the human singularity merging all of mankind through machines. Sounds good to me
***Kimapr7 is now known as Kimapr
<rekado>we have a number of good ML applications for diagnostics
<rekado>it’s a point of embarrassment for me that we can’t package these (and can’t easily replace the CUDA stuff).
<rekado>here are just three of them:,, and
<rekado>(Maui probably even works without GPU acceleration.)
<civodul>apteryx: xnnpack is a neural network thingie that pytorch depends on
<civodul>that's all i know about it :-)
<civodul>rekado: oh indeed, i can sympathize with being embarrassed
<civodul>i've just pushed the pytorch dependencies that were missing, so we should be able to provide it (CPU) Real Soon Now
<civodul>(famous last words)
<zacchae[m]>rekado: It looks like your codes use tensorflow, which now has AMD/ROCm support, so it may not be difficult to package them freely anymore. Though, there are a lot of other codes in your requirements.txt, so I'm not 100% sure
<civodul>zacchae[m]: don't tell rekado about tensorflow ;-)
<civodul>rekado packaged tensorflow v1, which was quite a bit of a challenge
<civodul>but v2 can only build with Bazel, and Bazel can only build with itself
<zacchae[m]>also, I should reitterate that I haven't completely verified that AMD/ROCm is totally free software compatible, but it seems to be the case
<rekado>we also don’t have a package for aiscm ( yet, which keeps me from playing with ML.
<rekado>it would not be a good look if I started to write Python code
<rekado>someone suggested we should evaluate gradient boosting instead of jumping straight to deep learning.
<rekado>I agree not because I understand why, but because it gives me an excuse not to write deep learning code.
<rekado>on gradient boosting:
<leoprikler>rekado: what's the problem with aiscm? It appears to use the GNU build system at least
<leoprikler>in terms of dependencies, we might need to package clearsilver, but the rest is also there
<leoprikler>ahh, clearsilver appears to be a packaging nightmare though
<nefix>Hello! I'm struggling to use C++ standard library, specifically the "<limits>" package. It shows the following error: /c++/limits:42:10: fatal error: 'bits/c++config.h' file not found. Does somebody know what am I missing? Thanks! :)
<nefix>I'm creating a pure environment with `gcc-toolchain`, but it doesn't seem to contain the required file
<GNUtoo>nefix: do you have the commands to run (guix environment --pure gcc-toolchain?) and example C++ file?
<monego>rekado: i sent patches for xgboost and lightgbm (gradient boosting libraries in both C++ and python) a while ago
<monego>they compile fast, have few dependencies, and it's easy to separate the c++/python interfaces
<Noisytoot>Guix includes the CC Sampling 1.0+ license in licenses.scm, which is nonfree (it does not allow commercial verbatim distribution):
<Noisytoot>openttd-opensfx seems to be the only package licensed under it
<leoprikler>nefix for the record, the following compiles and runs fine:
<Noisytoot> claims OpenSFX is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported license, which contradicts the Guix package definition
<nefix>GNUtoo: oh, I think it has nothing to do with the C++ standard library. I'm trying to use Zig, and I've build a custom derivation based on this and this issues
<GNUtoo>Ah Zig is a toolchain?
<leoprikler>yep, zig should compile C code as well as zig code
<GNUtoo>ah yes it's the zig language which can also compile C / C++ for many architectures
*GNUtoo likes the idea of having clear runtime / compile time separation in the code