<kcurtet>Hi im trying to build a ruby gem anystyle-cli. after the build the ruby-build-system tries to test the gem but it throws an error no Rakefile found. I want to bypass the tests to check myself the package.
<kcurtet>How to get info about the build systems? your read the code?
<jackhill>kcurtet: to your first question: you may want to look in the code for other packages that set #:tests? #f or (modify-phases … (replace 'test …
<jackhill>I think what knowledge I have as come from reading the code/working with them. I can't remember if there is a particularly helpful section of the manual or not (if not, there probably should be ☺)
<bone-baboon>I am having trouble installing Guix on a x86-64 computer. I have tried several Guix x86-64 installer images including latest, 1.2.0, 1.1.0 and 1.0.1. The system becomes unresponsive after the grub menu but before I am able to get to the graphical installer or a terminal. I am not able to switch to a terminal with `C-A-<function-key>`. Here is the output before the system becomes unresponsive for the different instal
<lfam>It sounds like the installation completes, but the computer fails to reboot. This means the config.scm should be on the disk
<lle-bout>lfam: mhm I guess there is different interpretations of their message but if they are talking about GRUB it must mean things are installed..? Not sure.
<lle-bout>bone-baboon: I would suggest maybe downgrading/upgrading kernel version during install if you could even get to that.
<bone-baboon>lfam: To clarify the installation does not even begin installation before the system becomes unresponsive. The grub menu is for selecting to begin the installation process from the install image.
<lle-bout>so I believe that Cuirass at ci.guix.gnu.org being broken we are no longer getting new substitutes.
<wehlutyk>Following up with my question about poetry <https://email@example.com/msg11274.html>, I'm getting Phil's and zimoun's drift that I should stick with guix for packaging, so considering introducing colleagues to guix. So question: does anyone have experience installing guix on macOS? Is it possible? Should I try to discuss this on other channels as it involves a non-free OS?
<lle-bout>wehlutyk: macOS is completely unsupported AFAICT. Use GNU/Linux.
<wehlutyk>lle-bout: is it not supported because nobody did it, or because it goes against policies?
<wehlutyk>I'm asking because in many research environments the primary laptops are macs, and while HPC infrastructure runs GNU/Linux, people will already be doing a lot directly on their laptops whenever possible. That is at least my experience in several research institutions, whether they are more or less computation-oriented.
<lle-bout>wehlutyk: It's going to be quite an amount of work, but I don't think it goes against policy. Nor do I think people have much motivation to get GNU Guix working there.
<lle-bout>wehlutyk: GNU/Linux works well on Apple computers!
<lle-bout>Just choose a distribution, maybe not GNU Guix System, but another then install GNU Guix on top.
<wehlutyk>lle-bout: I don't have the resources to convince my colleagues to move away from macOS, but I do have them to convince them to use guix if I can make it work on macOS (and I know they have incentives to do that). Then flipping them could be a second step, but I think it involves a lot more convincing, so it's not my topic here 😛
<lle-bout>wehlutyk: Supporting macOS in GNU Guix will takes years (to actually get to a support as good as on GNU/Linux), so that gives you plenty of time for convincing, the latter is certainly easier :-)
<bone-baboon>Using the 0.16.0 installer I am able to attempt a manual install. This is better than the system going unresponsive as it does with the 1.x.x series of installer images. However I get an error at the last step `guix system init /mnt/etc/config.scm /mnt`. The error as well as other relevant information including config, partition information, file system information and luks information are here: https://termbin.com/
<lle-bout>bone-baboon: --no-substitutes on GNU Guix commands but I really don't know how 0.16.x installer works.
<bone-baboon>lle-bout: Okay I will try using that flag to disable substitues.
<lle-bout>bone-baboon: beware, it will try to build everything from source, but that's the only thing you can do.
<bone-baboon>lle-bout: I expect it to take a while. I will check back here when that attempt is completed and will share the results.
*bone-baboon begins Guix manual install with 0.16.0 installer
<lle-bout>seems I screwed up a bit on the docker update, forgot to update source hashes that also depended on that %docker-version variable. Doing so now.
<wehlutyk>lle-bout: (sorry for the lag, had to go to lunch.) Again, I don't see a macOS->GNU/Linux conversion of colleagues happening in the time span of my contract here, and I'll have to start over with new colleagues at the next contract (whereas support for macOS is something I can transfer to another lab). If you think support for macOS would be a bad idea (as in providing the benefits of guix without bringing people to a
<wehlutyk>free/libre OS), then maybe we can discuss that. I think macOS support could bring a big change to scientific reproducibility, so I'm interested in what kind of effort that could be 🙂
<wehlutyk>More to the point: I had no idea it would take years to get support comparable to that on GNU/Linux... where should I start looking if I wanted to dig deeper there?
<lle-bout>wehlutyk: You will need to create a new bootstrap path, e.g. x86_64-darwin
<lle-bout>wehlutyk: have a look at the wip-ppc64le branch, similar thing but for powerpc64le-linux
<lle-bout>wehlutyk: But many details of GNU Guix depend on GNU/Linux and it is likely even more complex that this port to powerpc64le-linux we have been undertaking. There's areas of totally new research for me there, so I wont be able to help on everything.
<lle-bout>I don't know if glibc works on darwin at all
<lle-bout>wehlutyk: so few steps: package (or install) all deps of GNU Guix within brew, cross-compile 'bootstrap-tarballs' package to x86_64-darwin from GNU/Linux
<lle-bout>wehlutyk: build GNU Guix with --with-courage added as arg to ./configure on macOS, add previously cross-compiled 'bootstrap-tarballs' to GNU Guix sources, try to get './pre-inst-env guix build hello' to work natively on macOS.
<lle-bout>Once you're there, you've probably done the most difficult work.
<Whyvn>I am trying to edit my /etc/pulse/default.pa but since its from gnu/store I cannot. What is the recommened way of editing this? I am trying to comment out a line so that .esd_auth is not im my $HOME dir and people suggest commenting out the line module-esound-protocol-unix.so inside of /etc/pulse/default.pa
<lle-bout>civodul: I have security updates to apply to desktop packages in GNOME or KDE eco-systems and since these are very interdependant it is more complicated.. right now I am thinking gvfs or kdeconnect
<lle-bout>Let's say security situation is GNOME/KDE desktop in GNU Guix right now is uncertain, on the other hand, since XFCE is easy to bump in general, we're pretty much clear there.
<lle-bout>raghavgururajan: We should at least stay in the GNOME supported releases, at this time, 3.36 is still supported AFAICT, but I am not so knowledgeable about GNOME release policies.
<lle-bout>raghavgururajan: if not GNOME upstream supported, I think we should look at the support some other mainstream distro is providing like Ubuntu, Debian or Red Hat then nourish ourselves from their work by closely following the versions they are supporting to lower our maintenance load.
<raghavgururajan>lle-bout: I understand. Also, then reason GNOME work got messed up is that, in wip-desktop,  I was not just working gnome packages, but also its dependencies  Work involved not just updates, but also improvements. This kinda complicated the "update stuff" norm.
<lle-bout>raghavgururajan: That's great, maybe we want to get stuff merged as soon as possible then work from there instead of delaying bunch of changes for too long because they would be WIP
<lle-bout>I think we are suffering the same kind of syndrome (somewhat) in wip-ppc64le
<efraim>lle-bout: I'm in and out a lot today, right now I'm not at home
<raghavgururajan>lle-bout: On a note, I put more work on myself. When I was working on wip-desktop, I made larget commits instead of 'one change per commit'. So after a discussion, I was asked to split them into smaller chunks. So I need to get #42958 out of the way.
<leoprikler>I'm currently rebasing it onto master and it seems to be ~100 commits
<nckx>jlicht: It could certainly be; don't ever hesitate to ask/investigate such things. If they are bundled and rebuilt, they should never be included in ‘guix build --source mono’; that's a bug in itself if they are.
<lle-bout>leoprikler: no idea, 3.36 sounds better than 3.34 though, but 3.38 wouldnt hurt
<leoprikler>thing is we don't have a wip-3.38 branch and it's have to go to c-u first anyways unless we squint really really hard
<montxero>It boots into a terminal, when I try gnome-session, I get lots of warnings. The first is `gnome-session-binary: Warning: Falling back to non-systemd startup procedure due to error: GDBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files`
<montxero>then a while page of more errors and warnings
<nckx>efraim: Your Savannah GPG key has expired. Could you update it?
<cbaines>civodul, just looking at the Guix Data Service processing of the wip-build-systems-gexp again. Looks like the profile-collisions checker generates some invalid G-expression input error
<montxero>With xfce4, when I try `xfce4-session`, I get `Unable to init server: Could not connect: Connection refused
<lle-bout>montxero: can you send output of 'guix system describe' and your config.scm?
<nckx>n1x_: You'll have to try to build ‘minimal’ versions of such packages for others to depend on. They can be private (‘define’ instead of ‘define-public’) or public depending on how useful they are for end users.
<leoprikler>cbaines: does patchwork test intermediate commits as well or only the series as a whole?
<cbaines>leoprikler, the series as a whole (although checks are reported per-patch)
<lle-bout>If anyone is interested, fixing security issues in GNU Guix is often only about knowing about them, so you can follow <https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml> with an rss reader and at a glance you can view the most recent entries any day you can and filter out the ones about nonfree software or unpackaged free software with few GNU Guix searches.
<nckx>Well, I build my own substitutes, so I'm not average. I also don't use Go.
<lle-bout>It is average traffic RSS feed (~10 entries per day)
<nckx>lle-bout: Do you know about any good (Free) RSS-to-e-mail adapters?
<zimoun>lle-bout: about your question, yeah it is not the first time someone says so. :-) The idea is to explore how it is possible to contribute to Guix without commit access. As it is pointed out, yesterday for example, more committers means more potential weakness. And from my point of view, there is too much granted people and until we will not have a clear rule to ungrant people (who do not often use their commit access or do not review,
<lle-bout>zimoun: I think that we can trust committers, but we need to provide better tools for them to secure their computing, e.g. require hardware security key for PGP signing of commits somehow (that GNU Guix can fund)
<nckx>zimoun: A simple ‘commit access is removed after N months of inactivity and can easily be rerequested’ policy has been suggested, but as you say the problem is deeper.
<nckx>efraim: Thanks! I've sent you ~encrypted mail~.
<nckx>Or, as it's called in Belgium this week, crime-mail.
<lle-bout>Today GNU Guix without as many committers would grind to a halt due to human bottleneck issues, it already kind of does. We need better review tooling and better flows of information for everyone to see easily.
<lle-bout>nckx: because malware will not be able to sign commits without the committer explicitly pressing the button and approving the malicious request displayed on screen which will raise concerns to the committer (or should)
<nckx>I don't know what's displayed on the screen, I've never had such a key.
<leoprikler>When we're saying reproducible builds, we don't mean reproducible signing keys.
<nckx>lle-bout: Not just convenient, but actually secure. If malware can send whatever it wants to the key, a hardware ‘sign’ button isn't security. Unless the key shows the actual data being signed in a readable form, a screen isn't either.
<lle-bout>nckx: the point of the screen is not the computer sends whatever it wants to the key, it never does that
<leoprikler>It's actually less secure than the same information on the computer screen.
<lle-bout>it's the key gets data being signed and produces useful verification screen inside the key
<lle-bout>I don't know if commit hashes can be produced standalone or need the whole repo to generate
<nckx>It's not searchable if you don't know what it does ;)
<nckx>pkill9: “Seatd is a minimal seat management daemon, and a universal seat management library. Seat management takes care of mediating access to shared devices (graphics, input), without requiring applications like Wayland compositors being granted root privileges”
<pkill9>that way it can be used with sandbox native applications with firejail
<pineapples>nckx: Hold on. I think I'm wrong. I think I only tested sway with libseatd support compiled in, with elogind, not seatd, to see if I was to implement a change that allows Sway users to use seatd wouldn't affect elogind users
<pineapples>Either way, if anyone wants to upstream my packages for me, I'm open for suggestions
<bone-baboon>nckx: Yes that version number of the installer was a typo.
<bone-baboon>I am trying to install Guix on a x86_64 computer. I have tries several x86_64 installer images but am running into different issues.
<bone-baboon>When I try the latest, 1.2.0, 1.1.0, 1.0.1 installers the system becomes unresponsive before the install is able to begin and before I can get to the graphical installer or a terminal. This is the output I get when I try using those installers: https://termbin.com/xkk1
<bone-baboon>With the 0.16.0 installer I was able to work through a manual install but when I try running the last command `guix system init /mnt/etc/config/scm /mnt` I get this error: https://termbin.com/n2w6
<bone-baboon>With the 0.16.0 installer and that same same manual install setup described previously when I try to run `guix system --no-substitutes /mnt/etc/config.scm /mnt` I get this error and build log.
<roptat>if you look at the definition for sysctl-service-type (gnu/services/sysctl.scm), you can extend it by passing a "settings", which is whatever can go inside the settings field of the sysctl-configuration
<roptat>so, I'd pass '(("fs.protected_hardlinks" . 1) ...) to the simple-service, not the whole sysctl-configuration record
<roptat>paniash, we don't propose non free software, but we don't prevent you from using them either
<lfam>It's not crashing immediately roptat. Thank you so much!
<paniash>roptat: I understand, i'd rather use a piece of software which is officially supported. but good to know that proprietary blobs can run. thanks!
<roptat>paniash, if you're talking about firmware in the kernel, we use linux-libre wich will actively prevent you from loading binary blobs. Though, you can still build your own kernel from mainline and use it in your system declaration
<nckx>lfam: This network seems to block mail (whut?) but LGTM on the ping.
<roptat>we don't officially support that, but it's not too hard either (and most likely already documented elsewhere)
<apteryx>bone-baboon: it's also possible to add it to the kernel-arguments of you operating-system declaration once you've found something that works
<lfam>Thanks PotentialUser-47 :) I'm sure someone will pick them up eventually.
<lfam>jas4711: You can explore this area with the command `guix refresh --list-dependent inetutils`
<lfam>Sometimes, this command doesn't report all of the packages that will be rebuilt. It's based on the full graph of Guix package dependencies, but it doesn't account for changes to Guix build-systems
<zimoun>roptat: yeah, personally I am always confused by the multi-output, fetching and building a lot of stuff that I am not necessary interested in, as for git:send-email. And now ‘guix build z3’ will drag ocaml.
<nckx>Noisytoot: It's a fancy (and somewhat ‘marketing’) name for looking at the data instead of just the metadata. A normal firewall just (dis)allows specific ports, IP addresses, other ‘envelope’-type stuff; DPI will try to open them & decode the packets themselves.
<lfam>The only thing that could be improved is that it would be nice if we could manually reset the Savannah repo on our own, but it's not a big deal
<nckx>One hitch was: I had to ping rwp in #savannah to do the actual rewinding, luckily they responded immediately. Even ‘maintainers’ can't undo a DoS which is problematic. That and of course the remote hook not catching it despite lfam's old bug report.
<civodul>vagrantc: the data center of a major hoster in France/EU burnt yesterday, leaving thousands of web sites off-line
<lfam>I think, it's always been known the remote hook wouldn't catch this kind of thing
<lfam>These kinds of mistakes are a risk when people come back after a long absence
<lfam>Other questions I'm wondering about: What architectures do we officially support in the next release (armhf...)? When should we start building the release branch, for an April 18 release? And who will actually "do" the release?
<efraim>oh wow, I've been holding my ppc binutils-final patch for almost a year
<apteryx>gdk-pixbuf is not able to render scalable SVG icons (pretty basic stuff nowadays for an application)
<lfam>We can build it now, merge it to master, and then create the release-1.2.1 branch
<lfam>The important thing is that the release shouldn't include any grafts
<roptat>what I mean is that we'd like to prepare the release on master, branch when ready and make sure we have substitute for everything on that branch (in addition to what cuirass managed to build), then release
<lfam>This might mean delaying some grafts, or rebuilding the world twice
<lfam>The other side of this is coordinating access to the CI resources
<lfam>But, I think we are in good shape for x86_64, which is what really matters
<lfam>It would be nice to get the rest of the overdrives connected to the build farm, but I don't know if it's going to happen
<zimoun>ah sorry, I have overlooked at wip-next-release because for 1.2 we did (almost) everything directly on master.
<lfam>I've been discussing it in the email thread you started
<lfam>We can't really do these things on master since they will rebuild almost every package
<zimoun>yeah, I agree. That’s my fault. And I agree about ungrafting too.
<lfam>But given my recent experiences with grafts masking serious problems, I think it's important to avoid including grafts in the release
<lfam>Alright, I'm going to update that branch today, and then I'll coordinate with mothacehe about building the branch
<lfam>I think we can merge it to master within a week, assuming there are no big problems
<lfam>I guess I am doing things a little backwards from how they've been done in the past. Sorry about that
<zimoun>ok, thanks. Well, currently I am checking the avaibility of substitutes on master. And try to fix «important» (to my eyes) packages that are broken.
<apteryx>raghavgururajan: as a GNOME package maintainer I think this is an important detail that you should know: anything that propagates gdk-pixbuf should propagate gdk-pixbuf+svg to stay in harmony with gtk+'s own propagated libs.
<apteryx>lfam: just to be clear, that 1.2.1 would include ungrafting changes mostly?