<dstolfa>nckx: btw if you'd like me to just bisect/report without pinging, just let me know :). i'm just pinging in case i run into common issues that i'm not aware of
<PotentialUser-83>howdy guix folk! newbie question: I can use 'guix system image' from a configuration file to build a custom live USB image, that I could boot from and use as a portable computer of sorts?
<PotentialUser-83>(e.g. work on the configuration I want to actually install on a computer, or just have a portable config the way I like to use anywhere)
<nckx>Bah, ‘record ABI mismatch; recompilation needed’, which takes a while on this machine, so bisecting won't be fast. Pinging is always welcome dstolfa, but since one of us has 20 cores, bisection would also be much appreciated.
<civodul>lfam: i think the "map(PROT_NONE)" failure is gone with 0aef94e7bcbd272720f14c5343f74da5201ef90a
<dstolfa>nckx: well, i tried to search for the obvious mistakes, but i don't have the brainpower to look for non-obvoius mistakes at the moment, it's past midnight and i spent the day debugging an IR type inference algorithm
<dstolfa>i now have two identical checkouts, one with a fresh run of ./bootstrap, and one with an incremental run of ./bootstrap, configured in the exact same way, one runs check-system, the other doesn't
<nckx>Well, running ‘make clean-go’ is a ‘known’ requirement… amongst those in the know. It's why I ran it as part of bootstrapping (without thinking) and noticed the tests now passed. However, I think it would make sense to run it as part of ./bootstrap. It's arguably surprising that it's not and can only reduce evil statefulness.
<nckx>Problem is it will still be opportunistic, because you can't always assume make works at that point.
<nckx>Although you could just invoke find -delete if that's a concern.
<dstolfa>right, so every git pull, i need to re-bootstrap everything from clean?
<nckx>Sending your reply to nnn-done at debbugs dot gnu dot org simultaneously closes the bug. If you just want to close a bug without having something to say, as in this case, send ‘close nnn’ to control at debbugs dot gnu dot org.
<helaoban>hey guix! if there are any virtualization gurus here, I'm trying to run guix system in a vm with qemu but I'm not able to reach a console / login prompt.
<helaoban>The image boots fine and I can ssh into it, but I can't get any io in the terminal directly. I can see some output from Grub, but everything goes away once the kernel starts booting and I never get a login prompt.
<helaoban>it looks like the tty option is set to #f by default in agetty-configuration, maybe it needs to be specified?
<lfam>"Valid terminal input names depend on the platform, but may include ‘console’ (native platform console), ‘serial’ (serial terminal), ‘serial_<port>’ (serial terminal with explicit port selection), ‘at_keyboard’ (PC AT keyboard), or ‘usb_keyboard’ (USB keyboard using the HID Boot Protocol, for cases where the firmware does not handle this). "
<Guest4977>Hello guix, since yesterday I'm still fighting with my fresh cross-builded pinebook-pro.scm image running on real hardware and I'm currently stuck with: 'guix pull: error: Git error: the SSL certificate is invalid'
<Guest4977>I've exported environmental variable GIT_SSL_CAINFO from 'guix environment --ad-hoc git nss-certs' and after 'herd restart guix-daemon' the error is still the same
<viivien>Hello guix, I’d like to create a channel with my package. I’m considering switching my main project to AGPL. Does guix provide an easy way to keep track of the full source tarball (after modification phases) so that I can serve it with a web service?
<boeg>Does anybody know how to get icon themes working when using something like i3/sway instead of GNOME and the like? I'm testing with Thunar which doesnt have any icons right now. I have installed hicolor-icon-theme as well as papirus-icon-theme but no luck.
<viivien>avalenn, this distribution does not seem to insist on only shipping free software. There’s even an FAQ entry about how to run proprietary DRMs. I’m not sure many guix people will be interested.
<avalenn>I am sure no Guix people will install this. But I thought the concept of putting all in Git could resonate for some.
<civodul>maximed: in other news, gcc-cross-aarch64-linux-gnu-10.3.0.drv fails to build for me on core-updates: "aarch64-linux-gnu-ld: skipping incompatible /gnu/store/kvq1fgklb4288cn0g13jl8pvach4p3r4-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc"
<helaoban>roptat: read my mind, ok, just wanted to make sure I wasn't missing something.
<roptat>(it doesn't create the vlan, but it uses iproute2)
<zap>i cant say that it happily did guix pull btw :) It it crashed every time with error <corrupted archife <closed file 12345>> or something like that. Then I realized that my odroid xu4 goes out of memory. And indeed guix pull filled up more than 2G at some stages. After adding swapfile and waiting few hours it did got through
<roptat>zap, I have a similar issue on my armhf server, that's why updating the system always takes so long
<roptat>(that and the lack of substitutes for armhf)
<helaoban>roptat: that's what I was looking for, I can extend that for my purposes.
<helaoban>Would be super useful to have in mainline guix!
<leoprikler>phew, finally worked around my store issues and it only took one regular gc without options
<roptat>again, the plan is to use guile-netlink instead
<roptat>similar to iproute2, but better integrated with guile
<roptat>helaoban, if you use the dhcp service, don't make the iproute2 service provision networking, or there'll be a conflict
<zap>roptat: but it wasn't 'guix upgrade' i'm talking about 'guix pull' -- whether you have substitutes or not it will build allway build several derivations that fill the or I miss something
<nckx>A mere 2 gigabytes is far too little memory to update the list of packages.
<helaoban>roptat: looking at guile-netlink now, interesting.
<nckx>Modify phodav so it installs to its own /lib/udev/rules.d.
<nckx>Somehow, some change elsewhere managed to change Meson's behaviour here, which is interesting. Maybe.
<hugotty>Hello there, I'm trying to run guix on my remarkable 2 tablet using the armhf build. The daemon is up and running but now when I try to run `guix install hello` I get this error: "guix install: error: cloning builder process: Invalid argument" What could cause this?
<nckx>soheilkhanalipur: I've started a git bisection to see what caused it.
<nckx>hugotty: That means clone() failed. You seem to be missing the kernel namespace support which the Guix daemon needs to isolate builds when run without --disable-chroot (which is the default). Which distribution and kernel is this?
<nckx>I guess it doesn't really matter unless you want to recompile your kernel. Try adding --disable-chroot to the daemon command line (if you're using systemd, that's guix-daemon.service), reload, and restart it.
<hugotty>nckx: Thanks a bunch, --disable-chroot seems to have done the trick. It's running on whatever vendor kernel they ship with the device plus systemd and their e-ink gui software on top, and I am not savvy enough to be tinkering with kernels ;)
<sbp>yeah, this is what I'd have to check. but you don't need to patch it out because podman and buildah already exist. that's what I was hinting at: that instead of having some sort of IceCat situation where Docker has to be meticulously patched to be free, you can just recommend podman/buildah
<sbp>what I'm thinking is that the manual could just mention podman and buildah where it presently mentions Docker, problem solved (if there is a problem in the first place)
<nckx>But all you've done so far is ‘imagine’ there's some problem with Docker.
<sbp>well, kind of. I recall seeing problems, but I don't remember the specifics. I was highlighting a potential problem, not suggesting that there is a problem for sure!
<nckx>(Which is a very poor argument for replacing it with two things I've never even heard of)
<sbp>as I said, I'd have to check. it'd be on me to check, I'm under no illusion about this
<sbp>I have been reviewing the logs, but there's only so much that I can read :)
***iskarian is now known as Guest3676
<nckx>sbp: I had no idea you were new, your nick sounded much more familiar than that. Welcome.
***iyzsong- is now known as iyzsong
<vagrantc>it seems guix tends to take the pragmatic approach of "we'll do our best effort to avoid FSDG issues, but please point to *specific* issues that we can actually address"
***iskarian is now known as Guest806
<nckx>vagrantc: Specifically in the case of browsers, a menu item that takes you to a ‘store’ that lists nonfree things amongst free ones, or doesn't even care about licencing.
<vagrantc>hypothetical or speculative issues are time consuming for little gain
<nckx>vagrantc: Anything else is borderline theatre IMO. It's pretending your distro treats all packages equally when that's obviously impossible, so in practice it's a known list of packages ‘we’ don't like receiving disproportionate scrutiny.
<nckx>Like random people insisting we audit Chromium or remove it.
<sbp>"Most distribution development teams don't have the resources to exhaustively check that their distribution meet all these criteria. Neither do we. So we expect distros to occasionally contain mistakes: nonfree software that slipped through, etc. We don't reject a distribution over mistakes."
<dstolfa>there are definitely people out there who would rather have no software than something that doesn't conform 100% to their ideology or political belief (even if it does, they might find an excuse that the author of that software doesn't meet their perfect criteria)
<nckx>roptat: (I mean, yes, exactly, where are the signed documents from underpaid students forced to audit it? Oh no best effort is fine *there*)
<vagrantc>it seemed to go along the lines of "there's probably a problem" ... "well, i've audited thousands of files and removed all the ones identified, did i miss any?" ... "you can
<vagrantc>'t possibly audit it all! there's probably still problems!"
<nckx>sbp: Yep, that's why I asked for details, not because I think you're lying :)
<munksgaard>I'm trying to define a package using haskell-build-system, but I cannot figure out how to specify that I want to use email@example.com instead of (what I think is the default) firstname.lastname@example.org. I see that there is a #:haskell argument, but if I write ``(#:haskell ,email@example.com)` as an argument, I get an error that firstname.lastname@example.org is an unbound variable
<maximed>it might be a good idea to automatically define OBJDUMP=..., STRIP=..., CC=..., but that seems more something for the next core-updates cycle to me
<civodul>plus it's normally unnecessary, at least for Autotools-based build systems
<maximed>so, set OBJDUMP in #:make-flags for now, and report it upstream?
<sbp>nckx: obviously I've not had long to look into this so far, but I haven't found that the Docker *CE* software in and of itself would violate the FSDG. the Guix manual does, however, link to both the Docker and the Singularity homepages, both of which are designed to onboard people to their commercial offerings
<maximed>Hopefully that's all that needs to be done
<munksgaard>After specifying `(#:haskell ,ghc-8.8), it seems like all the other dependencies I've specified as inputs are no longer passed along? This is the file I'm working with: https://pastebin.com/uzi1uU1c . Upon trying to build, I get a lot of missing dependencies. If I remove line 471 those all go away (but I can't build because the `base` package and other builtins are too old).
<sbp>nckx: it also links to the documentation for "docker load" on the Docker website, which I think is a more borderline case. I couldn't find a reasonable alternative either, except perhaps Ubuntu's hosting of the man page for docker load
<sbp>I believe the links to the Docker and Singularity homepages are both FSDG violations. consider this my report. I can duplicate to a mailing list or issue tracker etc. if need be
<munksgaard>Do I need to specify that all the other dependencies should also be built with ghc-8.8?
<civodul>maximed: i've joined #glibc on oftc to see what they think
<raghavgururajan>What is the difference between having alsa-service-type (which defaults to pulseaudio) or pulseaudio-service-type or both?
<leoprikler>pulseaudio-service-type does your pulseaudio settings which atm defaults to disabling flat-volumes like any sane distro
<nckx>That has always been my (personal) view on the matter.
<dstolfa>IMO, it doesn't matter if the software's home page recommends non-free things. what matters is that whatever you get to use as an end-product in guix doesn't by default advertise anything as that program
<nckx>‘The internet is scary and trying to contain it is folly.’
<dstolfa>otherwise you may as well just remove 90% of the software
<PotentialUser-40>irfus: thanks for the patch, I will try to build it tonight (I really need to log on here proper, was just browsing the log and saw your message)
<dstolfa>nckx: we should remove gnome.org too then
<munksgaard>So is the #:haskell argument to haskell-build-system just totally useless? I want to build the versions package using ghc-8.8, but it requires some other packages already in the guix system (ghc-megaparsec and others), and they're reported as missing dependencies when specifying ghc-8.8. I'm guessing it's because those packages were built with ghc-8.6. Do I need to manually import every single dependency and specify that they should use 8.8?
<dstolfa>gnome.org lists digitalocean, aws, google and a few others on their home page. is that now a probleme too?
<dstolfa>it also has twitter, facebook, linkedin, youtube, etc on its home page
<sbp>if Firefox cannot be packaged for Guix because it links to "Mozilla’s add-on catalog, which contains non-free software", then I don't see why the Guix manual can link to the Docker homepage or the Singularity homepage
<nckx>Yes, it is a matter of (literal) degrees of separation.
<nckx>I'd need to think about it more to write a thought-out response, but not linking to home pages feels wrong to me. Towards our users.
<PotentialUser-40>munksgaard: I've found the haskell system to be a bit messy, lots of older packages, and so need to update a lot of them together. there's also a patch to update haskell-build-system to handle nontrivial configures
<sbp>nckx: two clicks by my count. if you go to the Firefox addon store, you have to click twice before you've downloaded non-free software. it's the same number of clicks on the Docker homepage to do the same
<sbp>which means by your own metric it's exactly the same
<civodul>nckx: seconded; i mean, Docker is free software, it can and is being used to run free software
<nckx>I'm going to stop you right there, this language isn't doing it for me sbp.
<sbp>civodul: sure, but the Docker homepage has the enterprise version available
<sbp>if it were a link to the Docker CE specifically, that'd avoid the link to download the non-free software
<nckx>Don't (incorrectly) quote my supposed words at me like some imaginary checkmate.
<munksgaard>PotentialUser-40: Yeah, that's seems close to my experience. Any idea how to help improve the situation?
<civodul>ah well, sure, the project doesn't endorse that, but we're not going to give up on <a href="...">
<dstolfa>again, how is this any different to linking to gnome.org?
<dstolfa>it's 1 click to get to non-free software on gnome.org
<sbp>civodul: sure, but it's the specific reason you gave for why Firefox couldn't be packaged for Guix
<dstolfa>that doesn't mean it's the same thing as a literal addon store that installs it on your computer instantly
<sbp>if you're not going to give up on <a href="..."> for the Guix manual, why does Firefox have to give it up to be packaged for Guix?
<PotentialUser-40>munksgaard: I'd like that patch to be merged, as that is stopping some updates I think. I have a handful of updated haskell packages that go together too, that I needed to try to build something. it is tedious but easy to go through and update them as you need, but it would be good to get everything to current versions
<civodul>sbp: the two are very different, as has been explained multiple times above
<civodul>i don't think we need to reask the same questions over and over
<PotentialUser-40>munksgaard: so I guess submitting patches with updated versions, inevitably something will break because of newer version, fix that, rinse and repeat?
<nckx>sbp: OK, sorry then. It's just that discussions like this one polarise very quickly, because it's an apex of politics and bikeshedding, and positions quickly ossify and people dig in their heels and the public nature of the ‘debate’ does no favours. I've been there before.
<sbp>nckx: understood. I don't have a stance on the issue, I'm just trying to understand. I'm using non-free software to write these words to you. I'm not a member of the FSF. I truly only want to understand the problem
<sbp>the wider context is that I'm trying to understand how I feel about Guix in general, as software, as a community, as many other things, and what my potential contributions could be
<PotentialUser-40>munksgaard: noted from bug report on something failing with needing cabal-doctest in configure. some packages were working around that, but I think this would help not need custom build defintions
<munksgaard>PotentialUser-40: Ah yes! Yeah, that's actually my bug report, but I hadn't seen that patch.
<vagrantc>mbakke: i'd be curious to see how it compares to the debian one...
<nckx>Sorry for not assuming best faith, sbp. The ‘by your own logic’ phrase brought to mind people who want to force an open conversation into a final logic!™ endgame, where some conclusion is Obviously Correct and the matter is Settled. That will *never* happen here. It's a flipping FSDG Zen koan.
<PotentialUser-40>munksgaard: it is my patch : ) (I really need to log in via my matrix server)
<munksgaard>Thanks for the work on the patch, it works perfectly for me as well. Now I just run into other problems...
<sbp>nckx: as some further context, a lot of my thoughts about Guix are situated around usability and intended audience. I've spoken to the Systemcrafter folk about this (not sure if you're aware of them), but I think I ran into the same problem
<nckx>civodul: In fairness, these aren't the same people asking the same questions. These are intelligent people asking rather intelligent questions for the(ir) first time. Where is the FAQ they should have read? The log we can point them to?
<sbp>that a lot of what I'm thinking about, though I feel like I'm coming at it from a very neutral point of view and with very little baggage, immediately gets caught up in preconceived notions of politics and other things that people have going on
<PotentialUser-40>munksgaard: welcome! I too ran into difficulties later, but in the actual haskell packages (I'm still pretty new to Haskell, was trying to get taffybar working)
<dstolfa>sbp: i think the reason i assumed you were acting in somewhat bad faith was with the wording used around "consider this my report, i can duplicate it on...". to me that just sounded as if you're about to go to the FSF and complain about guix if it didn't immediately get corrected
<sbp>not at all. actually the opposite: I was offering to do extra work if it was required by the Guix community or its guidelines. sometimes I report a bug somewhere and people say "this is the wrong place, please submit to [ELSEWHERE] instead". I wanted to make clear I could do that if necessary, that I was not expecting somebody else to do the work for me
<sbp>if I reported it to the FSF, the first thing they'd do it report it to you ;)
<sbp>but I sorta considered FSF/GNU/Guix to be all quite tightly integrated so I don't even consider it really different. I don't know how the organisation works here, that's just my shallow understanding so far
<civodul>nckx: right! though i seemed to read the same argument multiple times
<nckx>There's something particularly noxious about people walking into a community to present their genious ideas that of course nobody in the community can ever have discussed to death before, and why-don't-you-just. You didn't do that, but unfortunately enough have in the past that we're easily triggered.
<nckx>…and you are underestimating the internal politics of GNU by several orders of magnitude 😉
<sbp>if I were going to contribute, I'd like to contribute in ways that people like. there are lots of things that I've been thinking about. contributing build servers, helping to answer comments in here, going through the issues list and finding ones that it looks like I can solve, packaging software
<PotentialUser-40>and that was after hacking the install script a little to move /gnu/store (with a mount --bind) due to low space on my root partition. I swear, I'm never partiioning root separate again, it always needs more than I expect
<nckx>sbp: Geniuses are overrated and overblown. Then I'd rather have you.
<na2th>PotentialUser-40: I came here a couple of days ago and people told me the best way to build my own package was to clone guix. I thought that was kinda crazy; now I have even sent a patch!
<Kitty[m]>na2th: I am unfamiliar situation but this is probably the best "wiki" and website I've seen for a gnu/fsf styled project lol
<nckx>It's not a guarantee (and the quip is in danger of becoming cliched and further losing its effect), but if you're the kind of person who even pauses to worry about Dunning-Kruger… you're probably not the problem.
<civodul>raghavgururajan: the contents of /etc/profile cannot be extended from nix-service-type i believe; is that what you had in mind?
<nckx>Oh, I thought they literally meant sudo emacsing the thing.
<nckx>na2th: the (extremely simplified) reasoning could go something like: if we're going to have a wiki, we don't want low-quality submissions, so we'll have editors & reviewers anyway, so then the only difference between the wiki and the rest of Guix is the Web UI, so why not use the workflow we use for everything else anyway.
<na2th>Can we exploit how guix hash packages to create a "refactor only" patch?
<nckx>There's this ‘if you host a Wiki they will come’ view, which, who knows, might be true, but the fact that we're hardly inundated with submissions makes me sceptical. Review is the bottleneck for code patches, but we get barely any documentation patches as is.
<na2th>When I looking around gnome.scm to patch evince I noticed that there is a common task of removing font-config; so I thought that I could create some auxiliary functions for that, or similar things
<nckx>I don't think open-access publishing would cause that dam to burst.
<na2th>perhaps something that becomes a "gnome build system" eventually
<na2th>but I thought that this could only make sense if I changed many packages in a roll
<na2th>which sucks, as it is extremely hard to check if I have broke something
<nckx>The glib-or-gtk-build-system is kind of the GNOME build system.
<viivien>Hello, what package has the "htpasswd" command?
<na2th>nckx: I wrote in the worst possible manner; lemme rephrase
<na2th>many gnome packages require a modify-phases that skips gtk update icon cache
<na2th>I noticed because my build crash because of it, and it was actually easy to fix because I just had to look around other packages
<na2th>nckx: but it is something "comsetic"; it is a scheme refactor with the aim of simplifying the code and not changing the packages themselves
<nckx>PotentialUser-71: Welcome! Do you mean running Guix System under Xen? (If that even makes sense, Xen in my mind is a KVM alternative but maybe I'm wrong.) I ask because it's quite possible nobody's tried, and it might be quicker to try than to wait for a reliable answer.
<nckx>na2th: Sorry to be dense, but what would this purely cosmetic refactoring look like? Guix (by design, for reliability) doesn't do clever things with the quoted build code before hashing it. Cosmetic differences like changing a variable name or swapping two idempotent things or the order of inputs (I think) will still change it.
<PotentialUser-71>nckx: Hello, the concept of Xen is different from the concept of KVM, in my case I want to use this to safely isolate each of my operating systems from each other, designed for different applications. I am an active user of Qubes OS, and I wanted to organize at least a little similar mechanism on GNU Guix, most of it is clear to me, but I don't kno
<PotentialUser-71>w how much it will work and be supported on Guix, for example, I don't even know how to isolate the drivers, but I hope that sooner or later my hands will reach this.
<helaoban>is there a way to be dropped directly into a shell with 'guix system container'?
<PotentialUser-71>I'm interested in compatibility with Xen, because I've heard that there seems to be an analog of Xen in Guix, perhaps it will work better, but I don't remember the name
<helaoban>my understanding is that you have to separately run 'guix container exec <container-pid> <some-shell>' after having started the container
<helaoban>unlike 'guix environment --container ' where you are dropped in directly.
<zap>PotentialUser-71: From what I know about Xen (I dont know much) it hypervisor living on hardware. And you have "domanis" in xen jargon as vm. You can basically have guix system domain running on xen
<nckx>PotentialUser-71: As you can tell I'm completely unfamiliar with Xen and can't answer those questions. I hope someone can. You should also send a mail to help-guix at gnu.org to reach a wider audience, but keep in mind that the number of people familiar with everything that you want to combine might be tiny or zero. You'd be treading interesting new ground if so.
<na2th>nckx: I did not have something specific in mind, to be honest. I was thinking about trying to develop some helper functions for some things that come up in many places throughout the gnome.scm
<zap>PotentialUser-71: "there seems to be an analog of Xen in Guix" there is guix container (that uses linux namespaces for isolation) and "guix system vm" that spawns vm from with your configuration. "guix system vm" uses KVM/qemu for virtualization. If you want to have desktop experience where some or all your programs run in isolation It will require configuration.