<Guix-beginner7>Lutris uses a meson build file but it has python modules I need to load. Is there a crafty way to add it using phases or should I guix import them from pypi and add them as guix modules? <pkill9_>Guix-beginner7: i would import them from pypi <pkill9_>Blackbeard: i got the banking site working, i dleeted it's cookies <raghavgururajan>apteryx If I don't mention "--enable-64bits" for libantlr3c (#40291), I get "fatal error: gnu/stubs-32.h: No such file or directory". <pkill9>ok i got sway to run in qemu, but it's not appearing, just freezes the screen <Blackbeard>pkill9: I have so much trouble with sway I gave up with it <pkill9>i just want a graphical environment in qemu really <lfam>Xorg should "just work" in QEMU <pkill9>it didn't last time, i'll try again <pkill9>lat time i tried was a while back <lfam>pkill9: I haven't tried in a couple months but it's always worked for me. Please report a bug if you have trouble with it! <pkill9>hmm i get a cursor in the virtual machine, but the screen is blank, either it's not working or it's taking ages to load <lfam>pkill9: Can you share your config.scm and the command line you used to build the VM and run the VM? <pkill9>i'm just running the script on it's own, /gnu/store/v5smnm2jdsm1sw89xb86q94sh79kyfkp-run-vm.sh <pkill9>when i do that, it starts gdm, and a cursor in the virtual machine can be moved around on a black background <Blackbeard>pkill9: if this is a virtual machine, why are you encrypting home? not that it matters, just curious <lfam>pkill9: I don't think you can use GDM in these read-only throwaway VMs <lfam>I recommend using `guix system vm-image` instead <lfam>I don't know exactly what goes wrong but I think that GDM needs to write some session info which fails <pkill9>Blackbeard: that's just leftover from my base image i copied <apteryx>raghavgururajan: I saw that Arch defines a different package for lib32. <apteryx>Perhaps what we can do for now, is 1) test it for the system i686, and if it fails there, mark is as not compatible with this architecture. <apteryx>mbakke: reading the thread right now <dustyweb>someone willing to help a noob to packaging elisp out a bit? <dustyweb>I have a program which has its emacs lisp files in a subdirectory <dustyweb>I actually don't know much about emacs-build-system but I assume it installs all the elisp it sees from the directory but I dunno <dustyweb>how should I package it so it installs stuff from that subdir? <dustyweb> (add-after 'build-info-manual 'chdir-lisp <apteryx>raghavgururajan: We have something documented about using the qemu-binfmt-service-type service. <apteryx>in info (guix) -> i qemu-binfmt-service-type RET will bring you to the right place. <dustyweb>raghavgururajan: ah that's true, sorry :) <raghavgururajan>apteryx Output 'out' should install everything right? And 'static' output installs just static libs? <apteryx>raghavgururajan: yes. You can 'git show 5d1a4133c8' to see what I did for spandsp, as an example. <apteryx>(I reused another example from linux.scm myself :-)) <raghavgururajan>It seems static was moved, instead of copied. So that deletes static libs in 'static' output right? <apteryx>no, it deletes the static libs from the regular output "out", and places them under the "static" output. <apteryx>The point is to separate the outputs, so that the regular output is smaller. <apteryx>I meant to type: we might already have some sugar that means "install all outputs" when working with manifests. I'm not sure. <apteryx>From my experience the user that needs a specific output must manually install it. <raghavgururajan>Yeah. I was hoping 'out' to install everything. Then for minimal or specific install, user can choose an output. <apteryx>"out" should be sufficient to run the program, but if you need something unusual such as a static library, or HTML documentation, then it is expected that the user look for other outputs. <nckx>raghavgururajan: Wanting only :out is probably the most common, in fact. :foo is usually ‘big stuff that most people don't want’. <nckx>Maybe a :* (let's not hard-magic :all) notation on the command line would be cool, yah. <raghavgururajan>apteryx Ah I see. But why for gtk+ there is 'out' 'bin' 'lib' 'doc'? The 'out' isn't sufficient to run. I always get error when I just put 'gtk+' in inputs. Either missing command or library error. <nckx>raghavgururajan: Because ‘sufficient’ depends on the context. <raghavgururajan>nckx I agree is common. But I see 'out' as 'all' logical. Because when nothing is mentioned, it installs everything. When minimal is required or user knows what they are looking for specifically, then user can mention specific output. <nckx>raghavgururajan: You're a bit misleading 😉 Your list doesn't make sense, indeed, but then that's not the real list of outputs: it's out,bin,doc, with :lib being simply the default :out. And that makes a lot of sense. The vast majority of gtk+ users want to own the libs, so :out is indeed ‘sufficient to run’ in the majority of cases. <nckx>raghavgururajan: No, ‘out’ means default. <nckx>Imagine if ‘knot’ meant ‘all outputs’. Installing ‘knot:out’ wouldn't even make sense. ‘Just the outiest things, please.’ <nckx>But I see your point. I think a ‘:*’ notation would be a better backwards-compatible solution *if* we decide to do it, though. <raghavgururajan>Btw, I am not sure about how static libs are used. If they are not necessary, then I'll just disable it. <nckx>We only build static libraries if something else requires them (e.g. initrds), otherwise we try to remove them even if built by default by upstream. <raghavgururajan>Okay, so I'll disable them in my package definitions for now. If we need them n future, we can enable at that time. <nckx>Yep. And even if we do (although I doubt we'll be phoning from our initrds any time soon), the ‘static-package’ magickifier works surprisingly well considering how crazy it is. <raghavgururajan>Btw, where those static libs gets installed? I don't see any 'static' directory inside installation directory. <nckx> /lib/*.so = dynamic libz. <apteryx>they're big and not very useful in the context of Guix (unless for initrds as mentionned by nckx). <nckx>They're also a potential security risk since they're ungraftable, which is why we delete them with such extreme prejudice. <raghavgururajan>Hmm. I have seen some comments online regarding static libs not included in nix. <nckx>Just in case something decides to link with 'em. <apteryx>Your user land programs are all dynamically loaded in Guix. This prevents duplicating copies of the same libraries over and over on the disk and in the memory. <raghavgururajan>I need to learn more about static libs and what it does. So that I can understand the security risks. <nckx>In a way, Guix/Nix provide most of the purported ‘‘‘‘advantages’’’’ of static libraries. <nckx>Without all the less subjective downsides. <apteryx>raghavgururajan: static libs are like a big bag where everything needed was included. They are self contained. *rekado_ apparently is not the only insomniac here <apteryx>all GNU/Linux distros share this property, I believe. <nckx>rekado_ is pitiful amateur but should still take care of themselves. <raghavgururajan>apteryx I see. May be I'll understand this better when starting to code. Where I will be using libraries. <raghavgururajan>apteryx When you asked me to mark the package as incompatible with i386, did you mean comment? Not sure what mark means there. <apteryx>raghavgururajan:actually for the i686 experiment, qemu-binfmt is not needed. A regular cross-build is much faster. <apteryx>./pre-inst-env guix build --target=i686-linux-gnu libantlr3c <apteryx>I guess if we wanted to *run* it it would be useful. <nckx>raghavgururajan: I don't know what this was about but he meant use (supported-systems '("x86_64…" […])) to let Guix know which architectures are (not) supported by the package authors. <nckx>Eh, somehow my brain read ‘mark’ as both ‘mark something’ and ‘mark weaver’ at the same time o_O <nckx>I didn't mean to presume to speak for apteryx of course. *nckx possibly somewhat sleepy. *raghavgururajan just saw "glibc-cross-i686-linux-gnu-2.29-static" downloading by guix. *static --> triggered* xD <nckx>Good luck raghavgururajan, that's never fun. <Blackbeard>rekado_: can you help me work on it? it doesn't have to be today if you are tired <pkill9>lfam: sddm works with the throwaway guix vm \o/ <pkill9>does guix take ages to build a docker image? ***rekado_ is now known as rekado
<rekado>but that’s because docker images are big. <Blackbeard>rekado_: well I want to help in any task that is needed :) <rekado>to build a docker image you need to copy all these things that are already in the store and put them in a big tarball. <rekado>I bet it would be faster on the Hurd <rekado>because there you could set up a translator that fakes the archive. <rekado>Blackbeard: I don’t have a proper list of tasks yet. <brendyyn>What is the reason people here work on the Hurd? <pkill9>it sounds like you've been working on the hurd lately rekado <rekado>I haven’t, unfortunately, but the Hurd is just amazing. <pkill9>now i'm curious about what's amazing about the Hurd <rekado>Blackbeard: the recent thread about brainstorming features has a lot of good ideas. I’ll soon turn them into a TODO list and add them to the mumi repo. <rekado>I suppose I could ask for your help after that. <Blackbeard>I remember reading something about some mathematics that used to be really abstract and useless when they were discovered <pkill9>rekado: what's amazing about the Hurd? <pkill9>it sounds good, but I don't really know <rekado>One reason why the Hurd is neat is because it does virtualization right. <Blackbeard>rekado: wonderful, please let me know so I can help and learn :) <rekado>the file system is virtualized by design. <rekado>what Linux gained very late has been in the Hurd from the very beginning. <rekado>a user with access to a node in the file system can set up a translator that does unusual things when the node is accessed. <brendyyn>i just want it so we can drop "Linux" in "GNU/Linux" <brendyyn>no hate to linux, but then we can just say we run the GNU operating system. easy. <rekado>you could, for example, set up a zip translator so that you can transparently access a zip file’s contents as if it was unpacked. <rekado>you can rebind file system nodes as a regular user (something that requires root permissions in Linux) <rekado>you can give processes extra permissions when they are already running <pkill9>a tonne of things are just file system abstractions <rekado>in Linux processes run just as one user and with that user account’s permissions <rekado>to change privileges you need to change the groups that the account belongs to and log out and in again. <rekado>in the Hurd you just grant a process more privileges. Easy. <rekado>nah, SELinux tries to make accessing files harder. <rekado>i.e. processes can only access files that have the right context <rekado>you can use SELinux to restrict things more than possible with ACLs or old-fashioned ugo permissions <rekado>but you can’t grant extra rights dynamically <rekado>another thing that’s great: drivers are just user processes. <brendyyn>A thank you to whoever made guix pull distinguish package version updates and dependency only updates with guix package -u . <rekado>drivers crashed? No problem, just restart it. <rekado>have you ever struggled with VPN on Linux? Annoyed that it applies to all connections and requires special privileges? <rekado>not so on the Hurd! Just add a private translator to your network interface file system node. <brendyyn>it has its negatives though right? more complexity and context switching? <rekado>The Hurd does a lot of things right — and you don’t need to know these things if you don’t want to. It still looks like a good old GNU system. <rekado>disadvantages due to message passing do exists, but the performance impact is pretty small on modern hardware. <rekado>the biggest problem is perhaps that reusing drivers from Linux is tricky. <rekado>it’s actually easier to use drivers from NetBSD via rumpkernel <rekado>oh, but I guess this is a discussion for #hurd <rekado>anyway, the Hurd is fun and I’m looking forward to using Guix with it. <brendyyn>its ok its relevant to the building of the Guix distribution an future, <rekado>what severely inhibited my development progress on the Hurd was its Debianness, to be honest. <rekado>Debian GNU/Hurd is the best distribution of the Hurd at this point and it used to be really tricky to figure out how to build a Hurd system from source. <rekado>because there are repositories with Debian-specific patches which were the only ones that could realistically be used to build a system. <rekado>this has slowly changed in the past years <pkill9>rekado: so with the VPN example you mentioned, you would add a translator to /dev/<network interface>? <brendyyn>well, it links to it and suggests joining if you are on it <drakonis>will hurd ever run on a machine released within the last 5 years? <rekado>drakonis: it runs on virtual machines built today! :) <Blackbeard>rekado: I am reading everything you write like wow that's amazing, but I have little of value to say hahaha <drakonis>to be fair, a vm has terrible performance <rekado>drakonis: actually, the Hurd runs faster in VMs than on hardware… <rekado>(that’s because of read-ahead / driver problems, not because VMs are magically faster with the Hurd) <drakonis>eventually getting to running hurd on real hardware would be great. <rekado>at FOSDEM 2017 Justus brought a laptop running the Hurd. <rekado>doesn’t qualify for “machine released within the last 5 years”, of course *rekado goes back to hacking on mumi <drakonis>real hardware not being incredibly niche hardware <drakonis>as that would consign hurd to being a thing only a very limited and shrinking group of users could ever possibly use <pkill9>can you run a server in a guix container? <pkill9>(that can be accessed from outside the container) <pkill9>hmm it fails to start a bunch of services, so probably not <rekado>pkill9: it’s possible but you’d need to permit networking (and perhaps a bunch of other things) <pkill9>ah yea, i enabled networking and the networking service didn't fail <lfam>Hey pkill9, did you have luck with vm-image? Or did you change the display manager with the immutable vm builder? <pkill9>lfam: yes i did, i changed gdm to sddm and it worked with the immutable vm builder <pkill9>rekado: if im reading slide 19 correctly, you can make a remote ISO file from an FTP server a filesystem, and browse that ISO and download from it only what you need? <pkill9>i don't think it makes a difference Blackbeard, unless you want to delete old generations of every profile ithink <Blackbeard>I thought that maybe it would make a difference because of reconfigure <apteryx>raghavgururajan: debian does this for antlr3c: ifeq ($(DEB_HOST_ARCH_BITS),64); ENABLE_64BIT = --enable-64bit; endif <apteryx>so they do have some conditional depending on if the builder (host) has 64 bit support or not. <apteryx>which are the architecture supported by Guix that lack 64 bit support? is that i686 only? <lfam>apteryx: armhf is 32-bit only <lfam>Not sure about i586 (hurd) <kristofer>is anyone here familiar with the guix-artwork/website workflow? <kristofer>I'm curious how website contributors use haunt in the workflow <Guix-beginner7>Hey, if I am testing a package with guix build, is it best to put it in a container to see if all my inputs are working properly? <Guix-beginner7>I am trying to build Lutris. It's a meson build file but it needs some python modules. I imported evdev from pypi but it's complaining about missing kernel-headers.. Figure I should get it as isolated as possible <apteryx>lfam: it seems debian's package for libantlr3c does conditionals that determines wheter 64 bit object code compilation is enabled or not dependening on the *host*. How would I achieve this in Guix? <anadon>OK, paper draft sent to guix-devel and no rejection notice, but no confirmation either. <apteryx>lfam: seems there's a "system" build system argument passed around that I could test. <apteryx>hmm, how to access this at the level of the package though (not in the build side code) <anadon>I just fixed up some grammar and spelling stuff which should make it less grating on the eyes. <anadon>Let me send out one with some spelling and grammar fixes I just added. <Blackbeard>anadon: oh ok! so far I have not noticed anything :) maybe because I am not native english speaker hahah <rekado>kristofer: have you seen the README in artwork/website? <apteryx>because I must connect 1:1 the arguments of the configure and its wrapper, which seems fragile in the long term. <apteryx>also, now you have different flavors of packages depending on the host instead of the target... I'm not sure we have a precedent for that? <lfam>I mean, each host already creates a different derivation <lfam>I've never really worked on this stuff or with cross-compilation, so I can't say what's okay or not <apteryx>OK, thanks anyway :-). Your previous message makes me think that's it's OK. <rekado>Blackbeard: I’ve added a TODO.org to the mumi repo. <apteryx>raghavgururajan: I've pushed antlr3c as commit f1cf62f5dc. <jackhill>Is it recommened to avoid referring to name in a source url and instead type out the package name? <jackhill>I thought I saw that recommended somewhere, but I see examples of both in the code. <apteryx>raghavgururajan: I've posted a first review of your linphone series; it'll give you something to work on until I can continue the review. <kristofer>rekado: yes! It's useful, absolutely. I am more interested in the workflow: like how a contributor establishes an environment and introduces changes <Blackbeard>rekado: I hope this might not be that hard to start * do not download messages outside of the worker <rekado>Blackbeard: I think we have all the pieces we need to not download messages outside of the worker. <rekado>we can get a list of messages with (mu:message-list "bug-id:1234") IIRC <rekado>we can use that to get the raw email (mu:path or sor) <rekado>and then we can load the file, parse it with (email email)’s “parse-email” etc <brendyyn>rekado, I'm still hella confused about wrap-script. how ever I look at it, the (car cl) is duplicated. I created a test bash script that does echo "$@". `./foo hi' returns "hi". After wrapping it, it returns "./foo hi". <brendyyn>does the interpreter not take car of passing on the zeroth argument on its own? <rekado>brendyyn: I don’t know. It’s been too long since I wrote it, and I have a sleep deprived brain right now. <rekado>it’s quite possible that it’s buggy in more ways than one. <brendyyn>ok then i will investigate it. you should get sleep <rekado>Blackbeard: it seems to me that patch-messages in (mumi messages) is a good place to start. <rekado>take your time, there’s no rush. <rekado>I must admit that it’s not immediately obvious how to improve this. <rekado>the problem is that the guile-debbugs operation returns nice records, but we don’t have them when we use the mails+db directly <Blackbeard>rekado: I have lots of free time so I can help a lot <Veera>Does anyone can tell how to list files of a package? <Veera>Read manual but could not find. <alextee[m]>Veera: do guix package --list-installed=mypackage <rekado>Blackbeard: first step would be to run mumi locally. After entering the environment start both the worker and the server <rekado>and then ./pre-inst-env scripts/mumi --worker & <rekado>this will download all bug messages and index them regularly <rekado>then run ./pre-inst-env scripts/mumi --listen-repl <rekado>this starts the web interface and a Guile REPL to which you can connect with Geiser <jackhill>Veera: the only way I now is look at what's in your store (e.g. `cd $(guix build <package-name>); find .`) I don't think we track files the same way traditional package manager do. Maybe someone will correct me? <jackhill>Veera: oops, sorry I was scrolled up and didn't see the other responses. Yay other people had something useful to say :) <Veera>jackhill: yep that nice answer <apteryx>any idea why icecat thinks the downloaded files should all be opened with LibreOffice? <brendyyn>id check XDG_DATA_DIRS and XDG_CONFG_DIRS *apteryx facepalms: Icecat -> Settings -> Applications "file" was mapped to Action "libreoffice". <rekado>apteryx: hah, I was just about to recommend checking that <apteryx>I think the reason it was set like this is because I had issue with Icecat opening the correct application in the right place, though. This is on Guix System. <rekado>for the record: go to about:preferences, search “applications”, and play with the table mapping content types to actions. <apteryx>rekado: shouldn't the installed apps be picked up automatically, based on the MIME type of the file and their .desktop description (I don't really know what I'm talking about, but I think it has to do with this :-)) <rekado>I don’t know. My preferences here are “Always ask” <rekado>except for “mailto” (“Use (default)”) and PDF (“Preview in IceCat”) <rekado>you may need to do “mkdir -p mails/cur” first <rekado>yup, the command above should help <apteryx>rekado: thanks. I'll regain some sanity. <rekado>(it’s only needed to set up the directories for the first time) <rekado>that’s where all the debbugs emails are stored. <Blackbeard>I am writing README.org with all the instructions you gave me. Is that ok? <Blackbeard>rekado: i guess it will take a bit to download everything, right? <rekado>yes, but you don’t need all messages to get started <rekado>the reason why this is slow is that we need to fetch the message numbers associated with a bug number first <rekado>no, you can leave it running in the background <rekado>(if you didn’t end the command with ’&’ you can hit Ctrl-Z and then type “bg”) <rekado>we cannot request the message numbers from debbugs directly. We can only request all messages for a bug and then extract the message numbers from there. <rekado>without the message numbers we can’t check if we have already downloaded that email. <rekado>Debbugs should offer a cheaper way to get at these message numbers. <Blackbeard>I am bit tired for today. Tomorrow morning I'll start working on this ***apteryx_ is now known as apteryx
<rekado>Blackbeard: I just made the changes to patch-messages. Turns out we actually don’t need the message numbers in this case. ***apteryx is now known as Guest44796
***apteryx_ is now known as apteryx
<efraim>ugh I just remembered why we didn't upgrade newsboat to the latest version, it needs rust now <efraim>we really need to figure out a foo+rust build system <efraim>opensuse's crate vendor-packs start looking nicer and nicer <Guix-beginner7>Hey all, is it possible to run a meson-build-system and then modify a phase to have (add-before 'build ((python-build-system)) type thing? <brendyyn>which part of the python build system do you want ***sneek_ is now known as sneek
<Guix-beginner7>Lutris has a meson build file but it requires some python modules as well <brendyyn>you can look in gnu/build/python-build-system.scm, and gnu/build/meson-build-system.scm, and have a brief look at how they are different. each build system exists as a series of "phases" that do thing like patch shebangs, run configure, make, etc... <sarg>Is there a way to install individual locale? Don't want to pull (make-glibc-utf8-locales glibc) into my config to change only hardcoded list of locales. <brendyyn>its possible to take the phase from another build system and include it. it takes setting #:modules and #:imported modules in a way you wouldn't easily guess, but fortunately there are examples in guix already. if you search the repo you will see examples like: <brendyyn>*dont* copy lollypops way, that method is obsolete and need to be updated <cbaines>Does anyone know how to apply a patch that doesn't apply? <cbaines>I can ask Magit to do a three way merge, which seems to kind of work, but the date, author and commit message from the patch are completely lost <bricewge>cbaines: You can always amend the commit afterward with --author and such. <cbaines>the patch seemed to have an odd character in it. I deleted that and things worked better. <cbaines>I also just checked out the revision the patch seemed to have been written to apply to, and then rebased to fix the conflicts ***gavlee_ is now known as gavlee
<kmicu>So it’s official: Guix will be leaving GNU and starting new libre operating system organization KINDNU (which is like GNU but with more kindness). Also there’s new experimental branch of Guix called ‘welltyped’ where we start writting modules in Shen to check if a good type system can help us prevent runtime errors in Guix, help appriciated. <bricewge>The community was definitely very hostile I'm sure the new organization name will greatly help in that regard. <brendyyn>I went through every letter of the alphabet to ensure this was the best sounding name. <marmulak>oh what way was the gnu community hostile? sounds disappointing <Parra>is it possible to change gcc compiler by clang or another? how to achieve it? <bricewge>marmulak: You know, the part where you get lashes of the whip for each non free line of codes you are running ;) <Parra>lprndn: I want to try a different compiler for building my software, not sure if that will mean globally or not <Parra>but all depends of my software should be built with this compiler at least <lprndn>Parra: I'm not an expert but I fear there is currently no easy way. If the number of dependencies is manageable by hand, I would write a clang-build-system and build them myself... <Parra>if I use a clang-build-system it will build all the dependencies of my software with clang as well? <brendyyn>there is always a way to achieve something like this. like see chromium it has (setenv "CC" "clang") (setenv "CXX" "clang++") <brendyyn>just include clang as a native-input, and then have a look at the build system and how it finds the compiler <Parra>thanks brendyyn, I will check it out <civodul>Parra: in practice probably you can just add clang as a native input and it'll be picked up <Parra>I'm considering using zig compiler which has an wide support for crosscompiling targets, but I want it to be reproductible and self portable as Guix offers <Parra>maybe this will solve problems Guix has right now with crosscompiling <lprndn>Parra: obviously better answers by civodul and brendyyn but I don't think it will affect your dependencies. (right?) <Parra>you mean my dependencies wont be compiled with this? <lprndn>Unless i'm mistaken, you will have to do it fo each of your dependencies. but maybe wait from a confirmation (or not) from someone else haha <starcrATI[m]>kmicu: wait a sec, just to be sure, this isn't some type of april fools joke, right ? <Parra>civodul: can you confirm lprndn's hypothesis? <brendyyn>Parra, thats right. to do that you would need to go make variants of all the dependencies <civodul>Parra: indeed, there's currently no simple way to replace the base toolchain globally <civodul>you'd need something like --with-input but that applies to those implicit inputs <Parra>civodul: what's --with-input ? <kmicu>Guix secured 3.5mln€ in funding generously provided by Tesla to work on reproducible automotive systems for cars. <rekado>Parra: that’s a command line option to override package inputs. <kmicu>(That’s also one of reasons why me moved from GNU to KINDNU.) <brendyyn>Parra, that being said guile is a powerful language that you can use to build up your ideal system. you can write your on zig based build system bit inheriting most of the gnu-build-system and making the small changes you need. packages can be definied by simply `inherit'ing them and swapping in your build system. obviously everything will break at first and you will need to go through making fixes <starcrATI[m]>kmicu: Well thats cool I guess, is there a blog post or something similar ? I'd like to know more about this :) <hulten>kmicu, that's good news, I'd say. <kmicu>Automotive systems require high degree of correctness that’s why we will focus on introducing seL4 as an additional Guix kernel and write replacement modules in Shen. <Parra>brendyyn: that would be great, but I'm not sure I'm able to do it, I'm not enough expert in guile <hulten>I always found Ubuntu in the Tesla vehicles a bit unsettling (but maybe any similar software complexity is for cars). <brendyyn>Parra, start by packaging just 1 program you want, switching it to zig, then have a study of gnu/build/gnu-build-system.scm. <brendyyn>i think guix does not limit you fundamentally. you cannot expect swapping out a whole core compiler to be trivial and not require lots of debugging <kmicu>(Those new tasks will be developed in addition to usual Guix work so progress on introducing Hurd will not be impacted.) <brendyyn>Parra, also look in gnu/packages/.. for mentions of %current-target-system. you can see how some packages define special rules for a given targed, if you want to make packages work on an obscure system <Parra>brendyyn: you are right, I will experiment with it <Parra>the real need is to provide full cross compiling for different triplets than linux <hulten>Does someone understand what the /gnu/store/*-*-configuration/ items are, or any directory in /gnu/store/ that don't end with a version number? <Parra>I've tried mingw32 but it fails, and macos is not planned to be in there <rekado>hulten: these are probably the results of profile hooks <rekado>see line 1525 in guix/profiles.scm for one example <hulten>Thanks, I'm reading the comments in the source to make sense of it (right now, I don't know what a profile hook is). <hulten>My *guess* so far is that certain software maybe tries to do non-guixy things like writing configuration where it shouldn't, and these hooks are ways to work around this? <rekado>hulten: profile hooks are for generating stuff when a profile is built. <rekado>such as configuration files or databases that depend on the contents of the profile. <mbakke>hmm, on the 'core-updates' branch, 'guix build -s armhf-linux foo' on an x86_64 system returns "x86_64-linux" for (%current-system). <mbakke>at least inside the (patches ...) field of an origin <hulten>rekado, I understand that these are ("data") objects, by default symlinks, pointing to stuff in real packages (the /gnu/store/*-PACKAGE-VERSION/ directories). <hulten>I suppose that the symlinks to binaries in the texlive package is a peculiarity of the build process (or demands) of TeX Live? <hulten>Because I would not expect binaries but rather configuration or database stuff (consistent with the %default-profile-hooks list). <hulten>I am talking about /gnu/store/*-texlive-configuration/bin/*. <rekado>hulten: texlive-configuration generates a union to make the configuration work. <rekado>hulten: see the comment there: ;; Build a modifiable union of all texlive inputs. We do this so ;; that TeX live can resolve the parent and grandparent directories ;; correctly. There might be a more elegant way to accomplish this. <rekado>texlive is very hard to configure :-/ <zzappie>I finally had time to sit down ad watch fosdem talks. Haven't watched all of them. But those that I've seen are very cool. <zzappie>civodul: I did have a waat moment when saw my quote from irc on the stage <mbakke>zzappie: heh, what was the quote? :) <zzappie>i've comented on pkill9's that "yeah you just need to speak it's language" <civodul>perhaps we should build linux-libre and qemu-minimal as part of the "core" subset on ci. <civodul>rekado: there's a couple of build machines low on disk space <civodul>perhaps because mcron is no longer running jobs <civodul>should we re-deploy them and restart mcron? <mbakke>uff, it's not possible to change Python arguments without triggering a full rebuild all the way down to 'python-boot0' because of substitute-keyword-arguments <mbakke>I will try the new python-on-guile for the next core-updates <mbakke>I tried moving the patch to a native-input + phase, but that triggers a complete full rebuild <mbakke>so I think we should just take the rebuild hit on all platforms and apply it normally <civodul>mbakke: yeah, it's not possible to apply patches conditionally <civodul>but you can add the patch as a native input, and there you can make it conditional <mbakke>civodul: yes, but then I need to add a phase, and that causes 'python-boot0' to be rebuilt :/ <civodul>you can make that phase conditonal too <civodul>with ,@(if condition `((add-before ...)) '()) <mbakke>civodul: what I mean is that it will rebuild python-boot0 on armhf and aarch64 <mbakke>which means we need a few days to get back to where we were <civodul>and the thing you want to fix is "python", not "python-boot0", right? <civodul>you could always arrange to remove that phase in python-boot0 <civodul>the thing is to make it not too ugly <mbakke>I tried to add (delete 'apply-foo), but that did not help <mbakke>will inspect the derivation and see if I can hack it in place <kmicu>PINE donated 64 RK3239 boards to Guix. Alas we’ve found that those boards cannot work without a 3kB blob in preboot setup hence we were forced to return them. <hulten>Where can I find post-installation instructions of already-installed packages (things like 'set this shell variable')? <nckx>hulten: In the package's documentation, if anywhere. <nckx>Or the manual for a handful of very common/important packages. <hulten>nckx, that makes sense, but I'm used to start typing 'zless /usr/share/doc/...' or something like that, or indeed apropos/man. <hulten>I have not gotten the hang of / understood how the user should best interact with documentation where in Guix System. *kmicu thinks about four pages long take about why guix-homemanager going to be default in Guix System since today. <rekado>hulten: the best way is to access the info manual with an info reader. <rekado>the web manual is fine but you can’t easily search or access the index. <nckx>hulten: For share/docs, remember that .guix-profile/share/ has a union of all your installed packages. <nckx>No need to hunt for store hashes. *alextee[m] sees non-music-related stuff <alextee[m]>osu! is there though! i want to package that, but we need a working mono compiler <NieDzejkob>kmicu: Is that blob ARM code or some other processor? 3kb sounds easy enough to create a libre replacement for <alextee[m]>maybe i'll give gnome builder a try later today jonsger , thanks for the list <pkill9>civodul: i'm getting that issue with substitutes again, are you able to reproduce it? <pkill9>(the isseu of it only showing one at a time) <rekado>pkill9: is there a bug report about this? <pkill9>but Blackbeard and civodul could reproduce it <rekado>I’m asking because I don’t know what it means and it would help me to see a description of the problem. <pkill9>ah ok, basically if you try to build anything, it will list one derivation to build/download, then builds/downloads it, and once that's complete it does the same for another one <pkill9>Instead of listing them all once and then building/downloading them <pkill9>hmm actually, it's only doing it with `guix build`, before it was doing it with `guix profile -u` <pkill9>actually it didn't do it with blender, hmm <pkill9>it just did it with minetest now <pkill9>i'll post a proper bug report if necessary, this is confusing <pkill9>maybe i misread the output or something <nckx>bricewge: Yes, that's the error I've always used as an example. <nckx>Compare that to running youtube-dl in a pure env without nss-certs, now that's bad. <bricewge>True that making the package 8 times larger is not good at all... <nckx>More like 5, but still agree. <nckx>In fact, I think that further proves my point: ‘ERROR: m3u8 download detected but ffmpeg or avconv could not be found. Please install one’ isn't only quite clear, but gives the user a choice. It's not ‘please install ffmpeg to use this script at all’. <bricewge>I did not realize the size increase was that large. *nckx doesn't actually download from YT with YTDL so has never even needed ffmpeg. <bricewge>I'll close the issue. Thanks for reviewing it though. <zzappie>kmicu: pine people say that only non-free components are WiFi and Bluetooth firmware and modem <nckx>bricewge: We're obviously looking at that error in different ways. I think it's a rare example of a damn good one and friendly, you think it's ugly and shouldn't even be shown to users at all (my reading at least). I get that. <nckx>bricewge: My pleasure. Sorry you didn't get what you wanted from me 🙂 <nckx>Plz submit many more improvements. <bricewge>But you are right that the increase of size is not worth it; you convinced me. <nckx>I should've used the real error instead of my silly note. My bad. I was too lazy to find a video that triggered it and just typed something. <nckx>Because despite discussing a script called youtube-dl, I forgot that Youtube existed. I… guess that's a good thing? <bricewge>Less time wasted more time spend coding; definitely good overall. <nckx>kmicu: <replicant> That's a wild link, although I'm sceptical of how it's written (I am 100% certain the court did not rule that he had to ‘work on more constructive things like adding support for phones with a removable battery only’, for example. Not in those words). *nckx (defiantly) I'll waste my own time, I don't need no stupid Google to help me! <sirgazil>brendyyn: I think it is about time that users of the Guix System start calling it a/the GNU operating system. I think calling this "GNU/Linux" leads to false expectations about hardware support and software availability (just to mention the practical side of things). <brendyyn>sirgazil, I say I run the GNU operating system anyway ;) <nckx>‘This is the GNU system. Welcome.’ <sirgazil>nckx: That's a great start. Now we have to patch the manual. <nckx>I think that'll happen quite naturally with Hurd support around the corner, but sure. *nckx can't wait for Hurd to make Wikipedia Linux fanboy police's heads explode. <civodul>it's clear that Linux is just a transitory hack <sirgazil>THe day people started calling the system GNU. <nckx>drakonis: Tonight? Interesting. Here it's only acceptable to prank people before noon-ish. <nckx>I can't read that without my brain adding ‘…in hell’. <zzappie>calling it *the* GNU operating system may cause another GNU/Shitstorm <nckx>Only because very little is needed to cause a one. Guix is *a* distribution of *the* GNU operating system. Calling it ‘the GNU distribution’ is what was discouraged. <nckx>'s Like saying ‘Linux OS’ or ‘Windows OS’. Redundant, but not wrong. <nckx>(It should be gnu_OS! obviously.) <nckx>* GNU/Linux OS, of course. Damn, being a zealot's hard work. <zzappie>alextee[m]: nice. I was surprised once how much music software is already packaged for guix <zzappie>alextee[m]: I was thinking about packaging vcvrack <rekado>so only the component library graphics are non-free. <rekado>well… I don’t know. Parts are free, I guess. <zzappie>there may be a way to compile it without component libraries <alextee[m]>wait i just noticed this is AUR, i thought i was looking at an official package <hulten>Is there a reason that base32 string in the package store leave out e, o, t and u from its characters, instead of the usual(?) 0, 1, 8 and 9? <alextee[m]>do you need to do something special for autotools to get it working with guix, when building a package? <alextee[m]>configure has a "#! /bin/sh " at the top when you run autogen.sh <rekado>alextee[m]: we usually patch this automatically <rekado>but some autogen scripts are weird and don’t give us a chance <rekado>I don’t see the sources so I’m just guessing: delete the “autogen.sh” script <alextee[m]>i... don't know lol. this build system is so horrible that it expects the sources of libuv to be there and builds it as part of the build <rekado>many packages do this and it’s always a pain to unbundle <rekado>the reason why this doesn’t work is that you unpack the tarball after we have already patched shebangs <nckx>hulten: Which immediately triggers the ‘which naughty words can I still make?’-reaction in most folks but oh well. <rekado>no, but you could re-run the patch shebangs phase. <rekado>(why does this package look so familiar…?) <rekado>I think you could patch the Makefile to remove “builddep: deps/libuv.a” <alextee[m]>how do i re-run the patch shebangs phase manually? any example package that does that? <rekado>and then to replace references to libuv.a with (string-append (assoc-ref inputs "libuv") "/lib/libuv.so") or similar <rekado>build phases are procedures that are collected in a big alist of symbols to procedures. <rekado>you can access any of these procedures with (assoc-ref %standard-phases 'the-phase-name) <alextee[m]>cd src/osc-bridge && CFLAGS="-I ../../deps/$(UV_DIR)/include " make lib <rekado>so you can do (modify-phases %standard-phases (add-after 'unpack-that 'patch-shebangs-again (assoc-ref %standard-phases 'patch-shebangs))) or simliar <rekado>here 'unpack-that is the name of a phase where you unpack the libuv tarball. <alextee[m]>this could work if i add the cflags/ldflags fo rit somehow <rekado>to find examples: search for “assoc-ref %standard-phases” in gnu/ <rekado>a Makefile like this is a good example for reasons why configure scripts exist. <alextee[m]>maybe i should send a patch upstream to make it more tolerable instead of hacking this for the package <hulten>nckx, well, only your second comment triggered that response for me—I don't know of bad words without those characters. <hulten>For the rest it is of course really arbitrary which four characters to exclude. <nckx>I guess it's just me then 🙂 <nckx>It's a bit annoying that our ‘base32’ isn't the common one (at least one person a year gets confused by this), but I can imagine some client/manager/professor not liking running /gnu/store/fuckubob-icecat every day. I guess. <civodul>nckx: there's a justification for the base32 alphabet in Eelco's thesis <civodul>no justification for the fact that it's reverse-order, tho :-) <civodul>but note that (guix base32) supports both <dustyweb>why was I afraid of the emacs build systtem <nckx>Oops, what did I link to if it wasn't the thesis on my clipboard? <nckx>This could get embarrassing. <drakonis>eelco's moved it out from nixos.org because of netlify btw *nckx closes love letter to civodul and clears selection. <drakonis>nix is axing a dedicated server for the website, netlify was going to pony up the costs so they went for it <nckx>Which they use for their subs IIRC. <nckx>I don't really see the jump to going (own-)serverless for all of nixos.org. <drakonis>it was free of charge for them and it was convenient <nckx>But why does that mean moving the PDFs? <nckx>alextee[m]: python-2, probably. <drakonis>idk, netlify limitations regarding hosting arbitrary files? <alextee[m]>oh thanks nckx , weird, guix search shows it as python2 <nckx>We'll take you bajillions of binaries that no human has ever seen, but get those filthy PDFs out of here. <drakonis>they're not hosting hydra's cache mind you <lfam>alextee[m]: The variable is called python-2. The package is called python2 <nckx>alextee[m]: That's the ‘name’ field. If you look at gnu/packages/python.scm:98 you'll see that the variable is python-2(.7 but whatever, -2 is aliased to it). <alextee[m]>oh i see that with guix edit python2, cool, thanks! <nckx>drakonis: Ooh. I thought the whole point of going saassy was to help distribute gigs substitutes. I didn't realise it was just for… well, whatever's left. Makes no sense to me TBH. <nckx>‘Free Web hosting’ isn't the best deal of the century. <drakonis>they already have fastly for delivering the cache <drakonis>if i'm not wrong, fastly does the same deal for debian too <nckx>I suddenly realise I never realised fastly and netlify are 2 different things. <nckx>drakonis: It is EoL, but it will be in Guix for a while. Too many dependents. <nckx>hulten: Scientists confirm: PDFs are filthy. <drakonis>the move is justified by not breaking the website for no stupid reason when changing it <nckx>Download their report as PDF. <drakonis>it keeps breaking whenever they fiddle with it <zzappie>kmicu: omg this replicant article is awesome. I agree nckx that it looks strange in some parts not to mention they posted it on April 1st <nckx>Oh god, I didn't even notice that. I hate today so much. <lfam>"Exploiting these weaknesses, Vranken was able to create a server that impersonated downloads.openwrt.org and served a malicious update. As long as the malicious file is the same size at the legitimate file, it will be executed by a vulnerable device." <lfam>"But Vranken found that it was possible to bypass the hash check by adding a space to the beginning of an input string in the checksum_hex2bin function." <nckx>‘Security researcher Guido Vranken, however, recently found that updates and installation files were delivered over unencrypted HTTPs connections’ <nckx>Common mistake. HTTPs is only half as secure as HTTPS. <lfam>I wonder how easily you could bypass our hash check and signature verification *nckx really happy they build owrt from source right now :-/ <nckx>lfam: Ever done more than wonder? I poked around a bit but got bored before I found anything of interest. I don't have the patience. <nckx>(This was not recently.) <lfam>I've created bogus files and made sure they didn't pass but that's it <lfam>Seems like most distros go through a "signature verification not required" moment <lfam>I'm not sure if the Red Hat family ever did but Debian and Arch did <lfam>Obviously nobody ever really tried attacking them from a friendly perspective <lfam>Debian actually has a ton of these bugs. It's clear their security mechanisms are bolted on <nckx>Paying for a friendly audit is not outside of the realm of possibility for us. <lfam>I'm not sure but I'd guess that the difficulty of auditing and experimenting with Debian's source code did not help the situation <lfam>We are in a better position here <nckx>My optimistic hunch is that our code is already more secure that our processes. No reason not to audit both, of course. <lfam>Just thinking about stuff <alextee[m]>yeah i give up on zynfusion, i managed to get past the libuv thing, but now it wants to download a bunch of mruby-* dependencies from obscure repos no one knows about and have no releases <alextee[m]>i can't believe someone wrote this, really. i think an alien did it <alextee[m]>and i have no knowledge of ruby or mruby and guix doesn't seem to have any mruby-* packages to look at soooo, let's get used to the old zynaddsubfx <nckx>anadon: Nothing's on file that wasn't already, everything is fine, carry on 🙂 <nckx>That sounds super-sarcastic but wasn't. <nckx>Is there a nice modern way to say (car (proc)), that also assumes (=errors) if PROC returns more than one element? <nckx>I'd rather ask here than in Guile because strangers scare me. <rekado>nckx: “more than one element” as in multiple values or a list? <rekado>alextee[m]: let’s prevent it from downloading anything. <nckx>rekado: A non-singleton list, yes, sorry. <rekado>alextee[m]: we won’t be using rake then. <rekado>we should first package these ruby things <nckx>civodul: Thanks! I was hoping something shorter existed but that's probably best. <alextee[m]>rekado: oh using the ruby build system could work. do mruby packages work similar to the ruby-* ones? <rekado>nckx: the code would be longer with error handling; you’d need at least one more clause to catch other cases. *alextee[m] tries to package that using ruby-build-sytem *rekado looks up info on mruby <rekado>we can override the ruby that’s used by the ruby-build-system. <PurpleSym>Do we have an installer nightly somewhere? I can recall Ludo asked people to test it, but I can’t find it on the mailinglist. The one one the website is failing with a null pointer dereference for me. <nckx>PurpleSym: No, you'd generally just build it yourself with the one-liner in the manual. <nckx>So… now I have (symlink (match (find-files "." "\\.so\\.[^.]*\\.[^.]*$") ((head _ ...) head)) "libnetpbm.so"), and that's not including the new #:modules (…) :-/ <nckx>That's a lot of noise just to avoid hard-coding the soname. <nckx>(Which is not VERSION-derived, no.) <rekado>nckx: this will produce an error when (find-files …) returns the empty list <alextee[m]>rekado: how would one do that? i tried building mruby-pack with ruby-build-system but it says No files matching pattern: "\\.gemspec$" <alextee[m]>there is a mrbgem.rake file that looks like it's some build configuration file. not sure what it's supposed to be or how to run it though <rekado>I guess you’d need to run rake on that file first to get the gemspec <rekado>nckx: is a match error really what you want there? <apteryx>Recently, tramp hangs on my system doing /sudo::/etc/guix. Ideas? <nckx>What do you mean? It's actually better than symlink silently creating a dangling link, which would happen if I hard-coded the soname and it changes later. <apteryx>it seems waiting for a prompt, that it doesn't find <rekado>apteryx: you can set tramp-verbose to 8 or higher to see what’s going one <rekado>nckx: it’s just not a very pretty error message. <nckx>I agree. We don't really have a tradition of generating error messages in package code, though. So I'm a bit confused even though I see your point. <rekado>invoke produces an error on non-zero exit codes. <nckx>So does match. We don't ‘handle’ either. Invoke's just happens to look less spooky. <nckx>Methinks we might be overthinking this (and I completely started it). <rekado>yes, that’s really my only point. It’s not very important. <rekado>but to me a match error screams “programmer’s fault” <rekado>whenever I see a match error I shake my head and judge the programmer who seemingly forgot to account for all cases. <nckx>It would only be visible to users if someone bumps netpbm without even building it themselves, so that would be true. <rekado>alextee[m]: do you have some WIP definition for mruby-pack that I can play with? <apteryx>rekado: interesting. It is doing some exec ssh -e none my-host-name instead of ssh -e none localhost, which fails. <apteryx>ha! ~/.ssh/config -> I changed machine and forgot to delete what used to point to that machine, which broke resolution by the machine host name. <alextee[m]>rekado: just a sec, talking to the person who wrote this, apparently we might not need those things. trying a new build now of another branch <asterope>What path should I add to %load-path to have guix modules available in a geiser/guile-repl? <apteryx>for offloading, is it possible to have the builds dispatched to both my local machine and to a remote offload, to build in parallel? ***Guix-beginner7 is now known as Kozodev
<asterope>do I just install the guix package and use .current-profile/share/[...]/guix or something? <nckx>apteryx: ‘Offloading’ to localhost worked (=did something) when I tried it, but I never tested it properly. <rekado>on ci.guix.gnu.org we offload to multiple ports on localhost, because that’s where our SSH tunnels listen for connections. <apteryx>you must configure and build the sources <apteryx>it currently is derived from a indent-code.el.in at build time. <rekado>is ./etc/indent-code.el executable? <nckx>raghavgururajan: What happens when you explicitly make etc/indent-code.el ? <nckx>(In your build environment.) <alextee[m]>rekado: i managed to move on quite a bit, now i stumbled across another configure script that uses "/bin/sh", but this is all generated as part of that make command, so i can't really patch it in-between. maybe i should somehow make "sh" available at "/bin/sh"? is that possible? <apteryx>raghavgururajan: install emacs in your profile, then rerun configure && make <rekado>alextee[m]: the configure script should not be generated and run like that. Can you show me your WIP? <nckx>alextee[m]: You can substitute whatever generates that offending script. Something has to echo /bin/sh to it somewhere. Patch that. Maybe set an environment variable. <nckx>raghavgururajan: Not what I asked tho' 😛 <nckx>So what happens when you ask make to build it? You might have to make emacs available. <nckx>No, inside: guix environment guix … --ad-hoc emacs … -- make etc/indent-code.el *nckx forgot --pure but one gets the point. <nckx>As apteryx well notes, if that still fails you might have to configure to make the build system see emacs & try make again. <apteryx>I also have a patch getting rid of this indent-code.el.in complication, if nothing works <anadon>Have many people gotten to see my paper in guix-devel? <nckx>apteryx: Might be interesting regardless? <nckx>anadon: Not yet but it will happen today. <alextee[m]>does this need to be escaped somehow when running it through (substitute*) ? "../../deps/$(UV_DIR)/include" <nckx>Hell yes. "\\.\\./\\.\\./deps/\\$\\(UV_DIR\\)/include". Phew! <raghavgururajan>nckx Now I get "bash: ./indent-code.el: --script: bad interpreter: No such file or directory" <raghavgururajan>* "bash: ./etc/indent-code.el: --script: bad interpreter: No such file or directory" <nckx>That means @EMACS@ was replaced with the empty string. <nckx>If you haven't reconfigured yet now's the time. <nckx>Don't forget --localstatedir=/var as always. <nckx>If that still doesn't work, and you're sure ‘emacs’ can be executed inside the environment, I'm out of ideas. *raghavgururajan just accidentally deleted the cloned guix repo folder <raghavgururajan>apteryx Btw, I forgot to ask. When I ran `guix lint`, I didn't get any errors regarding indentation. <alextee[m]>rekado: so i almost managed to build mruby-zest in an environment (it just fails at link time now with libuv but that can easily be fixed). however i get build failures because of this and im not sure how to fix it: /tmp/guix-build-mruby-zest-ghaction.drv-0/source/deps/mruby-file-stat/configure: line 4383: /bin/sh: No such file or directory <alextee[m]>i mean i get build failures with guix build but it builds successfully in an environment (although id idnt use ad-hoc, probably that's why) <pkill9>where does lua search for lua libraries? <PurpleSym>Does the guix installer write debug logs somewhere? I see a few messages in /var/log/debug, but nothing that could pinpoint the crash. <alextee[m]>oh actually nvm, i did something else and it works! now just link-time things left to fix \o/ <nagamalli>Hi , i am trying to learn updating gnome pakages <nagamalli>I have updated package description with version and checksum in gnome.scm <nagamalli>when i tried to build ./pre-inst-env guix build cheese <nagamalli>/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: ./configure: No such file or directory <nagamalli>command "/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "./configure" "CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "--prefix=/gnu/store/2bgw89q3jwrf39l3lvfld5sv3rz77f1m-cheese-3.34.0" "--enable-fast-install" failed with status 127 <nagamalli>builder for `/gnu/store/h6wyial5k676s0p5zjgmx162802rp358-cheese-3.34.0.drv' failed with exit code 1 <nagamalli>build of /gnu/store/h6wyial5k676s0p5zjgmx162802rp358-cheese-3.34.0.drv failed <nagamalli>is it that build system is looking for "configure" and coulnt find it in source tree? <nckx>nagamalli: Yes. This being a Gnome package, it's very likely they switched to using the Meson build system entirely. <nckx>You'll have to use the meson-build-system & rewrite most of the arguments to follow Meson conventions if that's the case. <nckx>s/pastebin/a pastebin/ (Not trying to be pedantic, but too many people read ‘the’ pastebin as pastebin.com which is horrible in every way.) <nckx>Blackbeard: I'm steady. You? <nagamalli>nckx:yeah,okay I will do that from next time onwards! <nagamalli>understood the problem , i have gone through the source tree. <Blackbeard>nckx: ah yes, I figured, that's why I sent a link immediately <nckx>nagamalli: We're currently experiencing a wave of Gnome projects switching to Meson en masse. It's not normally that common. <nckx>Blackbeard: Yah, your link arrived here right after I sent mine :-/ <nckx>Here I am playing around with sub-millisecond NTP servers while my connection to the world can't even deliver IRC messages on time. <Blackbeard>what do I need to install for doc-view-mode to show me the pdf <bdju>you may need "poppler", but I don't remember for sure <nckx>Blackbeard: ghostscript. <nckx>Maybe mupdf too, but I think my emacs shows PDFs even without it. I don't have poppler installed. <nckx>Blackbeard: Excellent. I'll blame Matrix. <nckx>Can I blame Matrix for other things in my life, too? <rekado>Blackbeard: I recommend emacs-pdf-tools <nckx>Ah, that uses poppler, rite? <Blackbeard>rekado: ah yes, I just installed that! But I thought maybe I also needed something else <nckx>Not if our package is properly packaged. <Blackbeard>I have a huge emacs config but I am trying to keep it to a minimum on Guix <apteryx>raghavgururajan: did you manage to get indent-code.el running? <apteryx>I'm surprised that guix lint wouldn't complain about indentation. <nckx>apteryx: So are we saying that guix lint silently skips the indentation check if emacs is not available? <nckx>‘We’ should at least detect & warn about that. 😉 <alextee[m]>um, i thought propagated inputs get installed inside the parent package's store? <Blackbeard>nckx: warning: seems like your system does not have Emacs. This is a huge security risk. Please install Emacs immediately. <nckx>Refusing to comply with this directive will be punished severely. <nckx>Punishment is implemented as an elisp macro. Please install Emacs to be punished. <nckx>alextee[m]: No, what's happening is grafting, propagation is something completely different. Those end up ‘installed’ in all profiles that contain the propagating package. <nckx>The two don't share any concepts I can think of. <mbakke>so I just had the weirdest remote troubleshooting session ever <mbakke>a friend could not get network access on their Guix System on a particular network <mbakke>they got an 192.168.100 address, while the network was supposed to advertise 192.168.0.x <mbakke>apparently the network had lots of bespoke switches, so I had them unplug everything but the main router to find the rogue DHCP server <mbakke>eventually it was discovered that the address came from their own PC! <civodul>so they were running a DHCP server on their PC? <mbakke>but they had no dhcpd-service-type, and stopping Docker etc did not help <mbakke>with Wireshark we found that a local IP 192.168.100.39 was handing out IP addresses <mbakke>it responded to ping, but not ARP queries, so no MAC address could be extracted <mbakke>and Linux did not know of any such IP, nor was anything bound to the DHCP server port *civodul wants to know the continuation :-) <nckx>Uh, yes please, I've been reading this like a mystery crime novel with the expectation of a big pay-off at the end. <mbakke>nmapping the IP revealed that ports 1, 2, 6, 17, 103, 136 and 255 was open <mbakke>but it could not recognize any services on those ports <alextee[m]>still needs a bit of work but we're on the right path..... <mbakke>they tried rebooting to no avail <mbakke>eventually they tried a second reboot, and the problem went away O_o <civodul>it sounds like those frustrating thrillers where you're left wondering what that could have been <NieDzejkob>how certain are you that the first reboot happened? ;) <nckx>C'mon, with those port numbers I was at least expecting something like ‘it was reading /etc/hostname as a list of ports in binary’ or something equally insane. <rekado>alextee[m]: did you use a different repository? <mbakke>NieDzejkob: about 70%. sure of the first reboot. They actually had a similar problem on that same network a while back (and called me), but then they just set a static IP and moved on (the network was apparently somewhat experimental at the time). <mbakke>now we took the time to getting to the bottom of it <mbakke>Blackbeard: yes, we could set a static IP and talk to the proper network <mbakke>I'm going to go up there at some point and have a poke :P <NieDzejkob>took the time to *attempt* getting to the bottom :P <mbakke>will also try extracting some of the firmwares and grep for the magic numbers <NieDzejkob>I really hope this is not your attempt at an April Fools joke :D <alextee[m]>3 packages: libuv built with -fPIC, mruby-zest special branch (from mruby-zest-build repo) and zyn-fusion is the same repo as the zynaddsubfx package, so maybe we can just inherit or something <nckx>mbakke doesn't do those. <rekado>alextee[m]: is the libuv build is only necessary because you’re linking with libuv.a (instead of using the shared object)? *mbakke whistles innocently <alextee[m]>rekado: plugins must not use .so, it should be statically linked <nckx>But so extracting firmware is easier than unplugging cables until the ping stops? What hell-network is this? <rekado>alextee[m]: but isn’t this also linking with cairo? <alextee[m]>cairo/opengl/etc are generally ok, anything else causes problems when you run multiple plugins <rekado>where can I find these rules? Is this audio software writers’ secret knowledge? :) <mbakke>nckx: there were no cables to unplug, the address was on their own PC. <rekado>you could have unplugged the power cable <mbakke>but somehow this problem only manifested itself on one particular network (not their home network) <alextee[m]>rekado: hehe, kind of, i am just parroting what i get told from other audio devs' experiences <nckx>Part of me is hoping for some smoking-gun ME horror story, part of me really isn't. <cbaines>mbakke, my virtual network I use for QEMU/virt-manager stuff uses 192.168.100.0/24 <mbakke>cbaines: is that a default or something you chose? <cbaines>I think it's configurable, but probably a default <mbakke>cbaines: interesting, I did not think to check for virt-manager. I'll ask for a copy of their system configuration. <mbakke>cbaines: can you ping 192.168.100.39 on the VM host? <cbaines>mbakke, No, I ran nmap 192.168.100.0-254 and it seemed different to the situation you had <cbaines>I think running virsh net-list as root might show if there's a network which is active <alextee[m]>does " also need a \\ before it when substituting? <rekado>"this is a so-called \"string\"." <alextee[m]>rekado: i know the source file that loads the zest library, should i patch it with the full path from the inputs to avoid using propagated-inputs ? <rekado>alextee[m]: sounds good. It’s best to avoid propagated-inputs where possible. <mbakke>FWIW the laptop in question was one of those rebranded things from a local reseller <mbakke>waiting for confirmation on the actual brand, I see the reseller now stocks Compal <mbakke>side story, when the same laptop was on my network, they were unable to SSH to one particular server, but they could jump through another machine on the local network without problems. I could see SSH packets coming back from the router, but not getting accepted by their PC O_o <mbakke>so we've known for a while that the laptop has some funny network issues <mbakke>this DHCP issue "took the cake" though <NieDzejkob>I always say the best thing about free software is that in the worst case, you can sprinkle in printfs until you figure out why it doesn't work the way you expect it to <cbaines>I think printf, print, puts, peek, ... is the default way I do debugging! <rekado>a day ago I used call-with-error-handling (which spawns a debug REPL) in a Guile project and I felt so proud of myself for a moment. <mbakke>unfortunately they were not running a free wifi firmware, so we can't really hack it :-/ <rekado>a moment later I found myself adding pk in the test suite ¯\_(ツ)_/¯ <alextee[m]>zynfusion plugin works! ^ it uses the same name as zynaddsubfx though, should probably patch it a bit to be called ZynFusion instead <janneke>i have been working /so/ hard the past weeks on this <janneke>but with today's sprint by civodul and rekado; just wow <cbaines>janneke, I managed to also build hello on the hurd <cbaines>janneke, I feel like there's something to do at some point to support hurd stuff in the Guix Data Service, but I'm not sure what yet... <cbaines>Like, I'm using QEMU currently to compute the Guix derivations for different systems, but all of that's still using Linux <janneke>cbaines: yes; i think rekado will start getting a couple of hurd vm's hooked up on ci.guix.info <janneke>i guess you'll pull data from those builds? <civodul>with the wip-hurd-vm branch, we can actually have a "Hurd service" on GNU/Linux Guix System <dustyweb>janneke: civodul: this *isn't* an april 1st joke though right? <janneke>i've been working pretty hard on this for the past month, but the help of you all today was amazing!!! <rekado>dustyweb: go ahead and try the VM! <dustyweb>because Guix has actually been working toward that for a long time! <rekado>native builds on the Hurd are a huge step forward! <cbaines>janneke, only if the Guix Data Service knows about the derivations, which it doesn't at the moment. I think that's reasonably easy to sort though <civodul>yep, janneke's focus has been a game changer <rekado>when I last tried to update Manolis’ work native builds failed with a segfault in tar. <rekado>having overcome this and many other problems is just amazing <janneke>rekado: ty, but since phant0mas' work many glibc patches have been upstreamed by debian <rekado>I last worked on this just after the glibc release which included most of the patches. <pkill9>do search paths of a package's dependencies only get applied if they are propagated inputs? <rekado>it was still a very bumpy road at that point <rekado>I was even a little pessimistic at that time <pkill9>also, what's the difference between search-paths and native-search-paths? <janneke>well, make-4.3 switched to spawn instead of fork and, oh irony, that currently doesn't work on the hurd <janneke>it took me some time to bisect that; we now use fork on the hurd :-) <janneke>what i don't understand the hurd-clock_* patches, i mean, why they haven't been upstreamed yet <janneke>they are living in debian's glibc since 2012 or 2013 at least <civodul>i don't think there's a good reason for that <rekado>this is one area where new people can help. There is no strong motivation to upstream the patches because Debian GNU/Hurd works just fine. <rekado>with more distributions of the Hurd there’s an incentive to “despecialize”.