<lekzikon>Is help-guix working alright? I sent a message 5 hours ago, but I can't see it anywhere. <leoprikler>erikg: If CMake provides some flags to use system libraries, use that. Otherwise try putting the source code into the expected destination path and hope that CMake acts reasonable <leoprikler>although guix usually aims to debundle such packages, so you may want to add a patch in your cmake setup, even if that is for guix only <erikg>leoprikler: yeah, I get the debundling motif, but in this case the project is under very active development. The whole reason for using the ExternalProject_Add incantations was to reduce the cost of updating dependencies to an absolute minimum, because I'm doing it very frequently <erikg>I'd like to use guix for packaging and deployment in various places, so it's worth patching the repo to allow everything to get pulled down with a recursive git clone (which is totally cool with guix) <leoprikler>Recursive clone is usually a sign that the packager gave up on your ugly submodule structure. <leoprikler>"Reducing the cost of updating" should not be that much of a concern if you're using guix for packaging/development anyway. <leoprikler>Package the dependency in guix, then use a `guix environment` for hacking or just add another package for deployment. <erikg>I need to be able to build without guix. It's not possible for the majority of my users to install it. However, it is useful to me and some users who need to deploy via containers. <erikg>If your focus is making a binary executable that is precisely specified by its input source code, submodules and ExternalProject specifications are just fine. They meet the basic requirements. We can blame C++ for never developing a proper module system. Obviously, guix would be ideal, but it's not a standard facility that everyone can have access to (e.g. in HPC systems), even if it should be... <erikg>And yes, this pattern has resulted in some nasty source trees with plenty of awkwark duplication <leoprikler>most modern languages, like python, npm, etc. make things even more difficult with their language-bound package managers <erikg>leoprikler: sorry, any module system... proper or not <leoprikler>tbh I'm not sure how much "modules" have to do with this <leoprikler>lacking modules certainly makes encapsulation harder, but encapsulation != packaging <brettgilio>Just sent a V2 of the Mercury WIP to guix-patches, can check it out here: bugs.gnu.org/38603 ***KE0VVT_ is now known as KE0VVT
<raghav-gururajan>sneek: later ask roptat: Can I participate for outreachy may-august 2020 with guix? :-) <nckx>raghav-gururajan: On which area of Guix would you like to work? <nckx>raghav-gururajan: Outreachy internships focus on one coherent, ideally ‘finishable’ task. See <https://www.outreachy.org/past-projects/> and search on each page in that list for ‘Guix’ (except the last one, we haven't submitted anything for that yet) to get an idea. <nckx>You're welcome to propose something yourself (anyone is) and if it's accepted you can apply for it : <raghav-gururajan>nckx Cool! I'll get back to you. I think we can come up with an objective to work on in that either of those areas. <apteryx>hmm, trying to build arc-theme always busts my memory <efraim>That reminds me, I need to figure something out for python-efl. Cythonizing the source takes at least 6GB of RAM <efraim>You can try zswap, it compresses some RAM (20% by default) before sending it off to swap <apteryx>efraim: interesting idea. In theory a swapfile on compressed Btrfs should work too. <str1ngs>apteryx: I would build on another machine either directly or offloading. *efraim in a stage whisper: Don't tell anyone, but sometimes I build on bayfront and then ask it for substitutes ***Server sets mode: +cnt
<efraim>interesting, arc-theme is FTBFS on bayfront, looks like a memory leak somewhere. 48GB of RAM in use ***g_bor71 is now known as g_bor
<g_bor>I have an almost complete hands-off installer for guix system :) <g_bor>I intend to do a multi-stage setup finally. <civodul>one of the blockers for a new release is a proper test of the installer <g_bor>First step is to get a minimal system installed fully automated. <civodul>and for that we need... and 'automatable' installer <g_bor>civodul: I only excercise some of the binding sof the installer. <civodul>oh i see, so you don't use the installer "as is", right? <g_bor>Also, I did not try to drive the frontend. <civodul>still pretty cool and certainly useful! <g_bor>it still needs some refactoring, it is now a chain of functions, but I would like to have a single function, and a config object to pass to it. <civodul>g_bor: ooops, that was an old one, sorry for the delay! <raghav-gururajan>sneek: later tell nckx: I have email ideas to guix-maintainers@gnu.org. :-) <g_bor>I banged my head into something... <g_bor>It seems that after starting cow-store I can no longer exec anything... <g_bor>problem is that at that moment I am actually locked out of the system <civodul>i think you cannot retry an install if the previous install failed <g_bor>civodul: ok. I will have to map that knoweledge to the internals of the installer though... <g_bor>I also see something strange when running nested vms. <g_bor>Sometimes boot stucks after error in finalization thread, bu sometimes it goes on with and udev messsage no sender credential received. <g_bor>When the vm is not a nested one it always works. <Parra>janneke: I tried the --keep-failed flag but the npm logs doesn't appear yet, it appears logs about cmake and intermediate builds of my package, but nothing related to npm <Parra>is it possible to enable network while building in Guix? even if it breaks reproductibility <leoprikler>Parra: it shouldn't be needed. npm-build-system puts inputs where you want them, if something is missing you can inspect the failed tree on your own. <Parra>I need to see npm logs, it is failing <Parra>my build system embeds other build systems and I don't know how to handle it <Parra>it's based on cmake but it uses pip and npm inside <g_bor>Parra: the logs should be dropped to somewhere in the kept build tree. <Parra>I did a find /tmp -name '*.log' but nothing was found <leoprikler>C-q runs the command quoted-insert (found in global-map), which is an interactive compiled Lisp function in ‘/gnu/store/hg2qd5ggvnxq5gfdhxqpidhm3rr8vysr-emacs-26.3/share/emacs/26.3/lisp/simple.el’. <leoprikler>Whereas C-q in most GNOME programs (such as Polari) closes the program. <Parra>what can I do with it? or do you have some doc? <leoprikler>Parra: there should be a file with environment variables in your failed tree <leoprikler>source that, then run npm from there and record what it does <Parra>another option maybe mixing build systems <Parra>but I have no idea how to do that <janneke>Parra: and you did override /tmp as the destination to write the logs? <Parra>this is what fails when building the project <Parra>it says there is no home, that's why I overrided it, then it started to fail with an strange error that says, "cb() is not executed", and throws logs to /tmp, but I can't read it <leoprikler>you can setenv home to the current working directory, you know? <Parra>No I don't, and I don't even know why would I need that <leoprikler>so that logs are thrown there instead of directly in /tmp? <Parra>but logs aren't in /tmp neither, that won't solve my problem <leoprikler>"it throws logs to /tmp, but logs aren't in /tmp" – which of them is it now? <leoprikler>either way, "mixing" build systems should work, that is including phases from node-build-system into your build <Parra>npm run by guix says: logs are in /tmp, but I go there and I can't find them <Parra>@leoprikler do you have an example <leoprikler>e.g. (add-after 'configure 'node-configure node:configure) <leoprikler>I think there are some emacs packages, which mix stuff <Parra>I should disable that raw commands from cmake too, right? <Parra>and also, I should copy the output to the build folder or something? <Parra>and is node-gyp command included in node-build-system? how can I include it? <leoprikler>is node-gyp shipped with node or is it an extra library? <Parra>gyp is another build system developed by google <leoprikler>then you have to package that up as well and use it as (native?) input <Parra>my software is ultra complex to fit properly guix <Parra>I use docker right now for building, but guix provides super effective way of generating self contained and portable tarballs <leoprikler>"I use docker for building" shows the extent to which build systems are borked right now 😉️ <Parra>in any case my use case is not typical <leoprikler>There are several articles on the state of project management in "modern environments", specifically web development. <Parra>you don't use 5 build systems in the same project normally <leoprikler>Your use case is not typical,but your build flow certainly is. <Parra>docker is the only way I found to make it reproductible before guix <leoprikler>come to think about it, wouldn't it be easier if you decoupled metacall? <Parra>the problem is that I designed this build system in order to fit docker, not guix <Parra>but I didn't think about this before <Parra>metacall/core would be like 10 repos by itself <Parra>but my idea was to make it mono-repo <Parra>because it's easier to handle in general <Parra>most devs don't know how to manage submodules <Parra>I build with cmake on my debian <Parra>but in order to make it reproductible I used docker before Guix <Parra>I don't get jokes easily, sorry <civodul>Parra: np, that's ok, using Docker for that certainly was a good choice <civodul>i think leoprikler was suggesting that the fact that Docker is used as a build tool tells a lot about the state of build tools, package management, etc. <Parra>I used debian package manager and sometimes, from time to time you can't build it anymore <Parra>the repo gets outdated and you can't install more packages <Parra>you are forced to update to newest version <civodul>Guix folks like to argue that "containers" used as packaging tools are flawed: opaque and non-reproducible <Parra>I used Ubuntu at the beginning, and then I moved to debian <Parra>it wasn't easy but at least it worked for me <Parra>I would use Guix from the beginning if I had known about it <Parra>also, I don't think guix was ready for production 4 years ago <Parra>and now it's ready but it lacks doc, I feel like I die in this irc chat each time I need to do something complex <Parra>or.. going through master code <Parra>but I'm used to do that things <leoprikler>that will give you some examples of how people mix traditional build systems (most often gnu) with emacs-build-system. <leoprikler>Also have a look at node-build-system, which has the steps you'd want to copy. <raghav-gururajan>civodul Where can I find comprehensive information about guix project's infrastructure? Like sys -admin related information. <raghav-gururajan>civodul I will have a look and get back to you. Also, do you have any draft copies for updated road-map? <raghav-gururajan>civodul Perfect! That hydra link is exactly what I was looking for. Thanks! <g_bor>ok, now I can definitely confirm that starting cow-store makes any further exec permission denied... <g_bor>I started up a bash just before it, then started cow-store the way it is described in manual installation. <g_bor>I believe this is related to that the gexp is run as an autologin root. <civodul>then yeah, i guess you have to build a full-blown image with "guix system disk-image" in that case <civodul>yeah, it's an undocumented issue :-/ <g_bor>I did this because it was much faster to iterate. <Parra>you will reproduce the error then <Parra>this will enable support for NodeJS and it will call npm <Parra>the first like is just a workaround, to avoid another error of npm saying there is no permissions for /homeless-shelter which is a default path it uses when there is no HOME defined <Parra>the important line is the last one <leoprikler>just to be sure, one can build the node loader without needing metacall first, can one? <Parra>maybe possible but I've never triee <Parra>one sec let me ldd node_loader <leoprikler>specifically, scripts/preinstall.js appears to issue a warning about that <Parra>yes that's right, it is only linked against libnode, which is already provided in metacall.scm <Parra>leoprikler: also trampoline and bootstrap.js <Parra>trampoline is a node extension, and bootstrap uses cherow which is already packaged in metacall.scm too <Parra>all loaders are plugins dynamically loaded by metacall <Parra>leoprikler: libnode takes a lot to build that's why I provided two different scripts, one for building deps and another for building metacall, so it can be cached <Parra>if you don't use guix insisw docker to build, it will be useless because guix already caches it <Parra>I would like to achieve this, because it will help to Guix directly, I want to package netcore and other tools that will be very useful for packaging a lot of software with Guix <Parra>leoprikler: have you tried with node loader? <Parra>I use a 20 core machine of a friend XD, with my laptop it will be impossible <Parra>you can disable other loaders if you want to speed it up <Parra>so you disable ruby build for example <Parra>and did you use --keep-failed? <leoprikler>the logs are in $failed_tree/core-0.1.24/.npm/logs <leoprikler>funnily enough the directories reported by npm themselves appear to be empty <Parra>I couldn't find them because of that <Parra>thabks so much, I will continue later, my brain is burned out right now <Parra>at least with logs I will be able to understand better the problem, and with your snippet of code I will be able to mix build.systems.too :D <leoprikler>my brain would be burned out as well, if I had to deal with such a humongous package 😉️ <Parra>if you want to try it out, it's already working with ruby and python <Parra>this works even in a busybox <Parra>if you have curl+https support, otherwise you can install it on an alpine <Parra>it installs metacall system wide, and you can run later on <Parra>and type help to check different commands <Parra>this is all generated by guix, it's super powerful <g_bor>I just got a letter from the Outreachy Organizers that community applications are open. <g_bor>I would like to take take on the role of Community Coordinator again, and hereby I request your permission to apply Guix as a participating organization for the next round. <civodul>g_bor: i'm all for it! you can email guix-maintainers/guix-devel to get more +1s <civodul>or ping rekado mbakke nckx apteryx :-) ***KE0VVT_ is now known as KE0VVT
<aitzkora>question about scheme (I know I could read the FM) : what is the meaning of % ? <g_bor>if you mean why some variables start with it <aitzkora>g_bor: thanks, I was thinking it was a operator of list concatenation 😕 <g_bor>civodul: I've sent a post to guix-blog for review. <g_bor>It has the project ideas we collected in the last round. <g_bor>The community links should come up soon, the rest just work as is. <civodul>Scheme identifiers can contain almost anything but white space <leoprikler>buu buu, scheme identifiers can contain white space <civodul>so "+" or "%" or "α+b" are all valid identifiers <g_bor>civodul: I marked Guix as participating, and FSF as a sponsor for one intern,as was done last round. I also updated the website link. <aitzkora>civodul: someone in the guix-hpc project could accept my merge request for opencoarrays ? <civodul>aitzkora: sure, i or someone else will take a look <jonsger>civodul: can guix already be used with guile-3.0? <thesfrash>Hi Guixers! I was wondering how bad an idea it was to share a Guix Store between the Guix System and Arch Linux dual booting on my laptop. My understanding is that if I never use "guix gc" everything should be fine because if something already is in the Store then it's ok, if it's not it just gets substituted/built. But everything could break if, <thesfrash>after I run "guix gc", Guix decides that a Store item is not linked to any profiles in the running distro it'll just GC them and they could be possibly linked in some other profiles in the other distribution. Is that a real problem or Guix is smart enough to figure this out for itself? Thanks! <leoprikler>It should probably be fine if one of them only makes references to the other <leoprikler>e.g. if you `guix pull` on arch, using guix commits that you already have on Guix system <leoprikler>building the same packages on both systems etc. etc. <efraim>you should probably share /var/guix between the two also <civodul>jonsger: if you add "3.0" to GUILE_PKG in configure.ac, it can be built; there are still test failures though <g_bor>efraim: yes, I was about to suggest the same thing :) <thesfrash>leoprikler: So I should always update guix pull before on the Guix System and then on arch is that right? <leoprikler>and use the same commits from arch, that's a very important step <leoprikler>fwiw you could also try mounting your arch partition and manage your arch profiles from guix system <thesfrash>efraim: I didn't think about that! So it should be sufficient to share /var/guix and /gnu/store to keep both Guix aware of all profiles? <thesfrash>and all the arch stuff in /var won't mess with Guix System? Sorry I'm not really sure about what goes in /var except for /var/www D: . <efraim>i'd try to just share /var/guix from /var <efraim>you could bind mount /gnu/var/guix to /var/guix or something on both systems <pkill9>could it be possible to have resumable downloads? <pkill9>oh nice, downloads continue after a suspend, so maybe not such a big deal afterall <leoprikler>after suspend, but probably not after shutdown (which is good(?)) and there's not hibernate yet <aitzkora>somebody knows how to pass option to cmake using (build-system cmake-build-system) <leoprikler>(arguments `(#:configure-flags (list "flag1" "flag2"))) <leoprikler>do you by any chance get locale warnings elsewhere as well? <jonsger>hm. guile-git doesn't have a release with guile 3.0 support, only in master branch ***wxie1 is now known as wxie
<efraim>how do I checkout the submodules of submodules? <jayspeer>how can I make just installed font visible to running emacs instance without restarting? both font and emacs are from guix repos <dctrud>oh sorry - you said "running" emacs. Misread. <jayspeer>I can always restart it... but that means killing this lovely irc session :) <leoprikler>probably nothing to refresh fonts inside a running program <zimoun>Debbugs question: why does the tag "patch" only appear when the subject contains PATCH? Does it come from the old time where the patches were sent to guix-devel? Is it possible to add the tag "patch" to all the emails sent to guix-patches? <erikg>efraim: that should be happening with (recursive? #t) set in (git-reference ...) <mehlon>I'm actually trying to put guix on my raspberry pi 2 rn <mehlon>it's hard to find a suitable distro that allows modifying the root filesystem <mehlon>debian didnt boot for some reason <jayspeer>isn't guix support for arm devices sketchy? Or is it just for guix system? <jayspeer>or is guix on foreign distro working fine? <jayspeer>mehlon: if you're looking for good foreign distro gentoo works fine. just setup cross compilation and it's a breeze :) <mehlon>actually that sounds like a good idea <jayspeer>imho only guix is more elastic than gentoo <civodul>it's brand new! right from cbaines_ labs :-) <mehlon>oh I couldnt duckduckgo it so I just assumed it doesnt exist *kmicu thought about too many folks sending competing patches/PR but that was about Public Relations :( <jayspeer>civodul: almost all of it says "no data" <civodul>jayspeer: right, i think it just shouldn't show diagrams for architectures for which no info is available <civodul>but it's really cool because it's updated for each revision, and as new builds complete <mehlon>jayspeer: do you suggest I use the chroot+qemu method then? since I don't have gentoo on my current laptop <jayspeer>mehlon: I did that once when building image for rpi0, it's infinitely faster <kmicu>graham hijacked r13y.org for NixOS’ benefit. Not cool 😺 <nixo>civodul: cool! thanks :) <mjw>that doesn't really help for getting a trusted guix pull :{ <grillon>I have a question close to melhon question...Could guix replace yocto? <kmicu>Not really, different goals. <kmicu>And for sure not for embedded stuff in the near future. <kmicu>mehlon: thank your for the correction. I didn’t pay attention. <civodul>mjw: this was bound to happen, but still: ouch <civodul>they mention gpg 1.4, which is not all that relevant <kmicu>Oh, that’s a paper by INRIA so civodul patched everything year ago already ;) <mehlon>just saw the phrase "libre or leave, bruh" <mehlon>so obviously this needs to become the official motto of guix <kmicu>The issue was aleardy discussed and corrected by git maintainers and users in kernel Linux space (year ago). <civodul>jonsger: SHA1 has always been a bad choice for Git :-/ <kmicu>(The paper mentions that collision detection library.) <civodul>more importantly, the fact that it's hard-wired is terrible <kmicu>And here I will start lobbying for switching to Darcs/Pijul [jokin’]. <jonsger>civodul: so it has a potential real world impact. This gnupg 1.4 stuff is not so bad, because it's not widely used anymore (I guess) <mehlon>aha ! we have found a critical linux bug! free software retired <civodul> jonsger: yes, that's what i meant about GnuPG; 1.4 is really old <kmicu>(1.4 is decades old and used for archives only.) <civodul>problems in the OpenPGP spec would be more interesting, i haven't yet read what they say <civodul>but RFC4880 has those 64-bit key IDs in different places, for example <mehlon>when reporting a broken package, should I include the entirety of the build log in the email? <pkill9>i would put it in a pastebin if it's huge <mehlon>debian's paste could work but that's stored either for 90 days or infinite <pkill9>oh no wait, attach it to the email <erikg>i've got a ton of derivations floating around from failed package builds during testing. guix gc doesn't want to remove them. any way to force them out? <g_bor[m]>alextee (@alextee:matrix.org): no, what does its name field say? <alextee[m]>and this means it's the doc output (outputs (cons "doc" (package-outputs glib))) <g_bor[m]>The variable name and the package name is independent. <alextee[m]>ah i see, thanks. i always thought it was the variable name <alextee[m]>yaassss i have glib docs in devhelp again \o/ no more pinging gnome's servers for docs <alextee[m]>ummm, there's no pkgconfig for the portmidi package? <efraim>erikg: sorry, was afk. Yeah, but I wanted a local checkout with everything also. Finally found git clone --recursive <nckx>alextee[m]: It is a 10-year-old package, we'd probably have to write our own .pc file and install that. Possible but questionable. <sneek>Welcome back nckx, you have 1 message. <sneek>nckx, raghav-gururajan says: I have email ideas to guix-maintainers@gnu.org. :-) <nckx>raghav-gururajan: Could you explain why you removed system-config-printer from the gnome package in commit a8cda7? <nckx>raghav-gururajan: I saw, thanks. ***drakonis2 is now known as drakonis
<nckx>raghav-gururajan: And the reason that it was added in the first place is no longer valid? <nckx>I wish a8cda7 hadn't been merged as it was, it does far to much with no explanation. <raghav-gururajan>I thought when list was first made, it was following the old stack. So I revised it to be in sync with current stack. <nckx>I don't know if that reasoning is still valid (do you?) but any commit reverting it should a) not be mixed in with many unrelated changes and b) include some rationale for why Chris's addition is no longer needed. <nckx>Pretty sure there was PackageKit in Guix in Jan 2019, so maybe ‘support’ means something specific. <nckx>Through gnome-control-center? OK. <nckx>raghav-gururajan: Another good reason to use ‘git revert’ + an explanation: people won't come bothering you on IRC 😉 Thanks! <raghav-gururajan>Yeah, I have printer settings in the control center. Though user need cups service to connect to printer. <nckx>I guess that's to be expected. <nckx>Wait, what do you mean by ‘the other one’? <nckx>%d-s only includes cups-pk-helper-service-type, cups-service-type is of course required to print, that's OK. <mehlon>ah, I just installed alpine on my raspberry pi <nckx>I don't really understand why "PolicyKit helper to configure CUPS with fine-grained privileges." should be part of %d-s when cups-service-type isn't, but I don't need to. <raghav-gururajan>nckx yep, thought of that. It's one of the things I planned to do. So I have put that in that one of the ideas I sent. *raghav-gururajan --> Zzz Have to go work in 7hrs. <mehlon>ugh, I keep doing CTRL+shift+c in firefox and it brings up the console instead of copying <janneke>nckx: you want to have a look at my updated grub gfxmode patch; i added your suggestions; wondering if OK to push to master *janneke somehow missed a 'do" or ? somewhere there <KE0VVT>Why are you against /usr/bin/env? <nckx>KE0VVT: Who is? Janneke? <janneke>nckx: ty; i added an @cindex HiDPI locally, did not update the patch/bug with that yet <nckx>KE0VVT: Guix System explicitly installs a /usr/bin/env by default to make that work so I still don't follow. <mehlon>using it will make builds somewhat less reproducible <KE0VVT>I was advised against it, and it didn't work last time I tried it years ago. <nckx>Not the builds, but the runs. <mehlon>although wait no, the builds will still be reproducible <lfam>Yeah, it's more about run-time, and it was decided that the loss of reproducibility was worth the increase in user friendliness <KE0VVT>And then someone mentioned what mehlon said about ruining reproducibliity <mehlon>hey so alpine linux does not currently have the 'shadow' package <lfam>Especially since it mainly affects shell scripting <mehlon>should I report this to guix so they can add instructions for alpine, or should I just wait? <KE0VVT>Hm. I learned here not to do /usr/bin/env bash <lfam>mehlon: What is missing? <mehlon>I already have fixed instructions ready that should be more portable anyway <nckx>KE0VVT: We aren't ‘against /usr/bin/env’, we explicitly support it if you want to write/use scripts that have it. What we don't do is ship *Guix packages* that contain such shebangs because there's no way to know what they will invoke at run time. <mehlon>lfam: useradd and groupadd are not present on alpine linux, you have to user adduser, addgroup <mehlon>wait no, even *that* doesn't work unless you have busybox... <nckx>janneke: Looks good, assuming the code & GRUB xref work! Only nitpick I can think of would be to check whether the list elements contain a ‘,’ or ‘;’, which should probably not be silently allowed, but I'm sure most other services don't go that far either so it's certainly not a blocker. <lfam>mehlon: Can Guix work on alpine at all? Guix is heavily dependent on glibc <mehlon>well it can work either way since it pulls in its own glibc <lfam>Well we should aim to make the installer script as portable as we can <janneke>nckx: yeah, i have been thinking about syntax checking -- i will test what happens with empty entries <nckx>I always considered the add… variants to be human-friendly wrappers around the lower-level …add tools. This is the first time I've heard of a distro that turns it around. <mehlon>busybox only has 'add-*' without corresponding '*-add' <mehlon>the 'shadow' package with useradd/groupadd is not in stable yet <nckx>I wonder if that's a menuconfig option that Alpine chose or true for all busyboxen. <nckx>Anyway, sigh, I guess we can't even assume the ‘lower-level’ interface to be universal so change away. <lfam>Also, the installer script is a helper tool, but it's not the only way to install Guix <lfam>If there are some weird systems that it doesn't support I think that could be okay <mehlon>I wasn't using the installer tool, I was installing manually <lfam>My overall point stands though <lfam>The idea is to create some users, however your system requires you to do that <mehlon>wouldn't work anyway since bash is not on alpine linux <lfam>No, it's a totally different track of Linux systems <mehlon>it does not use GNU coreutils or GNU libc by default (although GCC is still necessary for most builds <nckx>Then as long as the manual says something like ‘create your users, for example’ and not ‘run exactly this command now’ I think we're fine. <lfam>I think we should accept a change that makes the examples more universal, if possible <mehlon>you'd need to manually add 10 guixbuild users though <nckx>But universal is impossible. The alternative seems to be 2 full code example blocks. <lfam>Well if it's not possible then it's not possible <mehlon>most of the commands still work fine, only the guixbuild config needs to have 2 examples <nckx>lfam: Sorry, I meant that I agree with your point, but it's not an option here. <lfam>I'm still not sure that guix can run on alpine at all... have you made it work yet mehlon? <mehlon>oh, hold on, just doing some finishing touches <nckx>mehlon: Does (busybox) adduser not support a GECOS field, or did you just omit that for brevity? <mehlon>of course note that -g means primary group for useradd but GECOS field for adduser <mehlon>so adduser is POSIX compliant (and missing on my NixOS) while useradd is from a debian package <nckx>AFAIK neither were POSIX. <nckx>mehlon: Where'd you read that? <nckx>‘adduser is POSIX compliant’. <mehlon>oh, no POSIX does not allow a GECOS field <mehlon>it's only compliant in the sense that it's backwards compatible with POSIX so to say <mehlon>"adduser" is in here without any command line options <mehlon>I have this weird problem where I can't guix build coreutils because it says "failed to run program a8041[..]/libexec/guix/download: permission denied" <lfam>Suprising "permission denied" errors are often masking something else, like file not found or incorrect executable format <lfam>If your system has strace you could run the guix-daemon with `strace -f` to try learning more <lfam>Or whatever tracing tools are available there <janneke>nckx: it's not pretty, but grub is robust against extra ; and , with empty entries; so i guess we're fine <janneke>sneek: later tell civodul: second hidpi patch is now on master; for setting grub resolution -- you may like that <nckx>janneke: Having never touched a HiDPI box, I've always wondered: is the Linux console/boot readable on those things? <janneke>it's either 40x25; the usual huge letters or <janneke>when it switches to full resolution, it's next to unreadable <janneke>i need to take a picture to read it -- very annoying :) <janneke>now, i finally have a sulution for grub as well as for the console <nckx>The kernel supports different compiled-in fonts, although Guix doesn't enable them yet. Sounds like it would be useful. <janneke>ah, that could help; i now use font-terminus ter-132n; or 128n <nckx>(I use them for the opposite: set a 6x10 font as default so early-boot debugging is more pleasant on my non-hidpi screen.) <nckx>Right, these fonts are for before shepherd/userspace is ever loaded. <str1ngs>janneke: I recall reading there is a HiDPI console font. but I have'nt had time to follow up on it <janneke>in X, i can have very nice and sharp letters, and am able to use a pretty small font and get lots of hacking space <janneke>str1ngs: ah, well my solutions are in the manual now, please improve on them or mail to guix-devel or something <nckx>Biggest kernel font is 16x32 Terminus. Bigger than I expected. <nckx>Although it does say ‘not supported by all drivers’. <mehlon>I also have guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <mehlon>this is on raspberry pi armv7l (using armhf guix) <nckx>mehlon: Did you run something like: sudo guix archive --authorize < the-key-file-for-the-server <nckx>? If not, search the manual for that command. <mehlon>at least, running GNU hello after guix build hello worked correctly <nckx>It won't affect the binaries, just how fast you get them (if berlin has substitutes). <nckx>But yay! Guix on Alpine! <mehlon>there might be a problem with compiling stuff, but using substitutes works <mehlon>after installing in diskless mode, follow the "Traditional disk-based (sys) installation" and then install guix <pkill9>i once heard a nice metaphor for the command-line: It's like cheat codes for your computer <mehlon>hard to use, unmemorable and easy to mess up? <mehlon>where does guix keep the git repository of the main guix channel? <nckx><as someone with a rPi in a drawer, not with chanop hat on> mehlon: does this still require installing non-free firmware? <mehlon>I didn't install any unfree firmware for my rpi2b <mehlon>but rpi 3 might require unfree wifi driveres <nckx>And none is included (AFAYK) with Alpine? <nckx>I thought the Pi couldn't boot the CPU without booting the GPU which requires fw, but that was years ago. <mehlon>I think not, since you have to install them separately <nckx>mehlon: Unless things have changed it doesn't keep a full git repository but checks out (shallowly) to the store as with any other package. <nckx>But there is ~/.cache/guix/checkouts which probably will contain a Guix checkout if you look closely. I'm not familiar with how that cache is used, but it's obviously not the canonical source <nckx>In the drawer it shall remain. <oriansj>who needs wifi, when wired is an option? <nckx>oriansj: Booting is less optional. <mehlon>it appears to be a CPU chip driver <mehlon>ah, then GuixOS won't be coming to Pi anytime soon either <lfam>The later RPIs may be better... <lfam>That old one was not going to be a satisfying experience with Guix anyways <lfam>Way too slow and not enough RAM <oriansj>painful but works is better than nothing at all <lfam>Better to use another distro IMO, where you don't have to compile anything <apteryx>inkscape fails to build on core-updates, some C++ compiling error: no known conversion for argument 1 from 'GlobalParams*' to 'std::nullptr_t' (line 18 of pdfinput.cpp). Might be due to an update to Poppler, which defines GlobalParams <lfam>apteryx: Did you try updating inkscape? <mehlon>yeah but NixOS does not work well on rpi and I want my functional packages! <lfam>Unfortunately you'll need a little more power <mehlon>it has around 1 GB of ram though so it's fine enough <lfam>Oh, my bad, I thought the 32-bit RPIs only had 500 MB RAM <mehlon>raspberry pi 2b armv7l has 1GB with roughly 800 MHz CPU iirc <nckx>CompanionCube: ‘It's not dead and not abandoned in a conventional sense.’ 😃 <lfam>Oh, I didn't know they kept making 32-bit models <mehlon>well they're not making them anymore, this one's from 2015 <nckx>mehlon: I think that's what I have. <lfam>I meant after the first model, mehlon <mehlon>it has 4 USB slots to the right of the ether port, and no wifi <lfam>apteryx: I would try inkscape 1.0 <mehlon>if guix gets armv7l support it will even run slightly faster :) *CompanionCube has an rpi3 but i run archlinuxarm for armv7l <apteryx>lfam: I just wanted to patch enabling its tests, and then noticed it wouldn't build :-) <apteryx>oh, Inkscape 1.0; I hadn't realized this was a thing. <mehlon>anyway I'll submit an issue to guix for busybox support <oscar123123>hey folks, I'm new to guix, I'm trying to run firefox but it needs libstdc++ and libgcc which are missing <mehlon>otherwise there's flatpak or nix <apteryx>oscar123123: have you tried Icecat? It's Firefox, minus branding, and some privacy minded tweaks. <oscar123123>apteryx: yeah tried it but I prefer firefox to be honest <mehlon>I mean icecat does not work well <mehlon>I think firefox works if you use flatpak <mehlon>I really dont see the point of using librejs or spyblock either way <bandali>i would *highly* recommend icecat over firefox <bandali>but of course i’m biased (am icecat maintainer) <mehlon>ublock origin + noscript + firefox's new enhanced tracking protection is better <bandali>by default firefox does a lot of data collection etc <oscar123123>is there any equivalent to `apt-file` in guix world? I want to know which package provides a certain file <oscar123123>bandali: ok I'll take your word for it, but icecat is like 12 version behind the firefox, isn't it? <mehlon>actually it's up to date now, if you run guix pull <bandali>firefox sync has currently been disabled <bandali>we might enable it at some point in the future <bandali>esp. if we can run a hosted version of the sync server <jojoz[m]>My solution was to stop syncing bookmarks. Obviously not viable for everyone, but personally I find I miss it a lot less than I thought I would. <bandali>also, currently, icecat only tracks firefox esr releases, so latest version is 68 <bandali>though icecat doesn’t yet have a stable 68 release (working hard on that) <bandali>guix has a ‘preview’ version of icecat 68 *kmicu is dissapointed to miss the opportunity for an Alpine joke. <mehlon>kmicu: I always pronounce your name as if it was in lojban <oscar123123>i'm new user but man guix is massively different to what I used up until now <kmicu>(The moment after nckx’s ‘Does Apline even GNU’ would be perfect ;) <oscar123123>so how can I ask guix to add the symlinks for a package from /gnu/store to my local .guix-profile ? <kmicu>mehlon: thank you so much, but I gonna wait for the next organic opportunity 😺 <oscar123123>ok then something is broken "build of /gnu/store/jxi9q3ajgs1d8k78jcwh8x0h6dizdlm9-guix-system-tests.drv failed" <nckx>Not when ‘guix install’ing packages as you'll be doing now. <oscar123123>i installed some package with root and some other packages with my user <mehlon>do guix build packagename for more info <nckx>oscar123123: That error message should be near mention of a log (.bz2) file. <mehlon>that's the great thing about guix: finally no more sudo! <oscar123123>nckx what's the convention ? only install using local user ? <nckx>Ah. Yes. It shouldn't be necessary to run ‘guix pull’ as root while managing ‘your’ software. <mehlon>guix pull will update guix for all users <nckx>The one exception is updating the daemon on a non-Guix-System distribution. <nckx>Results may vary. Please ask a qualified foreign distro professional for advice. Do not guix pull drunk. <mehlon>it doesn't matter whether you install only for local user or for whole system since it works the same either way <nckx>mehlon: Don't the installation instructions result in a guix-daemon.service that takes its daemon from the root profile? They used to. <mehlon>cat /var/log/guix/drvs/jx/i9q3ajgs1d8k78jcwh8x0h6dizdlm9-guix-system-tests.drv.bz2 | bzip2 -d <nckx>oscar123123: ‘View build log at…’ is what you want. You can view it with bzless, for example. <nckx>mehlon: Bad, bad use of cat! :3 *nckx .bz2 < bunzip2 | cat <mehlon>you mean <bz2 bunzip2 > /tmp/tmp && tee /tmp/tmp /dev/null | less <oscar123123>it seem like a bug in the package "In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f" <nckx>oscar123123: Could you paste the full log to the 'bin? Or at least a good part of the tail. <nckx>janneke: Could you take a look at that log? <nckx>oscar123123: In the meantime, try ‘guix pull --commit=451775a5675cdf1dfb9f4503427442b21bb5041a’ to pull from the previous commit that should work. <nckx>This is indeed a bug in Guix master. <oscar123123>nckx: so when i do pull what happens to the packages that I installed using root ? <nckx>oscar123123: No packages are affected by a pull. It only changes (updates) the set packages that can be installed with other guix commands, by the same user. <nckx>It's like ‘apt-get update’ or whatever. <nckx>Just slower 🙂 (Which is being worked on, but, er, slowly.) <oscar123123>and I have a package in my /gnu/store/ which is /4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib . is it right to assume that the package name is gcc in this example ? <lfam>Or, it's related to the package name but there is not a guaranteed exact correlation <nckx>oscar123123: and it's the ‘lib’ output of a ‘gcc’ package (so gcc:lib). <oscar123123>ok so I don't have access to it via guix, when i do guix install gcc unknown package, i know about the toolchain but it's weird that gcc itself isn't there <nckx>janneke: Oh, hi! I'd just reverted it on master. <janneke>oscar123123: what command did you use? <janneke>nckx: ah, thank you ... any idea what went wrong? <nckx>oscar123123: I don't know, I don't know how to combine the ‘guix install -e '(@@ (gnu packages gcc) gcc)'’ trick with outputs off the top of my head. <leoprikler>because gcc without toolchain is not really functional IIRC <nckx>oscar123123: Because people kept installing ‘gcc’ wanting a working ‘gcc’ this drastic choice was made. Also not a fan. <oscar123123>nckx, oooh boy, that's a killer decision, I need a libstdc++ <nckx>janneke: Can you reproduce this with guix pull --commit=a23091880d4dc6115acbfa3b7ef09d731fc5abb0 <janneke>ah, that makes sense; good to have a command that could fail \o/ <nckx>oscar123123: There is a *filthy* hack: gcc-objc is not hidden and has a :lib output that should inherit all that junk from gcc's trukn. <nckx>Try installing gcc-obcj++:lib or gcc-obcj:lib. <nckx>Note that I'm not saying you should be doing this, since I don't know what you're trying to achieve; just handing you the gun. <oscar123123>nckx thanks, that's what i've asked for and I'm responsible for my own mess :)) <janneke>nckx: guix pull --commit=a23091880d4dc6115acbfa3b7ef09d731fc5abb0 reprocuces it for me <nckx>janneke: ‘Great’! Would you mind debugging this? I'm actually supposed to be working. <oscar123123>to be honest this gcc decision and hidden gcc pissed me off a bit. because i expected guix to be hacker friendly, i shouldn't really try to do something liek a jail break here <janneke>nckx: of course, thanks for identifying and reverting <janneke>i'm off to be soon, but no hurry right? <nckx>janneke: Whenever suits you. <leoprikler>I never had to install GCC on my system and can still hack 🙂️ <oscar123123>leoprikler in many places i'm sure it is , but i mean the gcc part wasn't so much *janneke cheers as nckx allows them to sleep <mehlon>well I mean the solution is *obvious*........ program in scheme exclusively <nckx>oscar123123: The decision was made because hackers and others kept coming into this channel, more than weekly, to ask the same identical question. I don't like the solution very much but it was made in good faith. Other suggested solutions (like guix install --force) do not seem to me to be an improvement. <leoprikler>Even if you program in C, `guix environment` FTW! <oscar123123>what about changing the package name to something beside gcc <nckx>‘gcc-toolchain’ was and is documented in the manual but that didn't help. <nckx>What does that even mean. <nckx>I hate ‘names’ like that 😛 <leoprikler>there is no need for an "internal-build-essential" <kmicu>The GCC Toolchain is the chapter in docs and folks ignored it anyway? <nckx>oscar123123: Sure, your question is legit. I meant the deluge of folks asking the opposite. <kmicu>I see the same situation with ghc and haskell in Nix. :/ <nckx>If only our channel bot was, y'know, open zource we could've had sneek trigger on ‘gcc’. <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs <kmicu>Darcs… nice. I see that our bot is the top quality code. <nckx>oscar123123: It's a technical (non-)solution to a social problem. No qvesh. *nckx remembers something about ‘working’, whatever that means. See y'all later o/ <mehlon>sneek: if you're so 'extensible' why can't we program you from the chat, huh? <leoprikler>I think we should have "sneek install <package>", where <package> is a hidden package <oscar123123>nckx well, i can see why people made this decision but it can make peoples life a bit hard. I'm trying to run firefox for like an hour now and at the end i used another package to find a libstdc++ <kmicu>We could write second bot and let them fight. <nckx>oscar123123: Sure, I agree with you personally, was speaking with my Guix project hat on. It is such a pretty hat. <mehlon>sneek is just here to remember what we say forever <mehlon>I guess he won't give up who he's working for so easily <mehlon>I mean aside from the total chaos and havoc it would wreak onto this channel I think it'd be nice to have a bot that can be reprogrammed from within the channel itself <leoprikler>sneek, gcc is a hidden package. If you need a complete toolchain for compiling and linking source code, what you really want is "gcc-toolchain". <sneek>I've heard gcc is a hidden package. If you need a complete toolchain for compiling and linking source code, what you really want is "gcc-toolchain".