IRC channel logs


back to list of logs

<unmatched-paren>johnjaye: well, guix, and nix which it is a fork of, try to solve problems with traditional unices such as: you can only have one version of a library, updates are non-atomic, packages are usually just unreproducible binaries, when building IS done it's not sandboxed
<rekado>ham5urg_: “append” takes one or more lists
<rekado>(guix is not a fork of nix)
<unmatched-paren>rekado: is it not?
<nckx>civodul: Ooh…
<unmatched-paren>I thought the Guix daemon was derived from the Nix one
<johnjaye>yes when people talk about nix they usually emphasize the packaging aspect. but what does guix bring then on top of that?
<unmatched-paren>johnjaye: declarative management of services and dotfiles too
<unmatched-paren>e.g. see home.scm and system.scm
<unmatched-paren>it may look a little alien because scheme :) it's quite easy to pick up though
<unmatched-paren>johnjaye: also installations/removals/updates can be rolled back (if you're running a system, you can do it from GRUB)
<rekado>Nix doesn’t have packages as first-class objects. Guix does.
<civodul>johnjaye: the idea is to provide a single programming interface to all things deployment, environment management, etc.
<civodul>compared to a mixture of different languages and tools
<unmatched-paren>rekado: i suppose i meant just the daemon. of course, all the scheme code cannot possibly be derived from it
<civodul>at least that's the thing one may notice quickly when comparing Nix and Guix
<unmatched-paren>a sloppy choice of words
<unmatched-paren>from me
<unmatched-paren>johnjaye: because of how guix works, it can implement this:
<johnjaye>civodul: ok i was wondering about that. because once you have declarative packaging implemented... what else do you? mission accomplished. we did it. yay.
<unmatched-paren>`guix shell scdoc` drops you into a shell. you are able to use scdoc in this shell. once you exit the shell you can no longer use it.
<nckx>civodul: Another question: How do I re-activate a Cuirass job? It has vanished from the UI and whilst I can edit it by giving the URL directly, there's no ‘enable’ checkbox.
<civodul>johnjaye: you can get more tools around it: "guix system", "guix pack", "guix shell", "guix home", etc., all building on those foundations
<civodul>sky's the limit :-)
<rekado>nckx: same question I had. That’s why there’s a wip-r2 jobset.
<unmatched-paren>really handy to keep your system neat and tidy; you don't need to install development tools, just use a shell
<unmatched-paren>`guix pack` can create e.g. self-contained proot-based tarballs that can be unpacked and used on systems without guix, and it can also make docker images
<civodul>nckx: i thought there'd be an enable checkbox; then there's doc/ in maintenance.git
<unmatched-paren>johnjaye: but if you're looking for the sheer simplicity you have with your current BSD system, you'll probably not find it
<unmatched-paren>i'd say the increase in complexity is worth it
<nckx>I had to hack into the Postgres mainfraim once to tweak something trivial before, I guess I'll do it again.
<nckx>…seriously? mainfraim?
<nckx>efraim: Free new nickname if you want it.
<civodul>mainefraim operates a big computer in the US
<unmatched-paren>johnjaye: also, along the way, you'll discover that Rust makes distro packagers cry
<unmatched-paren>have a look! :P
<singpolyma>Except in guix, where lots or crates we can do fully automated
<singpolyma>It's very nice
<unmatched-paren>singpolyma: yeah, it certainly eases the pain. and so will antioxidant when it's merged
<nckx>In the end I chose the lazy—er, rekado's way out. New job name it is.
<lechner>nckx: thanks for your initial review! why would an upgrade of linux-pam rebuild large parts of the system? (it did not here.) were you thinking of nyacc?
<nckx>lechner: guix refresh -l linux-pam says 7415 dependent packages are rebuilt.
<nckx>Which jives with my intuition, but maybe there's a variant for builds? I didn't check…
<nckx>I don't see it.
<lechner>Could those mostly be servers or client apps that are not installed in my somewhat minimal Guix System?
<nckx>I didn't read the list 😉
<nckx>Lots of R packages, for example.
<nckx>Still, it means that the patch has to land on core-updates first.
<ham5urg_>Is there a page to find where file.scm grammar is explained?
<nckx>What do you mean by grammar? Are you already familiar with the programming language, Scheme?
<ham5urg_>Never heard of.
<ham5urg_>That's about scm.
<ham5urg_>I get into it
<nckx>Yes, .scm is just like .c. It's ‘just’ a programming language in its own right. Not designed specifically for Guix, like the Nix language was for Nix. Guix just defines data structures on top of it, like the operating-system and package record types.
<nckx>See, e.g., ‘operating-system Reference’ in the manual. But that won't teach you basic syntax like ‘what does ( do’.
<nckx>I'm not aware of a page that teaches you the basics without assuming you actually want to learn it ‘properly’, sorry.
<vagrantc>some of us manage to get by without ever learning it properly :)
<ham5urg_>Why has been Scheme choosen? Why not Perl or some other script-lang?
<singpolyma>ham5urg_: guix exists to promote scheme
<singpolyma>I mean, not quite, and not only, but sort of
<nckx>ham5urg_: Scheme (specifically, one implementation: Guile) is the official GNU extension language.
<nckx>It's very similar to Lisp, a hackery language of old, see also Emacs Lisp (elisp). It's a high-level language that lends itself well to creating DSLs (domain-specific ‘sub’ languages), which makes it well-suited to something like Guix. It's also, frankly, more elegant and sane than Perl.
<lechner>nckx: maybe it's pulled in via the build system. how else, for example, could cl-css require linux-pam please?
<lechner>i bet its sudo or fakeroot
<nckx>There's a path from fakeroot to linux-pam, yes, but I don't know about cl-css.
<nckx>Thing is, ‘guix refresh’ is notoriously blind to implicit (build-system) inputs. That's a known bug. So that alone can't be it.
<nckx>guix graph --path gives nothing.
<lechner>nckx: does cl-css have any other inputs?
<nckx>(I only see cl-css-lite in that list, not that it matters much.)
<lechner>btw, which part of guix/build system/profile sets environment variables that may be required for building, such as GUILE_LOAD_PATH or PKG_CONFIG_PATH, please?
<nckx>How would I debug ?
<lechner>nckx: cl-css@0.1-1.8fe654c
<lechner>although i haven't pulled in a few days
<nckx>That's not in my list.
<nckx>lechner: Environment variables are set through native-search-paths (i.e., don't waste time for an explicit 'set-some-handy-vars phase — it is more abstract than that). pkg-config and guile both define paths, which the profile generation code combines into the final environment.
<nckx>If you really want the exact code path, er, you'll have to follow it yourself, sorry. Busy :)
<nckx>s/time/time searching/
<lechner>nckx: thanks! do you have cl-uglify-js@0.1-1.429
*nckx away.
<vagrantc>hrm. trying to add a patch to groff, but it appears to break groff-minimal ...
<vagrantc>./pre-inst-env guix build groff-minimal --no-grafts ... guix build: error: getting attributes of path `/gnu/store/a28r867wvm9b2qlfvhpqs4pa4psvb4xf-groff-1.22.4': No such file or directory
<johnjaye>guix installation proceeding apace. i saw something about mozilla NSS certificates and openssh.
<johnjaye>just checked a desktop and go
***Xenguy_ is now known as Xenguy
<tinybronca[m]>Anyone ever used or heard about this:
<tinybronca[m]>Seems only "RAW" version is libre but it is claimed to be more efficient than Nagios, perhaps packagable?
<nckx> <> Hyperyikes, and there's a lot more in packages/, but who knows… maybe it could be drilled into submission.
*nckx → 😴💤
<lechner>Hi, is sysctl-service-type a good place to turn off the IP privacy extension for randomized ipv6 addresses?
<unmatched-paren>johnjaye: oh, yes, a warning:
<unmatched-paren>the installer in the stable iso has a particularly annoying bug
<unmatched-paren>whereby it does not wipe the /boot/efi partition
<unmatched-paren>so you need to enable wiping it so that your old OS is removed
<unmatched-paren>at least, whatever was on that desktop before..
<unmatched-paren>(assuming that you are doing a system)
<unmatched-paren>in general, you may come across some instability, due to guix's youth; it works fine most of the time, though
<PotentialUser-10>Hello, I just installed gnu guix the other day, and upon reboot I get the white screen with the message "oh no, something has gone wrong". Anyone here familiar with this issue?
<unmatched-paren>PotentialUser-10: GNOME has broken somehow.
<unmatched-paren>do you have any GNOME extensions?
<civodul>Hello Guix!
<unmatched-paren>o/ civodul
<PotentialUser-10>unmatched-paren I didnt even install the gnome DE, i used xfce! And no, i didnt do anything else than trying to reboot the computer after the installer
<unmatched-paren>PotentialUser-10: hmm. okay, i only ever got that (back when I used gnome) because GNOME was broken
<unmatched-paren>i guess you're using gdm though?
*unmatched-paren searches up "gdm log file"
<unmatched-paren>there might be a log in /var/log/gdm3?
<unmatched-paren>actually /var/log/gdm exists on my system
<unmatched-paren>but it's empty of course, since i don't gdm
***jesopo is now known as jsp
<PotentialUser-10>trying atm to reinstall with gnome instead of xfce
<unmatched-paren>PotentialUser-10: i don't think that will help, but you could try...
<unmatched-paren>wait, you reinstalling the whole system??
<unmatched-paren>you don't need to do that
<PotentialUser-10>Haha the system was freshly installed anyway haha
<PotentialUser-10>But yeah
<unmatched-paren>you could just substitute xfce-service-type for gnome-service-type in /etc/config.scm but okay
<PotentialUser-10>ah okay
<unmatched-paren>i'm writing a package where the officially given license is MIT, but it depends on a GPL library (notmuch). does this make the former effectively GPL?
<unmatched-paren>PotentialUser-10: then you just `guix system reconfigure /etc/config.scm`
<unmatched-paren>of course
<PotentialUser-10>okay thanks! I will check it out
<gnoo>unmatched-paren: i think so, look at wpa-supplicant's package definition for eg
<unmatched-paren>gnoo: okay, thanks. i'm trying to package aerc in case anyone's interested
<ham5urg_>What is the correct way to create a package which depends on other packages and altering their configurations (e.g. installing postfix, dovecot, openldap)?
<unmatched-paren>ham5urg_: sounds like you might want a service, not a package
<ham5urg_>I'm to much into debs...
<unmatched-paren>because you can't modify *anything* outside /gnu/store and your /tmp/guix-build-... directory with a package
<unmatched-paren>services are designed for this kind of use case where you want to modify a configuration file outside the store
<jpoiret>unmatched-paren: ahem, the configuration files end up in the store with services
<unmatched-paren>e.g. i think the nginx service provides functionality to manipulate the nginx config
<unmatched-paren>jpoiret: yes, i know, but don't they get copied over to the system like guix home dotfiles?
<jpoiret>depends on the specific software
<jpoiret>some have flags like `-c config.cfg`, in which case no
<unmatched-paren>i see.
<jpoiret>using /etc/ is last-resort
<unmatched-paren>hmm, seems like i can't use (replace ...) in modify-phases anymore?
<jpoiret>that would seem weird
<unmatched-paren>./guixrus/packages/aerc.scm:62:14: warning: 'replace' may only be used within 'modify-inputs'
<unmatched-paren>no mismatched parens as far as i can see
<foobarxyz>Hi, I'm trying to debug an issue with elfutils libdw pkg-config' delendencies
<foobarxyz>so if I install elfutils and do pkg-config --clflags libdw
<foobarxyz>it fails with
<foobarxyz>Package 'liblzma', required by 'libdw', not found
<foobarxyz>liblxma is provided by package xz, but it is not part of the package elfutils inputs
<unmatched-paren>foobarxyz: it should have it as an input if it's required, but maybe the pkg-config file is mistaken?
<unmatched-paren>since it builds fine without liblzma
<foobarxyz>actually it is picked up by elfutils configure script as a dependency
<foobarxyz>though xz is not part of the inputs, so I am a bit puzzled how xz is in the package environment when building the elfutils packages
<ham5urg_>I do not understand the first scm file shown at properly. In the first line '(use-modules (gnu))' does what? The second line '(use-service-modules networking ssh)' brings up the network (no daemon) and starts ssh (daemon). How can it start ssh when ssh is not a globally installed package? Is it inside base_packages?
<foobarxyz>unmatched-paren: include xz in the package inputs is probably a solution, but how does it get in the build enviornment to begin with?
<jpoiret>ham5urg_: i think you're mistaken here, are you used to programming languages in general? (use-modules ...) and (use-services-modules ...) are just import/include statements
<jpoiret>it says, "please let me use the things defined in those modules", but apart from that it doesn't setup anything
<unmatched-paren>ham5urg_: (use-modules (gnu)) brings in the (gnu) module which "re-exports core parts of the (gnu ...) modules"
<ham5urg_>jpoiret, aha, that are just includes
<ham5urg_>So I guess ssh is in base_packages.
<unmatched-paren>(use-services-modules foo) is syntax sugar for (use-modules (gnu services foo))
<unmatched-paren>similarly for use-package-modules, in case you ever encounter it
<unmatched-paren>so it's actually saying (use-modules (gnu services networking) (gnu services ssh))
<ham5urg_>Where are *-modules files stored? I would like to look inside.
<jpoiret>they are in the guix source tree
<jpoiret>you can find the ones you are using be looking into ~/.config/guix/current/
<jpoiret>then, eg (gnu services ssh) would be gnu/services/ssh.scm
***jsp is now known as jess
<mothacehe>jpoiret: hey, i made some progress by upgrading xdg-desktop-portal to the latest release, I know have the screen/window choosing display in chromium, but then it still fails with:] Failed to start the screen cast session.
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, apteryx says: yeah teams screensharing doesn't work with ungoogled-chromium, because some custom extension gets disabled (it would potentially be a privacy concern), which Teams expect to be available for Chromium. Ironically screensharing "works" in Icecat (albeit badly, and has a tendency to crash).
<jpoiret>did you also update xdg-desktop-portal-gtk with it?
<jpoiret>you could try to peep the dbus during that
<jpoiret>it comes from
<ham5urg_>Are global *-modules files (like the ones of ssh) also copied into some directory (not ~/.config/guix/current/) ?
<unmatched-paren>ham5urg_: wdym?
<unmatched-paren>guile uses some search path to find them, which is modified whenever you install a guile package
<mothacehe>jpoiret: good idea:
<jpoiret>did you start wireplumber?
<jpoiret>foobarxyz: i'm looking at the configure script of elfutils
<jpoiret>it does say that lzma support is enabled although it shouldn't when building it
<foobarxyz>jpoiret: thanks; it appears that the `xz` input (provider of liblzma) is included in the build system, although is not explicitly mentioned as an input.
<jpoiret>ohhhhhh, that may be because it's in the build system's default inputs
<mothacehe>oh forget it, i started pipewire & wireplumber, no more errors but chromium crashes :(
<mothacehe>i give up
<jpoiret>xz and bzip2 should be included in the native-inputs of elfutils then, but it'd cause a world rebuild
<unmatched-paren>jpoiret: would that affect the actual results of the build in any way?
<jpoiret>i'd say it's a bug
<jpoiret>the result no, but the dependent derivations yes
<jpoiret>well, maybe not, since they were already included
<jpoiret>you could try adding those and seeing if it does end up rebuilding dependent things
<unmatched-paren>if no, couldn't we just use grafts or something?
<foobarxyz>jpoiret: I think it hsould be just in propagated-inputs, since it is just a pkg-config dependency?
*unmatched-paren does not yet understand exactly what grafts do
*unmatched-paren is just flinging out random suggestions
<jpoiret>foobarxyz ehm, right!
<jpoiret>forget i ever said native-inputs, i didn't sleep that well this night
<unmatched-paren>what's a native-inputs???//?///
<foobarxyz>jpoiret: where is xz coming from though in the build system to begin with? is it part of the source decompress dependencies?
<foobarxyz>:unmatched-paren: have a look at wrt inputs
<jpoiret>all of (gnu packages commencement)'s %final-inputs are included in gnu-build-system's implicit build inputs
<unmatched-paren>foobarxyz: i know, it was a poor attempt at humour re "forget i ever said native-inputs"
<jpoiret>which includes xz ond bz2
<jpoiret>it hasn't been an issue in guix because all packages virtually have those as implicit build inputs
<foobarxyz>jpoiret: great, now this has been clarified, I guess the next step is to include xz as a propagated input? Does it need to a comment or a documentation entry somewhere to clarify this to package authors as well?
<foobarxyz>jpoiret: would this trigger a world rebuild even if it is a prop-input as opposed to a nat-input?
<unmatched-paren>foobarxyz: almost certainly yes
<unmatched-paren>some packages have a configure script that detects libraries, for example
<unmatched-paren>and if it doesn't find X, it turns of features dependent on X
<unmatched-paren>so adding/removing inputs can still make a difference
<jpoiret>unmatched-paren: the thing is, those libraries should be dependencies of almost all derivations already because of gnu-build-system having those as inputs
<jpoiret>so maybe it won't change anything
<unmatched-paren>i guess so
<jpoiret>the issue arises when you try to manually compile something, then it's not propagated
<foobarxyz>There is also an alternative option of passing --without-lzma to `configure', but it will be taking something off the current package, so it sounds worst. Would this also trigger a world rebuild?
<jpoiret>yes, that would change the build script hence the derivation
<foobarxyz>btw, is there a way to build a package locally and maintain the build tree? akin to build -K, but also keep the build tree even if it succeeds?
<foobarxyz>It happened to me in several occasions that I wanted to do this, but couldn't find an option to do so. For example in this particular case, i wanted to play with the configure script
<foobarxyz>Getting hold of the log file of course if fantastic, but I needed more in this occasion. Waht I end up doing is to put a statement into the pacakge definition so that it eventually breaks and can get hold of the build tree
<jpoiret>foobarxyz: you could add a dummy phase that breaks
<foobarxyz>jpoiret: I would have thought this is something everybody would have wanted and could have been an option, or is it just me and I should never require this?
<unmatched-paren>foobarxyz: it's not just you, i also asked this question at one point
<foobarxyz>unmatched-paren: thanks for confirming
<foobarxyz>jpoiret: bz2 also ends up in the libdw.pc file, so perhaps is also needed to be included in the propagated inputs if the preferred solution is to go down this road; ideally I think these packages should have never been exposed to the elfutils packages as inputs during the configure phase. If the rationale is for elfutils to be a vanilla package,
<foobarxyz>then it currently has extra support for liblzma and libz2 which is far and beyond what is expected
<foobarxyz>jpoiret: I assume the reason why both xz and bz2 are included as inputs from the base package is for decompressing the sources?
<foobarxyz>jpoiret: and thus in theory could be removed after that phase?
<jpoiret>You can't remove inputs after a phase
<foobarxyz>jpoiret: ok thanks. How can we take a fix for elfutils forward, are you going to do it fast forward perhaps, or shall I send an email to the mailing list to initiate a discussion?
<jpoiret>I think it needs a thorough discussion, I don't know which option would be preferable between adding propagated inputs or compiling with explicit --with—lzma=no"
<jpoiret>Although i'd prefer the first since realistically xz is on every guix system anyways
<unmatched-paren>jpoiret: might you know why i get "./guixrus/packages/aerc.scm:62:14: warning: 'replace' may only be used within 'modify-inputs'
<unmatched-paren>" with ./guixrus/packages/aerc.scm:62:14: warning: 'replace' may only be used within 'modify-inputs'
<unmatched-paren>" with
<foobarxyz>jpoiret: ok, thanks I'll try to post something later today
<nouun>How does one open a port? I'm running netcat on port 8080 but I can't connect to it on my phone.
<jpoiret>nouun: i don't think guix does anything differently here
<jpoiret>unmatched-paren i'm really not sure about that
<jpoiret>can you post the whole package def?
<jpoiret>or the whole .scm file for that matter
<nouun>jpoiret: Oh, so there's nothing like NixOS's 'networking.firewall.allowedTCPPorts'?
<jpoiret>the error happens while building or in guix itself
<unmatched-paren>jpoiret: okay, thanks for the help
<unmatched-paren>jpoiret: it happens within guix itself
<jpoiret>hmmm, we do have iptables-service-type and nftables-service-type, so there's an analogue
<jpoiret>unmatched-paren: hmmmm
<jpoiret>forgot guix gexp?
<unmatched-paren>jpoiret: yes i did actually, thanks!
<jpoiret>weird that guile did not complain about a missing reader for #~
<jpoiret>does that work now?
<unmatched-paren>jpoiret: yeah (except that some of the required inputs are not defined, but that's easily fixed)
<nckx>nouun: Which firewall are you using?
<nckx>(Hai Guix.)
<unmatched-paren>hi nckx
***wielaard is now known as mjw
<jpoiret>hang on
<jpoiret>we don't have lei?
<nouun>jpoiret: Cheers, that worked.
<jpoiret>great! didn't expect that comment to be enough, but glad you worked it out
<nckx>jpoiret: Are you talking about Guix Europe…?
<jpoiret>no, lei as in the public-inbox fetcher
<nckx>Ha 😃
<jpoiret>quick, create the guix microstate
<nckx>Damn, no huge ‘anonymous’ donation incoming, eh…
<jpoiret>FTR: lei is in the new public-inbox committed 2 days ago
<jonsger[m]>nouun we have a nice firewall bitrotting in our backlog:
<f1refly>what are the requirements for thunar-volman? I have thunar and thunar-volman installed in my user profile and gvfs installed in my global profile, could that be an issue with thunar not recognizing gvfs?
<f1refly>Because currently it's telling my gvfs isn't installed and won't manage removable media.
<fnstudio>hi, sorry, but if i type "guix system image test.scm" i'm told that "image" is an "unknown action"
<fnstudio>i'm using guix on a foreign distro
<fnstudio>it's a debian where i apt installed guix
<nckx>Is your ‘guix’ ancient?
<fnstudio>probably... but i tried apt update / upgrade and that didn't help
<fnstudio>i also tried guix pull / package -u
<unmatched-paren>`guix` from debian's repos is ancient
<unmatched-paren>use `guix pull`'s guix
<unmatched-paren>and uninstall the `guix` from debian once you've done that
<nckx>Use ‘guix pull’ to update guix. Make sure ~/.config/current/bin is in $PATH.
<unmatched-paren>because it'll override the `guix pull` guix binary
<nckx>Debian doesn't really do updates AIUI.
<nckx>Not often.
<fnstudio>unmatched-paren, nckx: i see, i was a little bit scared of guix updating guix :D but yeah it makes sense, i'll do so, thank you very much!!
<unmatched-paren>the guix from debian is a convenient way to bootstrap it, i'll give them that
<nckx>f1refly: Could you file a bug? ‘guix shell --pure thunar dbus hicolor-icon-theme gdk-pixbuf gvfs thunar-volman -- thunar’ fails too.
<f1refly>ticket opened
<maximed>sneek: later tell nckx: is applied!
<sneek>Got it.
<apteryx>civodul: hi! it seems least-authority-wrapper is stricter than make+forkexec-constructor? It doesn't have access to /etc/passwd for example
<apteryx>e.g., I got: dbus[2]: Could not get password database information for UID of current process
<maximed>there appear to be only 45 non-library rust packages
<maximed>that's a lot less than what I'd have expected from the size of (gnu packages crates-io)
<unmatched-paren>maximed: there's also crates-graphics, rust-apps, and crates-gtk
<unmatched-paren>i suspect rust-apps has most of the non-library rust packages
<maximed>unmatched-paren: 45 includes the apps in crates-graphics, rust-apps, and crates-gtk -- it should include all the rust apps unless my counting script is wrong
<unmatched-paren>ah, ignore me then
<unmatched-paren>in that case that's pretty surprising for me too
<apteryx>well considering the average app requires 1,000,000 dependencies, that's not so surprising, no?
<maximed>tbf most of these dependencies are not used by a single app but (indirectly) by many apps
<maximed>though since Guix apparently doesn't package much rust apps, the number looks huge
<unmatched-paren>apteryx: yeah, but i was still expecting more rust apps. apparently i have not fully grasped the scale of rust's dependency problem.
<tribals>Hi, folks!
<apteryx>hmm... can someone advise on using make+forkexec-constructor with the #:user and #:group arguments + least-authority-wrapper? When I wrap dbus-daemon this way, it complains about not finding the user in the database
<unmatched-paren>tribals: \o
<apteryx>I tried exposing the whole /etc directory, but the problem persists
<apteryx>perhaps I need to specify the guest-uid and guest-gid arguments of least-authority-wrapper, with those matching the desired user/group from the host?
<apteryx>I didn't need to do this with make+forkexec-constructor/constructor though
<f1refly>if more rust applications where distributed the application-to-library rate would probably go up quickly
<apteryx>OK, setting #:guest-uid and #:guest-gid to 0 allowed dbus to start
<apteryx>so these args specify the user/group ids starting point to map in the container
<apteryx>are normal users always created in the 900+ uid range?
<apteryx>this suggests >= 500
<apteryx>OK, seems dbus-daemon is picky, it only works when I use #:guest-uid 0 and #:guest-gid 0
<tribals>What I need to do in order to get rid of "note: newer than compiled" message after each `git pull` of guix git repo?
<unmatched-paren>tribals: run make again
<gnoo>apteryx: so always running it as root
<unmatched-paren>if it doesn't work, make clean-go
<unmatched-paren>then run make
<apteryx>gnoo: no, it runs as 'jami:jami" the user/group specified in make-forkexec-constructor
<gnoo>but uid and gid being 0 is root, right?
<apteryx>yes, but these args of least-authority specify the IDs *mapped* in the container, not the ones used
<apteryx>the user/group used is rather chosen by the higher level make-forkexec-constructor
<apteryx>(to clarify what I'm doing, I'm adjusting the jami-dbus-session service to use make-forkexec-constructor + least-authority-wrapper instead of make-forkexec-constructor/container
<ham5urg>Has anyone used ldap for authenticating guix-clients? Any config.scm-examples (server, client) out there?
<rekado>I used ldap for accounts with Guix System. It’s been a long time since I’ve set this up, though.
<ham5urg>rekado, do you still have the scm files?
<tribals>unmatched-paren: thanks!
<tricon>tribals: did you get your Java build error resolved?
<leinad>Hi Guix! Is it possible to setup a database, like Postgres, that runs in a container using Guix' configuration mechanism and can be stopped and started as a regular user? How would you do this?
<tribals>tricon: No, still not
<tribals>I'm just trying to solve it by updating local guix repo to latest master
<tribals>Before I've updated "main" guix using `guix pull` - no luck :D
<tribals>Likely, it is not related ))
<unmatched-paren>anyone here do go and know what `go install` exiting with status 2 means?
<unmatched-paren>nvm, not important anymore
<unmatched-paren>okay, apparently it is.
<unmatched-paren>anyone notice anything suspicious here?
<jpoiret>unmatched-paren: if by suspicious you mean "are you getting 502s from" then yes
<unmatched-paren>jpoiret: no, that link was to the log from my failing build :)
<unmatched-paren>someone in #aerc found the problem anyway
<tribals>How could I refer to package's `outputs` in `copy-build-system` argument `#:install-plan`?
<tribals>Or even, do I need to?
<tribals>Or even, how to use `#:install-plan` to install files to output other than "out"?
<jpoiret>i don't think you can
<jpoiret>have you tried passing a full store path as a target?
<tribals>jpoiret: no, I don't know where to get one
<jpoiret>have you tried (string-append $output:my-output "/path/to/target")?
<tribals>Quick look at `copy-build-system.scm` told me there is no way to do that, so I used to define custom `'install` phase
<tribals>jpoiret: > have you tried (string-append ... Yes
<jpoiret>well then you did the right thing :)
<jpoiret>maybe an update to copy-build-system would be welcome
<tribals>Wait... No, I've tried `(assoc-ref #$output "my-custom-output")`, and package definition has `(outputs '("my-custom-output"))`
<jpoiret>no, outputs should be accessed via the special syntax #$output:my-output
<tribals>Will try that, minute...
<jpoiret>#$output is specific syntax, it doesn't try to use an output variable
<tribals>No, this doesn't work too, sadly
<pashencija[m]>Is it alright I cannot cross-compile perl-file-mimeinfo?
<pashencija[m]>test@guix_test ~$ guix build perl-file-mimeinfo --target=aarch64-linux-gnu
<pashencija[m]>guix build: error: gnu/packages/freedesktop.scm:1920:2: perl-file-mimeinfo@0.29: build system `perl' does not support cross builds
<unmatched-paren>i guess nobody's added cross-compilation to perl-build-system
<pashencija[m]>Is there a goal to get 100% of the packages cross-compile?
<pashencija[m]>Or just the base system so the packages can be built natively on the target machine?
<unmatched-paren>i don't think there's any explicit goal, though more packages being cross-compilable is always a good thing of course
<unmatched-paren>though... wouldn't the result of building something perly work on any machine?
<unmatched-paren>it's an interpreted language, after all
<pashencija[m]>The problem is that perl-file-mimeinfo is a dependency of dependency of dependency...
<jackhill>There's always builds in an emulated environment, but clearly cross-building has some effciency advantages there.
<unmatched-paren>i cannot make any sense of this build failure
<unmatched-paren>i'm sure there's an error somewhere in there, but >10000 lines are not exactly trivial to search through :P
<unmatched-paren>there is the cgo-gcc-prolog:347:2: warning: ‘notmuch_database_open’ is deprecated: function deprecated as of libnotmuch 5.4 [-Wdeprecated-declarations] warning
<unmatched-paren>but it's just that, a warning
<roptat>hi guix!
<roptat>I'm trying to install the guix system on a rockpi 4, it has the same processor as the rock64pro which is supposedly supported
<roptat>I managed to create a u-boot, install it and it boots the kernel and initrd, but it doesn't find the partition and I end up in the early guile repl
<roptat>I'm not sure, but aren't disks supposed to show up in /dev at this point of the boot?
<roptat>if so, it means I'm missing some modules, right?
<apteryx>would someone know how to set ulimit in a Guix container?
<roptat>no idea
<apteryx>dbus-daemon[2]: [session uid=0 pid=2] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
<pashencija[m]>roptat: Did you create an image with guix image ?
<roptat>pashencija[m], no I used "guix system init" from another distro
<roptat>installing from the SD card to the internal eMMC
<pashencija[m]>I recommend trying image API instead
<pashencija[m]>At least it helps you getting it to boot
<pashencija[m]>All you need is basically redefining kernel package (so it builds with correct defconfig) and uboot package (ditto)
<pashencija[m]>That should be enough to boot
<pashencija[m]>I have a Pinebook Pro here to test/check things is required
<roptat>pashencija[m], isn't that pretty much similar though?
<roptat>I can already boot on u-boot and the initrd
<roptat>so my question is more like what am I missing in my kernel?
<roptat>how would you modify your kernel package?
<pashencija[m]>What is your kernel package?
<pashencija[m]>Is it linux-libre with rockpi defconfig?
<roptat>it's the default linux-libre
<unmatched-paren>ah, i found the issue by searching using a regex for a line that looks like a Go compiler error
<roptat>I have another arm board where I use that kernel. I only had to specify a few modules to be added to the initrd
<pashencija[m]>roptat: Can you please show me the package definition?
<roptat>"guix edit linux-libre" should do it :)
<pashencija[m]>Did you try "linux-libre-arm64-generic"?
<pashencija[m]>Also, what uboot did you use?
<pashencija[m]>PBP uses modified package at u-boot-pinebook-pro-rk3399
<pashencija[m]>Did you do something like this for your board?
<pashencija[m]>I have not much experience porting GUIX to rockchip boards, but I have a port to raspberry pi here
<roptat>yes, I slightly modified the definition of another rk3399 board's u-boot
<GNUtoo>apteryx: hi, I think it works some of the time
<roptat>I haven't tried another kernel yet
<pashencija[m]>roptat: What about linux kernel? Did you try the one I mentioned?
<GNUtoo>When I tested it I saw this behavior but I tested it on a very old laptop so I though that it had some problem with the Ethernet
<GNUtoo>apteryx: It might not be related to h-client at all but it could instead be related to the server:
<GNUtoo>apteryx: btw, thanks a lot about having pinged me about h-client
<apteryx>yeah, I felt bad removing it from Guix due to Python 2 reliance, so I tried fixing it
<apteryx>hopefully it gets resolved soon!
<GNUtoo>I hope so too, I've installed Guix on a tablet, and I'd like to report what works and what doesn't
<GNUtoo>It also helps me understanding the FSDG status of more recent hardware as it's a bay trail tablet. Sound probably needs signed firmwares for instance.
<unmatched-paren>yay, aerc builds!
<unmatched-paren>and runs, even :P
<apteryx>unmatched-paren: well done!
<unmatched-paren>apteryx: thanks. i've been working on this one for some time, but always was defeated by the go-build-system :P
<unmatched-paren>Until now mwahahahaha
<unmatched-paren>...urgh "guix home: error: profile contains conflicting entries for go-github-com-gdamore-tcell
<unmatched-paren>my work is not done yet, apparently.
<unmatched-paren>oh, simple fix.
<unmatched-paren>what am i thinking of course it's not a simple fix.
<jpoiret>just configured a piem-based workflow, took a random patchset and applied it with a new branch all in 5 keystrokes
<unmatched-paren>aren't propagated inputs SOOO much fun!?
<jpoiret>we'll have to see how well it fares
<unmatched-paren>You get to deal with profile conflicts and everything! Buy tickets today at half price, free for kids!
<jackhill>unmatched-paren: as I understand it, go thinks of v1 and v2 package as different packages, so the different name feels appropriate.
<jackhill>question though: why does aerc need to propagate that?
<unmatched-paren>jackhill: ...ok you have a point
<unmatched-paren>since it's a binary
<unmatched-paren>jackhill: ok, i've updated it to remove my "workaround" and not propagate the inputs :)
<unmatched-paren>i should probably make a patch for guix main
<jackhill>unmatched-paren: cool, glad I could "help"
<jackhill>("help" becuase I think you did most of the work!) Happy to see it in guix main.
<unmatched-paren>jackhill: you did help :)
<unmatched-paren>without scare quotes
<jackhill>yay :)
<rekado>jpoiret: do you have pointers to that piem-based workflow?
<jpoiret>rekado: i'll have soon, when i finish ironing out everything
<jpoiret>i'm trying it out on some patches right now
<jpoiret>i'll review some
***mark_ is now known as mjw
<lechner>Hi, i statically define both ipv4 and ipv6 in static-networking-service-type but it seems to interfere with shepherd's networking service, which won't start and instead shows this error: Throw to key `%exception' with args `("#<&netlink-response-error errno: 17>")'. It blocks knot-dns from starting. Any ideas? Thanks!
<roptat>lechner, errno 17, that's "no such file or directory"
<roptat>maybe you specified an interface that doesn't exist?
<unmatched-paren>lechner: you can use `moreutils`'s `errno(1)` tool to figure out what an errno means
<roptat>er, no 17 is "file exists"
<roptat>(we should catch these exceptions and print better error messages...)
<roptat>lechner, can you share your static networking config?
<jpoiret>good old strerror
<civodul>i feel a bit ashamed, but i still don't understand how to use public-inbox
<mitchell>what is that?
<civodul>a tool that "stores email in git", among other things
<civodul>for instance, how do i clone ?
<jackhill>civodul: don't worry, I'm not sure I've fully grasped public-inbox either, but maybe this page woule help: ?
<civodul>jackhill: neat, thanks! (how did you find this page?)
<civodul>i ran those commands, and it gives me a directory with metadata it seems
<jackhill>one of my questions (alhtought maybe this is better asked in a different forum): how does public-inbox deal with removing messages, either spam that gets through the filters or messages that need to be removed for policy reaons. public-inbox-spam(1) says, in part, "The message remains accessible in git history." I understand that messages can't be erased from The Internet, but it would be nice to be able
<civodul>but no trace of email
<jackhill>to remove something from official record
<jackhill>civodul: in the second line of the page you posted " help / color / mirror / code / Atom feed"
<civodul>hmm yes?
<civodul>what should i see? :-)
*civodul feels dumb
<jackhill>civodul: I mean I just clicked on "mirror" to get to the page I linked that has the clone/mirroring instructions. I can't help beyond that I'm afraid. I'm trying to understand them too, but it seemed like it might help you
<civodul>oh got it, thanks
<civodul>i find rather unhelpful
<civodul>it tells me that as a participant, i can use email to write to a mailing list and i don't need public-inbox
<civodul>maybe the primarily goal of public-inbox is to provide that web interface + search engine?
<civodul>(which is already better than what runs)
<oriansj>civodul: I think you just described usenet
<civodul>public-inbox provides an NNTP gateway, so there's definitely a connection :-)
<oriansj>emacs gnus is a basic usenet client so...
<djeis>Is there a strategy for static networking with custom link settings on a physical network device? As far as I can tell the existing static-networking-service-type on master only lets you set link properties for a virtual network device. I suppose I could write a custom networking script that does the right calls to guile-netlink myself, but I want to make sure I haven't missed something obvious before I go that far.
<lechner>roptat: also about static networking,
<roptat>lechner, I don't see anything suspicious, except your default v6 route is not in your v6 prefix
<roptat>(I think you meant /56, but that's not what would cause the issue I think)
<jpoiret>civodul: from what i understand, public-inbox has tools to replicate/create/serve a public-inbox archive
<jpoiret>and lei (also from public-inbox) lets you interact with public-inboxes, either local or remote, and use searches
<roptat>lechner, maybe that was caused by eth0 already having a default route, or already having this IP set (either on v6 or on v4)
<roptat>is that possible?
<jpoiret>from the last 3 hours for me, i recommend piem's piem-lei-q to read
<jpoiret>it's not documented yet though but works pretty well
<roptat>djeis, you're right, you can only set settings on links you create, not on existing ones
<roptat>djeis, if you figure out a way to improve the service, please send a patch :)
<jackhill>I guess everyone has something different that they don't like about various collaboration schemes (I was at a conference last where github/gitlab workflows were difficult for new folks (context matters, these were people don't write code full time but where collaborating on some code other plain text files in git), but the think that I find most annoying about our workflow is that correcting small
<jackhill>mistakes/typos I make is much more of an effort than hitting edit/correct in a webapp
<jackhill>and the incorrect version causes more noise to other people looking at it.
<jpoiret>i'm still trying to figure out how to properly inject public-inbox threads into my MUA (notmuch)
<jackhill>jpoiret: where can one find piem?
<djeis>roptat: Yea I suppose the trouble there is... what do you do in the stop script to undo the settings.
<jpoiret>it's on elpa (it's an emacs package)
<jackhill>but not guix yet?
<jpoiret>i use straight.el, haven't migrated to using guix for my emacs packages yet
<jpoiret>it's planned though
<jpoiret>my 1kLOC init org file is gonna take a while to port though
<jackhill>even if I don't use piem, the documentation looks pretty helpful
<jackhill>ah, looks useful "incrementally add messages from public-inbox V1/V2 to a Maildir"
<jackhill>clearly we need guile-public-inbox :D
<jpoiret>lei does that and is included with public-inbox
<lechner>roptat: thanks for pointing out the prefix discrepancy! i'll try the larger subnet.
<lechner>roptat: as for the "file exists" I did notice some additional dhcp-type addresses that my debian install did not request. i'll have to experiment with that too
<roptat>lechner, maybe the default route already exists?
<roptat>if addresses were autoconfigured, I suppose the default route too?
<lechner>roptat: how could it?
<roptat>via router advertisement?
<roptat>I'm not sure what's supposed to listen to that though
<civodul>jpoiret: one thing i don't get: if i already use Gnus + debbugs.el, how's public-inbox or piem going to help?
<lechner>i have had this provider for many years. when i signed up, they did not offer any kind of dhcp and required a static setup. i assume they then bowed to public demand and provided automatic assigments except my antique Debian setup had dhcp disabled. then i installed Guix...
<lechner>roptat: ^
<lechner>roptat: it must just be the route. because the ip is definitely mine. i even provide my own reverse zone, which they delegated to me
<jpoiret>civodul: public-inbox lets u sift through guix-devel too, and other lists
<jpoiret>and the b4 integration is great
<jpoiret>i think that's the main selling point
<jpoiret>I do "C-z i a" on a thread and it applies the whole patch series using b4 + git am using a new branch
<jpoiret>until now i was subscribed to the MLs so this is a huge step up
<civodul>jpoiret: public-inbox as a server you mean?
<civodul>i'm not supposed to run it myself, am i?
<jpoiret>you can
<jpoiret>personally i mirrored it locally
<civodul>so what did you do?
<jpoiret>it's quite easy to do
<civodul>i pasted the commands from
<civodul>and that gives a bunch of files
<civodul>when i expected a Maildir-like structure
<jpoiret>i mirrored multiple archives
<jpoiret>oh no, public-inbox doesn't store anything as maildir
<jpoiret>if you want to extract things into a maildir, that's where you use a client like lei
<civodul>hmm ok
<jpoiret>but you can also browse it directly using piem-lei-q for example
<jpoiret>so that you don't have to convert to maildir first
<civodul>let's forget about piem lei whatever for now :-)
<civodul>the commands at gave me 220K of files
<civodul>what am i supposed to do with that?
<civodul>i feel like i'm missing something important
<oriansj>I guess most people don't know about:
<jpoiret>civodul: public-inboxes are basically git repos
<roptat>lechner, I don't know... you're not supposed to have dhcp with static-networking
<jpoiret>each commit == a mail iiuc
<apteryx>civodul: howdy! I'm trying to adapt the jami service to least-authority, and it's proving challenging for some reasons
<lechner>roptat: you are on to something. the error goes away (and networking starts plus dependent services) when i remove the ipv6 default route, but it stays when i remove the ipv4 default route. unfortunately, without the ipv6 default route declared, that route is also gone
<apteryx>I'm trying to see what is done differently between make-forkexec-constructor/container and least-authority-wrapper
<roptat>lechner, so I guess you need to figure out what is causing this default route to be added before static-networking does its magic
<civodul>apteryx: the defaults in least-authority-wrapper are a bit stricter
<apteryx>one thing I've discovered is that least-authority uses 7 namespaces, while make-forkexec-constructor(/container) drops the 'net and 'user ones
<civodul>also, individual store items are shared, as opposed to the whole store
<apteryx>If I try adding back the 'user namespace, I get: guix/build/syscalls.scm:1099:12: In procedure clone: 771883025: Operation not permitted
<apteryx>I mean, removing it
<apteryx>dbus-daemon will also only run if I use #:guest-uid 0 and #:guest-gid 0 arguments; I don't really understand the relationship between make-forexec-constructor's user and group arguments vs least-authority-wrapper's guest-uid and guest-gid ones?
<civodul>make-forkexec-constructor #:user and #:group are the actual user/group under which the process executes
<civodul>where #:guest-{uid,gid} are the UID/GID used inside that separate user namespace
<civodul>the process can have UID 0 within the namespace, mapped to UID 1234 outside
<apteryx>OK, so inside the container the process would think it's running as root, but that's only true inside the container?
<civodul>right it's not running as root at all, but what it sees is that it has UID 0
<apteryx>another new problem that appears is this: dbus-daemon[2]: [session uid=0 pid=2] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
<apteryx>I don't really get it -- ulimit -H returns 'unlimited'
<maximed>apteryx: FWIW dbus-daemon and the process from which you ran ulimit might have a different ulimit
<maximed>they are process-specific (and inherited by subprocesses) IIUC
<apteryx>I ran my test like so: (run-container "/" '() %namespaces 1 (lambda () (system "ulimit -H > /tmp/ulimit")))
<maximed>apteryx: what does (system "ulimit -H -n") say?
<maximed>E.g. on my system "ulimit -H -n" (ouside the container) returns 1048576
<maximed>whereas without the "-n" it returns unlimited
<maximed>(-n = open files)
<maximed>by default, it uses ‘the maximum size of files written by the shell and its children’ (according to "help ulimit)
<maximed>which doesn't seem to be what you want here?
<apteryx>maximed: it says 4096
<apteryx>I think the issue is dbus trying to set a bunch of limits itself, and failing due to X
<apteryx>(the same application works when using mark-forexec-constructor/container instead of mark-forexec-constructor + least-authority-wrapper
<apteryx>the reason could be the use of the user namespace when using least-authority-wrapper (it's dropped when using make-forexec-constructor/container)
<civodul>hmm yes, could be
<apteryx>repro of he clone 'operation not permitted' issue: (run-container "/" '() (fold delq %namespaces '(net user)) 1 (lambda () (system "true")))
<apteryx>or even just: (run-container "/" '() (delq 'user %namespaces) 1 (lambda () (system "true")))
<civodul>"/" doesn't seem like a good idea (it should be the root directory for the container)
<lechner>roptat: does the static service maybe conflict with something in %base-services that i should subtract out?
<civodul>run-container is pretty low-level though; better use call-with-container
<apteryx>the issue exists also in the actual service (making use of make-forkexec-constructor + least-authority-wrapper) though, where directory would consider HOME and the user /etc/passwd home directory
<civodul>my mind is fuzzy, but i suspect we're overlooking something
<apteryx>ah, the default directory of least-authority-wrapper is '/'
<civodul>ah yes
<roptat>lechner, I don't know
<civodul>and environment variables are all cleared by default
<civodul>apteryx: ↑
<apteryx>except for "HOME" "USER" "LOGNAME" "DISPLAY" "XAUTHORITY" "TERM" "TZ" "PAGER" (%precious-variables)
<apteryx>but if you specify one it's easy to override that default
<apteryx>eh, still getting this:
<nckx>sneek: later tell maximed: Thanks! I've switched the Cuirass URL back to yours. Have fun. It polls every 15 minutes. HMU if that needs to be tweaked.
<sneek>nckx, you have 1 message!
<sneek>nckx, maximed says: is applied!
<sneek>Got it.
<apteryx>with this experiment:
<apteryx>I have to go; thanks for entertaining the discussion!