<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.
<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"
<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 (https://paste.debian.net/1205947/) 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
<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?
<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: 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?
<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
<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.
<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>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.
<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.
<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).
<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
<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