<rain1>gnu/packages/terminals.scm:365:2: firstname.lastname@example.org: probably vulnerable to CVE-2018-1000532
<rain1>probably best to just delete the beep package, what do you think?
<rain1>on guix, the beep binary is owned by root but not suid so the cve does not apply
<OriansJ>rain1: well it has it's uses on servers but outside of that special case there isn't going to be much demand for it but there is no danger in having a package definition available and just simply not providing a substitute
<rk4>do people run into much problems just using the latest mainline kernel from kernel.org?
<rk4>[why yes, work has issued me a non-ideal laptop...]
<OriansJ>rk4: generally no, the kernel can generally be built rather easily
<OriansJ>it just isn't recommended due to reasons related to freedom
<thomassgn>anyone encountered build errors with python packages from something called '/homeless-shelter'? I get error: [Errno 13] Permission denied: '/homeless-shelter' from trying to package proselint...
<OriansJ>notnotdan: and I used to be terrible at walking when I was 2 but I put in the effort and got over it. Now it feels completely natural
<jlicht>notnotdan: provided you use something like git, you can also write a simple `guix.scm' file and put it in the root of your project; you would only need to change it if the actual build steps for your project change as well, and none of this munging with hashes and checksums while you are hacking the good hack :)
<notnotdan>jlicht: hm so how does that work? I don't think I can just get rid of the checksums in the .scm file
<jlicht>notnotdan: I there would have been multiple actual releases, I would bump the commit and hash every time. But while hacking away, I just build from my local git checkout using guix. That is what the second package is for (guile-semver.git).
<jlicht>so while workign locally, you have the best of both worlds; reproducible builds with guix and all other advantages (e.g. guix environment, rollback), while still being able to keep working on new features :-)
<jlicht>notnotdan: In case I was not being clear; you subsequently build guile-semver from the current revision of the source with a simple `guix build -f guix.scm' while your working directory is at the project root.
<notnotdan>jlicht: I see. This makes sense. But why the difference (source) inputs then?
<jlicht> notnotdan: because the non-.git version refers to the actual (online) released version, and the .git-version is only for local development e.g. you could put a slightly modified version of that file in your GUIX_PACKAGE_PATH, and guix would be able to do `guix package -i guile-semver' but for you this might not be as relevant. The `git-file?' + `local-file' part seems the most interesting
<notnotdan>jlicht: ok, thanks for walking me through this
<civodul>vagrantc: isn't it enough to add python-pyelftools and python to your inputs?
<janneke>civodul: months of work, two major things: implement strings as array-of-bytes (WAS: list of char cells) and moving the scheme stack out of the arena ;so that pushing/popping stack frames does not imply creating cells/gc'ing cells but is only the moving of a pointer
<ajtos>how capable tcc is those days? can you build glibc against it or you starting with uclibc/musl or something else? guess path to building modern gcc with tcc can be long - c++ dependency and so on.
<janneke>ajtos: what i know is that tcc can build glibc-2.2.5 and gcc-4.7.4
<janneke>however, to build gcc-4.7.4, you need a decent glibc; tcc does not come with a libc
<vagrantc>civodul: it appears to be all python2 paths, but python is 3.7 and python-pyelftools uses python 3.7
<OriansJ>civodul: the C code size of Mes.c isn't an issue thanks to cc_x86.s and M2-Planet.
*vagrantc tries using a python2-pyelftools variant
<OriansJ>the Mes.c binary isn't required once the M2-Planet->Mes.c step is complete and then the bootstrap binary will be reduced to just 431bytes on AMD64
<OriansJ>(We revised hex0 to eliminate the need for exec_enable and shell redirection)
<espectalll[m]>So it may be related to how GRUB now makes images, compared back to when GuixSD 0.10 was the latest version (and it worked fine)
<ajtos>janneke: i was out of loop when it comes to linux - i remember that rob landley was toying with idea of minimal bootstrap with tcc and musl libc few years ago - don't think anything came out of it
<vagrantc>how to make python-build-system use python3 ?
<civodul>vagrantc: you can use #:python python-wrapper, i think
<civodul>OriansJ: ok, though i would expect the size of mes.c to be an important factor?
<civodul>i mean if the C version is big, then the asm version will be big as well
<ajtos>espectalll[m]: legacy bios or efi boot? i'm new to guix, but i'm guessing that guixsd introduced efi booting at some point?
<OriansJ>civodul: we are going to eliminate the need for the asm version entirely
<OriansJ>(4,395 lines of handwritten M1 assembly including copyright header, comments and blank lines)
<ajtos>this is offtopic - i was having problems with wifi card on guixsd. seems like Atheros AR9462 is way more noise dependant than intel wifi card i used before. switching channels did the magic for me.
<ajtos>RX drop was like 10% after switching cards.
<ajtos>i installed guixsd without issues and guess that traffic hours affected connection to the point i couldn't get ip from dhcp server running on router.
<janneke>ajtos: okay...they might be interested in where we are now?
<ajtos>janneke: i don't have an idea. rob is still working with toybox i guess - minimal replacemnt for coreutils. that is still relevent to bootstraping i guess.
<OriansJ>ajtos: Mes.c is the core of the guix bootstrap and we are updating the channel on changes relating to the generation of the Guix bootstrap binaries
<OriansJ>aka reducing the total binary size down to just 431bytes for AMD64 systems
<efraim>I thought toybox was to replace busybox with a weaker license
<janneke>ajtos: toybox may be interesting, together with samplet and Rutger i'm working on a bash+coreutils replacement in Guile: Gash
<ajtos>efraim: my memory can be iffy, but there were also maintaince issues with busybox and uclibc ant the time. musl libc started with gpl then switched to bsd license and toybox did happen. those are way smaller targerts than glibc/coreutils.
<janneke>the bad thing of not pushing my core-updates to savannah, is that each time origin/core-updates changes i must rebase on it and change the commit messages 'Built with ...' after actually re-building it